Avant de décider des spécificités de la configuration du client dans la gestion des identités (IdM), il faut d'abord établir les spécificités de la configuration actuelle, avant la migration.

L'état initial de presque tous les déploiements LDAP à migrer est l'existence d'un service LDAP fournissant des services d'identité et d'authentification.

Figure 4.1. Configuration de base de l'annuaire LDAP et du client

Les clients Linux et Unix utilisent les bibliothèques PAM_LDAP et NSS_LDAP pour se connecter directement aux services LDAP. Ces bibliothèques permettent aux clients d'extraire des informations sur les utilisateurs de l'annuaire LDAP comme si les données étaient stockées dans /etc/passwd ou /etc/shadow. Dans la réalité, l'infrastructure peut être plus complexe si un client utilise LDAP pour les recherches d'identité et Kerberos pour l'authentification ou d'autres configurations.

Il existe des différences structurelles entre un annuaire LDAP et un serveur de gestion des identités (IdM), notamment en ce qui concerne la prise en charge des schémas et la structure de l'arborescence de l'annuaire. Pour plus d'informations sur ces différences, voir la section Contrasting IdM with a Standard LDAP Directory de la page Planification de la configuration du client lors de la migration de LDAP vers IdM. Ces différences peuvent avoir un impact sur les données, en particulier sur l'arborescence de l'annuaire, qui affecte les noms d'entrée. Cependant, les différences ont peu d'impact sur la configuration du client et sur la migration des clients vers IdM.

Le System Security Services Daemon (SSSD) de Red Hat Enterprise Linux (RHEL) utilise des bibliothèques PAM et NSS spéciales, pam_sss et nss_sss. Grâce à ces bibliothèques, SSSD peut s'intégrer très étroitement à la gestion des identités (IdM) et bénéficier de toutes ses fonctions d'authentification et d'identité. SSSD dispose d'un certain nombre de fonctions utiles, telles que la mise en cache des informations d'identité afin que les utilisateurs puissent se connecter même si la connexion au serveur central est perdue.

Contrairement aux services d'annuaire LDAP génériques qui utilisent les bibliothèques pam_ldap et nss_ldap, SSSD établit des relations entre les informations d'identité et d'authentification en définissant domains. Dans SSSD, un domaine définit les fonctions dorsales suivantes :

Le domaine SSSD est ensuite configuré pour utiliser un site provider afin de fournir les informations nécessaires à l'une ou à l'ensemble de ces fonctions. La configuration du domaine nécessite toujours un fournisseur identity. Les trois autres fournisseurs sont facultatifs ; si un fournisseur d'authentification, d'accès ou de mot de passe n'est pas défini, c'est le fournisseur d'identité qui est utilisé pour cette fonction.

SSSD peut utiliser IdM pour toutes ses fonctions d'arrière-plan. Il s'agit de la configuration idéale, car elle offre toute la gamme des fonctionnalités de l'IdM, contrairement aux fournisseurs d'identité LDAP génériques ou à l'authentification Kerberos. Par exemple, au cours des opérations quotidiennes, le SSSD applique les règles de contrôle d'accès basées sur l'hôte et les fonctions de sécurité de l'IdM.

Figure 4.2. Clients et SSSD avec un back-end IdM

Le script ipa-client-install configure automatiquement SSSD pour qu'il utilise IdM pour tous ses services back-end, de sorte que les clients RHEL sont configurés par défaut avec la configuration recommandée.

Les systèmes Unix et Linux tels que Mac, Solaris, HP-UX, AIX et Scientific Linux prennent en charge tous les services gérés par la gestion des identités (IdM), mais n'utilisent pas SSSD. De même, les anciennes versions de Red Hat Enterprise Linux (RHEL), en particulier 6.1 et 5.6, prennent en charge SSSD mais ont une version plus ancienne qui ne prend pas en charge IdM en tant que fournisseur d'identité.

S'il n'est pas possible d'utiliser une version moderne de SSSD sur un système, les clients peuvent être configurés de la manière suivante :

