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 las cuentas de servicio de directorio (DSA).

Nota:

Independientemente de las cuentas de servicio de directorio configuradas, el servicio de sensor funcionará con la identidad LocalService y el servicio de actualización funcionará con la identidad localSystem.

Aunque una DSA es opcional en algunos escenarios, se recomienda configurar una DSA para Defender for Identity para 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 un 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 de ETW supervisadas.

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

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

  • Solicitar 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 DeletedObjects para recopilar información sobre usuarios y equipos eliminados.

  • Asignación de dominio y 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 de cada dominio se define como sincronizador de dominio y es responsable del seguimiento de los cambios en las entidades del dominio. Por ejemplo, los cambios pueden incluir objetos creados, atributos de entidad cuyo seguimiento realiza 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
GMSA de cuenta de servicio administrada de grupo (recomendado) Proporciona una implementación más segura y administración de contraseñas. 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, vea Configurar una cuenta de servicio de directorio para Defender for Identity con una gMSA.
Cuenta de usuario normal Fácil de usar al empezar y más sencillo de 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 un tiempo de inactividad si la contraseña expira y no se actualiza tanto para el usuario como para 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 obtener más información, consulte Concesión de permisos DSA necesarios.
Cuenta de servicio local La cuenta de servicio local se usa de forma predeterminada cuando no hay ningún DSA configurado.
Note:
  • Las consultas SAM-R para posibles rutas de desplazamiento lateral no se admiten en este escenario.
  • Las consultas LDAP solo se encuentran dentro del dominio en el que está instalado el sensor. Se producirá un error en las consultas a otros dominios del mismo bosque o entre bosques.
    		•  Ninguno

    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 se usan las entradas DSA y cómo el sensor selecciona una entrada DSA en cualquier escenario determinado. Los intentos del sensor difieren, dependiendo del tipo de entrada DSA:

    Tipo Descripción
    Cuenta de gMSA El sensor intenta recuperar la contraseña de la cuenta de gMSA de Active Directory y, a continuación, inicia sesión en el dominio.
    Cuenta de usuario normal El sensor intenta iniciar sesión en el dominio con 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 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 de gMSA de DSA tienen mayor prioridad que las entradas de DSA normales.

    Lógica de ejemplo con un DSA

    En esta sección se proporciona un ejemplo de cómo el sensor prueba la totalidad de DSA 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 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 DSA de entrada regular 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 round robin de todas las entradas de gMSA de DSA.

    8. El sensor ejecuta un round robin 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 DSA que se usa 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 Round robin

    Importante

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

    Concesión de 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.

    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, vea Configurar 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 la referencia de PowerShell DefenderForIdentity.

    Paso siguiente

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