Solução de problemas: proteção de senha do Microsoft Entra local

Após a implantação da proteção de senha do Microsoft Entra, a solução de problemas pode ser necessária. Este artigo apresenta detalhes para ajudá-lo a entender algumas etapas de solução de problemas comuns.

O agente do controlador de domínio não consegue localizar um proxy no diretório

O principal sintoma disso são eventos 30017 no log de eventos do administrador do agente do DC (controlador de domínio).

A causa usual desse problema é um proxy ainda não ter sido registrado. Caso um proxy tenha sido registrado, pode haver algum atraso devido à latência de replicação do AD até que um agente do DC específico consiga ver esse proxy.

O agente do DC não consegue se comunicar com um proxy

O principal sintoma desse problema são eventos 30018 no log de eventos do administrador do agente do DC. Esse problema pode ter várias causas possíveis:

1. O agente do DC está localizado em uma parte isolada da rede, que não permite a conectividade de rede com os proxys registrados. Esse problema pode ser benigno, desde que outros agentes do DC consigam se comunicar com os proxys para baixar políticas de senha do Azure. Depois de baixadas, essas políticas serão obtidas pelo DC isolado por meio da replicação dos arquivos de política no compartilhamento SYSVOL.

2. O computador host do proxy está bloqueando o acesso ao ponto de extremidade do mapeador de ponto de extremidade RPC (porta 135)

   O instalador do proxy de proteção de senha do Microsoft Entra cria automaticamente uma regra de entrada do Firewall do Windows que permite acesso à porta 135. Se essa regra for excluída ou desabilitada posteriormente, os agentes do DC não poderão se comunicar com o serviço do proxy. Se o firewall interno do Windows tiver sido desabilitado no lugar de outro produto do firewall, você deverá configurar esse firewall para permitir o acesso à porta 135.

3. O computador host do proxy está bloqueando o acesso ao ponto de extremidade RPC (dinâmico ou estático) escutado pelo serviço do proxy

   O instalador di proxy da proteção de senha do Microsoft Entra cria automaticamente uma regra de entrada do Firewall do Windows que permite o acesso a qualquer porta de entrada escutada pelo serviço de proxy de proteção de senha do Microsoft Entra. Se essa regra for excluída ou desabilitada posteriormente, os agentes do DC não poderão se comunicar com o serviço do proxy. Se o Firewall do Windows interno tiver sido desabilitado em vez de outro produto de firewall, você deverá configurar esse firewall para permitir o acesso a quaisquer portas de entrada escutadas pelo serviço do proxy da proteção de senha do Microsoft Entra. Essa configuração pode se tornar mais específica se o serviço de proxy tiver sido configurado para escutar em uma porta RPC estática específica (usando o cmdlet Set-AzureADPasswordProtectionProxyConfiguration).

4. O computador host do proxy não está configurado para permitir que os controladores de domínio possam fazer logon no computador. Esse comportamento é controlado pela atribuição do privilégio de usuário "Acessar esse computador pela rede". Todos os controladores de domínio em todos os domínios na floresta devem receber esse privilégio. Essa configuração geralmente é restrita como parte de um esforço maior de proteção de rede.

O serviço de proxy não consegue se comunicar com o Azure

1. Verifique se o computador do proxy tem conectividade com os pontos de extremidade listados nos requisitos de implantação.

2. Verifique se a floresta e todos os servidores proxy estão registrados no mesmo locatário do Azure.

   Verifique esse requisito executando os cmdlets Get-AzureADPasswordProtectionProxy e Get-AzureADPasswordProtectionDCAgent do PowerShell e comparando a propriedade AzureTenant de cada item retornado. Para a operação correta, o nome do locatário relatado deve ser igual em todos os agentes do DC e servidores proxy.

   Se houver uma condição de incompatibilidade de registro de locatário do Azure, esse problema poderá ser corrigido executando os cmdlets Register-AzureADPasswordProtectionProxy e/ou Register-AzureADPasswordProtectionForest do PowerShell conforme necessário, sempre usando credenciais do mesmo locatário do Azure para todos os registros.

O agente do DC não consegue criptografar ou descriptografar arquivos de política de senha

A proteção de senha do Microsoft Entra tem uma dependência crítica da funcionalidade de criptografia e descriptografia fornecida pelo serviço de distribuição de chaves da Microsoft. Falhas de criptografia ou descriptografia podem ser manifestadas com vários sintomas e têm várias causas potenciais.

1. Verifique se o serviço KDS está habilitado e funcional em todos os controladores de domínio do Windows Server 2012 e posterior em um domínio.

   Por padrão, o modo de início do serviço do serviço KDS é configurado como Manual (Início do gatilho). Com essa configuração, na primeira vez que um cliente tenta usar o serviço, ele é iniciado sob demanda. Esse modo de início de serviço padrão é aceitável para que a proteção de senha do Microsoft Entra funcione.

   Se o modo de início do serviço KDS tiver sido configurado como Desabilitado, essa configuração deverá ser corrigida antes que a proteção de senha do Microsoft Entra funcione corretamente.

   Um teste simples para esse problema é iniciar manualmente o serviço KDS, seja pelo console do MMC de Gerenciamento de Serviços ou usando outras ferramentas de gerenciamento (por exemplo, execute "net start kdssvc" em um console do prompt de comando). Espera-se que o serviço KDS seja iniciado com êxito e permaneça em execução.

   A causa raiz mais comum de o serviço KDS não conseguir iniciar é devido ao objeto do controlador de domínio do Active Directory estar localizado fora da UO dos Controladores de domínio padrão. Essa configuração não é suportada pelo serviço KDS e não é uma limitação imposta pela proteção de senha do Microsoft Entra. A correção para essa condição é mover o objeto do controlador de domínio para um local na UO de Controladores de domínio padrão.

2. Alteração incompatível do formato de buffer criptografado do KDS do Windows Server 2012 R2 para o Windows Server 2016

   Uma correção de segurança do KDS foi introduzida no Windows Server 2016 que modifica o formato dos buffers criptografados do KDS; às vezes, esses buffers falharão ao descriptografar no Windows Server 2012 e no Windows Server 2012 R2. A direção inversa está bem – os buffers que são criptografados por KDS no Windows Server 2012 e no Windows Server 2012 R2 sempre serão descriptografados com êxito no Windows Server 2016 e posteriores. Se os controladores de domínio em seus domínios do Active Directory estiverem executando uma combinação desses sistemas operacionais, falhas ocasionais de descriptografia da proteção de senha do Microsoft Entra poderão ser relatadas. Não é possível prever com precisão o tempo ou os sintomas dessas falhas, dada a natureza da correção de segurança e dado que não é determinístico qual proteção de senha do agente de controle de domínio do Microsoft Entra em qual controlador de domínio criptografará dados em um determinado momento.

   Não há nenhuma solução alternativa para esse problema além de não executar uma combinação desses sistemas operacionais incompatíveis em seus domínios do Active Directory. Em outras palavras, você só deve executar controladores de domínio do Windows Server 2012 e do Windows Server 2012 R2, OU deve executar somente os controladores de domínio do Windows Server 2016 e superior.

O agente do DC pensa que a floresta não foi registrada

O sintoma desse problema são eventos 30016 sendo registrados no canal Agente\Administrador do DC que diz, em parte:

The forest has not been registered with Azure. Password policies cannot be downloaded from Azure unless this is corrected.

Há duas causas possíveis para esse problema.

1. A floresta realmente não foi registrada. Para resolver o problema, execute o comando Register-AzureADPasswordProtectionForest conforme descrito nos requisitos de implantação.
2. A floresta foi registrada, mas o agente do DC não consegue descriptografar os dados de registro da floresta. Esse caso tem a mesma causa raiz que o segundo problema listado acima em O agente do DC não consegue criptografar ou descriptografar arquivos de política de senha. Uma maneira fácil de confirmar essa teoria é que você só verá esse erro em agentes do DC sendo executados em controladores de domínio do Windows Server 2012 ou do Windows Server 2012R2, enquanto os agentes do DC sendo executados no Windows Server 2016 e controladores de domínio posteriores estão bem. A solução alternativa é a mesma: atualizar todos os controladores de domínio para o Windows Server 2016 ou posterior.

Senhas fracas estão sendo aceitas, mas não deveriam

Esse problema pode ter várias causas.

1. Seus agentes do DC estão executando uma versão de software em versão prévia pública que expirou. Confira O software do agente do DC em versão prévia pública expirou.

2. Seus agentes do DC não conseguem baixar uma política ou não é possível descriptografar políticas existentes. Verifique as possíveis causas nos tópicos acima.

3. O modo de Imposição de política de senha ainda está definido para Auditoria. Se essa configuração estiver em vigor, reconfigure-a para Impor usando o portal proteção de senha do Microsoft Entra. Para saber obter mais informações, confira os Modos de operação.

