Cuentas de servicio de directorio para Microsoft Defender for Identity

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

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.

Opciones de cuenta de DSA admitidas

Defender for Identity admite las siguientes opciones de DSA:

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:

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

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.

# 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