Compartir a través de

Cuentas de servicio de directorio para Microsoft Defender for Identity

  • Artículo

En este artículo se describe cómo Microsoft Defender for Identity usa cuentas de servicio de directorio (DSA).

Nota:

Independientemente de las cuentas de servicio de directorio configuradas, el servicio de sensor funcionará en la identidad LocalService y el servicio del actualizador funcionará con la identidad localSystem.

Aunque una DSA es opcional en algunos escenarios, se recomienda configurar una DSA para Defender for Identity con el objetivo de obtener una cobertura de seguridad completa.

Por ejemplo, cuando tiene una DSA configurada, la DSA se usa para conectarse al controlador de dominio en el inicio. También se puede usar una DSA para consultar al controlador de dominio los datos de las entidades que se ven en el tráfico de red, los eventos supervisados y las actividades ETW supervisadas.

Se requiere una DSA para las siguientes características y funcionalidades:

  • Cuando se trabaja con un sensor instalado en un servidor de AD FS/AD CS.

  • Solicitud de listas de miembros para grupos de administradores locales desde dispositivos vistos en el tráfico de red, eventos y actividades ETW a través de una llamada SAM-R realizada al dispositivo. Los datos recopilados se usan para calcular posibles rutas de desplazamiento lateral.

  • Acceso al contenedor Objetos eliminados para recopilar información sobre los usuarios y equipos eliminados.

  • Asignación de dominio y confianza, que se produce cuando el sensor se inicia y de nuevo cada 10 minutos.

  • Al detectar actividades de entidades en esos otros dominios, consultar otro dominio a través de LDAP para obtener más información.

Cuando se usa una única DSA, la DSA debe tener permisos de lectura para todos los dominios de los bosques. En un entorno de varios bosques que no es de confianza se requiere una cuenta de DSA para cada bosque.

Un sensor en cada dominio se define como el sincronizador de dominio y es responsable de realizar un seguimiento de los cambios en las entidades del dominio. Por ejemplo, los cambios pueden incluir objetos creados, atributos de entidad de los que realiza el seguimiento Defender for Identity, etc.

Nota:

De forma predeterminada, Defender for Identity admite hasta 30 credenciales. Para agregar más credenciales, póngase en contacto con el soporte técnico de Defender for Identity.

Opciones de cuenta de DSA admitidas

Defender for Identity admite las siguientes opciones de DSA:

Opción Descripción Configuración
Cuenta de servicio administrada de grupo (gMSA). (recomendado) Proporciona una implementación y administración de contraseñas más segura. Active Directory administra la creación y rotación de la contraseña de la cuenta, al igual que la contraseña de una cuenta de equipo, y puede controlar la frecuencia con la que se cambia la contraseña de la cuenta. Para obtener más información, consulte Configuración de una cuenta de servicio de directorio para Defender for Identity con una gMSA.
Cuenta de usuario regular Es fácil de usar al inicio y más simple para configurar permisos de lectura entre bosques de confianza, pero requiere una sobrecarga adicional para la administración de contraseñas.

