Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Résolution des problèmes liés AWS à Managed Microsoft AD Les informations suivantes peuvent vous aider à résoudre certains problèmes courants que vous pouvez rencontrer lors de la création ou de l'utilisation de votre répertoire Microsoft AD Active Directory AWS géré. ## Problèmes liés à votre Microsoft AD AWS géré Certaines tâches de dépannage ne peuvent être effectuées que par Support. Voici certaines des tâches à accomplir : + Redémarrer les contrôleurs de domaine que vous Directory Service avez fournis. + [Mise à niveau de votre Microsoft AD AWS géré](ms_ad_upgrade_edition.md). Pour créer un dossier d'assistance, consultez les sections [Création de dossiers d'assistance et gestion des dossiers](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html). ## Problèmes liés à Netlogon et aux communications par canal sécurisé En guise d'atténuation contre le [CVE-2020-1472](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1472), Microsoft a publié un correctif qui modifie la façon dont les communications par canal sécurisé Netlogon sont traitées par les contrôleurs de domaine. Depuis l'introduction de ces modifications relatives à la sécurité Netlogon, certaines connexions Netlogon (serveurs, postes de travail et validations de confiance) peuvent ne pas être acceptées par votre Managed Microsoft AD. AWS Pour vérifier si votre problème est lié à Netlogon ou aux communications par canal sécurisé, recherchez dans Amazon CloudWatch Logs l'événement IDs 5827 (pour les problèmes liés à l'authentification des appareils) ou 5828 (pour les problèmes liés à la validation AD Trust). Pour plus d'informations sur CloudWatch AWS Managed Microsoft AD, consultez[Activation du transfert de CloudWatch journaux Amazon Logs pour AWS Managed Microsoft AD](ms_ad_enable_log_forwarding.md). Pour plus d'informations sur les mesures d'atténuation contre le CVE-2020-1472, consultez [Comment gérer les modifications des connexions au canal sécurisé Netlogon associées au CVE-2020-1472 sur le site Web de Netlogon](https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e). Microsoft ## Vous recevez un message d'erreur « État de réponse : 400 mauvaise demande » lorsque vous tentez de réinitialiser le mot de passe d'un utilisateur Vous recevez un message d'erreur semblable au suivant lorsque vous tentez de réinitialiser le mot de passe d'un utilisateur : `Response Status: 400 Bad Request` Vous pouvez rencontrer ce problème lorsque votre unité organisationnelle Microsoft AD AWS gérée contient des objets dupliqués portant des noms d'ouverture de session utilisateur identiques. Les noms de connexion des utilisateurs doivent être uniques. Pour plus d'informations, consultez la section [Résolution des problèmes liés aux données de répertoire](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb727059(v=technet.10)?redirectedfrom=MSDN) dans la Microsoft documentation. ## Récupération d'un mot de passe Si un utilisateur oublie un mot de passe ou rencontre des difficultés pour se connecter à votre répertoire AWS Managed Microsoft AD, vous pouvez réinitialiser son mot de passe à l'aide du AWS Management Console, PowerShell ou du AWS CLI. Pour de plus amples informations, veuillez consulter [Réinitialisation d'un AWS mot de passe utilisateur Microsoft AD géré](ms_ad_manage_users_groups_reset_password.md). ## Ressources supplémentaires Les ressources suivantes peuvent vous aider à résoudre les problèmes pendant que vous travaillez avec AWS. + **[AWS Centre de connaissances](https://aws.amazon.com/premiumsupport/knowledge-center/)** : recherchez d'autres ressources FAQs et liens vers d'autres ressources pour vous aider à résoudre les problèmes. + **[AWS Centre de support](https://console.aws.amazon.com/support/home#/)** : bénéficiez d'une assistance technique. + **[AWS Premium Support Center](https://aws.amazon.com/premiumsupport/)** : bénéficiez d'un support technique haut de gamme. Les ressources suivantes peuvent vous aider à résoudre les problèmes courants liés à Active Directory. + [Documentation Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/active-directory-overview) + [AD DS Résolutions des problèmes](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) **Topics** + [Problèmes liés à votre Microsoft AD AWS géré](#general_issues) + [Problèmes liés à Netlogon et aux communications par canal sécurisé](#ms_ad_tshoot_netlogon_issues) + [Vous recevez un message d'erreur « État de réponse : 400 mauvaise demande » lorsque vous tentez de réinitialiser le mot de passe d'un utilisateur](#ms_ad_tshoot_reset_password) + [Récupération d'un mot de passe](#ms_ad_tshoot_password_recovery) + [Ressources supplémentaires](#troubleshoot_general_resources) + [Erreurs de jointure de domaine d'instance Amazon EC2 Linux](ms_ad_troubleshooting_join_linux.md) + [AWS Microsoft AD géré, faible espace de stockage disponible](ms_ad_troubleshooting_low_storage_space.md) + [Erreurs d'extension de schéma](ms_ad_troubleshooting_schema.md) + [Raisons liées aux statuts de création d'une relation d'approbation](ms_ad_troubleshooting_trusts.md) + [Résolution des problèmes liés AWS à l'utilisation élevée du processeur Microsoft AD dans Managed](ms_ad_troubleshooting_high_cpu.md) # Erreurs de jointure de domaine d'instance Amazon EC2 Linux Ce qui suit peut vous aider à résoudre certains messages d'erreur que vous pouvez rencontrer lorsque vous joignez une instance Amazon EC2 Linux à votre répertoire AWS Managed Microsoft AD. ## Impossible d'effectuer la jonction de domaine ou l'authentification d'instances Linux Les instances Ubuntu 14.04, 16.04 et 18.04 *doivent* pouvoir être résolues à l'envers dans le DNS pour qu'un domaine puisse fonctionner avec Microsoft Active Directory. Sinon, vous risquez de rencontrer l'un des deux scénarios suivants : ### Scénario 1 : Instances Ubuntu qui ne sont pas encore jointes à un domaine Pour les instances Ubuntu qui tentent de joindre un domaine, la commande `sudo realm join` peut ne pas fournir les autorisations requises pour joindre le domaine et afficher l'erreur suivante : \$1 Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) adcli: couldn't connect to EXEMPLE.COM domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: An invalid name was supplied (Success) \$1 Insufficient permissions to join the domain realm: Couldn't join realm: Insufficient permissions to join the domain ### Scénario 2 : Instances Ubuntu qui sont jointes à un domaine Pour les instances Ubuntu déjà jointes à un domaine Microsoft Active Directory, les tentatives de connexion SSH à l'instance à l'aide des informations d'identification du domaine peuvent échouer avec les erreurs suivantes : \$1 ssh admin@EXEMPLE.COM@198.51.100 aucune identité de ce type :/Users/username/.ssh/id\$1ed25519 : aucun fichier ou répertoire de ce type admin@EXEMPLE.COM@198.51.100's password: Permission denied, please try again. admin@EXEMPLE.COM@198.51.100's password: Si vous vous connectez à l'instance avec une clé publique et que vous vérifiez `/var/log/auth.log`, vous risquez de voir les erreurs suivantes d'utilisateur introuvable : May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.0 user=admin@EXEMPLE.COM May 12 01:02:12 ip-192-0-2-0 sshd[2251]: pam\$1sss(sshd:auth): received for user admin@EXEMPLE.COM: 10 (User not known to the underlying authentication module) May 12 01:02:14 ip-192-0-2-0 sshd[2251]: Failed password for invalid user admin@EXEMPLE.COM from 203.0.113.0 port 13344 ssh2 May 12 01:02:15 ip-192-0-2-0 sshd[2251]: Connection closed by 203.0.113.0 [preauth] Par contre, `kinit` pour l'utilisateur continue de fonctionner. Veuillez consulter cet exemple : ubuntu@ip-192-0-2-0:\$1\$1 kinit admin@EXEMPLE.COM Password for admin@EXEMPLE.COM: ubuntu@ip-192-0-2-0:\$1\$1 klist Ticket cache: FILE:/tmp/krb5cc\$11000 Default principal: admin@EXEMPLE.COM ### Solution La solution recommandée actuelle pour ces deux scénarios consiste à désactiver DNS inverse dans `/etc/krb5.conf` dans la section [libdefaults], comme illustré ci-dessous : ``` [libdefaults] default_realm = EXAMPLE.COM rdns = false ``` ## Problème d'authentification d'approbation unidirectionnelle associé à une jonction de domaine fluide Si une approbation sortante unidirectionnelle est établie entre votre Microsoft AD AWS géré et votre Active Directory local, vous pouvez rencontrer un problème d'authentification lorsque vous tentez de vous authentifier auprès de l'instance Linux jointe au domaine à l'aide de vos informations d'identification Active Directory fiables avec Winbind. ### Erreurs 31 juillet 00:00:00 EC2 LSMWq AMAZ-T sshd [23832] : échec du mot de passe pour user@corp.example.com depuis le port xxx.xxx.xxx.xxx 18309 ssh2 31 juillet 00:05:00 EC2 AMAZ- LSMWq T sshd [23832] : pam\$1winbind (sshd:auth) : obtention du mot de passe (0x00000390) 31 juillet 00:05:00 EC2 AMAZ- LSMWq T sshd [23832] : pam\$1winbind (sshd:auth) : pam\$1get\$1item a renvoyé un mot de passe 31 juillet 00:05:00 EC2 AMAZ- LSMWq T sshd [23832] : pam\$1winbind (sshd:auth) : wbcLogonUser échec de la demande : WBC\$1ERR\$1AUTH\$1ERROR, erreur PAM : PAM\$1SYSTEM\$1ERR (4), NTSTATUS : \$1\$1NT\$1STATUS\$1OBJECT\$1NAME\$1NOT\$1FOUND\$1\$1, le message d'erreur était le suivant : Le nom de l'objet est introuvable. 31 juillet 00:05:00 EC2 AMAZ- LSMWq T sshd [23832] : pam\$1winbind (sshd:auth) : erreur interne du module (retval = PAM\$1SYSTEM\$1ERR (4), user = 'CORP \$1 user') ## Solution Pour résoudre ce problème, vous devez exclure ou supprimer une directive du fichier de configuration du module PAM (`/etc/security/pam_winbind.conf`) en procédant comme suit. 1. Ouvrez le fichier `/etc/security/pam_winbind.conf` dans un éditeur de texte. ``` sudo vim /etc/security/pam_winbind.conf ``` 1. Excluez ou supprimez la directive suivante **krb5\$1auth = yes**. ``` [global] cached_login = yes krb5_ccache_type = FILE #krb5_auth = yes ``` 1. Arrêtez le service Winbind, puis redémarrez-le. ``` service winbind stop or systemctl stop winbind net cache flush service winbind start or systemctl start winbind ``` # AWS Microsoft AD géré, faible espace de stockage disponible Lorsque votre Microsoft AD AWS géré est altéré en raison d'un faible espace de stockage disponible dans Active Directory, une action immédiate est requise pour rétablir l'état actif de l'annuaire. Pour connaître les deux causes les plus fréquentes de cette déficience, veuillez consulter les sections suivantes : 1. [Le dossier SYSVOL stocke des objets de politique de groupe plus qu'essentiels](#sysvol-folder-gpo) 1. [La base de données Active Directory a atteint sa capacité maximale](#ad-db-filled-volume) Pour obtenir des informations sur les tarifs relatifs au stockage Microsoft AD AWS géré, consultez la section [Directory Service Tarification](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table). ## Le dossier SYSVOL stocke des objets de politique de groupe plus qu'essentiels Cette déficience est souvent causée par le stockage de fichiers non essentiels dans le dossier SYSVOL dédiés au traitement de la stratégie de groupe. Ces fichiers non essentiels peuvent être EXEs MSIs, ou tout autre fichier dont le traitement n'est pas essentiel à la stratégie de groupe. Les objets essentiels à traiter par la stratégie de groupe sont les objets de stratégie de groupe, les Logon/off scripts et le [magasin central des objets de stratégie de groupe](https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store). Tous les fichiers non essentiels doivent être stockés sur un ou plusieurs serveurs de fichiers autres que vos contrôleurs de domaine Microsoft AD AWS gérés. Si vous avez besoin de fichiers pour [l'installation du logiciel de stratégie de groupe](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software), stockez-les sur un serveur de fichiers. Si vous préférez ne pas gérer vous-même un serveur de fichiers, [Amazon AWS](https://aws.amazon.com/fsx/) propose une option de serveur de fichiers géré FSx. Pour supprimer les fichiers inutiles, vous pouvez accéder au partage SYSVOL via son chemin UNC (Universal Naming Convention). Par exemple, si le nom de domaine complet (FQDN) de votre domaine est exemple.com, le chemin UNC pour le SYSVOL serait « \$1\$1example.local\$1SYSVOL\$1example.local \$1 ». Une fois ces objets non essentiels au traitement de l'annuaire par la stratégie de groupe localisés et supprimés, l'annuaire doit redevenir actif sous 30 minutes. Si le répertoire n'est pas actif après 30 minutes, veuillez contacter le AWS Support. En stockant seulement les fichiers de stratégie de groupe essentiels dans le dossier partagé SYSVOL, vous permettez à votre annuaire de ne pas être affecté par la distension de SYSVOL. ## La base de données Active Directory a atteint sa capacité maximale Cette déficience est souvent causée par le fait que la base de données Active Directory a atteint sa capacité maximale. Pour vérifier cela, veuillez consulter le nombre **total** d'objets dans votre annuaire. Nous mettons en gras le mot **total** pour que vous compreniez que les objets **supprimés** sont toujours comptabilisés dans le nombre total d'objets d'un annuaire. Par défaut, AWS Managed Microsoft AD conserve les articles dans la corbeille de recyclage AD pendant 180 jours avant qu'ils ne deviennent des objets recyclés. Une fois un objet recyclé (désactivé), il est conservé pendant 180 jours avant d'être finalement supprimé de l'annuaire. Ainsi, un objet supprimé demeure dans la base de données de l'annuaire pendant 360 jours avant d'être définitivement supprimé. C'est pourquoi vous devez évaluer le nombre total d'objets. Pour plus de détails sur le nombre d'objets pris en charge par AWS Managed Microsoft AD, consultez la section [Directory Service Tarification](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table). Pour obtenir le nombre total d'objets dans un répertoire qui inclut les objets supprimés, vous pouvez exécuter la PowerShell commande suivante à partir d'une instance Windows jointe au domaine. Pour apprendre à configurer une instance de gestion, reportez-vous à la section [Gestion des utilisateurs et des groupes dans AWS Managed Microsoft AD](ms_ad_manage_users_groups.md). ``` Get-ADObject -Filter * -IncludeDeletedObjects | Measure-Object -Property 'Count' | Select-Object -Property 'Count' ``` Voici un exemple de sortie de la commande ci-dessus : ``` Count 10000 ``` Si le nombre total est supérieur au nombre d'objets pouvant être pris en charge par votre annuaire comme indiqué dans la note ci-dessus, cela veut dire que votre annuaire a atteint sa capacité de stockage maximale. Voici des options permettant de résoudre cette déficience : 1. Nettoyez AD 1. Supprimez tous les objets AD indésirables. 1. Supprimez tous les objets indésirables de la corbeille AD. Veuillez noter que cette action est irréversible et que vous ne pourrez récupérer ces objets supprimés qu'en restaurant l'annuaire. 1. La commande suivante supprimera définitivement tous les objets se trouvant dans la corbeille AD. **Important** Procédez avec prudence, car cette action est irréversible, et vous ne pourrez récupérer ces objets supprimés qu'en restaurant l'annuaire. ``` $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName $NetBios = $DomainInfo.NetBIOSName $ObjectsToRemove = Get-ADObject -Filter { isDeleted -eq $true } -IncludeDeletedObjects -SearchBase "CN=Deleted Objects,$BaseDn" -Properties 'LastKnownParent','DistinguishedName','msDS-LastKnownRDN' | Where-Object { ($_.LastKnownParent -Like "*OU=$NetBios,$BaseDn") -or ($_.LastKnownParent -Like '*\0ADEL:*') } ForEach ($ObjectToRemove in $ObjectsToRemove) { Remove-ADObject -Identity $ObjectToRemove.DistinguishedName -IncludeDeletedObjects } ``` 1. Ouvrez un dossier auprès du AWS Support pour demander la Directory Service récupération de l'espace libre. 1. Si votre répertoire est de type Standard Edition, ouvrez un dossier auprès du AWS Support pour demander que votre répertoire soit mis à niveau vers l'édition Enterprise. Cela augmentera également le coût de votre annuaire. Pour de plus amples informations sur la tarification, veuillez consulter [Directory Service Pricing](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table) (français non garanti). Dans AWS Managed Microsoft AD, les membres du groupe **AWS Delegated Deleted Object Lifetime Administrators** ont la possibilité de modifier `msDS-DeletedObjectLifetime` l'attribut qui définit le nombre de jours pendant lesquels les objets supprimés sont conservés dans la corbeille de recyclage AD avant de devenir des objets recyclés. **Note** Il s'agit d'un sujet avancé. Si la configuration n'est pas correctement effectuée, elle peut entraîner une perte de données. Pour mieux comprendre ce procédé, nous vous invitons à passer en revue [Corbeille AD : compréhension, application, meilleures pratiques et résolution de problèmes](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/the-ad-recycle-bin-understanding-implementing-best-practices-and/ba-p/396944). Réduire le `msDS-DeletedObjectLifetime`nombre d'objets pris en charge peut vous aider à ne pas dépasser le niveau de capacité maximale. La valeur de ce nombre ne peut être inférieure à 2 jours. Une fois cette limite dépassée, vous ne pourrez plus récupérer l'objet supprimé via la corbeille AD. Pour récupérer le(s) objet(s) en question, vous devrez restaurer votre annuaire à partir d'un instantané. Pour de plus amples informations, veuillez consulter [Restauration de votre Microsoft AD AWS géré à l'aide de snapshots](ms_ad_snapshots.md). **Toute restauration à partir d'un instantané peut entraîner une perte de données, car les instantanés correspondent à un moment donné.** Pour modifier le cycle de vie de l'objet supprimé de votre annuaire, exécutez la commande suivante : **Note** Si vous exécutez la commande telle quelle, le cycle de vie de l'objet supprimé sera défini sur 30 jours. Si vous souhaitez le rallonger ou le raccourcir, remplacez « 30 » par le chiffre que vous préférez. Cependant, nous vous recommandons de ne pas dépasser 180, le nombre par défaut. ``` $DeletedObjectLifetime = 30 $DomainInfo = Get-ADDomain $BaseDn = $DomainInfo.DistinguishedName Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,$BaseDn" -Partition "CN=Configuration,$BaseDn" -Replace:@{"msDS-DeletedObjectLifetime" = $DeletedObjectLifetime} ``` # Erreurs d'extension de schéma Les informations suivantes peuvent vous aider à résoudre certains messages d'erreur que vous pourriez rencontrer lors de l'extension du schéma de votre annuaire Microsoft AD AWS géré. ## Référence **Erreur** *Erreur d'ajout sur l'entrée commençant à la ligne 1 : Référence L'erreur côté serveur est : 0x202b Une référence a été renvoyée à partir du serveur. L'erreur de serveur étendue est la suivante : 0000202B : RefErr : DSID-0310082F, données 0, 1 points d'accès \$1 tref 1 : 'example.com' Nombre d'objets modifiés : 0* **Résolution des problèmes** Veillez à ce que tous les champs de nom uniques disposent d'un nom de domaine correct. Dans l'exemple ci-dessus, `DC=example,dc=com` doit être remplacé par le code `DistinguishedName` affiché par l'applet de commande `Get-ADDomain`. ## Impossible de lire le fichier d'importation **Erreur** *Impossible de lire le fichier d'importation. Nombre d'objets modifiés : 0* **Résolution des problèmes** Le fichier LDIF importé est vide (0 octet). Vérifiez que le bon fichier a été chargé. ## Erreur de syntaxe **Erreur** *Le fichier d'entrée Failed contient une erreur de syntaxe à la ligne 21. Le dernier jeton commence par « q ». Nombre d'objets modifiés : 0* **Résolution des problèmes** Le texte sur la ligne 21 n'a pas été formaté correctement. La première lettre du texte non valide est `A`. Mettez à jour la ligne 21 avec une syntaxe LDIF valide. Pour plus d'informations sur le formatage d'un fichier LDIF, veuillez consulter [Étape 1 : créer votre fichier LDIF](create.md). ## L'attribut ou la valeur existe **Erreur** *Erreur d'ajout sur l'entrée commençant à la ligne 1 : L'attribut ou la valeur existe L'erreur côté serveur est : 0x2083 Une valeur spécifique existe déjà. L'erreur de serveur étendue est la suivante : 00002083 : : DSID-03151830, \$11 AtrErr : \$1 t0 : 00002083 : DSID-03151830, problème 1006 (ATT\$1OR\$1VALUE\$1EXISTS), données 0, Att 20019 (MayContain) :len 4 Nombre d'objets modifiés : 0* **Résolution des problèmes** La modification du schéma a déjà été appliquée. ## Aucun attribut de ce type **Erreur** *Erreur d'ajout sur l'entrée commençant à la ligne 1 : Aucun attribut de ce type L'erreur côté serveur est : 0x2085 La valeur de l'attribut ne peut pas être supprimée car elle n'existe pas pour l'objet. L'erreur de serveur étendue est la suivante : 00002085 : : DSID-03152367, \$11 AtrErr : \$1 t0 : 00002085 : DSID-03152367, problem 1001 (NO\$1ATTRIBUTE\$1OR\$1VAL), data 0, Att 20019 (MayContain) :len 4 Nombre d'objets modifiés : 0* **Résolution des problèmes** Le fichier LDIF essaie de supprimer un attribut d'une classe, mais cet attribut n'est actuellement pas attaché à la classe. La modification du schéma a probablement déjà été appliquée. **Erreur** *Erreur d'ajout sur l'entrée commençant à la ligne 41 : Aucun attribut de ce type 0x57 Le paramètre est incorrect. L'erreur de serveur étendue est : 0x208d Objet de l'annuaire introuvable. L'erreur de serveur étendue est : « 00000057 : LdapErr : DSID-0C090D8A, commentaire : Erreur dans l'opération de conversion d'attributs, données 0, v2580" Nombre d'objets modifiés : 0* **Résolution des problèmes** L'attribut répertorié à la ligne 41 est incorrect. Revérifiez l'orthographe. ## Aucun objet de ce type **Erreur** *Erreur d'ajout sur l'entrée commençant à la ligne 1 : Aucun attribut de ce type L'erreur côté serveur est : 0x208d Objet de l'annuaire introuvable. L'erreur de serveur étendue est la suivante : 0000208D NameErr : DSID-03100238, problème 2001 (NO\$1OBJECT), données 0, meilleure correspondance entre : « CN=Schema, CN=Configuration, DC=example, DC=com » Nombre d'objets modifiés : 0* **Résolution des problèmes** L'objet référencé par le nom unique (DN) n'existe pas. # Raisons liées aux statuts de création d'une relation d'approbation Lorsque la création de confiance échoue pour AWS Managed Microsoft AD, le message d'état contient des informations supplémentaires. Ce qui suit peut vous aider à comprendre le sens de ces messages. ## L'accès est refusé Accès refusé lorsque vous essayez de créer la relation d'approbation. Le mot de passe de confiance est incorrect ou les paramètres de sécurité du domaine distant ne permettent pas de configurer une approbation. Pour plus d'informations sur les trusts, consultez[Améliorer l'efficacité de la confiance grâce aux noms de sites et DCLocator](#enhancing-trust-site-names). Pour résoudre ce problème, essayez ce qui suit : + Vérifiez que vous utilisez le même mot de passe de relation d'approbation que celui que vous avez utilisé lors de la création de la relation d'approbation correspondante sur le domaine distant. + Vérifiez que les paramètres de sécurité de votre domaine permettent la création de la relation d'approbation. + Vérifiez que votre stratégie de sécurité locale est définie correctement. En particulier, vérifiez `Local Security Policy > Local Policies > Security Options > Network access: Named Pipes that can be accessed anonymously` et assurez-vous que ce paramètre contient au moins les trois canaux nommés suivants : + netlogon + samr + lsarpc + Vérifiez que les canaux nommés ci-dessus existent en tant que valeur de la clé de **NullSessionPipes**registre qui se trouve dans le chemin de registre **HKLM \$1 SYSTEM \$1 \$1 services \$1 CurrentControlSet LanmanServer \$1 Parameters**. Ces valeurs doivent être insérées sur des lignes séparées. **Note** Par défaut, `Network access: Named Pipes that can be accessed anonymously` n'est pas défini et affiche `Not Defined`. Ceci est normal, car les paramètres par défaut effectifs du contrôleur de domaine pour `Network access: Named Pipes that can be accessed anonymously` sont `netlogon`, `samr`, `lsarpc`. + Vérifiez le paramètre de signature SMB (Server Message Block) suivant dans la *politique des contrôleurs de domaine par défaut*. Ces paramètres se trouvent sous **Configuration de l'ordinateur** > **Paramètres Windows > Paramètres** de **sécurité** > **Stratégies locales/Options de sécurité**. Ils doivent correspondre aux paramètres suivants : + Microsoftclient réseau : communications signées numériquement (toujours) : Par défaut : Activé + Microsoftserveur réseau : communications signées numériquement (toujours) : Activé ### Améliorer l'efficacité de la confiance grâce aux noms de sites et DCLocator Le nom du premier site n' Default-First-Site-Nameest pas obligatoire pour établir des relations de confiance entre les domaines. Cependant, l'alignement des noms de sites entre les domaines peut améliorer considérablement l'efficacité du processus Domain Controller Locator (DCLocator). Cet alignement améliore la prévision et le contrôle de la sélection des contrôleurs de domaine dans les forêts approuvées. Le DCLocator processus est crucial pour trouver des contrôleurs de domaine dans différents domaines et forêts. Pour plus d'informations sur le DCLocator processus, consultez [Microsoftla documentation](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/troubleshoot-domain-controller-location-issues). Une configuration de site efficace permet une localisation plus rapide et plus précise des contrôleurs de domaine, ce qui améliore les performances et la fiabilité des opérations interforestières. Pour plus d'informations sur la manière dont les noms de sites et les DCLocator processus interagissent, consultez les Microsoft articles suivants : + [Comment les contrôleurs de domaine sont-ils localisés entre les trusts](https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-domain-controllers-are-located-across-trusts/ba-p/256180) + [Localisateur de domaines dans les forêts](https://techcommunity.microsoft.com/blog/askds/domain-locator-across-a-forest-trust/395689) ## Le nom de domaine spécifié n'existe pas ou n'a pas pu être contacté Pour résoudre ce problème, assurez-vous que les paramètres du groupe de sécurité de votre domaine et de la liste de contrôle d'accès (ACL) de votre VPC sont corrects et que vous avez correctement saisi les informations relatives à votre redirecteur conditionnel. AWS configure le groupe de sécurité pour ouvrir uniquement les ports requis pour les communications Active Directory. Dans la configuration par défaut, le groupe de sécurité accepte le trafic vers ces ports à partir de n'importe quelle adresse IP. Le trafic sortant est limité au groupe de sécurité. Vous devez mettre à jour la règle sortante du groupe de sécurité pour autoriser le trafic vers votre réseau sur site. Pour plus d'informations sur les exigences de sécurité, veuillez consulter [Étape 2 : Préparation de votre Microsoft AD AWS géré](ms_ad_tutorial_setup_trust_prepare_mad.md). ![\[Modifier le groupe de sécurité\]](http://docs.aws.amazon.com/fr_fr/directoryservice/latest/admin-guide/images/edit_security_group.png) Si les serveurs DNS des réseaux des autres annuaires utilisent des adresses IP publiques (non conformes à la norme RFC 1918), vous devrez ajouter une route IP sur l'annuaire depuis la console Directory Services vers les serveurs DNS. Pour plus d'informations, veuillez consulter [Création, vérification ou suppression d'une relation d'approbation](ms_ad_setup_trust.md#trust_steps) et [Conditions préalables](ms_ad_setup_trust.md#trust_prereq). L'Internet Assigned Numbers Authority (IANA) a réservé les trois blocs suivants de l'espace d'adresse IP aux Internets privés : + 10.0.0.0 - 10.255.255.255 (préfixe 10/8) + 172.16.0.0 - 172.31.255.255 (préfixe 172.16/12) + 192.168.0.0 - 192.168.255.255 (préfixe 192.168/16) Pour plus d'informations, consultez [https://tools.ietf.org/html/rfc1918.](https://tools.ietf.org/html/rfc1918) Vérifiez que le **nom du site AD par défaut** de votre Microsoft AD AWS géré correspond au **nom du site AD par défaut** de votre infrastructure locale. L'ordinateur détermine le nom du site en utilisant un domaine dont l'ordinateur est membre, et non le domaine de l'utilisateur. Le fait de renommer le site pour qu'il corresponde au site le plus proche garantit que le localisateur de contrôleurs de domaine utilisera un contrôleur de domaine du site le plus proche. Si le problème n'est pas résolu, il est possible que les informations fournies d'un redirecteur conditionnel créé précédemment soient mises en cache et empêchent la création d'une nouvelle approbation. Patientez plusieurs minutes et essayez à nouveau de créer la confiance et un redirecteur conditionnel. Pour plus d'informations sur son fonctionnement, consultez [Domain Locator Across a Forest Trust](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689) sur le Microsoft site Web. ![\[Nom du premier site par défaut\]](http://docs.aws.amazon.com/fr_fr/directoryservice/latest/admin-guide/images/default_first_site_name.png) ## L'opération n'a pas pu être effectuée sur ce domaine Pour résoudre ce problème, assurez-vous que les noms NETBIOS des deux domaines/annuaires sont différents. Si les noms NETBIOS des domaines/annuaires sont identiques, créez à nouveau l'un d'entre eux avec un nom NETBIOS différent, puis réessayez. ## La création d'une relation d'approbation échoue en raison de l'erreur « Required and valid domain name » (Nom de domaine obligatoire et valide) Les noms DNS peuvent uniquement contenir des caractères alphabétiques (A à Z), des caractères numériques (0 à 9), le signe moins (-) et un point (.). Les points ne sont autorisés que lorsqu'ils sont utilisés pour délimiter les composants des noms de style de domaine. Éléments à prendre également en compte : + AWS Managed Microsoft AD ne prend pas en charge les approbations avec des domaines à étiquette unique. Pour plus d'informations, consultez la section [Microsoftprise en charge des domaines à étiquette unique](https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/single-label-domains-support-policy). + Selon la RFC 1123 ([https://tools.ietf.org/html/rfc1123](https://tools.ietf.org/html/rfc1123)), les seuls caractères pouvant être utilisés dans les étiquettes DNS sont « A » à « Z », « a » à « z », « 0 » à « 9 » et un trait d'union (« - »). Un point (.) est également utilisé dans les noms DNS, mais uniquement entre les étiquettes DNS et à la fin d'un FQDN. + Selon la RFC 952 ([https://tools.ietf.org/html/rfc952](https://tools.ietf.org/html/rfc952)), un « nom » (réseau, hôte, passerelle ou nom de domaine) est une chaîne de texte comportant jusqu'à 24 caractères tirés de l'alphabet (A-Z), des chiffres (0-9), du signe moins (-) et du point (.). Notez que les points ne sont autorisés que lorsqu'ils servent à délimiter les composants des « noms de style de domaine ». Pour plus d'informations, consultez la section [Respect des restrictions de noms pour les hôtes et les domaines](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959336(v=technet.10)) sur le Microsoft site Web. ## Outils généraux utilisés pour tester les approbations Les outils suivants peuvent être utilisés pour résoudre divers problèmes liés aux approbations. **AWS Outil de dépannage de Systems Manager Automation** [Support Automation Workflows (SAW)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-support.html) tire parti de AWS Systems Manager Automation pour vous fournir un runbook prédéfini pour Directory Service. L'outil [AWSSupport-TroubleshootDirectoryTrust](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-awssupport-troubleshootdirectorytrust.html)Runbook vous aide à diagnostiquer les problèmes courants de création de confiance entre AWS Managed Microsoft AD et un Microsoft Active Directory local. **DirectoryServicePortTest outil** L'outil de [DirectoryServicePortTest](samples/DirectoryServicePortTest.zip)test peut être utile pour résoudre les problèmes de création de confiance entre AWS Managed Microsoft AD et Active Directory sur site. Pour obtenir un exemple de la manière dont l'outil peut être utilisé, veuillez consulter [Test de votre connecteur AD Connector](ad_connector_getting_started.md#connect_verification). **Outils NETDOM et NLTEST** Les administrateurs peuvent utiliser les outils de ligne de commande **Netdom** et **Nltest** pour rechercher, afficher, créer, supprimer et gérer les approbations. Ces outils communiquent directement avec l'autorité LSA d'un contrôleur de domaine. Pour un exemple d'utilisation de ces outils, consultez [Netdom](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc772217(v=ws.11)) et [NLTEST](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11)) sur le Microsoft site Web. **Outil de capture de paquets** Vous pouvez utiliser l'utilitaire intégré de capture de paquets Windows pour étudier et résoudre un problème de réseau potentiel. Pour plus d'informations, veuillez consulter [Capture a Network Trace without installing anything](https://techcommunity.microsoft.com/t5/iis-support-blog/capture-a-network-trace-without-installing-anything-amp-capture/ba-p/376503) (français non garanti). # Résolution des problèmes liés AWS à l'utilisation élevée du processeur Microsoft AD dans Managed Les informations suivantes peuvent vous aider à résoudre les problèmes de processeur élevés sur les contrôleurs de domaine Microsoft AD AWS gérés. ## Trouver la cause première La première étape pour résoudre les problèmes d'utilisation élevée du processeur consiste à analyser les CloudWatch métriques afin d'identifier les modèles susceptibles d'expliquer l'augmentation de la consommation de ressources. ### Étape 1 : Examiner Directory Service CloudWatch les métriques Surveillez les performances de votre service Microsoft AD AWS géré à l'aide de CloudWatch métriques pour identifier les modèles de trafic liés à une utilisation élevée du processeur. Pour des informations détaillées sur l'affichage et l'interprétation Directory Service des métriques, consultez[Utilisation CloudWatch pour surveiller les performances de vos contrôleurs de domaine Microsoft AD AWS gérés](ms_ad_monitor_dc_performance.md). Recherchez des tendances changeantes dans les indicateurs clés suivants qui pourraient expliquer l'augmentation du processeur : + **Requêtes DNS par seconde** : des pics soudains peuvent indiquer des problèmes de résolution DNS ou des applications mal configurées. + Authentifications **Kerberos/NTLM : taux d'authentification plus élevés à partir des** connexions d'utilisateurs ou des comptes de service. + **Requêtes LDAP par seconde** : augmentation du trafic LDAP provenant d'applications ou de services. Comparez les mesures actuelles avec les données de référence historiques pour identifier le moment où l'utilisation élevée du processeur a commencé et corrélez-la avec des augmentations de trafic spécifiques. Si aucune corrélation n'est trouvée dans les métriques, la cause première n'est pas une augmentation massive du trafic. Au lieu de cela, la cause première est probablement une requête LDAP inefficace, passez à. [Étape 3 : Capturez une analyse détaillée du trafic avec Traffic Mirroring](#ms_ad_high_cpu_step3) ### Étape 2 : Identifier les machines sources à l'aide des journaux de flux VPC Les journaux de flux VPC constituent une méthode efficace pour identifier les adresses IP sources des machines générant du trafic vers vos contrôleurs de domaine. Pour plus d'informations, voir [Journalisation du trafic IP à l'aide des journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html). Utilisez les numéros de port de destination pour différencier les services : + **Port 53** — Requêtes DNS + **Port 88 — Authentification** Kerberos + **Port 123 — Synchronisation** de l'horloge NTP + **Port 135, 49152-65535** — RPC + **Ports 389, 636, 3268, 3269 : requêtes LDAP (389 ou 3268** pour le protocole LDAP standard, 636 ou 3269 pour le protocole LDAPS) + **Port 445** — Partage de fichiers SMB (politiques de groupe) + **Port 464 — Modification** du mot de passe Kerberos + **Port 9389** — Service Web Active Directory Pour activer et analyser les journaux de flux VPC : + Activez les journaux de flux VPC pour les sous-réseaux contenant votre contrôleur de domaine. ENIs + Filtrez les journaux par port de destination pour identifier les modèles de trafic. + Organisez selon le plus grand nombre de paquets and/or , le plus grand nombre d'octets sur une période donnée. + Analysez les adresses IP sources pour déterminer quelles machines génèrent le plus de trafic. ### Étape 3 : Capturez une analyse détaillée du trafic avec Traffic Mirroring Les journaux de flux VPC fournissent des informations limitées sur le contenu réel des demandes. Pour une analyse plus détaillée, envisagez la mise en miroir du trafic pour capturer les données complètes des paquets. Pour plus d'informations, voir [Commencer à utiliser la mise en miroir du trafic pour surveiller le trafic réseau](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-getting-started.html). Cela est particulièrement utile lorsque vous devez analyser : + Complexité et efficacité du filtre LDAP + Modèles de requêtes DNS spécifiques + Détails de la demande d'authentification La mise en miroir du trafic vous permet de capturer des paquets réseau complets envoyés à vos instances de contrôleur de domaine, ce qui permet une analyse approfondie du trafic entraînant une utilisation élevée du processeur. ### Étape 4 : Examiner les applications sources et optimiser le trafic Une fois que vous avez identifié les machines sources et les modèles de trafic, examinez les applications qui génèrent le trafic : + Passez en **revue les configurations des applications** : vérifiez si les applications font des requêtes inefficaces ou excessives. Évitez de coder l'application en dur sur un seul contrôleur de domaine. + **Analyser les requêtes LDAP** : les requêtes LDAP inefficaces sont la cause la plus fréquente d'un processeur de contrôleur de domaine élevé. Recherchez les filtres complexes qui pourraient bénéficier de l'indexation des attributs. + **Examiner la mise en cache DNS** — Vérifiez que la mise en cache du client DNS est activée pour réduire les requêtes répétitives. + **Vérifiez les modèles d'authentification** : déterminez si les comptes de service s'authentifient trop fréquemment. ## Stratégies de résolution Sur la base de votre enquête, mettez en œuvre des stratégies d'optimisation appropriées : ### Optimisez les applications + **Optimisation des requêtes LDAP** : réécrivez des requêtes LDAP complexes. Évitez de définir la base de recherche à la racine du domaine et configurez-la plutôt sur une unité d'organisation où résident les objets que vous recherchez. Évitez d'utiliser une zone de recherche qui effectue des recherches dans des sous-arborescences. Utilisez plutôt une portée de base ou à un seul niveau. Incluez la classe d'objet dans votre filtre. Par exemple, `(objectClass=user)` ou `(objectClass=computer)`. Évitez d'utiliser des caractères génériques dans le filtre, sauf si l'attribut est indexé. Ajoutez un index si une analyse par caractères génériques est requise. Pour de plus amples informations, veuillez consulter [Étendez votre schéma AWS Managed Microsoft AD](ms_ad_schema_extensions.md). N'indexez pas tout car le processus d'indexation augmente également l'utilisation du processeur. ``` # Sample LDIF code to index the email attribute dn: CN=mail,CN=Schema,CN=Configuration,DC=yourdomain,DC=com changetype: modify replace: searchFlags searchFlags: 1 ``` + **Activer la mise en cache des clients DNS** : configurez les clients pour qu'ils mettent en cache les réponses DNS localement afin de réduire la charge du serveur. + **Implémenter le regroupement** de connexions : configurez les applications pour qu'elles réutilisent les connexions LDAP plutôt que d'en créer de nouvelles pour chaque requête. ### Faites évoluer votre infrastructure d'annuaires Si l'optimisation du trafic ne résout pas le problème d'utilisation élevée du processeur : + **Ajouter d'autres contrôleurs de domaine** : augmentez votre capacité en déployant des contrôleurs de domaine supplémentaires pour répartir la charge. Pour de plus amples informations, veuillez consulter [Déploiement de contrôleurs de domaine supplémentaires pour votre Microsoft AD AWS géré](ms_ad_deploy_additional_dcs.md). + **Mise à niveau vers l'édition Enterprise** : si vous utilisez l'édition standard, passez à l'édition Enterprise pour augmenter la capacité et les performances du processeur. Pour de plus amples informations, veuillez consulter [Mise à niveau de votre Microsoft AD AWS géré](ms_ad_upgrade_edition.md). Si vous utilisez déjà Enterprise Edition, contactez [AWS Support](https://docs.aws.amazon.com//awssupport/latest/user/case-management.html)pour une capacité accrue. Pour obtenir des informations sur les tarifs des éditions AWS gérées de Microsoft AD, consultez la section [Directory Service Tarification](https://aws.amazon.com/directoryservice/pricing/#Comparison_Table).