Pour plus d'informations sur la configuration d'un site RHEL client with an older version of SSSD afin qu'il utilise le serveur IdM comme fournisseur d'identité et domaine d'authentification Kerberos, voir la section Configuration des fournisseurs d'identité et d'authentification pour SSSD du manuel RHEL 7 System-Level Authentication Guide.

Figure 4.3. Clients et IdM avec LDAP et Kerberos

La meilleure pratique consiste généralement à utiliser la configuration la plus sûre possible pour un client. Cela signifie SSSD ou LDAP pour les identités et Kerberos pour l'authentification. Cependant, dans certaines situations de maintenance et structures informatiques, il peut être nécessaire de recourir au scénario le plus simple possible : configurer LDAP pour fournir à la fois l'identité et l'authentification en utilisant les bibliothèques nss_ldap et pam_ldap sur les clients.

Pour migrer des comptes d'utilisateurs de LDAP vers Identity Management (IdM) sans obliger les utilisateurs à changer leurs mots de passe, vous pouvez utiliser les méthodes suivantes :

Method 1: Using the migration web page

Demander aux utilisateurs d'entrer leurs identifiants LDAP une seule fois dans une page spéciale de l'interface utilisateur Web IdM, https://ipaserver.example.com/ipa/migration. Un script exécuté en arrière-plan capture alors le mot de passe en clair et met correctement à jour le compte utilisateur avec le mot de passe et un hachage Kerberos approprié.

Method 2 (recommended): Using SSSD

Atténuez l'impact de la migration sur les utilisateurs en utilisant le démon des services de sécurité du système (SSSD) pour générer les clés utilisateur requises. C'est le meilleur scénario pour les déploiements avec un grand nombre d'utilisateurs ou lorsque les utilisateurs ne doivent pas être gênés par les changements de mot de passe.

Avec la méthode 2, l'ensemble du processus est invisible pour les utilisateurs. Ils se connectent à un service client sans remarquer que leur mot de passe a été transféré de LDAP à IdM.

Bien que dans la plupart des déploiements, les mots de passe LDAP soient stockés de manière cryptée, certains utilisateurs ou certains environnements peuvent utiliser des mots de passe en clair pour les entrées utilisateur.

Lorsque les utilisateurs sont transférés du serveur LDAP au serveur IdM, leurs mots de passe en clair ne sont pas transférés car IdM n'autorise pas les mots de passe en clair. Au lieu de cela, un principal Kerberos est créé pour chaque utilisateur, le keytab est défini sur true et le mot de passe est défini comme expiré. Cela signifie que l'IdM demande à l'utilisateur de réinitialiser le mot de passe lors de la prochaine connexion. Pour plus d'informations, voir Planifier la migration des mots de passe LDAP qui ne répondent pas aux exigences de l'IdM.

Si les mots de passe des utilisateurs dans le répertoire d'origine ne sont pas conformes aux politiques de mot de passe définies dans la gestion des identités (IdM), les mots de passe deviennent invalides après la migration.

La réinitialisation du mot de passe est effectuée automatiquement la première fois qu'un utilisateur tente d'obtenir un ticket Kerberos (TGT) dans le domaine IdM en entrant kinit. L'utilisateur est obligé de changer son mot de passe :

[migrated_idm_user@idmclient ~]$ kinit
Password for migrated_idm_user@IDM.EXAMPLE.COM:
Password expired.  You must change it now.
Enter new password:
Enter it again:

Le processus de migration d'un serveur LDAP vers IdM utilise un script spécial, ipa migrate-ds, pour effectuer la migration. Ce script a des exigences spécifiques concernant la structure de l'annuaire LDAP et les entrées LDAP. La migration n'est possible que pour les services d'annuaire conformes à LDAPv3, qui comprennent plusieurs annuaires courants :

La migration d'un serveur LDAP vers IdM a été testée avec Red Hat Directory Server et OpenLDAP.

Il existe de nombreux scénarios de configuration possibles pour les serveurs LDAP et pour la gestion des identités (IdM), ce qui influe sur la fluidité du processus de migration. Les exemples de procédures de migration présentés dans ce chapitre reposent sur les hypothèses suivantes concernant l'environnement :