4. A política de senha foi desabilitada. Se essa configuração estiver em vigor, reconfigure-a para Habilitada usando o portal proteção de senha do Microsoft Entra. Para saber obter mais informações, confira os Modos de operação.

5. Você não instalou o software do agente do DC em todos os controladores de domínio no domínio. Nessa situação, é difícil garantir que os clientes remotos do Windows direcionem um determinado controlador de domínio durante uma operação de alteração de senha. Se você acredita que tenha direcionado com êxito um determinado DC em que o software do agente do DC esteja instalado, você pode verificar novamente o log de eventos do administrador do agente do DC: independentemente do resultado, haverá pelo menos um evento para documentar o resultado da validação de senha. Se não houver nenhum evento presente para o usuário cuja senha foi alterada, a alteração de senha provavelmente será processada por um controlador de domínio diferente.

   Como um teste alternativo, tente configurar\alterar senhas enquanto estiver conectado diretamente a um DC no qual o software do agente do DC esteja instalado. Essa técnica não é recomendada para domínios Active Directory de produção.

   Embora a implantação incremental do software do agente do DC tenha suporte para essas limitações, a Microsoft recomenda fortemente que o software do agente do DC esteja instalado em todos os controladores de domínio em um domínio assim que possível.

6. O algoritmo de validação de senha pode, na verdade, estar funcionando conforme o esperado. Confira Como as senhas são avaliadas.

O Ntdsutil.exe falha ao definir uma senha de DSRM fraca

O Active Directory sempre validará uma nova senha do Modo de Reparo dos Serviços de Diretório para garantir que ela atenda aos requisitos de complexidade de senha do domínio; essa validação também chama DLLs de filtro de senha como a proteção de senha do Microsoft Entra. Se a nova senha do DSRM for rejeitada, surge a seguinte mensagem de erro:

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

Quando a proteção de senha do Microsoft Entra registra o(s) evento(s) de log de eventos de validação de senha para uma senha DSRM do Active Directory, espera-se que as mensagens do log de eventos não incluam um nome de usuário. Esse comportamento ocorre porque a conta do DSRM é uma conta local que não faz parte do domínio Active Directory real.

Falha na promoção da réplica do controlador de domínio devido a uma senha fraca do DSRM

Durante o processo de promoção do DC, a nova senha do Modo de Reparo dos Serviços de Diretório será enviada a um DC existente no domínio para validação. Se a nova senha do DSRM for rejeitada, surge a seguinte mensagem de erro:

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

Assim como no problema acima, qualquer evento de resultado de validação de senha da proteção de senha do Microsoft Entra terá nomes de usuário vazios para esse cenário.

O rebaixamento do controlador de domínio falha devido a uma senha de Administrador local fraca

Há suporte para rebaixar um controlador de domínio que ainda esteja executando o software do agente DC. No entanto, os administradores devem estar cientes de que o software do agente do DC continua aplicando a política de senha atual durante o procedimento de rebaixamento. A nova senha da conta de Administrador local (especificada como parte da operação de rebaixamento) é validada como qualquer outra senha. A Microsoft recomenda que senhas seguras sejam escolhidas para contas de Administrador local como parte de um procedimento de rebaixamento do DC.

Depois que o rebaixamento tiver ocorrido com êxito e o controlador de domínio for reiniciado e estiver em execução novamente como um servidor membro normal, o software do agente DC será revertido para execução em modo passivo. Então, poderá ser desinstalado a qualquer momento.

Inicialização no Modo de Reparo dos Serviços de Diretório

Se o controlador de domínio for inicializado no Modo de Reparo de Serviços de Diretório, a dll do filtro de senha do agente do DC detecta essa condição e fará com que todas as atividades de validação ou imposição de senha sejam desabilitadas, independentemente da configuração de política ativa no momento. A dll do filtro de senha do agente do DC registrará um evento de aviso 10023 no log de eventos do administrador, por exemplo:

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

O software do agente do DC em versão prévia pública expirou

Durante o período de visualização pública da proteção de senha do Microsoft Entra, o software do agente de controle de domínio foi codificado para parar de processar solicitações de validação de senha nas seguintes datas:

• A Versão 1.2.65.0 interrompeu o processamento de solicitações de validação de senha em 1º de setembro de 2019.
• A Versão 1.2.25.0 e anteriores interromperam o processamento de solicitações de validação de senha em 1º de julho de 2019.

