4.3. Planification de la migration des mots de passe lors de la migration de LDAP vers IdM
Une question cruciale à laquelle il faut répondre avant de migrer les utilisateurs de LDAP vers Identity Management (IdM) est de savoir s'il faut migrer les mots de passe des utilisateurs ou non. Les options suivantes sont disponibles :
- Migration des utilisateurs sans mot de passe
Peut être réalisée plus rapidement mais nécessite plus de travail manuel de la part des administrateurs et des utilisateurs. Dans certaines situations, c'est la seule option possible : par exemple, si l'environnement LDAP d'origine stockait les mots de passe des utilisateurs en clair ou si les mots de passe ne répondent pas aux exigences de la politique de mot de passe définie dans l'IdM.
Lors de la migration de comptes d'utilisateurs sans mot de passe, vous réinitialisez tous les mots de passe des utilisateurs. Les utilisateurs migrés se voient attribuer un mot de passe temporaire qu'ils modifient lors de leur première connexion. Pour plus d'informations sur la réinitialisation des mots de passe, voir Modification et réinitialisation des mots de passe des utilisateurs dans la documentation de HREL 7 IdM.
- Migration des utilisateurs avec leurs mots de passe
Cette solution permet une transition plus aisée, mais nécessite également une gestion parallèle de l'annuaire LDAP et de l'IdM au cours du processus de migration et de transition. La raison en est que, par défaut, IdM utilise Kerberos pour l'authentification et exige que chaque utilisateur ait un hachage Kerberos stocké dans le serveur d'annuaire IdM en plus du mot de passe standard de l'utilisateur. Pour générer le hachage, le mot de passe de l'utilisateur doit être accessible au serveur IdM en texte clair. Lorsque vous créez un nouveau mot de passe utilisateur, le mot de passe est disponible en clair avant d'être haché et stocké dans IdM. Toutefois, lorsque l'utilisateur est migré à partir d'un répertoire LDAP, le mot de passe de l'utilisateur associé est déjà haché, de sorte que la clé Kerberos correspondante ne peut pas être générée.
ImportantPar défaut, les utilisateurs ne peuvent pas s'authentifier auprès du domaine IdM ou accéder aux ressources IdM tant qu'ils n'ont pas de hash Kerberos - même si les comptes d'utilisateurs existent déjà. Il existe une solution de contournement : l'utilisation de l'authentification LDAP dans IdM au lieu de l'authentification Kerberos. Avec cette solution, les hashs Kerberos ne sont pas nécessaires pour les utilisateurs. Toutefois, cette solution limite les capacités de l'IdM et n'est pas recommandée.
Les sections suivantes expliquent comment migrer les utilisateurs et leurs mots de passe :
4.3.1. Méthodes de migration des mots de passe lors de la migration de LDAP vers IdM
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.
Flux de travail
- Un utilisateur tente de se connecter à une machine avec SSSD.
- SSSD tente d'effectuer une authentification Kerberos contre le serveur IdM.
- Bien que l'utilisateur existe dans le système, l'authentification échoue avec l'erreur key type is not supported parce que les hachages Kerberos n'existent pas encore.
- SSSD effectue une liaison LDAP en texte clair par le biais d'une connexion sécurisée.
- L'IdM intercepte cette demande de liaison. Si l'utilisateur a un principal Kerberos mais pas de hachages Kerberos, le fournisseur d'identité IdM génère les hachages et les stocke dans l'entrée de l'utilisateur.
- Si l'authentification est réussie, SSSD se déconnecte de l'IdM et réessaie l'authentification Kerberos. Cette fois, la demande aboutit car le hachage existe dans l'entrée.
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.
4.3.2. Planifier la migration des mots de passe LDAP en clair
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.
4.3.3. Planification de 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: