Resolver problemas Microsoft Defender para Identidade conhecidos

Este artigo descreve como resolver problemas conhecidos no Microsoft Defender para Identidade.

Falha ao iniciar o serviço do sensor

Entradas do registo do sensor:

Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=mdiSvc01]

Causa 1

O controlador de domínio não tem direitos para aceder à palavra-passe da conta gMSA.

Resolução 1:

Verifique se o controlador de domínio tem direitos para aceder à palavra-passe. Deve existir um grupo de segurança no Active Directory que inclua o controlador de domínio, o Microsoft Entra Connect, o servidor de Serviços de Federação do Active Directory (AD FS) / Serviços de Certificados do Active Directory (AD CS) e as contas de computador dos sensores autónomos incluídos. Se o Grupo de segurança não existir, recomendamos que crie um.

Pode utilizar o seguinte comando para verificar se uma conta de computador ou um grupo de segurança é adicionado ao parâmetro . Substitua mdiSvc01 pelo nome que criou.

Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword

Os resultados devem ter o seguinte aspeto:

Resultados do Powershell.

Neste exemplo, podemos ver que foi adicionado um grupo com o nome mdiSvc01Group . Se o controlador de domínio ou o grupo de segurança não tiverem sido adicionados, pode utilizar os seguintes comandos para o adicionar. Substitua mdiSvc01 pelo nome 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 o grupo de segurança já estiver adicionado, mas continuar a ver o erro, pode experimentar os seguintes passos:

  • Reiniciar o servidor para sincronizar as alterações recentes
  • Elimine o ticket Kerberos, obrigando o servidor a solicitar um novo ticket Kerberos. A partir de uma linha de comandos de administrador, execute o seguinte comando klist -li 0x3e7 purge

Causa 2

Devido a um cenário conhecido relacionado com Secure Time Seeding, o atributo PasswordLastSet da gMSA pode ficar definido com uma data futura, fazendo com que o sensor não consiga iniciar.

O seguinte comando pode ser utilizado para confirmar se a conta gMSA se enquadra no cenário, quando os valores PasswordLastSet e LastLogonDate mostram uma data futura:

Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet, LastLogonDate

Resolução 2:

Como solução provisória, pode ser criada uma nova gMSA que tenha a data correta para o atributo . É aconselhável abrir um pedido de suporte com os serviços de diretório para identificar a causa principal e explorar as opções para uma resolução abrangente.

Erro de comunicação de falha do sensor

Se receber o seguinte erro de falha do sensor:

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...

Solução:

Certifique-se de que a comunicação não está bloqueada para localhost, porta TCP 443. Para saber mais sobre os pré-requisitos do Microsoft Defender para Identidade, veja portas.

Localização do registo de implementação

Os registos de implementação do Defender para Identidade estão localizados no diretório temporário do utilizador que instalou o produto. Na localização de instalação predefinida, pode encontrá-la em: C:\Users\Administrator\AppData\Local\Temp (ou num diretório acima de %temp%). Para obter mais informações, veja Troubleshooting Defender for Identity using logs (Resolver problemas do Defender para Identidade com registos).

O problema de autenticação do proxy é apresentado como um erro de licenciamento

Se durante a instalação do sensor receber o seguinte erro: O sensor não conseguiu registar-se devido a problemas de licenciamento.

Entradas do registo de implementaçã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 comunicar através de um proxy, durante a autenticação, poderá 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.

Solução:

Certifique-se de que o sensor consegue navegar para *.atp.azure.com através do proxy configurado sem autenticação. Para obter mais informações, veja Configurar o proxy para ativar a comunicação.

O problema de autenticação do proxy é apresentado como um erro de ligação

Se durante a instalação do sensor receber o seguinte erro: O sensor não conseguiu ligar ao serviço.

Causa:

O problema pode ser causado quando os certificados de autoridades de certificação de raiz fidedigna exigidos pelo Defender para Identidade estão em falta.

Solução:

Execute o seguinte cmdlet do PowerShell para verificar se os certificados necessários estão instalados.

No exemplo seguinte, o certificado "DigiCert Global Root G2" destina-se a clientes comerciais e o certificado "DigiCert Global Root CA" destina-se a clientes Government GCC High do Governo dos EUA, conforme indicado.

# Certificate for commercial customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"} | fl

# Certificate for US Government GCC High customers
Get-ChildItem -Path "Cert:\LocalMachine\Root" | where { $_.Thumbprint -eq "BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11"} | fl

