Compartir vía

Solución de problemas: protección de contraseñas de Microsoft Entra local

  • Artículo

Después de la implementación de Protección con contraseña de Microsoft Entra, es posible que se requiera la solución de problemas. En este artículo se detallan detalles para ayudarle a comprender algunos pasos comunes de solución de problemas.

El agente de controlador de dominio no puede localizar un proxy en el directorio

El síntoma principal de este problema son eventos 30 017 en el registro de eventos de administración del agente de controlador de dominio.

La causa habitual de este problema es que no se ha registrado un proxy. Si se registra un proxy, puede haber algún retraso debido a la latencia de replicación de AD hasta que un agente de un controlador de dominio determinado pueda ver ese proxy.

El agente del DC no puede comunicarse con un proxy

El síntoma principal de este problema son eventos 30 018 en el registro de eventos de administración del agente de controlador de dominio. Este problema puede tener varias causas posibles:

  • El agente de controlador de dominio se encuentra en una parte aislada de la red que no permite la conectividad de red con el proxy registrado. Este problema puede ser benigno siempre que otros agentes de controlador de dominio puedan comunicarse con los proxy para descargar directivas de contraseña de Azure. Una vez descargados, el controlador de dominio aislado obtiene esas directivas mediante la replicación de los archivos de directiva en el recurso compartido sysvol.

  • El equipo host de proxy está bloqueando el acceso para el punto de conexión del mapeador del punto de conexión de RPC (puerto 135)

    El instalador del proxy de protección con contraseña de Microsoft Entra crea automáticamente una regla de entrada del Firewall de Windows que permite el acceso al puerto 135. Si esta regla se elimina o deshabilita posteriormente, los agentes de controlador de dominio no pueden comunicarse con el servicio proxy. Si el Firewall de Windows integrado está deshabilitado en lugar de otro producto de firewall, debe configurar ese firewall para permitir el acceso al puerto 135.

  • La máquina host de proxy está bloqueando el acceso al punto de conexión de RPC (dinámico o estático) que escucha el servicio de proxy

    El instalador del Proxy de Protección de Contraseñas de Microsoft Entra crea automáticamente una regla de entrada en el Firewall de Windows que permite el acceso a todos los puertos entrantes a los que el servicio Proxy de Protección de Contraseñas de Microsoft Entra escucha. Si esta regla se elimina o deshabilita posteriormente, los agentes de controlador de dominio no pueden comunicarse con el servicio proxy. Si el Firewall de Windows integrado está deshabilitado en favor de otro producto de firewall, debe configurar ese firewall para permitir el acceso a cualquier puerto de entrada que sean escuchados por el servicio de proxy de protección de contraseñas de Microsoft Entra. Esta configuración puede ser más específica si el servicio proxy está configurado para escuchar en un puerto RPC estático específico (mediante el cmdlet Set-AzureADPasswordProtectionProxyConfiguration).

  • La máquina host proxy no está configurada para permitir que los controladores de dominio puedan iniciar sesión en la máquina. Este comportamiento se controla a través de la asignación de privilegios de usuario "Acceder a este equipo desde la red". Todos los controladores de dominio de todos los dominios del bosque deben concederse este privilegio. Esta configuración suele restringirse como parte de un esfuerzo de protección de red mayor.

El servicio proxy no puede comunicarse con Azure

  1. Asegúrese de que la máquina proxy tiene conectividad con los puntos de conexión enumerados en los requisitos de implementación de .

  2. Asegúrese de que el bosque y todos los servidores proxy estén registrados en el mismo cliente de Azure.

    Para comprobar este requisito, ejecute el Get-AzureADPasswordProtectionProxy y Get-AzureADPasswordProtectionDCAgent cmdlets de PowerShell y, a continuación, compare la propiedad AzureTenant de cada elemento devuelto. Para un funcionamiento correcto, el nombre del inquilino informado debe ser el mismo en todos los controladores de dominio y servidores proxy.

    Si existe una condición de desajuste de registro de tenant de Azure, este problema se puede corregir ejecutando los cmdlets de PowerShell Register-AzureADPasswordProtectionProxy y/o Register-AzureADPasswordProtectionForest según sea necesario, asegurándose de usar credenciales del mismo tenant de Azure para todos los registros.

El agente de controlador de dominio no puede cifrar o descifrar archivos de directiva de contraseñas

La protección con contraseña de Microsoft Entra depende de la funcionalidad de cifrado y descifrado proporcionada por el servicio de distribución de claves de Microsoft. Los errores de cifrado o descifrado pueden manifestarse con varios síntomas y tienen varias causas potenciales.

  • Asegúrese de que el servicio KDS está habilitado y funcional en todos los controladores de dominio de Windows Server 2012 y versiones posteriores en un dominio.

    De forma predeterminada, el modo de inicio del servicio KDS está configurado como Manual (Inicio del desencadenador). Esta configuración significa que la primera vez que un cliente intenta usar el servicio, se inicia a petición. Este modo de inicio de servicio predeterminado es aceptable para que la protección con contraseña de Microsoft Entra funcione.

    Si el modo de inicio del servicio KDS está configurado en Deshabilitado, esta configuración debe corregirse para que La protección con contraseña de Microsoft Entra pueda funcionar correctamente.

    Una prueba sencilla para este problema es iniciar manualmente el servicio KDS, ya sea a través de la consola de MMC de administración de servicios o mediante otras herramientas de administración (por ejemplo, ejecutar "net start kdssvc" desde una consola de comandos). Se espera que el servicio KDS se inicie correctamente y siga ejecutándose.

    La causa principal más común para que el servicio KDS no se pueda iniciar es que el objeto de controlador de dominio de Active Directory se encuentra fuera de la unidad organizativa predeterminada controladores de dominio. Esta configuración no es compatible con el servicio KDS y no es una limitación impuesta por la protección con contraseña de Microsoft Entra. La solución para esta condición consiste en mover el objeto del controlador de dominio a una ubicación en la unidad organizativa de controladores de dominio predeterminada.

  • Cambio de formato incompatible del búfer cifrado KDS de Windows Server 2012 R2 a Windows Server 2016

    Se introdujo una corrección de seguridad KDS en Windows Server 2016 que modifica el formato de búferes cifrados KDS. A veces, estos búferes no se pueden descifrar en Windows Server 2012 y Windows Server 2012 R2. La dirección contraria está bien. Los búferes que están cifrados con KDS en Windows Server 2012 y Windows Server 2012 R2 siempre se descifran exitosamente en Windows Server 2016 y versiones posteriores. Si los controladores de dominio de los dominios de Active Directory ejecutan una combinación de estos sistemas operativos, es posible que se notifiquen errores ocasionales de descifrado de protección con contraseña de Microsoft Entra. No es posible predecir con precisión el tiempo o los síntomas de estos errores dada la naturaleza de la corrección de seguridad. Además, dado que no es determinista qué agente de controlador de dominio de protección de contraseñas de Microsoft Entra cifra los datos en un momento dado.

    No hay ninguna solución alternativa para este problema que no sea ejecutar una combinación de estos sistemas operativos incompatibles en los dominios de Active Directory. En otras palabras, solo debe ejecutar controladores de dominio de Windows Server 2012 y Windows Server 2012 R2, O bien solo debe ejecutar Controladores de dominio de Windows Server 2016 y versiones posteriores.

El agente del controlador de dominio considera que el bosque no se ha registrado.

El síntoma de este problema es que se registran 30.016 eventos en el canal del Agente DC\Administrador que indican, en parte:

The forest hasn't been registered with Azure. Password policies can't be downloaded from Azure unless this is corrected.

Hay dos causas posibles de este problema.

  • El bosque no se ha registrado. Para resolver el problema, ejecute el comando Register-AzureADPasswordProtectionForest como se describe en los requisitos de implementación de .
  • El bosque está registrado, pero el agente DC no puede descifrar los datos de registro del bosque. Este caso tiene la misma causa principal que el problema número 2 indicado anteriormente en El agente del DC no puede cifrar o descifrar los archivos de directivas de contraseñas. Una manera fácil de confirmar esta teoría es ver que este error solo aparece en agentes DC que se ejecutan en controladores de dominio con Windows Server 2012 o Windows Server 2012R2, mientras que los agentes DC que se ejecutan en los controladores de dominio de Windows Server 2016 y versiones posteriores funcionan correctamente. La solución alternativa es la misma: actualice todos los controladores de dominio a Windows Server 2016 o posterior.

