Solução de problemas conhecidos do Microsoft Defender para Identidade
Este artigo descreve como solucionar problemas conhecidos no Microsoft Defender para Identidade.
Erro de comunicação com falha do sensor
Se você receber o seguinte erro de sensor com falha:
System.Net.Http.HttpRequestException:
An error occurred while sending the request. ---> System.Net.WebException:
Unable to connect to the remote server --->
System.Net.Sockets.SocketException: A connection attempt failed because the
connected party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond...
Resolução:
Certifique-se de que a comunicação não está bloqueada para localhost, porta TCP 444. Para saber mais sobre os pré-requisitos do Microsoft Defender para Identidade, consulte portas.
Localização do log de implantação
Os logs de implantação do Defender para Identidade estão localizados no diretório temporário do usuário que instalou o produto. No local de instalação padrão, ele pode ser encontrado em: C:\Users\Administrator\AppData\Local\Temp (ou um diretório acima de %temp%). Para obter mais informações, consulte Solucionar problemas do Defender para Identidade usando logs.
Problema de autenticação de proxy apresentado como um erro de licença
Se durante a instalação do sensor você receber o seguinte erro: O sensor não conseguiu registrar devido a problemas de licenciamento.
Entradas do log de implantação:
[1C60:1AA8][2018-03-24T23:59:13]i000: 2018-03-25 02:59:13.1237 Info InteractiveDeploymentManager ValidateCreateSensorAsync returned [validateCreateSensorResult=LicenseInvalid]]
[1C60:1AA8][2018-03-24T23:59:56]i000: 2018-03-25 02:59:56.4856 Info InteractiveDeploymentManager ValidateCreateSensorAsync returned [validateCreateSensorResult=LicenseInvalid]]
[1C60:1AA8][2018-03-25T00:27:56]i000: 2018-03-25 03:27:56.7399 Debug SensorBootstrapperApplication Engine.Quit [deploymentResultStatus=1602 isRestartRequired=False]]
[1C60:15B8][2018-03-25T00:27:56]i500: Shutting down, exit code: 0x642
Causa:
Em alguns casos, ao se comunicar por meio de um proxy, durante a autenticação, ele pode responder ao sensor do Defender para Identidade com o erro 401 ou 403 em vez do erro 407. O sensor do Defender para Identidade interpreta o erro 401 ou 403 como um problema de licenciamento e não como um problema de autenticação de proxy.
Resolução:
Certifique-se de que o sensor possa navegar até *.atp.azure.com através do proxy configurado sem autenticação. Para obter mais informações, confira Configurar o proxy para habilitar a comunicação.
Problema de autenticação de proxy apresentado como um erro de conexão
Se durante a instalação do sensor você receber o seguinte erro: O sensor não conseguiu se conectar ao serviço.
Causa:
O problema pode ser causado quando os certificados de autoridades de certificação raiz confiáveis exigidos pelo Defender para Identidade estão ausentes.
Resolução:
Execute o cmdlet do PowerShell a seguir para verificar se os certificados necessários estão instalados.
No exemplo a seguir, use o certificado "DigiCert Baltimore Root" para todos os clientes. Além disso, use o certificado "DigiCert Global Root G2" para clientes comerciais ou use o certificado "DigiCert Global Root CA" para clientes GCC High do governo dos EUA, conforme indicado.
# Certificate for all customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "D4DE20D05E66FC53FE1A50882C78DB2852CAE474"} | fl
# Certificate for commercial customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "df3c24f9bfd666761b268073fe06d1cc8d4f82a4"} | fl
# Certificate for US Government GCC High customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436"} | fl
Saída para certificado para todos os clientes:
Subject : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer : CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Thumbprint : D4DE20D05E66FC53FE1A50882C78DB2852CAE474
FriendlyName : DigiCert Baltimore Root
NotBefore : 5/12/2000 11:46:00 AM
NotAfter : 5/12/2025 4:59:00 PM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Saída para certificado para certificado de clientes comerciais:
Subject : CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer : CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint : DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
FriendlyName : DigiCert Global Root G2
NotBefore : 01/08/2013 15:00:00
NotAfter : 15/01/2038 14:00:00
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Saída para certificado para clientes GCC High do governo dos EUA:
Subject : CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Issuer : CN=DigiCert Global Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
Thumbprint : A8985D3A65E5E5C4B2D7D66D40C6DD2FB19C5436
FriendlyName : DigiCert
NotBefore : 11/9/2006 4:00:00 PM
NotAfter : 11/9/2031 4:00:00 PM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
Se você não vir a saída esperada, siga as seguintes etapas:
Baixe os certificados a seguir para o computador Server Core. Para todos os clientes, faça o download do certificado Baltimore CyberTrust Root.
Além disso:
- Para clientes comerciais, baixe o certificado DigiCert Global Root G2.
- Para clientes GCC High do governo dos EUA, baixe o certificado DigiCert Global Root CA.
Use o cmdlet do PowerShell a seguir para instalar o certificado.
# For all customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\bc2025.crt" -CertStoreLocation Cert:\LocalMachine\Root # For commercial customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\DigiCertGlobalRootG2.crt" -CertStoreLocation Cert:\LocalMachine\Root # For US Government GCC High customers, install certificate Import-Certificate -FilePath "<PATH_TO_CERTIFICATE_FILE>\DigiCertGlobalRootCA.crt" -CertStoreLocation Cert:\LocalMachine\Root
Erro de instalação silenciosa ao tentar usar o PowerShell
Se durante a instalação silenciosa do sensor você tentar usar o PowerShell e receber o seguinte erro:
"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."
Causa:
Se você não incluir o prefixo ./ necessário para instalar ao usar o PowerShell verá esse erro.
Resolução:
Use o comando complete para instalar com êxito.
./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
Problema de agrupamento NIC do sensor do Defender para Identidade
Caso tente instalar o sensor do Defender para Identidade em um computador configurado com um adaptador de Agrupamento NIC e o driver Winpcap, você receberá um erro de instalação. Se você quiser instalar o sensor do Defender para Identidade em uma máquina configurada com agrupamento NIC, substitua o driver Winpcap por Npcap seguindo as instruções aqui.
Modo Multi Processor Group
Nos sistemas operacionais Windows 2008 R2 e 2012, não há suporte para o sensor do Defender para Identidade em um modo de Grupo de Multiprocessadores.
Sugestão de possíveis soluções alternativas:
Se o hyper threading estiver habilitado, desabilite-o. Isso pode reduzir o número de núcleos lógicos o suficiente para evitar a necessidade de execução no modo Multi Processor Group.
Se sua máquina tiver menos de 64 núcleos lógicos e estiver sendo executada em um host HP, você poderá alterar a configuração do BIOS NUMA Group Size Optimization do padrão de Clustered para Flat.
Problema do sensor na máquina virtual VMware
Se você tiver um sensor do Defender para Identidade em máquinas virtuais VMware, poderá receber o alerta de integridade Parte do tráfego de rede não está sendo analisada. Isso pode acontecer devido a uma incompatibilidade de configuração no VMware.
Como resolver o problema:
No SO convidado, defina o seguinte como Desabilitado na configuração da NIC da máquina virtual: IPv4 TSO Offload.
Use o seguinte comando para verificar se a opção LSO (Grande Envio de Descarregamento) está habilitada ou desabilitada:
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"
Se LSO estiver habilitado, use o seguinte comando para desabilitá-lo:
Disable-NetAdapterLso -Name {name of adapter}
Observação
- Dependendo da configuração, essas ações podem causar uma breve perda de conectividade de rede.
- Talvez seja necessário reiniciar o computador para as novas alterações entrarem em vigor.
- Essas etapas podem variar dependendo da sua versão do VMWare. Consulte a documentação do VMWare para obter informações sobre como desabilitar LSO/TSO para sua versão do VMWare.
O sensor não conseguiu recuperar credenciais da conta de serviço gerenciado de grupo (gMSA)
Se você receber o seguinte alerta de integridade: As credenciais de usuário dos serviços de diretório estão incorretas
Entradas de log do sensor:
2020-02-17 14:01:36.5315 Info ImpersonationManager CreateImpersonatorAsync started [UserName=account_name Domain=domain1.test.local IsGroupManagedServiceAccount=True]
2020-02-17 14:01:36.5750 Info ImpersonationManager CreateImpersonatorAsync finished [UserName=account_name Domain=domain1.test.local IsSuccess=False]
Entradas de log do atualizador de sensor:
2020-02-17 14:02:19.6258 Warn GroupManagedServiceAccountImpersonationHelper GetGroupManagedServiceAccountAccessTokenAsync failed GMSA password could not be retrieved [errorCode=AccessDenied AccountName=account_name DomainDnsName=domain1.test.local]
O sensor não conseguiu recuperar a senha da conta gMSA.
Causa 1
O controlador de domínio não recebeu permissão para recuperar a senha da conta gMSA.
Resolução 1:
Valide se o computador que executa o sensor recebeu permissões para recuperar a senha da conta gMSA. Para obter mais informações, consulte Conceder permissões para recuperar a senha da conta gMSA.
Causa 2
O serviço do sensor é executado como LocalService e se faz passar pela conta de Serviço de Diretório.
Se a política de atribuição de direitos do usuário Fazer logon como um serviço estiver configurada para o controlador de domínio, a usurpação de identidade falhará, a menos que a conta gMSA receba a permissão Fazer logon como um serviço.
Resolução 2:
Configure Fazer logon como um serviço para as contas gMSA, quando a política de atribuição de direitos do usuário Fazer logon como um serviço estiver configurada no controlador de domínio afetado. Para obter mais informações, consulte Verificar se a conta gMSA tem os direitos necessários.
Causa 3
Se o tíquete do Kerberos do controlador de domínio tiver sido emitido antes de o controlador de domínio ter sido adicionado ao grupo de segurança com as permissões adequadas, esse grupo não fará parte do tíquete do Kerberos. Portanto, ele não pode recuperar a senha da conta gMSA.
Resolução 3:
Execute uma das seguintes ações para resolver o problema:
Reinicialize o controlador de domínio.
Limpe o tíquete do Kerberos, forçando o controlador de domínio a solicitar um novo tíquete do Kerberos. Em um prompt de comando de administrador no controlador de domínio, execute o seguinte comando:
klist -li 0x3e7 purgeAtribua a permissão para recuperar a senha do gMSA a um grupo do qual o controlador de domínio já é membro, como o grupo Controladores de Domínio.
O serviço do sensor falhou ao iniciar
Entradas de log do sensor:
Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=AATP_gMSA]
Causa:
O controlador de domínio não recebeu direitos para acessar a senha da conta gMSA.
Resolução:
Verifique se o controlador de domínio recebeu direitos para acessar a senha. Você deve ter um Grupo de Segurança no Active Directory que contenha o(s) controlador(es) de domínio, servidor(es) AD FS/AD CS e contas de computador de sensores autônomos incluídos. Se isso não existir, recomendamos que você crie um.
Você pode usar o comando a seguir para verificar se uma conta de computador ou grupo de segurança foi adicionado ao parâmetro. Substitua mdiSvc01 pelo nome que você criou.
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
O resultado deve parecer com o seguinte:
Neste exemplo, podemos ver que um grupo chamado mdiSvc01Group foi adicionado. Se o controlador de domínio ou o grupo de segurança não tiver sido adicionado, você poderá usar os seguintes comandos para adicioná-lo. Substitua mdiSvc01 pelo nome de gMSA e substitua DC1 pelo nome do controlador de domínio ou mdiSvc01Group pelo nome do grupo de segurança.
# To set the specific domain controller only:
$specificDC = Get-ADComputer -Identity DC1
Set-ADServiceAccount mdiSvc01 -PrincipalsAllowedToRetrieveManagedPassword $specificDC
# To set a security group that contains the relevant computer accounts:
$group = Get-ADGroup -Identity mdiSvc01Group
Set-ADServiceAccount mdiSvc01 -PrincipalsAllowedToRetrieveManagedPassword $group
Se o controlador de domínio ou grupo de segurança já tiver sido adicionado, mas você ainda estiver vendo o erro, tente as seguintes etapas:
- Opção 1: reinicialize o servidor para sincronizar as alterações recentes
- Opção 2:
- Definir os serviços AATPSensor e AATPSensorUpdater como Desabilitado
- Parar os serviços AATPSensor e AATPSensorUpdater
- Coloque a conta de serviço em cache para o servidor usando o comando:
Install-ADServiceAccount gMSA_AccountName - Definir os serviços AATPSensor e AATPSensorUpdater como Automático
- Iniciar o serviço AATPSensorUpdater
O acesso à chave do Registro "Global" é negado
O serviço do sensor falha ao iniciar e o log do sensor contém uma entrada semelhante a:
2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
Causa:
A gMSA configurada para este controlador de domínio ou servidor de AD FS/AD CS não tem permissões para as chaves do Registro do contador de desempenho.
Resolução:
Adicione a gMSA ao grupo Usuários do Monitor de Desempenho no servidor.
Os downloads de relatórios não podem conter mais de 300 mil entradas
O Defender para Identidade não oferece suporte a downloads de relatórios que contenham mais de 300 mil entradas por relatório. Os relatórios são renderizados como incompletos se mais de 300 mil entradas forem incluídas.
Causa:
Essa é uma limitação de engenharia.
Resolução:
Não há uma resolução conhecida.
O sensor não consegue enumerar logs de eventos
Se você observar um número limitado ou a falta de, alertas de eventos de segurança ou atividades lógicas no console do Defender para Identidade, mas nenhum problema de integridade será acionado.
Entradas de log do sensor:
Error EventLogException System.Diagnostics.Eventing.Reader.EventLogException: The handle is invalid at void System.Diagnostics.Eventing.Reader.EventLogException.Throw(int errorCode) at object System.Diagnostics.Eventing.Reader.NativeWrapper.EvtGetEventInfo(EventLogHandle handle, EvtEventPropertyId enumType) at string System.Diagnostics.Eventing.Reader.EventLogRecord.get_ContainerLog()
Causa:
Uma Lista de Controle de Acesso Discricionário está limitando o acesso aos logs de eventos necessários pela conta do Serviço Local.
Resolução:
Certifique-se de que a Lista de Controle de Acesso Discricionário (DACL) inclua a seguinte entrada (este é o SID do serviço AATPSensor).
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
Verifique se a DACL do Log de Eventos de Segurança foi configurada por um GPO:
Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access
Anexe a entrada acima à política existente. Execute C:\Windows\System32\wevtutil.exe gl security depois para verificar se a entrada foi adicionada.
Os logs locais do Defender para Identidade agora devem exibir:
Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]
ApplyInternal falhou na conexão SSL bidirecional com o erro de serviço
Se durante a instalação do sensor você receber o seguinte erro: ApplyInternal falhou na conexão SSL bidirecional com o serviço e o log do sensor contiver uma entrada semelhante a:
2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal falhou na conexão SSL bidirecional com o serviço.
O problema pode ser causado por um proxy com inspeção SSL habilitada.
[_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]`
Causa:
O problema pode ser causado quando os valores de registro SystemDefaultTlsVersions ou SchUseStrongCrypto não estão definidos com o valor padrão de 1.
Resolução:
Verifique se os valores de registro SystemDefaultTlsVersions e SchUseStrongCrypto estão definidos como 1:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
Problema ao instalar o sensor no Windows Server 2019 com o KB5009557 instalado, ou em um servidor com permissões de EventLog protegidas.
A instalação do sensor pode falhar com a mensagem de erro:
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
Resolução:
Há duas soluções alternativas para esse problema:
Instale o sensor com PSExec:
psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"Instale o sensor com uma Tarefa Agendada configurada para ser executada como LocalSystem. A sintaxe de linha de comando a ser usada é mencionada em Instalação silenciosa do sensor do Defender para Identidade.
A instalação do sensor falha devido ao cliente de gerenciamento de certificados
Se a instalação do sensor falhar e o arquivo Microsoft.Tri.Sensor.Deployment.Deployer.log contiver uma entrada semelhante a:
2022-07-15 03:45:00.0000 Error IX509CertificateRequestCertificate2 Deployer failed [arguments=128Ve980dtms0035h6u3Bg==] System.Runtime.InteropServices.COMException (0x80090008): CertEnroll::CX509CertificateRequestCertificate::Encode: Invalid algorithm specified. 0x80090008 (-2146893816 NTE_BAD_ALGID)
Causa:
O problema pode ser causado quando um cliente de gerenciamento de certificados, como o Entrust Entelligence Security Provider (EESP), está impedindo que a instalação do sensor crie um certificado autoassinado no computador.
Resolução:
Desinstale o cliente de gerenciamento de certificados, instale o sensor do Defender para Identidade e reinstale o cliente de gerenciamento de certificados.
Observação
O certificado autoassinado é renovado a cada 2 anos e o processo de renovação automática pode falhar se o cliente de gerenciamento de certificados impedir a criação do certificado autoassinado. Isso fará com que o sensor pare de se comunicar com o back-end, o que exigirá uma reinstalação do sensor usando a solução alternativa mencionada acima.
A instalação do sensor falha devido a problemas de conectividade de rede
Se a instalação do sensor falhar com um código de erro de 0x80070643 e o arquivo de log de instalação contiver uma entrada semelhante a:
[22B8:27F0][2016-06-09T17:21:03]e000: Error 0x80070643: Failed to install MSI package.
Causa:
O problema pode ser causado quando o processo de instalação não consegue acessar os serviços de nuvem do Defender para Identidade para o registro do sensor.
Resolução:
Certifique-se de que o sensor possa navegar até *.atp.azure.com diretamente ou através do proxy configurado. Se necessário, defina as configurações do servidor proxy para a instalação usando a linha de comando:
"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]
Para obter mais informações, consulte Executar uma instalação silenciosa com uma configuração de proxy.
O serviço do sensor não pôde ser executado e permanece no estado Inicial
Os seguintes erros aparecerão no Log do sistema no Visualizador de eventos:
- O procedimento Aberto do serviço ".NETFramework" no DLL "C:\Windows\system32\mscoree.dll" falhou com o código de erro "Acesso negado". Os dados de desempenho não estão disponíveis para esse serviço.
- O procedimento aberto do serviço "Lsa" no DLL "C:\Windows\System32\Secur32.dll" falhou com o código de erro "Acesso negado". Os dados de desempenho não estão disponíveis para esse serviço.
- O procedimento Aberto para o serviço "WmiApRpl" no DLL "C:\Windows\system32\wbem\wmiaprpl.dll" falhou com o código de erro "O dispositivo não está pronto". Os dados de desempenho não estão disponíveis para esse serviço.
O arquivo Microsoft.TriSensorError.log conterá um erro semelhante a este:
Microsoft.Tri.Sensor.DirectoryServicesClient.TryCreateLdapConnectionAsync(DomainControllerConnectionData domainControllerConnectionData, bool isGlobalCatalog, bool isTraversing) 2021-07-13 14:56:20.2976 Error DirectoryServicesClient Microsoft.Tri.Infrastructure.ExtendedException: Failed to communicate with configured domain controllers at new Microsoft.Tri.Sensor.DirectoryServicesClient(IConfigurationManager
Causa:
NT Service\Todos os Serviços não têm o direito de fazer logon como um serviço.
Resolução:
Adicione a Política do Controlador de Domínio com o logon como um serviço. Para obter mais informações, consulte Verificar se a conta gMSA tem os direitos necessários.
Seu espaço de trabalho não foi criado porque um grupo de segurança com o mesmo nome já existe no Microsoft Entra ID
Causa:
O problema pode surgir quando uma licença de espaço de trabalho do Defender para Identidade expira e é excluída quando o período de retenção termina, mas os grupos do Microsoft Entra não foram excluídos.
Resolução:
- Vá para o Portal do Azure ->Microsoft Entra ID ->Grupos
- Renomeie os três grupos a seguir (em que workspaceName é o nome do seu espaço de trabalho), adicionando a eles um sufixo " - old":
- "Azure ATP workspaceName Administrators" -> "Azure ATP workspaceName Administrators - old"
- "Azure ATP workspaceName Viewers" -> "Azure ATP workspaceName Viewers - old"
- "Azure ATP workspaceName Users" -> "Azure ATP workspaceName Users - old"
- Em seguida, você pode voltar ao portal do Microsoft Defender, na seção Configurações ->Identidades para criar o novo espaço de trabalho para o Defender para Identidade.