Saída do certificado para o 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   : AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
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}

Resultado do 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   : BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
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 não vir o resultado esperado, utilize os seguintes passos:

  1. Transfira os seguintes certificados para o computador:

  2. Execute o seguinte cmdlet do PowerShell para instalar o certificado.

    # 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 utilizar o PowerShell

Se, durante a instalação do sensor silencioso, tentar utilizar o PowerShell e receber o seguinte erro:

"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."

Causa:

A falha ao incluir o prefixo ./ necessário para instalar ao utilizar o PowerShell causa este erro.

Solução:

Utilize o comando completo para instalar com êxito.

./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"

Problema de associação de NIC no sensor do Defender para Identidade

Quando instala o sensor do Defender para Identidade numa máquina configurada com um adaptador de agrupamento de NIC e o controlador WinPcap, recebe um erro de instalação. Se quiser instalar o sensor do Defender para Identidade numa máquina configurada com NIC teaming, certifique-se de que substitui o controlador Winpcap por Npcap seguindo as instruções aqui.

Modo de grupo multiprocessador

Para os sistemas operativos Windows 2008R2 e 2012, o sensor do Defender para Identidade não é suportado no modo Grupo de Multiprocessadores.

Soluções possíveis sugeridas:

  • Se o hyper threading estiver ativado, desative-o. Isto pode reduzir o número de núcleos lógicos o suficiente para evitar a necessidade de executar no modo de Grupo Multiprocessador .

  • Se a sua máquina tiver menos de 64 núcleos lógicos e estiver a ser executada num anfitrião HP, poderá alterar a definição da BIOS NUMA Group Size Optimization do valor predefinido Clustered para Flat.

Problema do sensor da máquina virtual do VMware

Se tiver um sensor do Defender for Identity em máquinas virtuais VMware, poderá receber um ou ambos os seguintes alertas de estado de funcionamento: Parte do tráfego de rede não está a ser analisado e Incompatibilidade de configuração de rede para sensores em execução no VMware. Isto pode acontecer devido a uma incompatibilidade de configuração entre a NIC do sistema operativo convidado do VMware e os requisitos do Sensor MDI.

Como resolver o problema:

No sistema operativo convidado, defina o seguinte como Desativado na configuração da placa de rede da máquina virtual: Descarregamento de TSO de IPv4.

Problema do sensor VMware.

Utilize o seguinte comando para verificar se a Descarga de Envio Grande (LSO) está ativada ou desativada:

Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"

Verifique o estado do LSO.

Se o LSO estiver ativado, utilize o seguinte comando para desativá-lo:

Disable-NetAdapterLso -Name {name of adapter}

Desative o estado LSO.

Nota

  • Consoante a configuração, estas ações podem causar uma breve perda de conectividade de rede.
  • Poderá ter de reiniciar o computador para que estas alterações entrem em vigor.
  • Estes passos podem variar consoante a sua versão do VMware. Consulte a documentação do VMware para obter informações sobre como desativar o LSO/TSO para a versão do VMware.

O sensor não conseguiu obter as credenciais da conta de serviço gerida de grupo (gMSA)

Se receber o seguinte alerta de integridade: As credenciais de utilizador dos serviços de diretório estão incorretas

Entradas do registo 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 registo do Sensor Updater:

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 obter a palavra-passe da conta gMSA.

Causa 1

O controlador de domínio não tem permissões para obter a palavra-passe da conta gMSA.

Resolução 1:

Confirme que foi concedida permissão ao computador que executa o sensor para obter a palavra-passe da conta gMSA. Para obter mais informações, veja Conceder permissões para obter a palavra-passe da conta gMSA.

Causa 2

O serviço de sensor é executado como LocalService e realiza a representação da conta do Serviço de Diretório.

Se a política de atribuição de direitos de utilizador Iniciar sessão como um serviço estiver configurada para este controlador de domínio, a representação falhará, a menos que a conta gMSA tenha a permissão Iniciar sessão como um serviço .

Resolução 2:

Configure Iniciar sessão como um serviço para as contas gMSA quando a política de atribuição de direitos de utilizador Iniciar sessão como um serviço estiver configurada no controlador de domínio afetado. Para obter mais informações, veja Verificar se a conta gMSA tem os direitos necessários.

Causa 3

Se o bilhete Kerberos do controlador de domínio tiver sido emitido antes de o controlador de domínio ser adicionado ao grupo de segurança com as permissões adequadas, este grupo não fará parte do bilhete Kerberos. Por isso, não pode obter a palavra-passe da conta gMSA.