Se aceptan contraseñas no seguras, pero no deberían ser aceptadas

Este problema puede tener varias causas.

  • Tus agentes DC están ejecutando una versión de software preliminar pública que ha expirado. Consulte El software de los agentes de controlador de dominio de versión preliminar pública expiró.

  • Los agentes de controlador de dominio no pueden descargar una directiva o no pueden descifrar las directivas existentes. Compruebe si hay posibles causas en los artículos anteriores.

  • El modo Exigir de la directiva de contraseñas sigue establecido en Auditoría. Si esta configuración está aplicada, vuelva a configurarla en Exigir con el portal de protección de contraseñas de Microsoft Entra. Para obtener más información, vea Modos de operación.

  • La directiva de contraseña está deshabilitada. Si esta configuración está en vigor, vuelva a configurarla para habilitarla mediante el portal de protección con contraseña de Microsoft Entra. Para obtener más información, vea Modos de operación.

  • No ha instalado el software del agente DC en todos los controladores del dominio. En esta situación, es difícil asegurarse de que los clientes remotos de Windows tienen como destino un controlador de dominio determinado durante una operación de cambio de contraseña. Si cree que se ha dirigido correctamente a un controlador de dominio determinado en el que está instalado el software del agente de controlador de dominio, puede comprobarlo mediante la comprobación doble del registro de eventos de administración del agente de controlador de dominio: independientemente del resultado, hay al menos un evento para documentar el resultado de la validación de contraseñas. Si no hay ningún evento presente para el usuario cuya contraseña se cambia, es probable que un controlador de dominio diferente procese el cambio de contraseña.

    Como una prueba alternativa, intente configurar/cambiar contraseñas al iniciar sesión directamente en un controlador de dominio donde esté instalado el software del agente de controlador de dominio. Esta técnica no se recomienda para dominios de Active Directory de producción.

    Aunque se admite la implementación incremental del software del agente de controlador de dominio sujeto a estas limitaciones, Microsoft recomienda encarecidamente que el software del agente de controlador de dominio esté instalado en todos los controladores de dominio de un dominio lo antes posible.

  • El algoritmo de validación de contraseñas puede funcionar realmente según lo previsto. Consulte ¿Cómo se evalúan las contraseñas.

Ntdsutil.exe falla al establecer una contraseña DSRM débil

Active Directory siempre valida una nueva contraseña del modo de reparación de servicios de directorio para asegurarse de que cumple los requisitos de complejidad de la contraseña del dominio; esta validación también llama a archivos DLL de filtro de contraseña como protección con contraseña de Microsoft Entra. Si se rechaza la nueva contraseña DSRM, se produce el siguiente mensaje de error:

C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
        WIN32 Error Code: 0xa91
        Error Message: Password doesn't meet the requirements of the filter dll's

Cuando Microsoft Entra Password Protection registra eventos de validación de contraseñas para una contraseña DSRM de Active Directory, se espera que los mensajes del registro de eventos no incluyan un nombre de usuario. Este comportamiento se produce porque la cuenta DSRM es una cuenta local que no forma parte del dominio real de Active Directory.

La promoción de réplica del controlador de dominio falla debido a una contraseña DSRM débil

Durante el proceso de promoción del controlador de dominio, la nueva contraseña del modo de reparación de servicios de directorio se envía a un controlador de dominio existente en el dominio para la validación. Si se rechaza la nueva contraseña DSRM, se produce el siguiente mensaje de error:

Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password doesn't meet a requirement of the password filter(s). Supply a suitable password.

Al igual que en el número anterior, cualquier evento de resultado de validación de la contraseña de la protección de contraseñas de Microsoft Entra tendrá nombres de usuario vacíos para este escenario.

Se produce un error de degradación del controlador de dominio debido a una contraseña de administrador local no segura

Se admite la degradación de un controlador de dominio en el que todavía se ejecuta el software del agente de controlador de dominio. No obstante, los administradores deben tener en cuenta que el software del agente de controlador de dominio sigue aplicando la directiva de contraseñas actual durante el procedimiento de degradación. La nueva contraseña de cuenta de administrador local (especificada como parte de la operación de degradación) se valida como cualquier otra contraseña. Microsoft recomienda que se elijan contraseñas seguras para las cuentas de administrador locales como parte de un procedimiento de degradación del controlador de dominio.

