Resolver Problemas: Proteção de Palavras-passe do Microsoft Entra no Local
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 de DC não pode localizar um proxy no diretório
O principal sintoma desse problema é 30017 eventos no log de eventos Admin do agente DC.
A causa habitual deste problema é que um proxy ainda não foi registado. Se um proxy tiver sido registrado, pode haver algum atraso devido à latência de replicação do AD até que um agente de DC específico seja capaz de ver esse proxy.
O agente DC não é capaz de se comunicar com um proxy
O principal sintoma desse problema é 30018 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 serã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 tiver sido desativado em vez de outro produto de firewall, você deverá configurar esse firewall para permitir o acesso à porta 135.
A máquina host proxy está bloqueando o acesso ao ponto de extremidade RPC (dinâmico ou estático) escutado 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 tiver sido desativado 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 Proxy de Proteção por Senha do Microsoft Entra. Essa configuração pode ser tornada mais específica se o serviço Proxy tiver sido configurado para escutar em uma porta RPC estática específica (usando o
Set-AzureADPasswordProtectionProxyConfigurationcmdlet).A máquina host proxy não está configurada para permitir que os controladores de domínio façam logon 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 pontos de extremidade listados nos requisitos de implantaçã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
Get-AzureADPasswordProtectionProxycmdlets e PowerShell eGet-AzureADPasswordProtectionDCAgent, em seguida, comparar aAzureTenantpropriedade de cada item retornado. Para uma operação correta, o nome do locatário relatado 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 e/ou
Register-AzureADPasswordProtectionForestPowerShell conforme necessário, certificando-se de usar credenciais do mesmo locatário do Azure para todos osRegister-AzureADPasswordProtectionProxyregistros.
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 uma variedade de 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 tiver sido configurado para Desativado, essa configuração deverá ser corrigida antes que a Proteção por Senha do Microsoft Entra funcione 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 para o serviço KDS não conseguir iniciar é que o objeto do controlador de domínio do Ative Directory está localizado fora da UO padrão dos Controladores de Domínio. Esta configuração não é suportada pelo serviço KDS e não é uma limitação imposta pelo Microsoft Entra Password Protection. A correção para essa condição é mover o objeto do controlador de domínio para um local na UO 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 falham ao descriptografar no Windows Server 2012 e no Windows Server 2012 R2. A direção inversa é aceitável - os buffers criptografados pelo KDS no Windows Server 2012 e no Windows Server 2012 R2 sempre serã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 e dado que não é determinístico qual Microsoft Entra Password Protection DC Agent em qual controlador de domínio criptografará dados em um determinado 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 é 30016 eventos sendo registrados no canal DC Agent\Admin que diz em parte:
The forest has not been registered with Azure. Password policies cannot be downloaded from Azure unless this is corrected.
Existem duas causas possíveis para este problema.
- De facto, a floresta não foi registada. Para resolver o problema, execute o comando Register-AzureADPasswordProtectionForest conforme descrito nos requisitos de implantação.
- A floresta foi registrada, mas o agente DC não consegue descriptografar os dados de registro da floresta. Este caso tem a mesma causa raiz que o problema #2 listado acima em DC agent é incapaz de criptografar ou descriptografar arquivos de política de senha. 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(s) está(ão) a executar uma versão de software de pré-visualização pública que expirou. Consulte Visualização pública O software do agente DC 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 tópicos acima.
O modo Impor política de senha ainda está definido como Auditoria. Se essa configuração estiver em vigor, reconfigure-a para Impor usando o portal de Proteção por Senha do Microsoft Entra. Para obter mais informações, consulte Modos de operação.
A política de senha foi 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 destino 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, haverá pelo menos um evento para documentar o resultado da validação da 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\alterar senhas enquanto estiver conectado diretamente em um controlador de domínio onde o software do agente de DC 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 Ative 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 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 de 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 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 does not meet a requirement of the password filter(s). Supply a suitable password.
Assim como na edição acima, 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 estar cientes, no entanto, de que o software do agente DC continua a impor 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 de DC.
Depois que o rebaixamento for bem-sucedido e o controlador de domínio tiver sido reinicializado e estiver novamente em execução como um servidor membro normal, o software do agente DC voltará 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 registrará 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 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 DC de 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 deixará de processar pedidos de validação de palavra-passe em 1 de setembro de 2019.
- A versão 1.2.25.0 e anteriores deixaram de processar pedidos de validação de palavra-passe em 1 de julho de 2019.
À medida que o prazo se aproxima, todas as versões do agente DC por tempo limitado emitirão um evento 10021 no log de eventos Admin do agente 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 an 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.
Uma vez passado o prazo, todas as versões do agente DC por tempo limitado emitirão 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 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 só é verificado na inicialização inicial, você pode não ver esses eventos até muito depois do prazo do calendário ter passado. Uma vez que o prazo tenha sido reconhecido, nenhum efeito negativo no controlador de domínio ou no ambiente maior ocorrerá, 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 Get-AzureADPasswordProtectionDCAgent cmdlet, 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 chave a ser examinada. Você também pode usar a filtragem do PowerShell para filtrar agentes de DC que já estão na versão de linha de base necessária 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 DC e proxy sejam atualizados para as versões mais recentes à medida que são lançados. O Get-AzureADPasswordProtectionProxy cmdlet pode ser usado para localizar agentes de proxy que exigem atualizações, semelhante ao exemplo acima para agentes de DC.
Consulte Atualizando o agente de 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 senha do agente DC ainda tenta chamar o serviço não em execução e registrará eventos de aviso (10012, 10013), mas todas as senhas de entrada são aceitas durante esse tempo. 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. Uma vez que a política atualizada tenha sido baixada, cada serviço de agente DC entrará em um modo quiescente, onde todas as senhas são aceitas como estão. Para obter mais informações, consulte Modos de operação.
Remoção
Se for decidido desinstalar o software de proteção por senha do Microsoft Entra e limpar todos os estados relacionados do(s) domínio(s) e da floresta, essa tarefa pode ser realizada usando as seguintes etapas:
Importante
É importante executar estas etapas em ordem. Se qualquer instância do serviço Proxy for deixada em execução, ela 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
Get-ADObjectcomando pode(m) ser canalizado(s) paraRemove-ADObject, ou 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
Get-ADObjectcomando pode(m) ser canalizado(s) paraRemove-ADObject, ou 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 tiver sido configurado em um local não padrão.
Testes de integridade com cmdlets do PowerShell
O módulo AzureADPasswordProtection PowerShell inclui dois cmdlets relacionados à integridade que executam a verificação básica de que o software está instalado e funcionando. Pode executar estes cmdlets depois de configurar uma nova implementação, periodicamente depois disso e quando um problema está em investigação.
Cada teste de integridade 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 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 registo de procuração
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 terá esta aparência:
PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyProxyRegistration Passed
Se um erro for detetado, o teste retornará um resultado de 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 que a comunicação completa de ponta a ponta está funcionando.
Uma execução bem-sucedida terá 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 terá esta aparência:
PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyTLSConfiguration Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed
Testes de integridade do Agente 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 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 integridade do agente DC | Description |
|---|---|
| -VerifyPasswordFilterDll | Verifica se a dll do filtro de senha está carregada no momento e é capaz de chamar o serviço do agente DC |
| -VerifyForestRegistration | Verifica se a floresta está atualmente registrada |
| -VerifyEncryptionDecryption | 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á usando DFSR para replicação sysvol |
| -VerifyAzureConnectivity | Verifica se a comunicação de ponta a ponta com o Azure está funcionando usando qualquer proxy disponível |
Aqui está um exemplo da aprovação no teste -VerifyPasswordFilterDll; Os outros testes serão semelhantes no sucesso:
PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyPasswordFilterDll Passed
Verificação do agente DC 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 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 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 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.
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. Uma execução bem-sucedida tem esta aparência:
PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com
DiagnosticName Result AdditionalInfo
-------------- ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed
Próximos passos
Perguntas frequentes sobre a Proteção por Senha do Microsoft Entra
Para obter mais informações sobre as listas de senhas proibidas globais e personalizadas, consulte o artigo Banir senhas incorretas
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários