1.5. Terminologie de l'IdM

Une entité qui émet des certificats numériques. Dans Red Hat Identity Management, l'autorité de certification primaire est ipa, l'autorité de certification IdM. Le certificat de l'autorité de certification ipa est l'un des types suivants :

Dans IdM, vous pouvez également créer plusieurs sub-CAs. Les sous-CA sont des AC IdM dont les certificats sont de l'un des types suivants :

Voir aussi Planification des services de l'AC.

Une confiance établit une relation d'accès entre deux domaines Kerberos, permettant aux utilisateurs et aux services d'un domaine d'accéder aux ressources d'un autre domaine.

Avec une confiance inter-forêts entre le domaine racine d'une forêt Active Directory (AD) et un domaine IdM, les utilisateurs des domaines de la forêt AD peuvent interagir avec les machines et les services Linux du domaine IdM. Du point de vue d'AD, la gestion des identités représente une forêt AD distincte avec un seul domaine AD. Pour plus d'informations, voir Comment fonctionne la confiance.

Un nom de domaine pleinement qualifié (FQDN) est un nom de domaine qui spécifie l'emplacement exact d'un hôte dans la hiérarchie du système de noms de domaine (DNS). Un appareil portant le nom d'hôte myhost dans le domaine parent example.com possède le FQDN myhost.example.com. Le FQDN distingue de manière unique le dispositif de tout autre hôte appelé myhost dans d'autres domaines.

Si vous installez un client IdM sur l'hôte machine1 en utilisant l'autodécouverte DNS et que vos enregistrements DNS sont correctement configurés, le FQDN de machine1 est tout ce dont vous avez besoin. Pour plus d'informations, voir Nom d'hôte et exigences DNS pour IdM.

L'interface de programme d'application du service de sécurité générique (GSSAPI, ou GSS-API) permet aux développeurs d'abstraire la manière dont leurs applications protègent les données envoyées à des applications homologues. Les fournisseurs de services de sécurité peuvent fournir des implémentations GSSAPI d'appels de procédure communs sous forme de bibliothèques avec leur logiciel de sécurité. Ces bibliothèques présentent une interface compatible avec la GSSAPI aux auteurs d'applications qui peuvent écrire leur application pour utiliser uniquement la GSSAPI indépendante du fournisseur. Grâce à cette flexibilité, les développeurs n'ont pas à adapter leurs implémentations de sécurité à une plate-forme, un mécanisme de sécurité, un type de protection ou un protocole de transport particuliers.

Kerberos est l'implémentation dominante du mécanisme GSSAPI, ce qui permet aux implémentations Red Hat Enterprise Linux et Microsoft Windows Active Directory Kerberos d'être compatibles au niveau de l'API.

Une réplique cachée est une réplique IdM dont tous les services fonctionnent et sont disponibles, mais dont les rôles de serveur sont désactivés, et que les clients ne peuvent pas découvrir parce qu'elle n'a pas d'enregistrements SRV dans le DNS.

Les répliques cachées sont principalement conçues pour des services tels que les sauvegardes, l'importation et l'exportation en masse, ou les actions qui nécessitent l'arrêt des services IdM. Étant donné qu'aucun client n'utilise un réplica caché, les administrateurs peuvent arrêter temporairement les services sur cet hôte sans affecter aucun client. Pour plus d'informations, voir Le mode réplique cachée.

SSSD peut utiliser le SID d'un utilisateur AD pour générer algorithmiquement des ID POSIX dans un processus appelé ID mapping. Le mappage d'ID crée une correspondance entre les SID dans AD et les ID sur Linux.

Une plage d'ID est une plage de numéros d'ID attribués à la topologie IdM ou à un réplica spécifique. Vous pouvez utiliser les plages d'ID pour spécifier la plage valide d'UID et de GID pour les nouveaux utilisateurs, hôtes et groupes. Les plages d'ID sont utilisées pour éviter les conflits de numéros d'ID. Il existe deux types distincts de plages d'ID dans IdM :

Pour plus d'informations, voir Plages d'identification.

Les vues ID vous permettent de spécifier de nouvelles valeurs pour les attributs des utilisateurs ou des groupes POSIX, et de définir sur quel(s) hôte(s) client(s) les nouvelles valeurs s'appliqueront. Par exemple, vous pouvez utiliser les vues ID pour :

Dans une configuration de confiance IdM-AD, le site Default Trust View est une vue d'identification appliquée aux utilisateurs et aux groupes AD. En utilisant Default Trust View, vous pouvez définir des attributs POSIX personnalisés pour les utilisateurs et les groupes AD, remplaçant ainsi les valeurs définies dans AD.

Pour plus d'informations, voir Utilisation d'une vue ID pour remplacer une valeur d'attribut utilisateur sur un client IdM.

Serveur IdM sur lequel le service d'autorité de certification IdM est installé et fonctionne.

Noms alternatifs : CA server

Terme désignant l'ensemble de votre installation IdM. Vous pouvez décrire votre déploiement IdM en répondant aux questions suivantes :

Pour installer le premier serveur d'un déploiement IdM, vous devez utiliser la commande ipa-server-install.

Les administrateurs peuvent alors utiliser la commande ipa-replica-install pour installer replicas en plus du premier serveur installé. Par défaut, l'installation d'une réplique crée un accord de réplication avec le serveur IdM à partir duquel elle a été créée, ce qui permet de recevoir et d'envoyer des mises à jour au reste d'IdM.

