Dépannage : l'utilisateur n'a pas été créé dans Active Directory par eADM

Cet article décrit les causes les plus courantes d'échec de la création d'un compte utilisateur dans Active Directory (AD) par eADM, et fournit des instructions permettant d'identifier et de résoudre chacune d'entre elles. Il s'adresse aux administrateurs eADM et aux partenaires informatiques chargés de la gestion des intégrations AD sur site.

Comment lire le journal d'exportation AD d'eADM

Le client local eADM génère un journal détaillé pour chaque opération d'exportation. Ce journal constitue le principal outil de diagnostic lorsqu'un compte utilisateur n'est pas créé dans AD.

Les fichiers journaux peuvent être téléchargés via « Synchronisation » -> « État » -> « Plus » -> « Télécharger le journal du client eADM ». Sinon, ils se trouvent généralement dans C:\eADM\ ou un sous-dossier configuré lors de l'installation. Chaque entrée respecte le modèle suivant :

DD.MM.YYYY HH:MM:SS - [action or result message]

Une opération de création réussie enregistre chaque attribut défini, suivie d'une ligne indiquant qu'aucune erreur n'est survenue. Une opération de création ayant échoué enregistre la séquence d'attributs, puis se termine par un code d'erreur et un message. Exemple d'échec de création tiré d'un dossier d'assistance connu :

23.07.2025 14:20:41 - Creating with LDAP://DC-SERVER/cn=Ola Nordmann,OU=eAdm,OU=Brukere,...\n23.07.2025 14:20:41 - Setting samAccountName to value 1001on\n23.07.2025 14:20:41 - Checking if upn is unique in domain ola.nordmann@eksempel.kommune.no\n23.07.2025 14:20:41 - Setting userPrincipalName to value ola.nordmann@eksempel.kommune.no\n23.07.2025 14:20:41 - 173585349|The object already exists.

Les lignes d'erreur respectent le format suivant : ERROR_CODE|Error message text. Le code d'erreur et le message permettent, ensemble, d'identifier la cause. Notez la dernière ligne d'attribut traitée avec succès avant l'erreur : cela permet de déterminer plus précisément à quel endroit Active Directory a rejeté l'opération.

Causes courantes et solutions

1. Objet en double — l'utilisateur existe déjà dans AD

eADM tente de créer un objet sous un nom distinctif (DN) ou avec un sAMAccountName qui existe déjà dans AD. AD rejette l'opération en affichant un message d'erreur tel que The object already exists.

Cela peut se produire dans les cas suivants :

• Deux employés partagent le même fichier généré sAMAccountName (par exemple, les deux se traduisent par 1001on).

• Un compte utilisateur précédemment supprimé n'a pas été entièrement supprimé d'Active Directory et un « tombstone » ou un objet recyclé subsiste.

• L'utilisateur a été créé manuellement dans AD avant que eADM ne tente de procéder à son provisionnement.

• Deux utilisateurs ont la même date de naissance, ce qui entraîne un conflit dans une règle de génération de nom d'utilisateur basée sur la date.

Résolution :

1. Rechercher dans AD le sAMAccountName ou le code CN figurant dans le journal pour identifier l'objet en conflit.

2. Dans eADM, ouvrez la fiche de l'utilisateur concerné et vérifiez le champ « Nom d'utilisateur AD ». Si deux utilisateurs partagent la même valeur, corrigez celle de l'un d'entre eux via la configuration d'eADM ou en modifiant la règle de génération des noms d'utilisateur.

3. Si un objet obsolète existe dans AD, supprimez-le ou déplacez-le hors de l'unité d'organisation (OU) cible, puis lancez un nouveau cycle de synchronisation.

2. Droits d'accès insuffisants sur le compte de service

Le compte de service utilisé par eADM pour se connecter à AD ne dispose pas des droits nécessaires pour créer des objets dans l'unité d'organisation (OU) cible, ou ne dispose pas d'un accès en écriture à un ou plusieurs attributs définis lors de la création.

Causes courantes :

• Le compte de service ne dispose pas de l'autorisation « Créer des objets enfants » sur l'unité d'organisation cible.