Una cuenta de usuario normal es menos segura, ya que requiere que cree y administre contraseñas, y puede provocar tiempo de inactividad si la contraseña expira y no se actualiza, tanto para el usuario como para el DSA.		 Cree una cuenta en Active Directory para usarla como DSA con permisos de lectura para todos los objetos, incluidos los permisos para el contenedor DeletedObjects. Para más información, consulte Otorgar permisos necesarios para DSA.
Cuenta de servicio local La cuenta de servicio local se puede usar de inmediato y se usa de forma predeterminada cuando no hay ninguna DSA configurada.
Nota:
  • Las consultas SAM-R para posibles rutas de desplazamiento lateral no se admiten en este escenario.
  • Las consultas LDAP solo se admiten dentro del dominio que el sensor está instalado. Se producirá un error en las consultas a otros dominios del mismo bosque o bosque cruzado.
    		•  None

    Nota:

    Aunque la cuenta de servicio local se usa con el sensor de forma predeterminada y una DSA es opcional en algunos escenarios, se recomienda configurar una DSA para Defender for Identity para una cobertura de seguridad completa.

    Uso de entradas de DSA

    En esta sección se describe cómo usar las entradas de DSA y cómo seleccionar el sensor una entrada de DSA en cualquier escenario determinado. Los intentos de sensor difieren, en función del tipo de entrada de DSA:

    Tipo Descripción
    Cuenta de gMSA El sensor intenta recuperar la contraseña de la cuenta gMSA de Active Directory y, a continuación, inicia sesión en el dominio.
    Cuenta de usuario regular El sensor intenta iniciar sesión en el dominio mediante el nombre de usuario y la contraseña configurados.

    Se aplica la siguiente lógica:

    1. El sensor busca una entrada con una coincidencia exacta del nombre de dominio para el dominio de destino. Si se encuentra una coincidencia exacta, el sensor intenta autenticarse con las credenciales de esa entrada.

    2. Si no hay una coincidencia exacta o si se produjo un error en la autenticación, el sensor busca una entrada en el dominio primario mediante el FQDN de DNS e intenta autenticarse con las credenciales de la entrada primaria en su lugar.

    3. Si no hay una entrada para el dominio primario o si se produjo un error en la autenticación, el sensor busca en la lista una entrada de dominio del mismo nivel, mediante el FQDN de DNS, e intenta autenticarse con las credenciales de la entrada del mismo nivel en su lugar.

    4. Si no hay ninguna entrada para el dominio del mismo nivel o si se produjo un error en la autenticación, el sensor vuelve a revisar la lista e intenta volver a autenticarse con cada entrada hasta que se realice correctamente. Las entradas de gMSA de DSA tienen mayor prioridad que las entradas de DSA regulares.

    Ejemplo de lógica de un DSA

    En esta sección se proporciona un ejemplo de cómo el sensor prueba el DSA completo cuando tiene varias cuentas, incluida una cuenta gMSA y una cuenta normal.

    Se aplica la siguiente lógica:

    1. El sensor busca una coincidencia entre el nombre de dominio DNS del dominio de destino, como emea.contoso.com y la entrada de gMSA de DSA, como emea.contoso.com.

    2. El sensor busca una coincidencia entre el nombre de dominio DNS del dominio de destino, como emea.contoso.com y la entrada normal de DSA, como emea.contoso.com

    3. El sensor busca una coincidencia en el nombre DNS raíz del dominio de destino, como emea.contoso.com y el nombre de dominio de entrada de gMSA de DSA, como contoso.com.

    4. El sensor busca una coincidencia en el nombre DNS raíz del dominio de destino, como emea.contoso.com y el nombre de dominio de entrada normal de DSA, como contoso.com.

    5. El sensor busca el nombre de dominio de destino para un dominio relacionado, como emea.contoso.com y el nombre de dominio de entrada de gMSA de DSA, como apac.contoso.com.

    6. El sensor busca el nombre de dominio de destino para un dominio relacionado, como emea.contoso.com y el nombre de dominio de entrada normal de DSA, como apac.contoso.com.

    7. El sensor ejecuta un todos contra todos de todas las entradas de gMSA de DSA.

    8. El sensor ejecuta un todos contra todos de todas las entradas regulares de DSA.

    La lógica de este ejemplo se implementa con la siguiente configuración:

    • Entradas de DSA:

      • DSA1.emea.contoso.com
      • DSA2.fabrikam.com

    • Sensores y la entrada de DSA que se usa primero:

      Nombre de dominio completo del controlador de dominio Entrada de DSA usada
      DC01.emea.contoso.com DSA1.emea.contoso.com
      DC02.contoso.com DSA1.emea.contoso.com
      DC03.fabrikam.com DSA2.fabrikam.com
      DC04.contoso.local Round robin

    Importante

    Si un sensor no puede autenticarse correctamente a través de LDAP en el dominio de Active Directory al iniciarse, el sensor no entrará en estado en ejecución y se generará un problema de mantenimiento. Para más información, consulte Problemas de funcionamiento de Defender for Identity.

    Otorgar permisos de DSA requeridos

    La DSA requiere permisos de solo lectura en todos los objetos de Active Directory, incluido el Contenedor de objetos eliminados.

    Los permisos de solo lectura en el contenedor Objetos eliminados permiten que Defender for Identity detecte eliminaciones de usuarios de Active Directory.

    Use el ejemplo de código siguiente para ayudarse a conceder los permisos de lectura necesarios en el contenedor Objetos eliminados, independientemente de si usa o no una cuenta de gMSA.

    Sugerencia

    Si la DSA a la que desea conceder los permisos es una Cuenta de servicio administrada de grupo (gMSA), primero debe crear un grupo de seguridad, agregar la gMSA como miembro y agregar los permisos a ese grupo. Para obtener más información, consulte Configuración de una cuenta de servicio de directorio para Defender for Identity con una gMSA.

    # Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'

# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
    $groupParams = @{
        Name           = $groupName
        SamAccountName = $groupName
        DisplayName    = $groupName
        GroupCategory  = 'Security'
        GroupScope     = 'Universal'
        Description    = $groupDescription
    }
    $group = New-ADGroup @groupParams -PassThru
    Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
    $Identity = $group.Name
}

# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName

# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params

# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
  
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params

    Para obtener más información, consulte Cambio de permisos en un contenedor de objetos eliminados.

    Prueba de los permisos y delegaciones de DSA a través de PowerShell

    Use el siguiente comando de PowerShell para comprobar que la DSA no tiene demasiados permisos, como permisos de administrador eficaces:

    Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]

    Por ejemplo, para comprobar los permisos de la cuenta mdiSvc01 y proporcionar detalles completos, ejecute:

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    Para obtener más información, consulte Referencia de PowerShell DefenderForIdentity.

    Paso siguiente

    Configurar una Cuenta de servicio de directorio para Defender for Identity con una gMSA »