Dans le cas d'un annuaire de taille modérée (environ 10 000 utilisateurs et 10 groupes), il est nécessaire de disposer d'un système IdM cible suffisamment puissant pour permettre la migration. Les exigences minimales pour une migration sont les suivantes

Si vous utilisez sudo avec LDAP, vous devez migrer manuellement les règles sudo stockées dans LDAP vers Identity Management (IdM). Red Hat vous recommande de recréer les groupes de réseau dans IdM en tant que groupes d'hôtes. IdM présente automatiquement les groupes d'hôtes comme des groupes de réseaux traditionnels pour les configurations sudo qui n'utilisent pas le fournisseur SSSD sudo.

Identity Management (IdM) utilise une commande spécifique, ipa migrate-ds, pour exécuter le processus de migration afin que les données de l'annuaire LDAP soient correctement formatées et importées dans le serveur IdM. Lors de l'utilisation de ipa migrate-ds, l'utilisateur du système distant, spécifié par l'option --bind-dn, doit avoir un accès en lecture à l'attribut userPassword, sinon les mots de passe ne seront pas migrés.

Le serveur IdM doit être configuré pour fonctionner en mode migration, puis le script de migration peut être utilisé. Pour plus de détails, voir Migration d'un serveur LDAP vers IdM.

Une migration LDAP est essentiellement une opération d'importation spécialisée pour l'instance 389 Directory Server (DS) au sein du serveur IdM. L'optimisation de l'instance 389 DS pour améliorer les performances de l'opération d'importation peut contribuer à améliorer les performances globales de la migration.

Deux paramètres influent directement sur les performances des importations :

La migration vers IdM comporte quatre étapes principales, dont l'ordre varie selon que l'on souhaite d'abord migrer le site server ou le site clients.

Utilisez la commande ipa migrate-ds pour migrer de LDAP vers Identity Management (IdM). Sans options supplémentaires, la commande prend l'URL LDAP de l'annuaire à migrer et exporte les données sur la base des paramètres par défaut courants. Cette section décrit des exemples de modification des paramètres par défaut.

# ipa migrate-ds ldap://ldap.example.com:389

La structure de répertoire par défaut place les entrées relatives aux personnes dans la sous-arborescence ou=People et les entrées relatives aux groupes dans la sous-arborescence ou=Groups. Ces sous-arbres sont des entrées de conteneur pour ces différents types de données d'annuaire. Si vous n'utilisez aucune option avec la commande migrate-ds, l'utilitaire suppose que l'annuaire LDAP donné utilise la structure ou=People et ou=Groups.

De nombreux déploiements peuvent avoir une structure de répertoire entièrement différente ou vous pouvez ne vouloir exporter que certaines parties de l'arborescence d'origine. En tant qu'administrateur, vous pouvez utiliser les options suivantes pour spécifier le RDN d'un sous-arbre d'utilisateur ou de groupe différent sur le serveur LDAP source :

Par exemple :

[ipaserver ~]# ipa migrate-ds --user-container=ou=employees \
--group-container="ou=employee groups" ldap://ldap.example.com:389

Il est possible d'ajouter l'option --scope à la commande ipa migrate-ds pour définir le champ d'application :

Par défaut, le script ipa migrate-ds importe chaque entrée d'utilisateur avec la classe d'objet person et chaque entrée de groupe avec la classe d'objet groupOfUniqueNames ou groupOfNames.

Dans certains chemins de migration, il peut être nécessaire de n'exporter que certains types d'utilisateurs et de groupes ou, au contraire, d'exclure certains utilisateurs et groupes. Vous pouvez sélectionner les types d'utilisateurs et de groupes à inclure en définissant les classes d'objets à rechercher lors de la recherche d'entrées d'utilisateurs ou de groupes.