• Le compte de service ne dispose pas des droits d'écriture sur certains attributs, tels que proxyAddresses, manager, ou employeeNumber.

• La structure de l'unité organisationnelle (OU) a été modifiée après la configuration de la délégation initiale, et les autorisations du compte de service ne couvrent plus la nouvelle OU cible.

Solution : Vérifiez les autorisations déléguées sur l'unité d'organisation (OU) cible dans Active Directory. Assurez-vous que le compte de service eADM dispose au minimum des droits suivants :

• Créer et supprimer des objets « Utilisateur » dans l'unité d'organisation cible.

• Droit d'écriture sur tous les attributs configurés dans le modèle d'exportation eADM pour ce type d'utilisateur.

Contactez l'administrateur AD du client pour modifier les autorisations déléguées. N'accordez pas les droits d'administrateur de domaine au compte de service eADM.

3. Exigences de complexité du mot de passe non respectées

Si eADM est configuré pour exiger la définition d'un mot de passe lors de la création d'un nouveau compte, Active Directory refusera cette création si le mot de passe ne respecte pas la politique de mot de passe du domaine, notamment en matière de longueur minimale, de règles de complexité ou d'historique des mots de passe.

Solution : Vérifiez le mot de passe par défaut configuré dans le modèle d'exportation eADM et comparez-le à la stratégie de mot de passe détaillée du domaine (le cas échéant) ou à la stratégie par défaut du domaine. Le mot de passe défini par eADM lors de la création du compte doit respecter toutes les exigences de la stratégie.

4. Données non valides ou violation du schéma

eADM tente d'écrire une valeur dans un attribut AD que le schéma n'autorise pas pour ce domaine — par exemple, une valeur dont le type de données est incorrect, une valeur contenant des caractères non pris en charge ou un attribut obligatoire manquant.

Causes courantes :

• Le sAMAccountName contient des caractères non autorisés par AD (par exemple, des espaces, des barres obliques ou des caractères spéciaux).

• Un attribut AD obligatoire requis par une extension de schéma n'est pas mappé dans le modèle d'exportation eADM.

• Le manager L'attribut fait référence à un DN qui n'existe pas dans AD, comme le montre An invalid dn syntax has been specified dans le journal.

• Le Chemin d'accès parent (parentPath) configuré dans le modèle d'exportation eADM pour les utilisateurs actifs est incorrect ou manquant pour l'utilisateur concerné, ce qui génère un DN cible non valide.

• L'utilisateur est en cours de création avec un CN valeur non valide dans AD, contenant par exemple des caractères non autorisés par AD dans un nom distinctif relatif.

• Un champ numérique du modèle d'exportation envoie une valeur de type chaîne de caractères.

Solution : Identifiez la dernière ligne d'attribut enregistrée avant l'erreur dans le journal. Vérifiez la valeur attribuée à cet attribut dans le modèle d'exportation eADM et dans les données sources issues du système RH. Corrigez soit le mappage des données dans eADM, soit la valeur source dans le système RH, puis lancez une nouvelle synchronisation.

5. Problème de réseau ou de connexion avec l'agent AD

Le service cloud eADM ne parvient pas à communiquer avec le client local eADM installé sur site, ou bien ce dernier ne parvient pas à communiquer avec le contrôleur de domaine AD. Dans ce cas, aucune entrée de journal n'est enregistrée pour le cycle de synchronisation concerné, ou bien le journal indique un délai d'expiration ou une erreur de connexion plutôt qu'un code d'erreur spécifique à AD.

Résolution :

1. Vérifiez que le service client local eADM ou la tâche planifiée est en cours d'exécution sur le serveur sur site.

2. Vérifiez que le trafic HTTPS sortant (port 443) est autorisé depuis le serveur vers le point de terminaison cloud eADM.

3. Vérifiez que le serveur peut accéder au contrôleur de domaine AD sur le port LDAP requis (389 ou 636).

4. Consultez l'Observateur d'événements Windows sur le serveur pour vérifier s'il y a des erreurs de connectivité ou de service.

