Cartes de transformation LDAP

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 6 minutes de lecture

    • 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 standard et des cartes de transformation. Vous pouvez également créer des cartes de transformation LDAP personnalisées.
    Important :
    Que vous sélectionniez ou que vous créiez des cartes de transformation LDAP personnalisées, il doit y avoir une carte de transformation 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 des 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 utilisateur à partir d’informations d’identification LDAP dans le cadre d’une connexion LDAP à la demande. Contient les mappages d’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’UO LDAP. Contient les mappages d’un serveur LDAP Active Directory.
    Remarque :
    Par défaut, le système ne dispose pas d’une carte de transformation pour les enregistrements du 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 responsable de l’utilisateur et pour placer les utilisateurs dans des groupes.
    ldap_import Sélectionnez 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

    Lorsque vous spécifiez 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 tel que « gestionnaire » est le nom unique (ND) du gestionnaire.

    Sans logique supplémentaire, vous pouvez créer 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 utilisateur 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 dispose d’un champ Carte qui fait référence au mappage d’importation hérité.
    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, désactivez la référence à la carte d’importation héritée.
    Paramètres du 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 l’importation d’utilisateurs LDAP), l’intégration utilise les mappages par défaut suivants :

    Tableau 3. Mappage par défaut de l’importation LDAP
    Champ ou variable d’utilisateur Attribut LDAP
    user_name Samaccountname
    e-mail Courrier
    Téléphone numéro de téléphone
    home_phone Téléphone à domicile
    mobile_phone mobile
    first_name givenName
    last_name Sn
    Titre Titre
    department department
    responsable responsable
    middle_name Initiales
    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 relie un attribut LDAP importé à un champ approprié dans la table cible (Utilisateur ou Groupe). Par exemple, les données témoins de l’attribut sAMAccountName sont mappées au champ ID d’utilisateur dans 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. Si aucun enregistrement correspondant n’existe, l’instance crée un nouvel enregistrement pour le champ de référence, sauf indication contraire du mappage de champ.

    Par exemple, supposons que l’attribut LDAP l soit mappé au champ de référence Emplacement dans 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 de l’utilisateur importé a maintenant un lien vers le nouvel enregistrement d’emplacement.

    Toutefois, il arrive que l’attribut LDAP renvoie un nom distinctif (DN), qui est essentiellement une référence à un autre enregistrement dans le répertoire LDAP. Par exemple, l’attribut gestionnaire contient généralement le nom unique du gestionnaire de l’entrée actuelle du répertoire LDAP. 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, qui peut ne pas être assez longue pour certaines valeurs DN. Le ServiceNow système tronque toute valeur qui dépasse la longueur du champ.

    Les administrateurs ne souhaitent généralement pas que le système crée de nouveaux utilisateurs à partir de la valeur DN, car le nouvel utilisateur n’est pas associé à un utilisateur existant. Au lieu de cela, les administrateurs veulent que l’importation localise l’enregistrement utilisateur existant du gestionnaire et l’associe à l’utilisateur nouvellement importé. Le script include LDAPUtils contient les fonctions setManager et processManagers qui peuvent analyser un DN et 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 de l’utilisateur du gestionnaire associé. Pour gérer de tels tickets, vous pouvez appeler la fonction processManagers une fois la transformation terminée. Par exemple, la carte de transformation 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 fonctions setManager et processManagers si votre intégration LDAP n’utilise pas l’attribut manager.