Il n'y a pas de différence fonctionnelle entre le premier serveur installé et une réplique. Les deux sont des serveurs IdM en lecture/écriture entièrement fonctionnels.

Noms obsolètes : master server

Si votre topologie IdM contient une autorité de certification (CA) intégrée, un serveur joue le rôle unique de serveur de renouvellement de la CA. Ce serveur assure la maintenance et le renouvellement des certificats du système IdM.

Par défaut, le premier serveur CA que vous installez remplit ce rôle, mais vous pouvez configurer n'importe quel serveur CA pour qu'il devienne le serveur de renouvellement CA. Dans un déploiement sans autorité de certification intégrée, il n'y a pas de serveur de renouvellement de l'autorité de certification.

Noms obsolètes : master CA

Si votre topologie IdM contient une autorité de certification (CA) intégrée, un serveur joue le rôle unique de serveur éditeur de liste de révocation de certificats (CRL). Ce serveur est responsable de la maintenance de la CRL.

Par défaut, le serveur qui joue le rôle de CA renewal server joue également ce rôle, mais vous pouvez configurer n'importe quel serveur d'autorité de certification pour qu'il devienne le serveur d'édition de CRL. Dans un déploiement sans autorité de certification intégrée, il n'y a pas de serveur éditeur de CRL.

Les indicateurs d'authentification sont attachés aux tickets Kerberos et représentent la méthode d'authentification initiale utilisée pour acquérir un ticket :

Pour plus d'informations, voir les indicateurs d'authentification Kerberos.

Alors que le mot de passe est la méthode d'authentification par défaut pour un utilisateur, les keytabs sont la méthode d'authentification par défaut pour les hôtes et les services. Un keytab Kerberos est un fichier qui contient une liste des principaux Kerberos et de leurs clés de chiffrement associées, de sorte qu'un service peut récupérer sa propre clé Kerberos et vérifier l'identité d'un utilisateur.

Par exemple, chaque client IdM possède un fichier /etc/krb5.keytab qui contient des informations sur le principal host, qui représente la machine du client dans le domaine Kerberos.

Des principes Kerberos uniques identifient chaque utilisateur, chaque service et chaque hôte dans un domaine Kerberos :

Le Centre de distribution de clés Kerberos (KDC) applique le contrôle d'accès aux tickets par le biais de stratégies de connexion et gère la durée des tickets Kerberos par le biais de stratégies de cycle de vie des tickets. Par exemple, la durée de vie globale par défaut des tickets est d'un jour, et l'âge maximum de renouvellement global par défaut est d'une semaine.

Pour plus d'informations, voir Types de politiques de ticket IdM Kerberos.

Le centre de distribution de clés Kerberos (KDC) est un service qui joue le rôle d'autorité centrale de confiance gérant les informations relatives aux justificatifs Kerberos. Le KDC émet des tickets Kerberos et garantit l'authenticité des données provenant des entités du réseau IdM.

Pour plus d'informations, voir Le rôle du KDC IdM.

Dans l'IdM, une sous-CA légère est une autorité de certification (AC) dont le certificat est signé par une AC racine de l'IdM ou par l'une des AC qui lui sont subordonnées. Une AC secondaire légère émet des certificats uniquement dans un but spécifique, par exemple pour sécuriser une connexion VPN ou HTTP.

Pour plus d'informations, voir Restreindre une application à un sous-ensemble de certificats.

Une politique de mot de passe est un ensemble de conditions auxquelles les mots de passe d'un groupe d'utilisateurs IdM particulier doivent satisfaire. Les conditions peuvent inclure les paramètres suivants :

Pour plus d'informations, voir Qu'est-ce qu'une politique de mot de passe?

Les attributs POSIX sont des attributs utilisateur permettant de maintenir la compatibilité entre les systèmes d'exploitation.

Dans un environnement Red Hat Identity Management, les attributs POSIX pour les utilisateurs incluent :

Dans un environnement Red Hat Identity Management, les attributs POSIX pour les groupes incluent :

Ces attributs identifient les utilisateurs et les groupes comme des entités distinctes.

Un accord de réplication est un accord entre deux serveurs IdM dans le même déploiement IdM. L'accord de réplication garantit que les données et la configuration sont répliquées en permanence entre les deux serveurs.

IdM utilise deux types d'accords de réplication : les accords domain replication, qui répliquent les informations relatives à l'identité, et les accords certificate replication, qui répliquent les informations relatives au certificat.

Pour plus d'informations, voir :

Après s'être authentifié auprès d'un centre de distribution de clés Kerberos (KDC), un utilisateur reçoit un ticket d'accès (TGT), qui est un ensemble temporaire d'informations d'identification pouvant être utilisées pour demander des tickets d'accès à d'autres services, tels que les sites web et le courrier électronique.

L'utilisation d'un TGT pour demander un accès supplémentaire permet à l'utilisateur de bénéficier d'une ouverture de session unique, puisqu'il ne doit s'authentifier qu'une seule fois pour accéder à plusieurs services. Les TGT sont renouvelables et les politiques de tickets Kerberos déterminent les limites de renouvellement des tickets et le contrôle d'accès.

Pour plus d'informations, voir Gestion des politiques de tickets Kerberos.