Cette option est particulièrement utile lorsque vous utilisez des classes d'objets personnalisées pour différents types de user. Par exemple, la commande suivante ne migre que les utilisateurs ayant la classe d'objets personnalisée fullTimeEmployee:

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee ldap://ldap.example.com:389

En raison des différents types de groupes, cette fonction est également très utile pour ne migrer que certains types de groups, tels que les groupes d'utilisateurs, tout en excluant d'autres types de groupes, tels que les groupes de certificats. Par exemple :

[root@ipaserver ~]# ipa migrate-ds --group-objectclass=groupOfNames --group-objectclass=groupOfUniqueNames ldap://ldap.example.com:389

La spécification d'entrées d'utilisateurs et de groupes à migrer en fonction de la classe d'objets exclut implicitement tous les autres utilisateurs et groupes de la migration.

Il peut également être utile de migrer toutes les entrées d'utilisateurs et de groupes, à l'exception d'une petite poignée d'entrées. Vous pouvez exclure des comptes d'utilisateurs ou de groupes spécifiques tout en migrant tous les autres comptes de ce type. Par exemple, ceci n'exclut qu'un groupe de loisirs et deux utilisateurs :

[root@ipaserver ~]# ipa migrate-ds --exclude-groups="Golfers Group" --exclude-users=idmuser101 --exclude-users=idmuser102 ldap://ldap.example.com:389

Les déclarations d'exclusion sont appliquées aux utilisateurs correspondant au modèle dans l'attribut uid et aux groupes correspondant au modèle dans l'attribut cn.

Vous pouvez migrer une classe d'objets générale mais exclure des entrées spécifiques de cette classe. Par exemple, ceci inclut spécifiquement les utilisateurs de la classe d'objets fullTimeEmployee, mais exclut trois gestionnaires :

[root@ipaserver ~]# ipa migrate-ds --user-objectclass=fullTimeEmployee --exclude-users=jsmith --exclude-users=bjensen --exclude-users=mreynolds ldap://ldap.example.com:389

Par défaut, tous les attributs et toutes les classes d'objets d'une entrée d'utilisateur ou de groupe sont migrés. Dans certains scénarios, cela peut ne pas être réaliste, soit en raison de contraintes de bande passante et de réseau, soit parce que les données d'attribut ne sont plus pertinentes. Par exemple, si les utilisateurs se voient attribuer de nouveaux certificats d'utilisateur lorsqu'ils rejoignent le domaine de la gestion des identités (IdM), la migration de l'attribut userCertificate serait inutile.

Vous pouvez ignorer des classes d'objets et des attributs spécifiques en utilisant les options suivantes avec la commande migrate-ds:

Par exemple, pour exclure l'attribut userCertificate et la classe d'objets strongAuthenticationUser pour les utilisateurs et la classe d'objets groupOfCertificates pour les groupes :

[root@ipaserver ~]# ipa migrate-ds --user-ignore-attribute=userCertificate --user-ignore-objectclass=strongAuthenticationUser --group-ignore-objectclass=groupOfCertificates ldap://ldap.example.com:389

Identity Management (IdM) utilise le schéma RFC2307bis pour définir les identités des utilisateurs, des hôtes, des groupes d'hôtes et d'autres réseaux. Toutefois, si le serveur LDAP utilisé comme source pour la migration utilise plutôt le schéma RFC2307, spécifiez l'option --schema avec la commande ipa migrate-ds:

[root@ipaserver ~]# ipa migrate-ds --schema=RFC2307 ldap://ldap.example.com:389

Par ailleurs, IdM dispose d'un site intégré schema compat feature qui lui permet de reformater les données pour les systèmes qui ne prennent pas en charge la norme RFC2307bis. Le plugin compat est activé par défaut, ce qui signifie que le serveur d'annuaire calcule une vue alternative des utilisateurs et des groupes et fournit cette vue dans l'entrée du conteneur cn=users,cn=compat,dc=example,dc=com. Pour ce faire, il calcule à l'avance le contenu de ses entrées au démarrage et les actualise si nécessaire.

Il est recommandé de désactiver cette fonction pendant la migration afin de réduire la surcharge du système.