Resolução 3:

Efetue um dos seguintes procedimentos para resolver este problema:

  • Reinicie o controlador de domínio.

  • Remova a permissão Kerberos, forçando o controlador de domínio a pedir uma nova permissão Kerberos. A partir de uma linha de comandos de administrador no controlador de domínio, execute o seguinte comando:

    klist -li 0x3e7 purge

  • Atribua a permissão para obter a palavra-passe do gMSA para um grupo do qual o controlador de domínio já seja membro, como o grupo Controladores de Domínio.

Acesso à chave de registo "Global" negado

O serviço de sensor não inicia e o registo 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 AD FS/AD CS não tem permissões para as chaves de registo do contador de desempenho.

Solução:

Adicione o gMSA ao grupo Utilizadores do Registo de Desempenho no servidor.

Os downloads de relatórios não podem conter mais de 300 000 registos

O Defender para Identidade não suporta transferências de relatórios que contenham mais de 300 000 entradas por relatório. Os relatórios são apresentados como incompletos se incluírem mais de 300 000 registos.

Causa:

Esta é uma limitação de engenharia.

Solução:

Nenhuma resolução conhecida.

O sensor não enumera os registos de eventos

Se observar um número limitado ou falta de alertas de eventos de segurança ou atividades lógicas na consola do Defender para Identidade, mas não forem acionados problemas de estado de funcionamento.

Entradas do registo 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 Controlo de Acesso Discricionária está a limitar o acesso aos registos de eventos necessários pela conta do Serviço Local.

Solução:

Certifique-se de que a Lista de Controlo de Acesso Discricionários (DACL) inclui 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 Registo de Eventos de Segurança foi configurada por um GPO:

Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access

Acrescente a entrada acima à política existente. Execute C:\Windows\System32\wevtutil.exe gl security posteriormente para verificar se a entrada foi adicionada.

Os registos locais do Defender for Identity devem agora apresentar:

Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]

ApplyInternal falhou na ligação SSL bidirecional ao serviço

Se durante a instalação do sensor receber o seguinte erro: ApplyInternal falhou na ligação SSL bidirecional ao serviço e o registo do sensor contém uma entrada semelhante a:

2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal falhou na ligação SSL bidirecional ao serviço. O problema pode ser causado por um proxy com a inspeção SSL ativada. [_workspaceApplicationSensorApiEndpoint=Não especificado/contoso.atp.azure.com:443 Impressão digital=CC33DD44EE55FF66AA77BB88CC99DD00EE11FF22]'

Causa:

O problema pode ser causado quando os valores do registo SystemDefaultTlsVersions ou SchUseStrongCrypto não estão definidos para o valor predefinido de 1.

Solução:

Verifique se os valores do registo 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 KB5009557 instalado ou num servidor com permissões do EventLog endurecidas

A instalação do sensor pode falhar com a mensagem de erro:

System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

Solução:

Existem duas soluções possíveis para este problema:

  1. Instale o sensor com PSExec:

    psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"
    
  2. Instale o sensor com uma Tarefa Agendada configurada para ser executada como LocalSystem. A sintaxe da linha de comandos a utilizar é indicada em Instalação silenciosa do sensor do Defender para Identidade.

A instalação do sensor falha devido ao cliente de gestão de certificados

Se a instalação do sensor falhar e o ficheiro de 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 gestão de certificados, como o Fornecedor de Segurança Entrust Entelligence (EESP) está a impedir a instalação do sensor de criar um certificado autoassinado no computador.

Solução:

Desinstale o cliente de gestão de certificados, instale o sensor do Defender para Identidade e, em seguida, reinstale o cliente de gestão de certificados.

Nota

O certificado autoassinado é renovado de dois em dois anos e o processo de renovação automática poderá falhar se o cliente de gestão de certificados impedir a criação do certificado autoassinado. Isto faz com que o sensor deixe de comunicar com o back-end, o que requer uma reinstalação do sensor com a solução 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 ficheiro de registo 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 aceder aos serviços cloud do Defender para Identidade para o registo do sensor.

Solução:

Certifique-se de que o sensor pode navegar para *.atp.azure.com diretamente ou através do proxy configurado. Se necessário, defina as definições do servidor proxy para a instalação com a linha de comandos:

"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]

Para obter mais informações, veja Executar uma instalação silenciosa com uma configuração de proxy e Instalar o sensor de Microsoft Defender para Identidade.

Importante