Una vez que la degradación se realiza correctamente y el controlador de dominio se reinicia y vuelve a ejecutarse como servidor miembro normal, el software del agente de controlador de dominio vuelve a ejecutarse en modo pasivo. Después, se puede desinstalar en cualquier momento.

Iniciando en modo de reparación de servicios de directorio

Si el controlador de dominio se inicia en modo de reparación de servicios de directorio, el archivo dll del filtro de contraseñas del agente de controlador de dominio detecta esta condición y hace que todas las actividades de validación o aplicación de contraseñas estén deshabilitadas, independientemente de la configuración de directiva activa actualmente. El archivo DLL del filtro de contraseña del agente DC registra un evento de advertencia 10023 en el registro de eventos del Administrador, por ejemplo:

The password filter dll is loaded but the machine appears to be a domain controller that is booted into Directory Services Repair Mode. All password change and set requests are automatically approved. No further messages are logged until after the next reboot.

El software de los agentes de controlador de dominio de versión preliminar pública expiró

Durante el período de versión preliminar pública de Protección con contraseña de Microsoft Entra, el software del agente de controlador de dominio estaba codificado de forma rígida para detener el procesamiento de solicitudes de validación de contraseñas en las fechas siguientes:

  • La versión 1.2.65.0 detuvo el procesamiento de solicitudes de validación de contraseña el 1 de septiembre de 2019.
  • La versión 1.2.25.0 y anteriores dejaron de procesar solicitudes de validación de contraseña el 1 de julio de 2019.

A medida que se aproxima la fecha límite, todas las versiones de agentes de controlador de dominio con límite de tiempo emiten un evento 10021 en el registro de eventos de administración del agente de controlador de dominio durante el arranque que tienen un aspecto similar al siguiente:

The password filter dll has successfully loaded and initialized.

The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll no longer processes passwords. Please contact Microsoft for a newer supported version of the software.

Expiration date:  9/01/2019 0:00:00 AM

This message won't be repeated until the next reboot.

Una vez superada la fecha límite, todas las versiones del agente de controlador de dominio con límite de tiempo emiten un evento 10022 en el registro de eventos de administración del agente de controlador de dominio en el momento de arranque similar al siguiente:

The password filter dll is loaded but the allowable trial period has expired. All password change and set requests are automatically approved. Please contact Microsoft for a newer supported version of the software.

No further messages are logged until after the next reboot.

Como la fecha límite solo se comprueba en el arranque inicial, es posible que no vea estos eventos hasta mucho después de la fecha límite. Una vez que se reconoce la fecha límite, no se producen efectos negativos en el controlador de dominio ni en el entorno más amplio, excepto que todas las contraseñas se aprueban automáticamente.

Importante

Microsoft recomienda que los agentes de controlador de dominio de versión preliminar pública expirados se actualicen inmediatamente a la versión más reciente.

Una manera fácil de detectar agentes de controlador de dominio en su entorno que deben actualizarse es mediante la ejecución del cmdlet Get-AzureADPasswordProtectionDCAgent, por ejemplo:

PS C:\> Get-AzureADPasswordProtectionDCAgent

ServerFQDN            : bpl1.bpl.com
SoftwareVersion       : 1.2.125.0
Domain                : bpl.com
Forest                : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC          : 8/1/2019 10:00:00 PM
AzureTenant           : bpltest.onmicrosoft.com

En este artículo, el campo SoftwareVersion es obviamente la propiedad clave que se va a examinar. También puede usar el filtrado de PowerShell para filtrar los agentes de controlador de dominio que ya tienen la versión de línea de base necesaria o una versión superior, por ejemplo:

PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}

El software proxy de protección de contraseñas de Microsoft Entra no tiene límite de tiempo en ninguna versión. Microsoft sigue recomendando que los agentes de controlador de dominio y proxy se actualicen a las versiones más recientes a medida que se publiquen. El cmdlet Get-AzureADPasswordProtectionProxy se puede utilizar para encontrar agentes proxy que necesiten actualizaciones, de manera similar al ejemplo anterior de los agentes DC.

Consulte Actualización del agente DC y Actualización del servicio proxy para obtener más información sobre los procedimientos de actualización específicos.

Remediación de emergencia

