Cuentas de servicio de directorio para Microsoft Defender for Identity

Los sensores de Defender for Identity v2.x utilizan Cuentas de Servicio de Directorio (DSA) para leer datos de Active Directory, como consultar objetos, rastrear cambios y resolver entidades específicas. Esto es independiente de la cuenta de acción, que realiza acciones de corrección, como deshabilitar usuarios o restablecer contraseñas.

Para sensores v2.x, un DSA es opcional en algunos casos, pero recomendamos configurarlo para cubrir la seguridad completa.

Por ejemplo, cuando tiene una DSA configurada, la DSA se usa para conectarse al controlador de dominio en el inicio. Una DSA también puede utilizarse para consultar al controlador de dominio datos sobre entidades vistas en el tráfico de red, eventos monitorizados y actividades ETW monitorizadas.

Para sensor v2.x, se requiere un DSA para las siguientes características y funcionalidades:

• Al trabajar con un sensor instalado en un servidor de AD FS, AD CS o Microsoft Entra Connect.

• Solicitar listas de miembros de los grupos de administradores locales a partir de los dispositivos detectados en el tráfico de red, los eventos y las actividades de ETW mediante una llamada SAM-R realizada al dispositivo.

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

• Asignación de dominios y relaciones de confianza, que se produce al iniciar el sensor y de nuevo cada 10 minutos.

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

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 DSA para cada bosque.

Un sensor en cada dominio actúa como sincronizador de dominio y rastrea los cambios en las entidades del dominio, como nuevos objetos y cambios en atributos de entidades.

Opciones de cuenta de DSA admitidas

Para sensores v2.x, Defender for Identity soporta las siguientes opciones DSA:

Uso de entradas de DSA

Un sensor v2.x selecciona una entrada DSA basada en el dominio de destino y las credenciales configuradas. Los intentos de autenticación varían según el tipo 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 de autenticación, el sensor busca en la lista 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, con el FQDN DNS, e intenta autenticarse con las credenciales de la entrada del mismo nivel en su lugar.

4. Si no hay una 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 autenticarse de nuevo con cada entrada hasta que se realice correctamente. Las entradas gMSA de DSA tienen mayor prioridad que las entradas de DSA normales.

Lógica de ejemplo con un DSA

El siguiente ejemplo muestra cómo el sensor intenta las entradas DSA cuando configuras tanto un gMSA como 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 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 DSA normal, 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 recorre de forma rotativa todas las entradas gMSA de DSA.

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

La lógica que se muestra en 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 utiliza primero:

  FQDN 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	Torneo en sistema de liguilla

Conceder los permisos de DSA necesarios

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 a Defender for Identity detectar eliminaciones de usuarios de Active Directory.

Use el ejemplo de código siguiente para ayudarle 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 tus permisos y delegaciones de DSA mediante 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 la referencia de PowerShell de DefenderForIdentity.

Paso siguiente