A Microsoft recomenda que utilize o fluxo de autenticação mais seguro disponível. O fluxo de autenticação descrito neste procedimento requer um grau muito elevado de confiança na aplicação e acarreta riscos que não estão presentes noutros fluxos. Só deve utilizar este fluxo quando outros fluxos mais seguros, como identidades geridas, não forem viáveis.

Não foi possível iniciar o serviço do sensor, que continua no estado "A iniciar"

Os seguintes erros serão apresentados no Registo do sistema no Visualizador de eventos:

  • O procedimento Open para o serviço ".NETFramework" da DLL "C:\Windows\system32\mscoree.dll" falhou com o código de erro «Acesso negado». Os dados de desempenho deste serviço não estarão disponíveis.
  • O procedimento "Open" do serviço "Lsa" na DLL "C:\Windows\System32\Secur32.dll" falhou com o código de erro: Acesso negado. Os dados de desempenho deste serviço não estarão disponíveis.
  • O procedimento Open para o serviço "WmiApRpl" na DLL "C:\Windows\system32\wbem\wmiaprpl.dll" falhou com o código de erro "O dispositivo não está pronto". Os dados de desempenho deste serviço não estarão disponíveis.

O Microsoft.TriSensorError.log irá conter um erro semelhante ao seguinte:

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\All Services não tem o direito de iniciar sessão como serviço.

Solução:

Adicione a Política de Controlador de Domínio com o início de sessão como um serviço. Para obter mais informações, veja Verificar se a conta gMSA tem os direitos necessários.

A área de trabalho não foi criada porque já existe um grupo de segurança com o mesmo nome no Microsoft Entra ID

Causa:

O problema pode surgir quando uma licença da área de trabalho do Defender for Identity expira e é eliminada após o termo do período de retenção, mas os grupos do Microsoft Entra não foram eliminados.

Solução:

  1. Aceda ao portal do Azure ->Microsoft Entra ID ->Groups
  2. Mude o nome dos três grupos seguintes (em que workspaceName é o nome da área de trabalho), adicionando-lhes um sufixo " - antigo":
    • "Azure workspaceName Administrators" -> "Azure atp workspaceName Administrators - old"
    • "Azure ATP workspaceName Visualizadores" -> "Azure ATP workspaceName Visualizadores - antigo"
    • "Azure ATP workspaceName Users" -> "Azure ATP workspaceName Users - antigo"
  3. Em seguida, pode voltar ao portal do Microsoft Defender, à secção Definições ->Identidades para criar a nova área de trabalho do Defender para Identidade.

O sensor do Entra Connect experimenta a perda de permissões da base de dados após a atualização para o Microsoft Entra Connect

Causa:

A atualização Microsoft Entra Connect pode fazer com que o sensor do Entra Connect perca as permissões da base de dados configurada anteriormente. Para investigar, verifique se existem indicadores relevantes nos registos do Microsoft Defender. Consulte Resolução de problemas do sensor do Microsoft Defender para Identidade com os registos do Defender para Identidade para obter as localizações dos registos e mais detalhes.

Registos de exemplo que podem indicar o problema:

GetEntraConnectGlobalSettingsAsync GetEntraConnectGlobalSettingsAsync failed. Exception - The EXECUTE permission was denied on the object 'mms_get_globalsettings', database Contoso', schema 'dbo'

GetEntraConnectConnectivityParametersAsync GetEntraConnectConnectivityParametersAsync failed. Exception - The EXECUTE permission was denied on the object 'mms_get_connectors', database Contoso, schema 'dbo'

Solução:

Se precisar de reconfigurar as permissões, siga os passos descritos neste guia.

Os alertas de auditoria sobre o estado de funcionamento persistem no sensor v3.x

Em alguns ambientes a correr o sensor Microsoft Defender para Identidade v3.x, os seguintes alertas de saúde podem persistir mesmo quando a auditoria está configurada corretamente:

  • A auditoria no contentor ADFS não está ativada conforme necessário
  • A auditoria no contentor de Configuração não está ativada como necessário

Este problema ocorre principalmente em ambientes que configuram a auditoria manualmente, como através de Group Policy ou PowerShell. O sensor mantém-se saudável e as deteções não são afetadas. Para resolver o problema, no portal Microsoft Defender, vá a Definições>>Identidades Funcionalidades Avançadas e ative a Configuração Automática de Auditoria do Windows. Espera-se que este problema seja resolvido numa futura atualização dos sensores.

Passos seguintes