À medida que o prazo se aproxima, todas as versões de agente do DC com tempo limitado emitirão um evento 10021 no log de eventos do administrador do agente do DC no momento da inicialização que se parece com isto:

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 will no longer process passwords. Please contact Microsoft for a newer supported version of the software.

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

This message will not be repeated until the next reboot.

Assim que o prazo terminar, todas as versões de agente do DC com tempo limitado emitirão um evento 10022 no log de eventos do administrador do agente do DC no momento da inicialização que se parece com isto:

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

No further messages will be logged until after the next reboot.

Como o prazo final só é verificado na inicialização inicial, pode ser que você não veja esses eventos até que o tempo do prazo do calendário tenha terminado. Depois que o prazo tiver sido reconhecido, nenhum efeito negativo no controlador de domínio ou no ambiente maior ocorrerá além de todas as senhas que serão aprovadas automaticamente.

Uma maneira fácil de descobrir agentes do DC em seu ambiente que precisam ser atualizados é executando o cmdlet Get-AzureADPasswordProtectionDCAgent, por exemplo:

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

Para este tópico, o campo SoftwareVersion é, obviamente, a propriedade de chave a ser analisada. Você também pode usar a filtragem do PowerShell para filtrar agentes do DC que já estejam na versão de linha de base necessária, por exemplo:

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

O software de proteção de senha do proxy do Microsoft Entra não é limitado por tempo em nenhuma versão. A Microsoft ainda recomenda que ambos os agentes do DC e de proxy sejam atualizados para as versões mais recentes à medida que são lançados. O cmdlet Get-AzureADPasswordProtectionProxy pode ser usado para localizar agentes de proxy que exijam atualizações, semelhante ao exemplo acima para agentes do DC.

Confira Atualização do agente de DC e Atualização do serviço de proxy para obter mais detalhes sobre os procedimentos de atualização específicos.

Correção de emergência

Se ocorrer uma situação em que o serviço do agente DC esteja causando problemas, o serviço do agente DC poderá ser encerrado imediatamente. O dll do filtro de senha do agente DC ainda tentará chamar o serviço que não está em execução e registrará eventos de aviso (10012, 10013), mas todas as senhas de entrada serão aceitas durante esse período. O serviço do agente DC poderá, então, também ser configurado através do Gerenciador de Controle de Serviço do Windows com um tipo de inicialização “Desabilitado”, conforme necessário.

Outra medida de correção seria definir o modo Habilitar como Não no portal de proteção de senha do Microsoft Entra. Depois que a política atualizada tiver sido baixada, cada serviço do agente do DC entrará no modo inativo em que todas as senhas são aceitas no estado em que se encontram. Para saber obter mais informações, confira os Modos de operação.

Remoção

Se for decidido desinstalar o software de proteção por senha do Microsoft Entra e limpar todo o estado relacionado do(s) domínio(s) e da floresta, essa tarefa poderá ser realizada usando as seguintes etapas:

1. Desinstale o software do Proxy de todos os computadores. Esta etapa não exige um reinício.

2. Desinstale o software do Agente DC de todos os controladores de domínio. Essa etapa exige um reinício.

3. Remova manualmente todos os pontos de conexão do serviço Proxy em cada contexto de nomenclatura do domínio. O local desses objetos pode ser descoberto com o seguinte comando do PowerShell do Active Directory:

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

   Não omita o asterisco (“*”) no final do valor da variável $keywords.

   O (s) objeto (s) resultante (s) encontrado (s) através do comando Get-ADObject pode então ser canalizado para Remove-ADObject, ou deletado manualmente.

4. Remova manualmente todos os pontos de conexão do agente DC em cada contexto de nomeação de domínios. Pode haver um desses objetos por controlador de domínio na floresta, dependendo de como o software foi implantado. O local desse objeto pode ser descoberto com o seguinte comando do PowerShell do Active Directory:

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

   O (s) objeto (s) resultante (s) encontrado (s) através do comando Get-ADObject pode então ser canalizado para Remove-ADObject, ou deletado manualmente.

   Não omita o asterisco (“*”) no final do valor da variável $keywords.

5. Remova manualmente o estado de configuração no nível da floresta. O estado de configuração da floresta é mantido em um contêiner no contexto de nomeação de configuração do Active Directory. É possível descobrir e excluir da seguinte forma:

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

