Cartes de transformation LDAP

La carte de transformation déplace les données de la table de jeux d’importation vers la table cible (Utilisateur ou Groupe).

L’intégration LDAP utilise des jeux d’importation et des cartes de transformation standard. Vous pouvez également créer des cartes de transformation LDAP personnalisées.

Important :

Que vous sélectionniez ou créiez des cartes de transformation LDAP personnalisées, une carte de transformation doit être active pour un ensemble de tables source et cible. L’activation de plusieurs cartes de transformation pour les mêmes tables source et cible peut produire des entrées en double dans la table cible, sauf si vous fusionnez avec les champs correspondants.

Cartes de transformation LDAP par défaut

Par défaut, le système fournit deux cartes de transformation pour les données LDAP.

Tableau 1. Cartes de transformation LDAP par défaut

Carte de transformation	Table source	Table cible	Description
Importation d’utilisateur LDAP	[ldap_import]	[sys_user]	Carte de transformation par défaut pour la création d’enregistrements d’utilisateurs à partir des informations d’identification LDAP dans le cadre de la connexion LDAP à la demande. Contient des mappages pour un serveur LDAP Active Directory.
Importation de groupe LDAP	[ldap_group_import]	[sys_user_group]	Carte de transformation par défaut pour la création d’enregistrements de groupe à partir d’unités d’organisation LDAP. Contient des mappages pour un serveur LDAP Active Directory.

Remarque :

Par défaut, le système ne dispose pas d’une carte de transformation pour les enregistrements de département LDAP.

Conditions requises pour les cartes de transformation LDAP personnalisées

Si vous choisissez de créer une carte de transformation personnalisée, celle-ci doit répondre aux exigences de mappage suivantes.

Tableau 2. Conditions requises pour les cartes de transformation LDAP personnalisées

Table source	Champ source	Table cible	Champ cible	Fusion	Description
ldap_import	u_source	sys_user	source	Faux	Le champ u_source identifie le ND LDAP de l’utilisateur ou du groupe importé. Le système utilise ce champ pour déterminer si un utilisateur a besoin d’une authentification LDAP, pour trouver le gestionnaire d’un utilisateur et pour placer les utilisateurs dans des groupes.
ldap_import	Sélectionnez l’un des champs suivants : u_samaccountname u_dn u_cn	sys_user	user_name	vrai	Si LDAP s’intègre à Active Directory, sélectionnez u_samaccountname comme champ source. Si d’autres répertoires LDAP sont utilisés, sélectionnez u_dn ou u_cn comme champ source.

Différences entre les cartes de transformation LDAP et les cartes d’importation héritées

Lors de la spécification des relations de mappage LDAP à l’aide de cartes de transformation, il existe une différence majeure dans la façon dont les champs de référence sont définis pour le gestionnaire et le département.

Lors de l’utilisation d’une carte de transformation, il est nécessaire d’utiliser un script de transformation pour créer des références. Cela est dû au fait que la valeur associée à un attribut LDAP comme « gestionnaire » est le nom unique (DN) du gestionnaire.

Sans logique supplémentaire, le résultat est la création d’un enregistrement utilisateur avec un nom de gestionnaire qui est le nom unique de cet utilisateur dans LDAP. L’intégration inclut un script de transformation pour faciliter la création de ces références. La carte de transformation par défaut « Importation d’utilisateurs LDAP » inclut des scripts de transformation pour ces références.

Relations de mappage existantes

Lors de la mise à jour des cartes d’importation héritées vers des cartes de transformation, vous pouvez conserver les relations de mappage LDAP qui existaient avant l’ajout de l’application LDAP système. Le serveur LDAP possède un champ Carte qui fait référence à la carte d’importation héritée.

Remarque :

Par défaut, ce champ est masqué, vous devez donc configurer le formulaire pour l’afficher.

Si vous souhaitez passer à l’utilisation d’une carte de transformation, effacez la référence à la carte d’importation héritée.

Paramètres de mappage d’importation LDAP

Vérifiez et utilisez des attributs pour limiter les champs que l’intégration importe à partir de la source LDAP. En outre, il est important de mapper le champ user_name à l’attribut LDAP qui contient l’ID de connexion de l’utilisateur. Pour Active Directory, il s’agit généralement de l’attribut sAMAccountName. Si vous souhaitez importer et fusionner sur un attribut binaire (tel que objectSID ou objectGUID), vous devez créer un script de transformation personnalisé.