Si se produce una situación en la que el servicio del agente de controlador de dominio causa problemas, este servicio se puede apagar inmediatamente. El archivo DLL del filtro de contraseña del agente del controlador de dominio sigue intentando llamar al servicio que no está en ejecución y registra eventos de advertencia (10012, 10013), pero todas las contraseñas entrantes se aceptan durante ese tiempo. El servicio del agente de DC también se puede configurar a través del Administrador de servicios de Windows con un tipo de inicio "Deshabilitado" según sea necesario.

Otra medida de corrección sería establecer el modo de habilitación en No en el portal de Protección de Contraseñas de Microsoft Entra. Una vez descargada la directiva actualizada, cada servicio del agente de controlador de dominio cambia a un modo inactivo donde se aceptan todas las contraseñas tal cual. Para obtener más información, vea Modos de operación.

Eliminación

Si decide desinstalar el software de protección de contraseñas de Microsoft Entra y eliminar todo el estado relacionado de los dominios y del bosque, esta tarea puede realizarse siguiendo estos pasos:

Importante

Es importante realizar estos pasos en orden. Si se deja en ejecución alguna instancia del servicio proxy, vuelve a crear periódicamente su objeto serviceConnectionPoint. Si se deja cualquier instancia del servicio del agente de controlador de dominio en ejecución, esta vuelve a crear periódicamente su objeto serviceConnectionPoint y el estado sysvol.

  1. Desinstale el software proxy de todas las máquinas. En este paso no es necesario reiniciar.

  2. Desinstale el software del Agente DC de todos los controladores de dominio. Este paso requiere un reinicio.

  3. Quite manualmente todos los puntos de conexión del servicio proxy en cada contexto de nomenclatura de dominio. La ubicación de estos objetos se puede detectar con el siguiente comando de PowerShell de Active Directory:

    $scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    No omita el asterisco ("*") al final del valor de la variable $keywords.

    Los objetos resultantes que se encuentran a través del comando Get-ADObject se pueden canalizar a Remove-ADObjecto eliminarlos manualmente.

  4. Quite manualmente todos los puntos de conexión del agente de controlador de dominio de cada contexto de nomenclatura de dominio. Puede haber uno de estos objetos por controlador de dominio en el bosque, en función de la amplitud de la implementación del software. La ubicación de ese objeto se puede detectar con el siguiente comando de PowerShell de Active Directory:

    $scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Los objetos resultantes que se encuentran a través del comando Get-ADObject se pueden canalizar a Remove-ADObjecto eliminarlos manualmente.

    No omita el asterisco ("*") al final del valor de la variable $keywords.

  5. Quite manualmente el estado de configuración en el nivel de bosque. El estado de configuración del bosque se conserva en un contenedor en el contexto de nomenclatura de configuración de Active Directory. Se puede detectar y eliminar de la siguiente manera:

    $passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer

  6. Quite manualmente todo el estado relacionado con sysvol eliminando manualmente la siguiente carpeta y todo su contenido:

    \\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection

    Si es necesario, también se puede acceder a esta ruta de acceso localmente en un controlador de dominio determinado; la ubicación predeterminada sería similar a la siguiente ruta de acceso:

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    Esta ruta de acceso es diferente si el recurso compartido sysvol está configurado en una ubicación no predeterminada.

Pruebas de mantenimiento con cmdlets de PowerShell

El módulo de PowerShell AzureADPasswordProtection incluye dos cmdlets relacionados con la salud del sistema que realizan la comprobación básica de que el software está instalado y funcionando. Es recomendable ejecutar estos cmdlets después de configurar una nueva implementación, periódicamente después de investigar un problema.

Cada prueba de salud individual devuelve un resultado básico aprobado o fallado, además de un mensaje opcional en caso de fallo. En los casos en los que la causa de un error no está clara, busque mensajes de registro de eventos de error que puedan explicar el error. La habilitación de mensajes de registro de texto también puede ser útil. Para obtener más información, consulte Supervisión de la protección de contraseñas de Microsoft Entra.

Pruebas de mantenimiento del proxy

El cmdlet Test-AzureADPasswordProtectionProxyHealth admite dos pruebas de estado que se pueden ejecutar individualmente. Un tercer modo permite ejecutar todas las pruebas que no requieren ninguna entrada de parámetro.

Comprobación del registro de proxy