6. Correspondance ambiguë — même valeur d'attribut de fusion partagée par deux comptes AD

Si deux comptes AD possèdent déjà la même valeur dans l'attribut « mergeattribute » configuré, eADM ne peut pas déterminer de manière univoque quel compte correspond à l'utilisateur en cours de provisionnement. Selon le cas, cela peut soit bloquer l'opération de création, soit entraîner la mise à jour du mauvais compte par eADM au lieu de la création d'un nouveau compte.

Cela peut se produire dans les cas suivants :

• La valeur de l'attribut « mergeattribute » a été définie manuellement sur un compte AD, en dehors du processus de provisionnement d'eADM.

• Un compte AD hérité d'une période d'emploi antérieure conserve toujours les mêmes employeeID ou employeeNumber en tant que nouvel employé.

• Deux enregistrements RH partagent le même « employeeID » ou « employeeNumber » en raison d'une erreur de saisie dans le système RH source.

• Un compte AD a été migré ou restauré à partir d'une sauvegarde avec une valeur obsolète pour l'attribut « mergeattribute », qui a depuis été réattribuée à un autre salarié dans le système RH.

Résolution :

1. Recherchez dans AD tous les comptes dont la valeur de l'attribut « mergeattribute » correspond à celle indiquée dans le journal eADM ou dans la fiche utilisateur, par exemple : Get-ADUser -Filter {employeeID -eq "value"} -Properties employeeID.

2. Vérifiez quel compte correspond bien et de manière à jour à la fiche RH. Supprimez ou corrigez la valeur de l'attribut « mergeattribute » sur tout autre compte qui présenterait à tort cette même valeur.

3. Restaurez les utilisateurs concernés dans eADM afin que les liens vers les utilisateurs correspondants dans AD soient corrigés.

7. La valeur de l'attribut « Merge » d'un compte existant correspond à un autre utilisateur

Contrairement à la cause n° 6, un seul compte AD est concerné ici — mais la valeur de son attribut « mergeattribute » correspond justement à l’identifiant d’une autre personne, généralement un utilisateur nouvellement provisionné. eADM identifie ce compte existant comme une correspondance certaine et le met à jour, au lieu de créer un nouveau compte pour le nouvel utilisateur. Du point de vue d’eADM, il n’y a aucune ambiguïté ; cela ne génère donc généralement aucune erreur : la synchronisation semble aboutir, mais c’est la mauvaise personne qui se retrouve associée au compte.

Cela peut se produire dans les cas suivants :

• Le système RH réutilise les numéros d'employé après le départ d'un salarié, et un nouvel employé se voit ensuite attribuer le même numéro, qui figure toujours sur le compte AD inactif de l'ancien salarié.

• Quelqu'un a saisi manuellement une valeur erronée employeeID ou employeeNumber une valeur associée à un compte AD existant, et cette valeur coïncide justement avec l'identifiant réel d'un autre salarié.

• Une migration ou une restauration de données a laissé une valeur obsolète pour l'attribut « mergeattribute » sur un compte que le service des ressources humaines a depuis réattribué à une autre personne.

Résolution :

1. Dans eADM, identifiez le compte AD existant auquel l'enregistrement du nouvel utilisateur a été associé et mis à jour, au lieu de créer un nouveau compte.

2. Vérifiez à qui appartient réellement ce compte AD et quelle doit être la valeur correcte de l'attribut « mergeattribute » pour les deux personnes concernées.

3. Corrigez la valeur de l'attribut « mergeattribute » du compte AD associé à tort afin qu'elle corresponde à son véritable propriétaire, ce qui permettra de libérer cette valeur pour la personne concernée.

4. Restaurez les utilisateurs concernés dans eADM afin que les liens vers les utilisateurs correspondants dans AD soient corrigés.

Liste de contrôle pour le diagnostic

Articles connexes

• Dépannage de l'exception « System.ServiceModel.FaultException » dans les journaux du client local eADM

• Mise à jour des données utilisateur dans eADM

Dernière mise à jour : 27 juillet 2026