Resolução de problemas: Proteção de senha local do Microsoft Entra
Após a implantação do Microsoft Entra Password Protection, a solução de problemas pode ser necessária. Este artigo entra em detalhes para ajudá-lo a entender algumas etapas comuns de solução de problemas.
O agente DC não consegue localizar um proxy no diretório
O principal sintoma desse problema é 30.017 eventos no log de eventos Admin do agente DC.
A causa habitual desse problema é que um proxy não foi registrado. Se um proxy estiver registado, poderá haver algum atraso devido à latência de replicação do Active Directory até que um agente do Controlador de Domínio específico consiga visualizar esse proxy.
O agente DC não é capaz de se comunicar com um proxy
O principal sintoma desse problema é 30.018 eventos no log de eventos Admin do agente DC. Este problema pode ter várias causas possíveis:
O agente DC está localizado em uma parte isolada da rede que não permite conectividade de rede com o(s) proxy(s) registrado(s). Esse problema pode ser benigno, desde que outros agentes de DC possam se comunicar com o(s) proxy(s) para baixar políticas de senha do Azure. Uma vez baixadas, essas políticas são obtidas pelo DC isolado por meio da replicação dos arquivos de política no compartilhamento sysvol.
A máquina host proxy está bloqueando o acesso ao ponto de extremidade do mapeador de pontos de extremidade RPC (porta 135)
O instalador do Microsoft Entra Password Protection Proxy cria automaticamente uma regra de entrada do Firewall do Windows que permite o acesso à porta 135. Se essa regra for excluída ou desabilitada posteriormente, os agentes de DC não poderão se comunicar com o serviço de Proxy. Se o Firewall do Windows interno estiver desabilitado em vez de outro produto de firewall, você deverá configurar esse firewall para permitir o acesso à porta 135.
O servidor proxy está bloqueando o acesso ao ponto de extremidade RPC (dinâmico ou estático) monitorizado pelo serviço Proxy.
O instalador do Microsoft Entra Password Protection Proxy cria automaticamente uma regra de entrada do Firewall do Windows que permite o acesso a quaisquer portas de entrada ouvidas pelo serviço Microsoft Entra Password Protection Proxy. Se essa regra for excluída ou desabilitada posteriormente, os agentes de DC não poderão se comunicar com o serviço de Proxy. Se o Firewall do Windows interno estiver desabilitado em vez de outro produto de firewall, você deverá configurar esse firewall para permitir o acesso a quaisquer portas de entrada ouvidas pelo serviço Microsoft Entra Password Protection Proxy. Essa configuração pode ser tornada mais específica se o serviço Proxy estiver configurado para escutar em uma porta RPC estática específica (usando o cmdlet
Set-AzureADPasswordProtectionProxyConfiguration).A máquina host proxy não está configurada para permitir que os controladores de domínio entrem na máquina. Este comportamento é controlado através da atribuição de privilégio de utilizador "Aceder a este computador a partir da rede". Todos os controladores de domínio em todos os domínios da floresta devem receber esse privilégio. Essa configuração geralmente é restrita como parte de um esforço maior de proteção da rede.
O serviço de proxy não consegue comunicar com o Azure
Verifique se a máquina proxy tem conectividade com os endpoints listados nos requisitos de implementação.
Verifique se a floresta e todos os servidores proxy estão registrados no mesmo locatário do Azure.
Você pode verificar esse requisito executando os cmdlets
Get-AzureADPasswordProtectionProxyeGet-AzureADPasswordProtectionDCAgentPowerShell e, em seguida, comparar a propriedadeAzureTenantde cada item retornado. Para uma operação correta, o nome do inquilino reportado deve ser o mesmo em todos os agentes de DC e servidores proxy.Se existir uma condição de incompatibilidade de registro de locatário do Azure, esse problema pode ser corrigido executando os cmdlets
Register-AzureADPasswordProtectionProxye/ouRegister-AzureADPasswordProtectionForestPowerShell, conforme necessário, certificando-se de usar credenciais do mesmo locatário do Azure para todos os registros.
O agente DC não consegue encriptar ou desencriptar ficheiros de política de palavra-passe
O Microsoft Entra Password Protection tem uma dependência crítica da funcionalidade de encriptação e desencriptação fornecida pelo Serviço de Distribuição de Chaves da Microsoft. As falhas de encriptação ou desencriptação podem manifestar-se com vários sintomas e ter várias causas potenciais.
Verifique se o serviço KDS está habilitado e funcional em todos os controladores de domínio do Windows Server 2012 e posteriores em um domínio.
Por padrão, o modo de início de serviço do serviço KDS é configurado como Manual (Trigger Start). Essa configuração significa que a primeira vez que um cliente tenta usar o serviço, ele é iniciado sob demanda. Este modo de início de serviço padrão é aceitável para que a Proteção por Senha do Microsoft Entra funcione.
Se o modo de início do serviço KDS estiver configurado para Desativado, essa configuração deverá ser corrigida antes que a Proteção por Senha do Microsoft Entra possa funcionar corretamente.
Um teste simples para esse problema é iniciar manualmente o serviço KDS, seja por meio do console MMC de Gerenciamento de Serviços ou usando outras ferramentas de gerenciamento (por exemplo, execute "net start kdssvc" a partir de um console de prompt de comando). Espera-se que o serviço KDS seja iniciado com sucesso e permaneça em execução.
A causa raiz mais comum de não conseguir iniciar o serviço KDS é que o objeto do controlador de domínio do Active Directory está localizado fora da Unidade Organizacional (OU) padrão de Controladores de Domínio. Esta configuração não é suportada pelo serviço KDS e não é uma limitação imposta pela Proteção por Palavra-passe Microsoft Entra. A correção para essa condição é mover o objeto do controlador de domínio para um local na OU dos Controladores de Domínio padrão.
Alteração do formato de buffer criptografado KDS incompatível 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. Esses buffers às vezes não conseguem descriptografar no Windows Server 2012 e no Windows Server 2012 R2. A direção inversa está bem. Os buffers criptografados pelo KDS no Windows Server 2012 e no Windows Server 2012 R2 sempre são descriptografados com êxito no Windows Server 2016 e posterior. Se os controladores de domínio em seus domínios do Ative Directory estiverem executando uma combinação desses sistemas operacionais, falhas ocasionais de descriptografia do Microsoft Entra Password Protection podem 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. Além disso, considerando que não é determinístico qual Microsoft Entra Password Protection DC Agent em qual controlador de domínio criptografa os dados em um dado momento.
Não há solução alternativa para esse problema além de não executar uma combinação desses sistemas operacionais incompatíveis no(s) seu(s) domínio(s) do Ative Directory. Em outras palavras, você deve executar apenas controladores de domínio do Windows Server 2012 e Windows Server 2012 R2, OU você deve executar apenas controladores de domínio do Windows Server 2016 e superiores.
Agente da DC acha que a floresta não foi registrada
O sintoma desse problema é 30.016 eventos sendo registrados no canal DC Agent\Admin que diz em parte:
The forest hasn't been registered with Azure. Password policies can't be downloaded from Azure unless this is corrected.
Existem duas causas possíveis para este problema.
- A floresta não foi registrada. Para resolver o problema, execute o comando Register-AzureADPasswordProtectionForest conforme descrito nos requisitos de implantação .
- A floresta está registrada, mas o agente DC não consegue descriptografar os dados de registro da floresta. Este caso tem a mesma causa subjacente que o problema #2, listado em , no qual o agente DC é incapaz de encriptar ou desencriptar ficheiros de política de palavras-passe. Uma maneira fácil de confirmar essa teoria é que você verá esse erro somente em agentes de DC em execução em controladores de domínio do Windows Server 2012 ou Windows Server 2012R2, enquanto agentes de DC em execução 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 devem ser
Este problema pode ter várias causas.
O(s) agente(s) DC está(ão) a executar uma versão de software de pré-visualização pública que expirou. Consulte O software do agente DC de visualização pública expirou.
O(s) seu(s) agente(s) DC(s) não pode(m) transferir uma política ou não consegue desencriptar as políticas existentes. Verifique possíveis causas nos artigos anteriores.
O modo de imposição da política de senha ainda está definido como 'Auditoria'. Se esta configuração estiver em vigor, reconfigure-a para aplicar usando o portal de proteção de senha do Microsoft Entra. Para obter mais informações, consulte Modos de operação.
A política de senha está desativada. Se essa configuração estiver em vigor, reconfigure-a para habilitada usando o portal de Proteção por Senha do Microsoft Entra. Para obter mais informações, consulte Modos de operação.
Você não instalou o software do agente de DC em todos os controladores de domínio no domínio. Nessa situação, é difícil garantir que os clientes remotos do Windows tenham como alvo um controlador de domínio específico durante uma operação de alteração de senha. Se você acha que direcionou com êxito um determinado controlador de domínio onde o software do agente de DC está instalado, você pode verificar verificando novamente o log de eventos de administrador do agente de DC: independentemente do resultado, há 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 foi processada por um controlador de domínio diferente.
Como um teste alternativo, tente definir ou alterar senhas enquanto está ligado diretamente a um dos controladores de domínio onde o software do agente do controlador de domínio está instalado. Essa técnica não é recomendada para domínios do Ative Directory de produção.
Embora a implantação incremental do software do agente de DC seja suportada sujeita a essas limitações, a Microsoft recomenda que o software do agente de DC seja instalado em todos os controladores de domínio em um domínio o mais rápido possível.
O algoritmo de validação de senha pode realmente estar funcionando conforme o esperado. Consulte Como as senhas são avaliadas.
Ntdsutil.exe falha ao definir uma senha DSRM fraca
O Active Directory sempre valida 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 filtros de senha DLL como o Microsoft Entra Password Protection. Se a nova senha DSRM for rejeitada, a seguinte mensagem de erro resulta:
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 por Senha do Microsoft Entra registra o(s) evento(s) do log de eventos de validação de senha para uma senha DSRM do Ative Directory, espera-se que as mensagens do log de eventos não incluam um nome de usuário. Esse comportamento ocorre porque a conta DSRM é uma conta local que não faz parte do domínio real do Ative Directory.
A promoção da réplica do controlador de domínio falha devido a uma senha DSRM fraca
Durante o processo de promoção do Controlador de Domínio, a nova senha do Modo de Reparo dos Serviços de Diretório é fornecida a um Controlador de Domínio existente no domínio para validação. Se a nova senha DSRM for rejeitada, a seguinte mensagem de erro resulta:
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.
Assim como na edição anterior, qualquer evento de resultado de validação de senha do Microsoft Entra Password Protection 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. Os administradores devem, no entanto, estar cientes de que o software do agente do controlador de domínio (DC) continua a aplicar 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 sugere que sejam escolhidas senhas seguras para as contas de Administrador locais como parte de um procedimento de despromoção de controlador de domínio (DC).
Quando o rebaixamento é bem-sucedido e o controlador de domínio é reinicializado e está novamente em execução como um servidor membro normal, o software do agente DC volta a ser executado em um modo passivo. Pode então ser desinstalado a qualquer momento.
Inicializando no Modo de Reparo dos Serviços de Diretório
Se o controlador de domínio for inicializado no Modo de Reparo dos Serviços de Diretório, a dll do filtro de senha do agente DC detetará 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 diretiva ativa no momento. A dll do filtro de senha do agente DC registra um evento de aviso 10023 no log de eventos Admin, por exemplo:
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.
O software do agente DC de pré-visualização pública expirou
Durante o período de visualização pública do Microsoft Entra Password Protection, o software do agente DC foi codificado para parar de processar solicitações de validação de senha nas seguintes datas:
- A versão 1.2.65.0 parou de processar solicitações de validação de senha em 1º de setembro de 2019.
- A versão 1.2.25.0 e anteriores pararam de processar solicitações de validação de senha em 1º de julho de 2019.
À medida que o prazo se aproxima, todas as versões temporárias do agente DC emitem um evento 10021 no registo de eventos Admin do agente DC durante a inicialização e têm o seguinte aspecto:
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.
Uma vez passado o prazo, todas as versões do agente DC por tempo limitado emitem um evento 10022 no log de eventos Admin do agente 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 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 o prazo só é verificado na inicialização, poderá não ver esses eventos até muito tempo após o prazo do calendário ter expirado. Uma vez que o prazo é reconhecido, nenhum efeito negativo no controlador de domínio ou no ambiente maior ocorre, além de todas as senhas serem aprovadas automaticamente.
Importante
A Microsoft recomenda que os agentes DC de visualização pública expirados sejam imediatamente atualizados para a versão mais recente.
Uma maneira fácil de descobrir agentes de 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 artigo, o campo SoftwareVersion é obviamente a propriedade chave a ser examinada. Você também pode usar filtros do PowerShell para filtrar agentes de DC que já estão na versão base exigida ou acima dela, por exemplo:
PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}
O software Microsoft Entra Password Protection Proxy não tem limite de tempo em nenhuma versão. A Microsoft ainda recomenda que os agentes de DC e proxy sejam atualizados para as versões mais recentes à medida que forem lançados. O cmdlet Get-AzureADPasswordProtectionProxy pode ser usado para localizar agentes Proxy que exigem atualizações, semelhante ao exemplo acima para agentes DC.
Consulte Atualizando o do agente DC e Atualizando o serviço de proxy para obter mais detalhes sobre procedimentos de atualização específicos.
Remediação de emergência
Se ocorrer uma situação em que o serviço do agente DC está causando problemas, o serviço do agente DC pode ser desligado imediatamente. A dll do filtro de palavra-passe do agente DC ainda tenta chamar o serviço inativo e regista eventos de aviso (10012, 10013), mas todas as palavras-passe de entrada são aceites durante este período. O serviço de agente de DC também pode ser configurado através do Gerenciador de Controle de Serviços do Windows com um tipo de inicialização de "Desativado", conforme necessário.
Outra medida de correção seria definir o modo Ativar como Não no portal de Proteção por Senha do Microsoft Entra. Depois que a política atualizada é baixada, cada serviço de agente DC muda para um modo quiescente, onde todas as senhas são aceitas as-is. Para obter mais informações, consulte Modos de operação.
Remoção
Se você decidir desinstalar o software de proteção por senha 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:
Importante
É importante executar essas etapas em ordem. Se qualquer instância do serviço Proxy for deixada em execução, ele recriará periodicamente seu objeto serviceConnectionPoint. Se qualquer instância do serviço do agente de DC for deixada em execução, ele recriará periodicamente seu objeto serviceConnectionPoint e o estado sysvol.
Desinstale o software Proxy de todas as máquinas. Esta etapa não requer uma reinicialização.
Desinstale o software DC Agent de todos os controladores de domínio. Esta etapa requer uma reinicialização.
Remova manualmente todos os pontos de conexão do serviço Proxy em cada contexto de nomeação de domínio. O local desses objetos pode ser descoberto com o seguinte comando do PowerShell do Ative 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 $keywords valor da variável.
O(s) objeto(s) resultante(s) encontrado(s) através do comando
Get-ADObjectpode ser canalizado paraRemove-ADObjectou excluído manualmente.Remova manualmente todos os pontos de conexão do agente de DC em cada contexto de nomeação de domínio. Pode haver um desses objetos por controlador de domínio na floresta, dependendo de quão amplamente o software foi implantado. O local desse objeto pode ser descoberto com o seguinte comando do PowerShell do Ative 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-ADObjectpode ser canalizado paraRemove-ADObjectou excluído manualmente.Não omita o asterisco ("*") no final do $keywords valor da variável.
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 Ative Directory. Pode ser descoberto e eliminado da seguinte forma:
$passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext Remove-ADObject -Recursive $passwordProtectionConfigContainerRemova manualmente todo o estado relacionado ao sysvol excluindo manualmente a seguinte pasta e todo o seu conteúdo:
\\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtectionSe necessário, esse caminho também pode ser acessado localmente em um determinado controlador de domínio; O local padrão seria algo como o seguinte caminho:
%windir%\sysvol\domain\Policies\AzureADPasswordProtectionEsse caminho será diferente se o compartilhamento sysvol estiver configurado em um local não padrão.
Testes de saúde com cmdlets do PowerShell
O módulo AzureADPasswordProtection PowerShell inclui dois cmdlets relacionados com a saúde que executam uma verificação básica para garantir que o software está instalado e a funcionar. É uma boa ideia executar esses cmdlets depois de configurar uma nova implantação, periodicamente depois disso, e quando um problema estiver sendo investigado.
Cada teste de saúde individual retorna um resultado básico de Aprovado ou Reprovado, além de uma mensagem opcional sobre falha. Nos casos em que a causa de uma falha não é clara, procure mensagens de log de eventos de erro que possam explicar a falha. Habilitar mensagens de log de texto também pode ser útil. Para obter mais detalhes, consulte Monitor Microsoft Entra Password Protection.
Teste de integridade de proxy
O cmdlet Test-AzureADPasswordProtectionProxyHealth oferece 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 registo de proxy
Este teste verifica se o agente de proxy está corretamente registrado no Azure e é capaz de se autenticar no Azure. Uma execução bem-sucedida tem esta aparência:
PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyProxyRegistration Passed
Se um erro for detetado, o teste retornará um resultado com falha e uma mensagem de erro opcional. Aqui está 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 da conectividade completa do Azure
Este teste é um superconjunto do teste -VerifyProxyRegistration. Ele requer que o agente de proxy esteja registrado corretamente no Azure, seja capaz de se autenticar no Azure e, finalmente, adicione uma verificação de que uma mensagem pode ser enviada com êxito para o Azure, verificando assim se a comunicação completa de ponta a ponta está funcionando.
Uma execução bem-sucedida tem esta aparência:
PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyAzureConnectivity Passed
Verificação por proxy de todos os testes
Esse modo permite a execução em massa de todos os testes suportados pelo cmdlet que não exigem entrada de parâmetros. Uma execução bem-sucedida é assim:
PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyTLSConfiguration Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed
Testes de integridade do Agente DC
O cmdlet Test-AzureADPasswordProtectionDCAgentHealth oferece 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 básicos de integridade do agente DC
Os testes a seguir podem ser executados individualmente e não aceitam parâmetros. Uma breve descrição de cada teste está listada na tabela a seguir.
| Teste de saúde do agente DC | Descrição |
|---|---|
| -VerifyPasswordFilterDll | Verifica se a DLL do filtro de senha está carregada no momento e consegue chamar o serviço do agente DC. |
| -VerificarRegistoFlorestal | Verifica se a floresta está atualmente registrada |
| -VerificarEncriptaçãoDesencriptação | Verifica se a criptografia e descriptografia básicas estão funcionando usando o serviço Microsoft KDS |
| -VerifyDomainIsUsingDFSR | Verifica se o domínio atual está a usar DFSR para a replicação do sysvol |
| -VerifyAzureConnectivity | Verifica se a comunicação de ponta a ponta com o Azure está funcionando usando qualquer proxy disponível |
O que se segue é um exemplo de um teste -VerifyPasswordFilterDll bem-sucedido, e outros testes bem-sucedidos têm um aspeto semelhante.
PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyPasswordFilterDll Passed
Verificação de todos os testes pelo agente DC
Esse modo permite a execução em massa de todos os testes suportados pelo cmdlet que não exigem entrada de parâmetros. Uma execução bem-sucedida é assim:
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 de DC e proxies. Há dois testes de saúde disponíveis para se concentrar em tais questões especificamente. Esses testes exigem que um servidor proxy específico seja especificado.
Verificando a conectividade entre um agente de DC e um proxy específico
Este teste valida a conectividade ao longo da primeira etapa de comunicação do agente DC para o proxy. Ele verifica se o proxy recebe a chamada, no entanto, nenhuma comunicação com o Azure está envolvida. Uma execução bem-sucedida tem esta aparência:
PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyProxyConnectivity Passed
Aqui está um exemplo de condição de falha em que o serviço de proxy em execução no servidor de destino é 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.
Verificando a conectividade entre um agente de DC e o Azure (usando um proxy específico)
Este teste valida a conectividade completa de ponta a ponta entre um agente de DC e o Azure usando um proxy específico. A aparência de uma execução bem-sucedida é a seguinte:
PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed
Próximos passos
Perguntas frequentes sobre o Microsoft Entra Password Protection
Para obter mais informações sobre as listas de senhas proibidas globais e personalizadas, consulte o artigo Ban bad passwords