Résolution des problèmes connus Microsoft Defender pour Identity
Cet article explique comment résoudre les problèmes connus dans Microsoft Defender pour Identity.
Erreur de communication des défaillances du capteur
Si vous recevez l’erreur de défaillance du capteur suivante :
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...
Résolution :
Assurez-vous que la communication n’est pas bloquée pour localhost, port TCP 444. Pour en savoir plus sur les prérequis Microsoft Defender pour Identity, consultez les ports.
Emplacement du journal de déploiement
Les journaux de déploiement Defender pour Identity se trouvent dans le répertoire temporaire de l’utilisateur qui a installé le produit. Dans l’emplacement d’installation par défaut, il se trouve à l’adresse suivante : C:\Users\Administrator\AppData\Local\Temp (ou un répertoire au-dessus de %temp%). Pour plus d’informations, consultez Résolution des problèmes liés à Defender pour Identity à l’aide des journaux.
Le problème d’authentification du proxy se présente sous la forme d’une erreur de licence
Si, lors de l’installation du capteur, vous recevez l’erreur suivante : Le capteur n’a pas pu s’inscrire en raison de problèmes de licence.
Entrées du journal de déploiement :
[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
Cause :
Dans certains cas, lorsque la communication s’effectue via un proxy, celui-ci peut, lors de l’authentification, répondre au capteur du Defender pour Identity par une erreur 401 ou 403 au lieu d’une erreur 407. Le capteur Defender pour Identity interprète l’erreur 401 ou 403 comme un problème de licence et non comme un problème d’authentification du proxy.
Résolution :
Vérifiez que le capteur peut accéder à *.atp.azure.com via le proxy configuré sans authentification. Pour plus d’information, consultez Configurer le proxy pour activer la communication.
Le problème d’authentification du proxy se présente sous la forme d’une erreur de connexion
Si, lors de l’installation du capteur, vous recevez l’erreur suivante : Le capteur n’a pas pu se connecter au service.
Cause :
Le problème peut être dû au fait que les certificats des autorités de certification racines approuvés requis par Defender pour Identity sont manquants.
Résolution :
Exécutez le cmdlet PowerShell suivante pour vérifier que les certificats requis sont installés.
Dans l’exemple suivant, utilisez le certificat « DigiCert Baltimore Root » pour tous les clients. En outre, utilisez le certificat « DigiCert Global Root G2 » pour les clients commerciaux ou utilisez le certificat « DigiCert Global Root CA » pour les clients GCC High du gouvernement américain, comme indiqué.
# 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
Sortie du certificat pour tous les clients :
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}
Sortie du certificat pour le certificat des clients commerciaux :
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}
Sortie du certificat pour les clients GCC High du gouvernement américain :
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}
Si vous ne voyez pas la sortie attendue, procédez comme suit :
Téléchargez les certificats suivants sur l’ordinateur Server Core. Pour tous les clients, téléchargez le certificat Baltimore CyberTrust root.
De plus :
- Pour les clients commerciaux, téléchargez le certificat DigiCert Global Root G2
- Pour les clients GCC High du gouvernement américain, téléchargez le certificat DigiCert Global Root CA.
Utilisez le cmdlet PowerShell suivant pour installer le certificat.
# 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
Erreur d’installation sans assitance lors de la tentative d’utilisation de PowerShell
Si, pendant l’installation sans assistance du capteur, vous tentez d’utiliser PowerShell et recevez l’erreur suivante :
"Azure ATP sensor Setup.exe" "/quiet" NetFrameworkCommandLineArguments="/q" Acce ... Unexpected token '"/quiet"' in expression or statement."
Cause :
L’échec d’inclusion du préfixe ./ requis pour l’installation lors de l’utilisation de PowerShell provoque cette erreur.
Résolution :
Utilisez la commande complète pour réussir l’installation.
./"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>"
Problème d’association de cartes réseau du capteur Defender pour Identity
Lorsque vous installer le capteur Defender pour Identity sur un ordinateur configuré avec un adaptateur d’association de cartes réseau et le pilote Winpcap, vous recevrez une erreur d’installation. Si vous souhaitez installer le capteur Defender pour Identity sur un ordinateur configuré avec l’association de cartes réseau, veillez à remplacer le pilote Winpcap par Npcap en suivant les instructions fournies ici.
Mode groupe multiprocesseur
Pour les systèmes d’exploitation Windows 2008R2 et 2012, le capteur Defender pour Identity n’est pas pris en charge en mode Groupe multiprocesseur.
Solutions de contournement possibles suggérées :
Si l’hyper threading est activé, désactivez-le. Cela peut réduire le nombre de cœurs logiques suffisants pour éviter d’avoir à s’exécuter en mode groupe multiprocesseur.
Si votre ordinateur a moins de 64 cœurs logiques et s’exécute sur un hôte HP, vous pouvez peut-être modifier le paramètre BIOS Optimisation de la taille du groupe NUMA, qui est par défaut Groupé, en Plat.
Problème de capteur de machine virtuelle VMware
Si vous disposez d’un capteur Defender pour Identity sur des machines virtuelles VMware, vous pouvez recevoir l’alerte d’intégrité Une partie du trafic réseau n’est pas analysé. Cela peut se produire en raison d’une incompatibilité de configuration dans VMware.
Pour résoudre le problème :
Sur le système d’exploitation invité, définissez ce qui suit sur Désactivé dans la configuration NIC de la machine virtuelle : IPv4 TSO Offload.
Utilisez la commande suivante pour vérifier si le déchargement d’envoi important (LSO) est activé ou désactivé :
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"
Si le LSO est activé, utilisez la commande suivante pour le désactiver :
Disable-NetAdapterLso -Name {name of adapter}
Remarque
- Selon votre configuration, ces actions peuvent entraîner une brève perte de connectivité réseau.
- Vous devrez peut-être redémarrer votre ordinateur pour que les modifications prennent effet.
- Ces étapes peuvent varier en fonction de votre version de VMWare. Consultez la documentation VMWare pour plus d’informations sur la façon de désactiver le LSO/TSO pour votre version de VMWare.
Le capteur n’a pas pu récupérer les informations d’identification du compte de service administré de groupe (gMSA)
Si vous recevez l’alerte d’intégrité suivante : Les informations d’identification d’utilisateur des services d’annuaire sont incorrectes
Entrées du journal du capteur :
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]
Entrées du journal du module de mise à jour du capteur :
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]
Le capteur n’a pas pu récupérer le mot de passe du compte gMSA.
Cause 1
Le contrôleur de domaine n’a pas été autorisé à récupérer le mot de passe du compte gMSA.
Résolution 1 :
Vérifiez que l’ordinateur exécutant le capteur a reçu des autorisations pour récupérer le mot de passe du compte gMSA. Pour plus d’informations, consultez Accorder des autorisations pour récupérer le mot de passe du compte gMSA.
Cause 2
Le service de capteur s’exécute en tant que LocalService et effectue l’usurpation d’identité du compte de service d’annuaire.
Si la stratégie d’attribution des droits utilisateur Se connecter en tant que service est configurée pour ce contrôleur de domaine, l’usurpation d’identité échoue, sauf si le compte gMSA reçoit l’autorisation Se connecter en tant que service.
Résolution 2 :
Configurez Se connecter en tant que service pour les comptes gMSA lorsque la stratégie d’attribution des droits utilisateur Se connecter en tant que service est configurée sur le contrôleur de domaine concerné. Pour plus d’informations, consultez Vérifier que le compte gMSA dispose des droits requis.
Cause 3
Si le ticket Kerberos du contrôleur de domaine a été émis avant l’ajout du contrôleur de domaine au groupe de sécurité avec les autorisations appropriées, ce groupe ne fait pas partie du ticket Kerberos. Il ne peut donc pas récupérer le mot de passe du compte gMSA.
Résolution 3 :
Pour corriger ce problème, effectuez l’une des opérations suivantes :
Redémarrez le contrôleur de domaine.
Videz le ticket Kerberos, forçant le contrôleur de domaine à demander un nouveau ticket Kerberos. À partir d’une invite de commandes administrateur sur le contrôleur de domaine, exécutez la commande suivante :
klist -li 0x3e7 purgeAttribuez l’autorisation de récupérer le mot de passe de gMSA à un groupe dont le contrôleur de domaine est déjà membre, tel que le groupe Contrôleurs de domaine.
Échec du démarrage du service du capteur
Entrées du journal du capteur :
Warn DirectoryServicesClient CreateLdapConnectionAsync failed to retrieve group managed service account password. [DomainControllerDnsName=DC1.CONTOSO.LOCAL Domain=contoso.local UserName=AATP_gMSA]
Cause :
Le contrôleur de domaine n’a pas été autorisé à accéder au mot de passe du compte gMSA.
Résolution :
Vérifiez que le contrôleur de domaine a reçu des droits d’accès au mot de passe. Vous devez disposer d’un groupe de sécurité dans Active Directory qui contient les contrôleurs de domaine, les serveurs AD FS/AD CS et les comptes d’ordinateur de capteurs autonomes inclus. S’il n’existe pas, nous vous recommandons d’en créer un.
Vous pouvez utiliser la commande suivante pour vérifier si un compte d’ordinateur ou un groupe de sécurité a été ajouté au paramètre. Remplacez mdiSvc01 par le nom que vous avez créé.
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword
Le résultat doit avoir l’aspect suivant :
Dans cet exemple, nous pouvons voir qu’un groupe nommé mdiSvc01Group a été ajouté. Si le contrôleur de domaine ou le groupe de sécurité n’a pas été ajouté, vous pouvez utiliser les commandes suivantes pour l’ajouter. Remplacez mdiSvc01 par le nom du gMSA et remplacez DC1 par le nom du contrôleur de domaine, ou mdiSvc01Group par le nom du groupe de sécurité.
# 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
Si le contrôleur de domaine ou le groupe de sécurité est déjà ajouté, mais que vous voyez toujours l’erreur, vous pouvez essayer les étapes suivantes :
- Option 1 : redémarrer le serveur pour synchroniser les modifications récentes
- Option 2 :
- Définir les services AATPSensor et AATPSensorUpdater sur Désactivé
- Arrêter les services AATPSensor et AATPSensorUpdater
- Mettre en cache le compte de service sur le serveur à l’aide de la commande :
Install-ADServiceAccount gMSA_AccountName - Définir les services AATPSensor et AATPSensorUpdater sur Automatique
- Démarrer le service AATPSensorUpdater
L’accès à la clé de registre « Global » est refusé
Le service de capteur ne parvient pas à démarrer et le journal des capteurs contient une entrée similaire à :
2021-01-19 03:45:00.0000 Error RegistryKey System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
Cause :
Le gMSA configuré pour ce contrôleur de domaine ou le serveur AD FS/AD CS n’a pas d’autorisations sur les clés de registre du compteur de performances.
Résolution :
Ajoutez le gMSA au groupe Utilisateurs de l’analyseur de performances sur le serveur.
Les téléchargements de rapports ne peuvent pas contenir plus de 300 000 entrées
Defender pour Identity ne prend pas en charge les téléchargements de rapports qui contiennent plus de 300 000 entrées par rapport. Les rapports s’affichent comme incomplets si plus de 300 000 entrées sont incluses.
Cause :
Il s’agit d’une limitation d’ingénierie.
Résolution :
Aucune résolution connue.
Le capteur ne parvient pas à énumérer les journaux des événements
Si vous observez un nombre limité ou un manque d’alertes d’événements de sécurité ou d’activités logiques dans la console Defender pour Identity, mais aucun problème d’intégrité n’est déclenché.
Entrées du journal du capteur :
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()
Cause :
Une liste de contrôle d’accès discrétionnaire limite l’accès aux journaux d’événements requis par le compte de service local.
Résolution :
Vérifiez que la liste de contrôle d’accès discrétionnaire (DACL) inclut l’entrée suivante (il s’agit du SID du service AATPSensor).
(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)
Vérifiez si la liste DACL du journal des événements de sécurité a été configurée par un GPO :
Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access
Ajoutez l’entrée ci-dessus à la stratégie existante. Exécutez ensuite C:\Windows\System32\wevtutil.exe gl security pour vérifier que l’entrée a été ajoutée.
Les journaux d’activité Defender pour Identity locaux doivent maintenant s’afficher :
Info WindowsEventLogReader EnableEventLogWatchers EventLogWatcher enabled [name=Security]
ApplyInternal a échoué à la connexion SSL bidirectionnelle au service
Si, lors de l’installation du capteur, vous recevez l’erreur suivante : ApplyInternal a échoué à la connexion SSL bidirectionnelle au service et que le journal des capteurs contient une entrée similaire à :
2021-01-19 03:45:00.0000 Error CommunicationWebClient+\<SendWithRetryAsync\>d__9`1 ApplyInternal a échoué à la connexion SSL bidirectionnelle au service.
Le problème peut être dû à un proxy avec l’inspection SSL activée.
[_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA7B5E1899B5B4AD0]`
Cause :
Le problème peut être dû au fait que les valeurs de registre SystemDefaultTlsVersions ou SchUseStrongCrypto ne sont pas définies sur leur valeur par défaut 1.
Résolution :
Vérifiez que les valeurs de registre SchUseStrongCrypto et SystemDefaultTlsVersions sont définies sur 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
Problème lors de l’installation du capteur sur Windows Server 2019 avec KB5009557 installé, ou sur un serveur avec des autorisations EventLog renforcées.
L’installation du capteur peut échouer avec le message d’erreur :
System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
Résolution :
Il existe deux solutions de contournement possibles pour ce problème :
Installez le capteur avec PSExec :
psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"Installez le capteur avec une tâche planifiée configurée pour s’exécuter en tant que LocalSystem. La syntaxe de ligne de commande à utiliser est mentionnée dans Installation sans assitance du capteur Defender pour Identity.
L’installation du capteur échoue en raison du client de gestion des certificats
Si l’installation du capteur échoue et que le fichier Microsoft.Tri.Sensor.Deployment.Deployer.log contient une entrée similaire à :
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)
Cause :
Le problème peut être dû au fait qu’un client de gestion des certificats tel que Entrust Entelligence Security Provider (EESP) empêche l’installation du capteur de créer un certificat auto-signé sur l’ordinateur.
Résolution :
Désinstallez le client de gestion des certificats, installez le capteur Defender pour Identity, puis réinstallez le client de gestion des certificats.
Remarque
Le certificat auto-signé est renouvelé tous les 2 ans et le processus de renouvellement automatique peut échouer si le client de gestion des certificats empêche la création du certificat auto-signé. Cela entraîne l’arrêt de la communication entre le capteur et le back-end, ce qui nécessite une réinstallation de capteur à l’aide de la solution de contournement mentionnée ci-dessus.
Échec de l’installation du capteur en raison de problèmes de connectivité réseau
Si l’installation du capteur échoue avec un code d’erreur de 0x80070643, et que le fichier journal d’installation contient une entrée similaire à :
[22B8:27F0][2016-06-09T17:21:03]e000: Error 0x80070643: Failed to install MSI package.
Cause :
Le problème peut être dû au fait que le processus d’installation ne peut pas accéder aux services cloud Defender pour Identity pour l’inscription du capteur.
Résolution :
Vérifiez que le capteur peut accéder directement à *.atp.azure.com ou via le proxy configuré. Si nécessaire, définissez les paramètres du serveur proxy pour l’installation à l’aide de la ligne de commande :
"Azure ATP sensor Setup.exe" [ProxyUrl="http://proxy.internal.com"] [ProxyUserName="domain\proxyuser"] [ProxyUserPassword="ProxyPassword"]
Pour plus d’informations, consultez Exécuter une installation sans assistance avec une configuration de proxy.
Le service de capteur n’a pas pu s’exécuter et reste dans l’état de démarrage
Les erreurs suivantes s’affichent dans le journal système dans l’Observateur d’événements :
- La procédure Ouvrir pour le service « .NETFramework » dans la DLL « C:\Windows\system32\mscoree.dll » a échoué avec le code d’erreur Access refusé. Les données de performances de ce service ne seront pas disponibles.
- La procédure Ouvrir pour le service « .Lsa » dans la DLL « C:\Windows\System32\Secur32.dll » a échoué avec le code d’erreur Access refusé. Les données de performance ne sont pas disponibles pour ce service.
- La procédure Ouvrir pour le service « WmiApRpl » dans la DLL « C:\Windows\system32\wbem\wmiaprpl.dll » a échoué avec le code d’erreur « L’appareil n’est pas prêt ». Les données de performances de ce service ne seront pas disponibles.
Microsoft.TriSensorError.log contient une erreur similaire à celle-ci :
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
Cause :
NT Service\Tous les services n’ont pas le droit de se connecter en tant que service.
Résolution :
Ajoutez une stratégie de contrôleur de domaine avec l’ouverture de session en tant que service. Pour plus d’informations, consultez Vérifier que le compte gMSA dispose des droits requis.
Votre espace de travail n’a pas été créé, car un groupe de sécurité portant le même nom existe déjà dans Microsoft Entra ID
Cause :
Le problème peut se présenter lorsqu’une licence d’espace de travail Defender pour Identity expire et est supprimée lorsque la période de rétention est terminée, mais que les groupes Microsoft Entra n’ont pas été supprimés.
Résolution :
- Accédez au portail Azure ->Microsoft Entra ID ->Groupes
- Renommez les trois groupes suivants (où workspaceName est le nom de votre espace de travail), en ajoutant un suffixe « - old » :
- « Azure ATP workspaceName Administrateurs » -> « Azure ATP workspaceName Administrateurs - old »
- « Azure ATPworkspaceName Reviseurs » -> « Azure ATP workspaceName Reviseurs - old »
- « Azure ATP workspaceName Utilisateurs » -> « Azure ATP workspaceName Utilisateurs - old »
- Puis retournez au portail Microsoft Defender, dans la section Paramètres ->Identités pour créer un nouvel espace de travail pour Defender pour Identity.