Remarque :

Toute valeur mappée au champ user_name doit être unique.

Si vous ne spécifiez pas de carte de transformation (telle que LDAP User Import), l’intégration utilise les mappages par défaut suivants :

Tableau 3. Mappage par défaut de l’importation LDAP

Variable ou champ d’utilisateur	Attribut LDAP
user_name	sAMAccountName
E-mail	courrier
Téléphone	Numéro de téléphone
home_phone	Téléphone du domicile
mobile_phone	mobile
first_name	givenName
last_name	Sn
Titre	Titre
département	département
responsable	responsable
middle_name	paraphe
u_memberof	groupes
u_member	membres
u_manager	responsable

Transformation des données LDAP

Si un attribut LDAP contient des données simples, la carte de transformation lie un attribut LDAP importé à un champ approprié dans la table cible (Utilisateur ou Groupe). Par exemple, les exemples de données de l’attribut sAMAccountName sont mappées au champ ID d’utilisateur de la table Utilisateur.

Si les données LDAP importées sont mappées à un champ de référence, l’instance recherche un enregistrement correspondant existant. S’il n’existe aucun enregistrement correspondant, l’instance crée un nouvel enregistrement pour le champ de référence, sauf indication contraire du mappage de champs.

Par exemple, supposons que l’attribut LDAP l est mappé au champ de référence Emplacement de la table Utilisateur. Chaque fois que l’importation apporte une valeur d’attribut qui ne correspond pas à une valeur d’enregistrement d’emplacement existante, la carte de transformation crée un nouvel enregistrement d’emplacement. Le nouvel enregistrement d’emplacement a la même valeur que l’attribut importé et l’enregistrement d’utilisateur importé a maintenant un lien vers le nouvel enregistrement d’emplacement.

Toutefois, il arrive que l’attribut LDAP retourne un nom unique (DN), qui est essentiellement une référence à un autre enregistrement dans l’annuaire LDAP. Par exemple, l’attribut gestionnaire contient généralement le nom unique du gestionnaire de l’entrée de répertoire LDAP actuelle. Un DN importé utilise généralement une longue chaîne de texte telle que : cn=Beth Anglin,ou=Users,dc=my-domain,dc=com.

Avertissement :

Assurez-vous que vos champs cibles sont suffisamment longs pour contenir un DN. De nombreux champs de texte utilisent la longueur par défaut de 40, ce qui peut ne pas être suffisant pour certaines valeurs DN. Le ServiceNow système tronque toute valeur qui dépasse la longueur du champ.

En général, les administrateurs ne souhaitent pas que le système crée de nouveaux utilisateurs à partir de la valeur DN, car le nouvel utilisateur n’a aucune association avec un utilisateur existant. Au lieu de cela, les administrateurs souhaitent que l’importation localise l’enregistrement utilisateur existant du gestionnaire et l’associe à l’utilisateur nouvellement importé. L’include de script LDAPUtils contient les fonctions setManager et processManagers qui permettent d’analyser un DN et de rechercher un utilisateur existant. Pour de meilleurs résultats, utilisez ces fonctions pour créer une carte de transformation personnalisée.

Par exemple, le script de carte de transformation d’importation d’utilisateur LDAP appelle la fonction setManager :

// 
// The manager coming in from LDAP is the DN value for the manager.   
// The line of code below will locate the manager that matches the 
// DN value and set it into the target record.  If you are not  
// interested in getting the manager from LDAP then remove or 
// comment out the line below
ldapUtils. setManager (source , target ) ;

Dans certains cas, l’intégration importe l’enregistrement d’un utilisateur avant l’enregistrement utilisateur du gestionnaire associé. Pour gérer de tels cas, vous pouvez appeler la fonction processManagers une fois la transformation terminée. Par exemple, la carte de transformation d’importation d’utilisateur LDAP utilise un script de transformation onComplete pour appeler la fonction processManagers .

// It is possible that the manager for a user did not exist in the database when // the user was processed and therefore we could not locate and set the manager field. // The processManagers call below will find all those records for which a manager could  // not be found and attempt to locate the manager again. This happens at the end of the  // import and therefore all users should have been created and we should be able to  // locate the manager at this point 
ldapUtils. processManagers ( ) ;

Supprimez ou commentez les appels de fonction setManager et processManagers si votre intégration LDAP n’utilise pas l’attribut manager.