Red Hat Summit4.2. Planification de la configuration du client lors de la migration de LDAP vers IdM
La gestion des identités (IdM) peut prendre en charge un certain nombre de configurations client différentes, avec divers degrés de fonctionnalité, de flexibilité et de sécurité. Décidez de la configuration qui convient le mieux à chaque client en fonction de son système d'exploitation et de vos priorités en matière de maintenance informatique. Tenez également compte du domaine fonctionnel du client : une machine de développement nécessite généralement une configuration différente de celle des serveurs de production ou des ordinateurs portables des utilisateurs.
Dans la plupart des environnements, les clients se connectent au domaine IdM de différentes manières. Les administrateurs doivent décider du scénario qui convient le mieux à chaque client.
4.2.1. Configuration initiale du client avant la migration
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.
4.2.2. Configuration recommandée pour les clients RHEL
La configuration client décrite dans cette section n'est prise en charge que pour les versions RHEL 6.1 et ultérieures et RHEL 5.7 ultérieures, qui prennent en charge les dernières versions de SSSD et le paquetage ipa-client. Les versions plus anciennes de RHEL peuvent être configurées comme décrit dans Configuration alternative prise en charge.
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 :
- Authentification
- Recherche d'identité
- Accès
- Modification du mot de passe
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.
Informations complémentaires
4.2.3. Configuration alternative supporté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 :
-
Le client se connecte au serveur IdM comme s'il s'agissait d'un serveur d'annuaire LDAP pour les recherches d'identité, en utilisant
nss_ldap. -
Le client se connecte au serveur IdM comme s'il s'agissait d'un KDC Kerberos ordinaire, en utilisant
pam_krb5.
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.
