Partilhar via


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

Não foi concedido ao controlador de domínio direitos para aceder à palavra-passe da conta gMSA.

Resolução 1:

Verifique se foi concedido ao controlador de domínio direitos para aceder à palavra-passe. Deve ter um Grupo de Segurança no Active Directory que contenha os controladores de domínio, Entra Connect, servidores AD FS/AD CS e contas de computador de sensores autónomos incluídos. Se isto não existir, recomendamos que crie um.

Pode utilizar o seguinte comando para verificar se foi adicionada uma conta de computador ou um grupo de segurança 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
  • Remova a permissão Kerberos, forçando o servidor a pedir uma nova permissão 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 a Propagação do Tempo Seguro, o atributo gMSA PasswordLastSet pode ser definido para uma data futura, o que faz 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 terá 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 444. Para saber mais sobre Microsoft Defender para Identidade pré-requisitos, 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, utilize o certificado "DigiCert Baltimore Root" para todos os clientes. Além disso, utilize o certificado "DigiCert Global Root G2" para clientes comerciais ou utilize o certificado "DigiCert Global Root CA" para clientes us Government GCC High, 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 do 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 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   : 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 do certificado para clientes us government GCC High:

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

  1. Transfira os seguintes certificados para o computador Server Core. Para todos os clientes, transfira o certificado de raiz Baltimore CyberTrust .

    Além disso:

  2. Execute o seguinte cmdlet do PowerShell 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 automática 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 agrupamento nic do sensor do Defender para Identidade

Quando instala o sensor do Defender para Identidade num computador configurado com um adaptador de agrupamento NIC e o controlador Winpcap, recebe um erro de instalação. Se quiser instalar o sensor do Defender para Identidade num computador configurado com agrupamento NIC, certifique-se de que substitui o controlador Winpcap por Npcap ao seguir as instruções aqui.

Modo de Grupo com Vários Processadores

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

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 ser executado no modo grupo de processadores múltiplos .

  • Se o computador tiver menos de 64 núcleos lógicos e estiver em execução num anfitrião HP, poderá conseguir alterar a definição BIOS de Otimização do Tamanho do Grupo NUMA da predefinição de Clustered para Flat.

Problema do sensor da máquina virtual do VMware

Se tiver um sensor do Defender para Identidade em máquinas virtuais VMware, poderá receber o alerta de estado de funcionamento Algum tráfego de rede não está a ser analisado. Isto pode acontecer devido a um erro de correspondência de configuração no VMware.

Como resolver o problema:

No SO Convidado, defina o seguinte como Desativado na configuração NIC da máquina virtual: Descarga de TSO 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 sua 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 estado de funcionamento: 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

Não foi concedida permissão ao controlador de domínio 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 a permissão kerberos do controlador de domínio tiver sido emitida antes de o controlador de domínio ser adicionado ao grupo de segurança com as permissões adequadas, este grupo não faz parte da permissão 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 Monitor de Desempenho no servidor.

As transferências de relatórios não podem conter mais de 300 000 entradas

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 compostos como incompletos se estiverem incluídas mais de 300 000 entradas.

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 para Identidade devem agora ser apresentados:

Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]

ApplyInternal falhou na ligação SSL bidirecional ao erro de 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=Specificed/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]'

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 é mencionada na 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 a cada 2 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 fará com que o sensor deixe de comunicar com o back-end, o que exigirá 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.

O serviço de sensor não pôde ser executado e permanece no estado A iniciar

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

  • O procedimento Abrir para o serviço ". NETFramework" na 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 para o serviço "Lsa" na DLL "C:\Windows\System32\Secur32.dll" falhou com o código de erro O acesso é negado. Os dados de desempenho para este 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:

Serviço NT\Todos os Serviços não têm o direito de iniciar sessão como um 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 para Identidade expira e é eliminada quando o período de retenção termina, mas os grupos de Microsoft Entra não foram eliminados.

Solução:

  1. Aceda ao portal do Azure ->Microsoft Entra ID ->Grupos
  2. Mude o nome dos três grupos seguintes (em que workspaceName é o nome da área de trabalho), adicionando-lhes um sufixo " - antigo":
    • "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"
  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.

Passos seguintes