6. Remova manualmente todo o estado relacionado ao sysvol excluindo manualmente a seguinte pasta e todo o conteúdo:

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

   Se necessário, esse caminho também poderá ser acessado localmente em um determinado controlador de domínio e o local padrão seria semelhante ao caminho a seguir:

   %windir%\sysvol\domain\Policies\AzureADPasswordProtection

   Esse caminho será diferente se o compartilhamento sysvol foi configurado em um local não padrão.

Testes de integridade com cmdlets do PowerShell

O módulo AzureADPasswordProtection do PowerShell inclui dois cmdlets relacionados à integridade que executam a verificação básica para ver se o software está instalado e funcionando. É interessante executar esses cmdlets depois de configurar uma nova implantação, periodicamente depois disso, e quando um problema estiver sendo investigado.

Cada teste de integridade individual retorna um resultado básico Aprovado ou Com falha, além de uma mensagem opcional em caso de falha. Nos casos em que a causa de uma falha não fique clara, procure mensagens de log de eventos de erro que possam explicá-la. Também pode ser útil habilitar mensagens de log de texto. Para obter mais detalhes, consulte Monitore a proteção de senha do Microsoft Entra.

Teste de integridade do proxy

O cmdlet Test-AzureADPasswordProtectionProxyHealth dá suporte a dois testes de integridade que podem ser executados individualmente. Um terceiro modo permite a execução de todos os testes que não exigem nenhuma entrada de parâmetro.

Verificação do registro de proxy

Esse teste verifica se o agente de proxy está registrado corretamente com o Azure e se consegue autenticar no Azure. A execução bem-sucedida terá esta aparência:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

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

Se um erro for detectado, o teste retornará um resultado Com falha e uma mensagem de erro opcional. Veja um exemplo de uma possível falha:

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.

Verificação de proxy de conectividade de ponta a ponta do Azure

Esse teste é um superconjunto do teste -VerifyProxyRegistration. Ele requer que o agente de proxy seja registrado corretamente no Azure, consiga se autenticar no Azure e, por fim, adicione uma verificação de que uma mensagem possa ser enviada com êxito ao Azure, verificando se a comunicação completa de ponta a ponta está funcionando.

A execução bem-sucedida terá esta aparência:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

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

Verificação de proxy de todos os testes

Esse modo permite a execução em massa de todos os testes com suporte pelo cmdlet e que não exigem entrada de parâmetro. A execução bem-sucedida terá esta aparência:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

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

Teste de integridade do agente do DC

O cmdlet Test-AzureADPasswordProtectionDCAgentHealth dá suporte a vários testes de integridade que podem ser executados individualmente. Um terceiro modo permite a execução de todos os testes que não exigem nenhuma entrada de parâmetro.

Testes de integridade básicos do agente do DC

Todos os testes a seguir podem ser executados individualmente e não aceitam parâmetros. Uma breve descrição de cada teste é fornecida na tabela a seguir.

Aqui está um exemplo de aprovação de teste-VerifyPasswordFilterDll; os outros testes terão aparência semelhante se bem-sucedidos:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

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

Verificação de agente do DC de todos os testes

Esse modo permite a execução em massa de todos os testes com suporte pelo cmdlet e que não exigem entrada de parâmetro. A execução bem-sucedida terá esta aparência:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

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

Teste de conectividade usando servidores proxy específicos

Muitas situações de solução de problemas envolvem a investigação da conectividade de rede entre agentes do DC e proxies. Há dois testes de integridade disponíveis para se concentrar especificamente nesses problemas. Esses testes exigem que um determinado servidor proxy seja especificado.

Verificação da conectividade entre um agente do DC e um proxy específico

Esse teste valida a conectividade sobre o primeiro segmento de comunicação do agente do DC para o proxy. Ele verifica se o proxy recebe a chamada, no entanto, nenhuma comunicação com o Azure é envolvida. Uma execução bem-sucedida tem a seguinte aparência:

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

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

Eis um exemplo de condição de falha em que o serviço de proxy em execução no servidor de destino foi interrompido:

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.

Verificação da conectividade entre um agente do DC e o Azure (usando um proxy específico)

Esse teste valida a conectividade completa de ponta a ponta entre um agente do DC e o Azure usando um proxy específico. Uma execução bem-sucedida tem a seguinte aparência:

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

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

Próximas etapas

Perguntas frequentes sobre a proteção de senha do Microsoft Entra

Para obter mais informações sobre as listas de senhas proibidas globais e personalizadas, consulte o artigo Proibir senhas incorretas