Esta prueba comprueba que el agente proxy está registrado correctamente con Azure y puede autenticarse en Azure. Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Passed

Si se detecta un error, la prueba devuelve un resultado erróneo y un mensaje de error opcional. Este es un ejemplo de un posible error:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Failed No proxy certificates were found - please run the Register-AzureADPasswordProtectionProxy cmdlet to register the proxy.

Comprobación del proxy de la conectividad de Azure de un extremo a otro

Esta prueba es un superconjunto de la prueba -VerifyProxyRegistration. Requiere que el agente proxy esté registrado correctamente con Azure, pueda autenticarse en Azure y, por último, agregue una comprobación de que un mensaje se puede enviar correctamente a Azure, lo que comprueba que la comunicación completa de un extremo a otro funciona.

Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyAzureConnectivity Passed

Verificación de todas las pruebas mediante proxy

Este modo permite la ejecución masiva de todas las pruebas admitidas por el cmdlet que no requieren entrada de parámetros. Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyTLSConfiguration  Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed

Pruebas de mantenimiento del agente del controlador de dominio

El cmdlet Test-AzureADPasswordProtectionDCAgentHealth admite varias pruebas de estado que se pueden ejecutar individualmente. Un tercer modo permite ejecutar todas las pruebas que no requieren ninguna entrada de parámetro.

Pruebas de mantenimiento básicas del agente del controlador de dominio

Todas las pruebas siguientes se pueden ejecutar individualmente y no aceptar parámetros. En la tabla siguiente se muestra una breve descripción de cada prueba.

Prueba de estado del agente del controlador de dominio Descripción
-VerifyPasswordFilterDll Comprueba que el archivo DLL de filtro de contraseña está cargado actualmente y puede llamar al servicio de agente DC.
-VerifyForestRegistration Comprueba que el bosque está registrado actualmente.
-VerifyEncryptionDecryption Comprueba que el cifrado y el descifrado básicos funcionan con el servicio Microsoft KDS.
-VerifyDomainIsUsingDFSR Comprueba que el dominio actual usa DFSR para la replicación de sysvol.
-VerifyAzureConnectivity Comprueba que la comunicación de un extremo a otro con Azure funciona con cualquier proxy disponible.

Lo que sigue es un ejemplo de la superación del test -VerifyPasswordFilterDll, y otras pruebas exitosas tienen resultados similares.

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyPasswordFilterDll Passed

Verificación por el agente del controlador de dominio de todas las pruebas

Este modo permite la ejecución masiva de todas las pruebas admitidas por el cmdlet que no requieren entrada de parámetros. Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

DiagnosticName             Result AdditionalInfo
--------------             ------ --------------
VerifyPasswordFilterDll    Passed
VerifyForestRegistration   Passed
VerifyEncryptionDecryption Passed
VerifyDomainIsUsingDFSR    Passed
VerifyAzureConnectivity    Passed

Pruebas de conectividad mediante servidores proxy específicos

Muchas situaciones de solución de problemas implican investigar la conectividad de red entre agentes de controlador de dominio y servidores proxy. Hay dos pruebas de estado disponibles para centrarse en estos problemas específicamente. Estas pruebas requieren que se especifique un servidor proxy determinado.

Comprobación de la conectividad entre un agente de controlador de dominio y un proxy específico

Esta prueba valida la conectividad en la primera etapa de comunicación del agente de controlador de dominio al proxy. Comprueba que el proxy recibe la llamada, pero no hay ninguna comunicación con Azure implicada. Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Passed

Esta es una condición de error de ejemplo en la que se detiene el servicio proxy que se ejecuta en el servidor de destino:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Failed The RPC endpoint mapper on the specified proxy returned no results; please check that the proxy service is running on that server.

Comprobación de la conectividad entre un agente de controlador de dominio y Azure (mediante un proxy específico)

Esta prueba valida la conectividad completa de un extremo a otro entre un agente de controlador de dominio y Azure mediante un proxy específico. Una ejecución correcta tiene este aspecto:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com

DiagnosticName                          Result AdditionalInfo
--------------                          ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed

Pasos siguientes

preguntas más frecuentes sobre la protección con contraseña de Microsoft Entra

Para obtener más información sobre las listas de contraseñas prohibidas globales y personalizadas, consulte el artículo Prohibición de contraseñas incorrectas