Risoluzione dei problemi Microsoft Defender per identità noti
Questo articolo descrive come risolvere i problemi noti in Microsoft Defender per identità.
Il servizio sensore non viene avviato
Voci di log dei sensori:
Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=mdiSvc01]
Causa 1
Al controller di dominio non sono stati concessi i diritti per accedere alla password dell'account gMSA.
Risoluzione 1:
Verificare che al controller di dominio siano stati concessi i diritti per accedere alla password. In Active Directory dovrebbe essere presente un gruppo di sicurezza contenente gli account computer dei controller di dominio, Entra Connect, AD FS/AD CS e sensori autonomi. Se questo non esiste, è consigliabile crearne uno.
È possibile usare il comando seguente per verificare se un account computer o un gruppo di sicurezza è stato aggiunto al parametro . Sostituire mdiSvc01 con il nome creato.
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
I risultati dovrebbero essere simili ai seguenti:
In questo esempio è possibile notare che è stato aggiunto un gruppo denominato mdiSvc01Group . Se il controller di dominio o il gruppo di sicurezza non è stato aggiunto, è possibile usare i comandi seguenti per aggiungerlo. Sostituire mdiSvc01 con il nome di gMSA e DC1 con il nome del controller di dominio o mdiSvc01Group con il nome del gruppo di sicurezza.
# 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 il controller di dominio o il gruppo di sicurezza è già stato aggiunto, ma l'errore persiste, è possibile provare la procedura seguente:
- Riavviare il server per sincronizzare le modifiche recenti
- Eliminare il ticket Kerberos, forzando il server a richiedere un nuovo ticket Kerberos. Da un prompt dei comandi dell'amministratore eseguire il comando seguente
klist -li 0x3e7 purge
Causa 2
A causa di uno scenario noto correlato al seeding dell'ora sicura, l'attributo gMSA PasswordLastSet può essere impostato su una data futura, causando l'impossibilità di avviare il sensore.
Il comando seguente può essere usato per verificare se l'account gMSA rientra nello scenario, quando i valori PasswordLastSet e LastLogonDate mostrano una data futura:
Get-ADServiceAccount mdiSvc01 -Properties PasswordLastSet, LastLogonDate
Risoluzione 2:
Come soluzione provvisoria, è possibile creare un nuovo account del servizio gestito del gruppo che avrà la data corretta per l'attributo. È consigliabile aprire una richiesta di supporto con i servizi directory per identificare la causa radice ed esplorare le opzioni per una risoluzione completa.
Errore di comunicazione del sensore
Se viene visualizzato l'errore di errore del sensore seguente:
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...
Risoluzione:
Assicurarsi che la comunicazione non sia bloccata per localhost, porta TCP 444. Per altre informazioni sui prerequisiti Microsoft Defender per identità, vedere porte.
Percorso del log di distribuzione
I log di distribuzione di Defender per identità si trovano nella directory temporanea dell'utente che ha installato il prodotto. Nel percorso di installazione predefinito è disponibile in: C:\Users\Administrator\AppData\Local\Temp (o una directory superiore a %temp%). Per altre informazioni, vedere Risoluzione dei problemi relativi a Defender per identità tramite i log.
Il problema di autenticazione proxy si presenta come un errore di licenza
Se durante l'installazione del sensore viene visualizzato l'errore seguente: Il sensore non è riuscito a registrarsi a causa di problemi di licenza.
Voci del log di distribuzione:
[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:
In alcuni casi, durante la comunicazione tramite un proxy, durante l'autenticazione potrebbe rispondere al sensore Defender per identità con l'errore 401 o 403 anziché l'errore 407. Il sensore Defender per identità interpreta l'errore 401 o 403 come un problema di licenza e non come un problema di autenticazione proxy.
Risoluzione:
Assicurarsi che il sensore possa passare a *.atp.azure.com tramite il proxy configurato senza autenticazione. Per altre informazioni, vedere Configurare il proxy per abilitare la comunicazione.
Il problema di autenticazione proxy si presenta come un errore di connessione
Se durante l'installazione del sensore viene visualizzato l'errore seguente: Il sensore non è riuscito a connettersi al servizio.
Causa:
Il problema può essere causato quando mancano i certificati delle autorità di certificazione radice attendibili richiesti da Defender per l'identità.
Risoluzione:
Eseguire il cmdlet di PowerShell seguente per verificare che siano installati i certificati necessari.
Nell'esempio seguente usare il certificato "DigiCert Baltimore Root" per tutti i clienti. Inoltre, usare il certificato "DigiCert Global Root G2" per i clienti commerciali o usare il certificato "DigiCert Global Root CA" per i clienti us government GCC High, come indicato.
# 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
Output per il certificato per tutti i clienti:
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}
Output per il certificato per il certificato dei clienti commerciali:
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}
Output per il certificato per i clienti 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 l'output previsto non è visualizzato, seguire questa procedura:
Scaricare i certificati seguenti nel computer Server Core. Per tutti i clienti, scaricare il certificato radice Baltimore CyberTrust .
Inoltre:
- Per i clienti commerciali, scaricare il certificato DigiCert Global Root G2
- Per i clienti us government GCC High, scaricare il certificato ca radice globale DigiCert
Eseguire il cmdlet di PowerShell seguente per installare il certificato.
# 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
Errore di installazione invisibile all'utente durante il tentativo di usare PowerShell
Se durante l'installazione del sensore invisibile all'utente si tenta di usare PowerShell e si riceve l'errore seguente:
"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."
Causa:
Il mancato inserimento del prefisso ./ necessario per l'installazione quando si usa PowerShell causa questo errore.
Risoluzione:
Usare il comando completo per eseguire correttamente l'installazione.
./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
Problema di teaming della scheda di interfaccia di rete del sensore defender per identità
Quando si installa il sensore Defender per identità in un computer configurato con una scheda di gruppo NIC e il driver Winpcap, viene visualizzato un errore di installazione. Se si vuole installare il sensore Defender per identità in un computer configurato con il teaming della scheda di interfaccia di rete, assicurarsi di sostituire il driver Winpcap con Npcap seguendo le istruzioni riportate qui.
Modalità gruppo multiprocessore
Per i sistemi operativi Windows 2008R2 e 2012, il sensore Defender per identità non è supportato in modalità Gruppo multiprocessore.
Possibili soluzioni alternative suggerite:
Se l'hyper threading è attivato, disattivarlo. Ciò può ridurre il numero di core logici sufficienti per evitare la necessità di eseguire in modalità Gruppo multiprocessore .
Se il computer ha meno di 64 core logici ed è in esecuzione in un host HP, potrebbe essere possibile modificare l'impostazione DEL BIOS ottimizzazione dimensioni gruppo NUMA dal valore predefinito Clustered a Flat.
Problema del sensore di macchine virtuali VMware
Se si dispone di un sensore Defender per identità nelle macchine virtuali VMware, è possibile che venga visualizzato l'avviso di integrità Alcuni traffico di rete non vengono analizzati. Ciò può verificarsi a causa di una mancata corrispondenza della configurazione in VMware.
Per risolvere il problema:
Nel sistema operativo guest impostare quanto segue su Disabilitato nella configurazione della scheda di interfaccia di rete della macchina virtuale: Offload TSO IPv4.
Usare il comando seguente per verificare se Large Send Offload (LSO) è abilitato o disabilitato:
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"
Se LSO è abilitato, usare il comando seguente per disabilitarlo:
Disable-NetAdapterLso -Name {name of adapter}
Nota
- A seconda della configurazione, queste azioni potrebbero causare una breve perdita di connettività di rete.
- Potrebbe essere necessario riavviare il computer per rendere effettive queste modifiche.
- Questi passaggi possono variare a seconda della versione di VMWare. Per informazioni su come disabilitare LSO/TSO per la versione di VMWare, vedere la documentazione di VMWare.
Il sensore non è riuscito a recuperare le credenziali dell'account del servizio gestito del gruppo (gMSA)
Se viene visualizzato l'avviso di integrità seguente: Le credenziali utente dei servizi directory non sono corrette
Voci di log dei sensori:
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]
Voci di log di 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]
Il sensore non è riuscito a recuperare la password dell'account gMSA.
Causa 1
Al controller di dominio non è stata concessa l'autorizzazione per recuperare la password dell'account gMSA.
Risoluzione 1:
Verificare che al computer che esegue il sensore siano state concesse le autorizzazioni per recuperare la password dell'account gMSA. Per altre informazioni, vedere Concedere le autorizzazioni per recuperare la password dell'account gMSA.
Causa 2
Il servizio sensore viene eseguito come LocalService ed esegue la rappresentazione dell'account del servizio directory.
Se il criterio di assegnazione dei diritti utente Accesso come servizio è configurato per questo controller di dominio, la rappresentazione non riesce a meno che all'account gMSA non venga concessa l'autorizzazione Accedi come servizio .
Risoluzione 2:
Configurare l'accesso come servizio per gli account gMSA quando i criteri di assegnazione dei diritti utente Accedere come servizio sono configurati nel controller di dominio interessato. Per altre informazioni, vedere Verificare che l'account gMSA disponga dei diritti necessari.
Causa 3
Se il ticket Kerberos del controller di dominio è stato emesso prima dell'aggiunta del controller di dominio al gruppo di sicurezza con le autorizzazioni appropriate, questo gruppo non farà parte del ticket Kerberos. Non è quindi possibile recuperare la password dell'account gMSA.
Risoluzione 3:
Per risolvere il problema, eseguire una delle operazioni seguenti:
Riavviare il controller di dominio.
Eliminare il ticket Kerberos, forzando il controller di dominio a richiedere un nuovo ticket Kerberos. Da un prompt dei comandi dell'amministratore nel controller di dominio eseguire il comando seguente:
klist -li 0x3e7 purgeAssegnare l'autorizzazione per recuperare la password dell'account del servizio gestito del gruppo a un gruppo di cui il controller di dominio è già membro, ad esempio il gruppo Controller di dominio.
Accesso alla chiave del Registro di sistema 'Global' negato
Il servizio sensore non viene avviato e il log del sensore contiene una voce simile a:
2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
Causa:
L'account del servizio gestito del servizio gestito configurato per questo controller di dominio o il server AD FS/AD CS non dispone delle autorizzazioni per le chiavi del Registro di sistema del contatore delle prestazioni.
Risoluzione:
Aggiungere gMSA al gruppo utenti Monitor prestazioni nel server.
I download dei report non possono contenere più di 300.000 voci
Defender per identità non supporta i download di report che contengono più di 300.000 voci per report. I report vengono visualizzati come incompleti se sono incluse più di 300.000 voci.
Causa:
Si tratta di una limitazione di progettazione.
Risoluzione:
Nessuna risoluzione nota.
Il sensore non riesce a enumerare i log eventi
Se si osserva un numero limitato, o la mancanza di, avvisi di eventi di sicurezza o attività logiche all'interno della console di Defender per identità, ma non vengono attivati problemi di integrità.
Voci di log dei sensori:
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:
Un elenco di Controllo di accesso discrezionali limita l'accesso ai log eventi richiesti dall'account del servizio locale.
Risoluzione:
Assicurarsi che l'elenco Controllo di accesso discrezionale includa la voce seguente (si tratta del SID del servizio AATPSensor).
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
Controllare se l'elenco DACL per il registro eventi di sicurezza è stato configurato da un oggetto Criteri di gruppo:
Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access
Aggiungere la voce precedente ai criteri esistenti. Eseguire C:\Windows\System32\wevtutil.exe gl security in seguito per verificare che la voce sia stata aggiunta.
I log di Defender per identità locali dovrebbero ora essere visualizzati:
Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]
Errore di connessione SSL a servizio ApplyInternal non riuscita
Se durante l'installazione del sensore viene visualizzato l'errore seguente: ApplyInternal failed two way SSL connection to service and the sensor log contains an entry similar to:
2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal ha avuto esito negativo per la connessione SSL bidirezionale al servizio.
Il problema può essere causato da un proxy con l'ispezione SSL abilitata.
[_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]'
Causa:
Il problema può essere causato quando i valori del Registro di sistema SystemDefaultTlsVersions o SchUseStrongCrypto non sono impostati sul valore predefinito 1.
Risoluzione:
Verificare che i valori del Registro di sistema SystemDefaultTlsVersions e SchUseStrongCrypto siano impostati su 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 durante l'installazione del sensore in Windows Server 2019 con KB5009557 installato o in un server con autorizzazioni EventLog protette
L'installazione del sensore potrebbe non riuscire con il messaggio di errore:
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
Risoluzione:
Esistono due possibili soluzioni alternative per questo problema:
Installare il sensore con PSExec:
psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"Installare il sensore con un'attività pianificata configurata per l'esecuzione come LocalSystem. La sintassi della riga di comando da usare è indicata nell'installazione invisibile all'utente del sensore Defender per identità.
L'installazione del sensore non riesce a causa del client di gestione dei certificati
Se l'installazione del sensore ha esito negativo e il file Microsoft.Tri.Sensor.Deployment.Deployer.log contiene una voce simile alla seguente:
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:
Il problema può essere causato quando un client di gestione dei certificati, ad esempio Entrust Entelligence Security Provider (EESP) impedisce all'installazione del sensore di creare un certificato autofirma nel computer.
Risoluzione:
Disinstallare il client di gestione dei certificati, installare il sensore Defender per identità e quindi reinstallare il client di gestione dei certificati.
Nota
Il certificato autofirmato viene rinnovato ogni 2 anni e il processo di rinnovo automatico potrebbe non riuscire se il client di gestione dei certificati impedisce la creazione del certificato autofirmato. In questo modo il sensore smetterà di comunicare con il back-end, che richiederà una reinstallazione del sensore usando la soluzione alternativa indicata in precedenza.
L'installazione del sensore ha esito negativo a causa di problemi di connettività di rete
Se l'installazione del sensore ha esito negativo con un codice di errore di 0x80070643 e il file di log dell'installazione contiene una voce simile a:
[22B8:27F0][2016-06-09T17:21:03]e000: Error 0x80070643: Failed to install MSI package.
Causa:
Il problema può essere causato quando il processo di installazione non può accedere ai servizi cloud defender per identità per la registrazione del sensore.
Risoluzione:
Assicurarsi che il sensore possa passare a *.atp.azure.com direttamente o tramite il proxy configurato. Se necessario, impostare le impostazioni del server proxy per l'installazione usando la riga di comando:
"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]
Per altre informazioni, vedere Eseguire un'installazione invisibile all'utente con una configurazione proxy e Installare il sensore Microsoft Defender per identità.
Importante
Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Il flusso di autenticazione descritto in questa procedura richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi non presenti in altri flussi. È consigliabile usare questo flusso solo quando altri flussi più sicuri, ad esempio le identità gestite, non sono validi.
Il servizio sensore non è stato eseguito e rimane in stato di avvio
Nel registro di sistema nel Visualizzatore eventi verranno visualizzati gli errori seguenti:
- Procedura Open per il servizio ". NETFramework" nella DLL "C:\Windows\system32\mscoree.dll" non riuscito con codice di errore Accesso negato. I dati sulle prestazioni per questo servizio non saranno disponibili.
- La procedura Open per il servizio "Lsa" nella DLL "C:\Windows\System32\Secur32.dll" non è riuscita con codice di errore Accesso negato. I dati sulle prestazioni per questo servizio non saranno disponibili.
- La procedura Open per il servizio "WmiApRpl" nella DLL "C:\Windows\system32\wbem\wmiaprpl.dll" non è riuscita con il codice di errore "Il dispositivo non è pronto". I dati sulle prestazioni per questo servizio non saranno disponibili.
Il Microsoft.TriSensorError.log conterrà un errore simile al seguente:
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 non ha il diritto di accedere come servizio.
Risoluzione:
Aggiungere criteri controller di dominio con l'accesso come servizio. Per altre informazioni, vedere Verificare che l'account gMSA disponga dei diritti necessari.
L'area di lavoro non è stata creata perché esiste già un gruppo di sicurezza con lo stesso nome in Microsoft Entra ID
Causa:
Il problema può verificarsi quando una licenza dell'area di lavoro Defender per identità scade e viene eliminata al termine del periodo di conservazione, ma i gruppi Microsoft Entra non sono stati eliminati.
Risoluzione:
- Passare al portale di Azure ->Microsoft Entra ID ->Gruppi
- Rinominare i tre gruppi seguenti (dove workspaceName è il nome dell'area di lavoro), aggiungendo loro un suffisso " - vecchio":
- "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"
- È quindi possibile tornare nel portale di Microsoft Defender alla sezione Impostazioni ->Identità per creare la nuova area di lavoro per Defender per identità.