Résolution des problèmes connus Microsoft Defender pour Identity

Erreur d’échec de communication du capteur

Si vous recevez l’erreur d’échec du capteur suivante :

System.Net.Http.HttpRequestException: An error occurred while sending the request. >--- System.Net.WebException : Impossible de se connecter au serveur distant ---> System.Net.Sockets.SocketException : une tentative de connexion a échoué, car la partie connectée n’a pas répondu correctement après une période de temps ou une connexion établie a échoué, car l’hôte connecté n’a pas pu répondre...

Résolution :

Assurez-vous que la communication n’est pas bloquée pour localhost, port TCP 444. Pour en savoir plus sur Microsoft Defender pour Identity prérequis, consultez les ports.

Emplacement des journaux 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 s’agit de : C:\Users\Administrator\AppData\Local\Temp (ou d’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’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 ValidateCreateS returned [validateCreateSensorResult=LicenseInvalid]] [1C60:1AA8][2018-03-24T23:59:56]i000: 2018-2018-2018 03-25 02:59:56.4856 Info InteractiveDeploymentManager ValidateCreateSensorAsync retourné [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: Arrêt, code de sortie : 0x642

Cause :

Dans certains cas, lors de la communication via un proxy, pendant l’authentification, il peut répondre au capteur Defender pour Identity avec l’erreur 401 ou 403 au lieu de l’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 proxy.

Résolution :

Assurez-vous que le capteur peut naviguer vers *.atp.azure.com via le proxy configuré sans authentification. Pour plus d’informations, 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 : Échec de la connexion du capteur au service.

Cause :

Le problème peut être dû au fait que les certificats des autorités de certification racines approuvées requis par Defender pour Identity sont manquants.

Résolution :

Exécutez l’applet de commande 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 us Government Cloud de la communauté du secteur public High, 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 us Government Cloud de la communauté du secteur public 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}

Si vous ne voyez pas la sortie attendue, procédez comme suit :

  1. Téléchargez les certificats suivants sur l’ordinateur Server Core. Pour tous les clients, téléchargez le certificat racine Baltimore CyberTrust .

    De plus :

  2. Exécutez l’applet de commande PowerShell suivante 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 silencieuse lors de la tentative d’utilisation de PowerShell

Si, pendant l’installation du capteur silencieux, 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 :

Échec de l’ajout du préfixe ./ requis pour l’installation lors de l’utilisation de PowerShell provoque cette erreur.

Résolution :

Utilisez la commande complète pour installer correctement.

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

Problème d’association de cartes réseau du capteur Defender pour Identity

Si vous tentez d’installer le capteur Defender pour Identity sur un ordinateur configuré avec un adaptateur Association de cartes réseau, vous recevez une erreur d’installation. Si vous souhaitez installer le capteur Defender pour Identity sur une machine configurée avec l’association de cartes réseau, veillez à déployer le pilote Npcap en suivant les instructions fournies ici.

Mode Groupe multiprocesseur

Pour Windows systèmes d’exploitation 2008R2 et 2012, Defender pour Identity Sensor n’est pas pris en charge en mode groupe multiprocesseur.

Solutions de contournement possibles :

  • Si l’hyperthreading est activé, désactivez-le. Cela peut suffisamment réduire le nombre de cœurs logiques pour éviter d’avoir à 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 d’optimisation de la taille du groupe NUMA de la valeur par défaut cluster surplat.

problème d’intégration Microsoft Defender pour point de terminaison

Defender pour Identity vous permet d’intégrer Defender pour Identity à Microsoft Defender pour point de terminaison. Pour plus d’informations, consultez Intégrer Defender pour Identity à Microsoft Defender pour point de terminaison.

Problème de capteur pour la 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é que le trafic réseau n’est pas analysé. Ce scénario se produit à cause d’une différence de configuration dans VMware.

Pour résoudre le problème

Sur le système d’exploitation invité, définissez la valeur suivante sur Désactivé dans la configuration de la carte réseau de la machine virtuelle : déchargement TSO IPv4.

VMware sensor issue.

Utilisez la commande suivante pour vérifier si le déchargement d’envoi volumineux (LSO) est activé ou désactivé :

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

Check LSO status.

Si LSO est activé, utilisez la commande suivante pour le désactiver :

Disable-NetAdapterLso -Name {name of adapter}

Disable LSO status.

Notes

  • 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 ces modifications prennent effet.
  • Ces étapes peuvent varier en fonction de votre version de VMWare. Pour plus d’informations sur la désactivation de LSO/TSO pour votre version de VMWare, consultez la documentation VMWare.

Le capteur n’a pas pu récupérer les informations d’identification de compte de service administré de groupe (gMSA)

Si vous recevez l’alerte d’intégrité suivante : Les informations d'identification de l'utilisateur des services d'annuaire sont incorrectes

Entrées du journal du capteur :

2020-02-17 14:01:36.5315 Info ImpersonationManager CreateImpersonatorAsync a démarré [UserName=account_name Domain=domain1.test.local IsGroupManagedServiceAccount=True] 2020-02-17 14:01:36.5750 Info ImpersonationManager CreateImpersonatorAsync a terminé [UserName=account_name Domain=domain1.test.local IsSuccess=False]

Entrées du journal de mise à jour du capteur :

2020-02-17 14:02:19.6258 Warn GroupManagedServiceAccountImpersonationHelper GetGroupManagedServiceAccountAccessTokenAsync a échoué, le mot de passe GMSA n’a pas pu être récupéré [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 Octroi 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’emprunt d’identité du compte des services d’annuaire.

Si la stratégie d’attribution des droits utilisateur Ouvrir une session en tant que service est configurée pour ce contrôleur de domaine, l’emprunt d’identité échoue à moins que l’autorisation Ouvrir une session en tant que service ne soit accordée au compte gMSA.

Résolution 2 :

Configurez l’ouverture de session en tant que service pour les comptes gMSA lorsque la stratégie d’attribution des droits utilisateur se connecte en tant que service est configurée sur le contrôleur de domaine affecté. Pour plus d’informations, consultez Vérifier que le compte gMSA dispose des droits requis (le cas échéant).

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 pourra donc pas récupérer le mot de passe du compte gMSA.

Résolution 3 :

Effectuez l’une des opérations suivantes pour résoudre ce problème :

  • 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 d’administrateur sur le contrôleur de domaine, exécutez la commande suivante :

    klist -li 0x3e7 purge

  • Affectez l’autorisation de récupérer le mot de passe du compte 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 :

Avertissement DirectoryServicesClient CreateLdapConnectionAsync n’a pas pu récupérer le mot de passe du compte de service managé de groupe. [DomainControllerDnsName=DC1. CONTOSO. DOMAINE LOCAL=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 avec le contrôleur de domaine et les capteurs autonomes inclus. Si cela n’existe pas, nous vous recommandons de en créer un.

Vous pouvez utiliser la commande suivante pour vérifier si l’ordinateur ou le groupe de sécurité a été ajouté au paramètre. Remplacez AccountName par le nom que vous avez créé.

Get-ADServiceAccount AccountName -Properties PrincipalsAllowedToRetrieveManagedPassword

Le résultat doit avoir l’aspect suivant :

Powershell results.

Dans cet exemple, nous pouvons voir que le contrôleur de domaine AATPDemo a été ajouté. Si le contrôleur de domaine ou le groupe de sécurité n’a pas été ajouté, nous pouvons utiliser la commande suivante ci-dessous pour l’ajouter. Remplacez Host1 par le nom du contrôleur de domaine ou le nom du groupe de sécurité.

Set-ADServiceAccount gmsaAccountName -PrincipalsAllowedToRetrieveManagedPassword Host1

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 :
    1. Arrêter AATPSensor et AATPSensorUpdater
    2. Compte de service de cache sur le serveur : Install-ADServiceAccount AccountName
    3. Démarrer AATPSensor

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 n’a pas d’autorisations sur les clés de Registre du compteur de performances.

Résolution :

Ajoutez gMSA au groupe Utilisateurs Analyseur de performances sur le serveur.

Les téléchargements de rapports contenant plus de 300 000 entrées ne sont pas pris en charge

Defender pour Identity ne prend pas en charge les téléchargements de rapports contenant plus de 300 000 entrées par rapport. Les rapports de plus de 300 000 entrées ne s’affichent pas intégralement.

Cause :

Il s’agit d’une limitation de conception.

Résolution :

Aucune solution connue.

Le capteur ne parvient pas à énumérer les journaux d’é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 qu’aucune alerte d’intégrité n’est déclenchée.

Entrées du journal du capteur :

Erreur EventLogException System.Diagnostics.Eventing.Reader.EventLogException : le handle n’est pas valide sur void System.Diagnostics.Eventing.Reader.EventLogException.Throw(int errorCode) sur l’objet System.Diagnostics.Eventing.Reader.NativeWrapper.EvtGetEventInfo(Handle EventLogHandle, EvtEventPropertyId enumType) à la chaîne System.Diagnostics.Eventing.Reader.EventLogRecord.get_ContainerLog()

Cause :

Une liste de Access Control 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 des Access Control discrétionnaires inclut l’entrée suivante :

(A;;0x1;;;S-1-5-80-818380073-2995186456-1411405591-3990468014-3617507088)

Échec de l’erreur de connexion SSL à service d’ApplicationInternal

Si lors de l’installation du capteur, vous recevez l’erreur suivante : ApplyInternal a échoué de deux manières de se connecter 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é de deux manières la connexion SSL au service. Le problème peut être dû à un proxy avec l’inspection SSL activée. [_workspaceApplicationSensorApiEndpoint=Unspecified/contoso.atp.azure.com:443 Thumbprint=7C039DA47E81E51F3DA3DF3DA3DA7B5E1899B5B4AD0]

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 SystemDefaultTlsVersions et SchUseStrongCrypto sont définies sur 1 :

[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 d’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 :

  1. Installez le capteur avec PSExec :

    psexec -s -i "C:\MDI\Azure ATP Sensor Setup.exe"
    
  2. 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 l’installation silencieuse du capteur Defender pour Identity.

Voir aussi