Planification de la gestion de l'identité

Scénario 1

Situation

Vous êtes administrateur Windows dans votre entreprise.

Outre les systèmes Windows, vous devez également administrer plusieurs systèmes Linux.

Comme vous ne pouvez déléguer le contrôle d'aucune partie de votre environnement à un administrateur Linux, vous devez gérer tous les contrôles de sécurité dans Active Directory (AD).

Solution

Integrate your Linux hosts to AD directly.

Si vous souhaitez que les règles sudo soient définies de manière centralisée dans un serveur LDAP, vous devez implémenter une extension de schéma dans le contrôleur de domaine AD (DC). Si vous n'êtes pas autorisé à implémenter cette extension, envisagez d'installer Identity Management (IdM) - voir le scénario 3 ci-dessous. Comme IdM contient déjà l'extension de schéma, vous pouvez gérer les règles sudo directement dans IdM.

Autres conseils si vous prévoyez d'avoir besoin de plus de compétences Linux à l'avenir

Entrez en contact avec la communauté Linux pour voir comment les autres gèrent les identités : utilisateurs, hôtes et services.

Rechercher les meilleures pratiques.

Familiarisez-vous avec Linux :

• Utilisez la console web RHEL dans la mesure du possible.
• Utilisez autant que possible des commandes simples sur la ligne de commande.
• Assister à un cours d'administration de système Red Hat.

Scénario 2

Situation

Vous êtes administrateur Linux dans votre entreprise.

Vos utilisateurs Linux ont besoin de différents niveaux d'accès aux ressources de l'entreprise.

Vous avez besoin d'un contrôle d'accès centralisé et rigoureux de vos machines Linux.

Solution

Installez IdM et migrez vos utilisateurs vers ce système.

Autres conseils si vous prévoyez de développer votre entreprise à l'avenir

Après avoir installé IdM, configurez le contrôle d'accès basé sur l'hôte et les règles sudo. Ces règles sont nécessaires pour maintenir les meilleures pratiques de sécurité en matière d'accès limité et de moindre privilège.

Pour atteindre vos objectifs de sécurité, développez une stratégie cohérente de gestion des identités et des accès (IAM) qui utilise des protocoles pour sécuriser à la fois l'infrastructure et les couches applicatives.

Scénario 3

Situation

Vous êtes administrateur Linux dans votre entreprise et vous devez intégrer vos systèmes Linux aux serveurs Windows de l'entreprise. Vous souhaitez rester le seul responsable du contrôle d'accès à vos systèmes Linux.

Différents utilisateurs ont besoin de différents niveaux d'accès aux systèmes Linux, mais ils résident tous dans AD.

Solution

Les contrôles AD n'étant pas assez robustes, vous devez configurer le contrôle d'accès aux systèmes Linux du côté Linux. Installez IdM et établissez une confiance IdM-AD.

Autres conseils pour renforcer la sécurité de votre environnement

Après avoir installé IdM, configurez le contrôle d'accès basé sur l'hôte et les règles sudo. Ces règles sont nécessaires pour maintenir les meilleures pratiques de sécurité en matière d'accès limité et de moindre privilège.

Pour atteindre vos objectifs de sécurité, développez une stratégie cohérente de gestion des identités et des accès (IAM) qui utilise des protocoles pour sécuriser à la fois l'infrastructure et les couches applicatives.

Scénario 4

Situation

En tant qu'administrateur de sécurité, vous devez gérer les identités et les accès dans tous vos environnements, y compris tous vos produits Red Hat. Vous devez gérer toutes vos identités en un seul endroit et maintenir des contrôles d'accès sur l'ensemble de vos plates-formes, nuages et produits.

Solution

Intégrer IdM, Red Hat Single Sign-On, Red Hat Satellite, Red Hat Ansible Tower et d'autres produits Red Hat.

Scénario 5

Situation

En tant qu'administrateur de sécurité et de système dans un environnement du ministère de la défense (DoD) ou de la communauté du renseignement (IC), vous êtes tenu d'utiliser l'authentification par carte à puce ou RSA. Vous devez utiliser des certificats PIV ou des jetons RSA.

Solution

1. Configurer le mappage des certificats dans IdM.
2. Assurez-vous que la délégation GSSAPI est activée si une confiance IdM-AD est présente.
3. Configurer l'utilisation de la configuration radius dans IdM pour les jetons RSA.
4. Configurer les serveurs et les clients Id M pour l'authentification par carte à puce.

Clients IdM

Les clients IdM sont des systèmes Red Hat Enterprise Linux enrôlés avec les serveurs et configurés pour utiliser les services IdM sur ces serveurs.

Les clients interagissent avec les serveurs IdM pour accéder aux services qu'ils fournissent. Par exemple, les clients utilisent le protocole Kerberos pour s'authentifier et obtenir des tickets pour l'authentification unique de l'entreprise (SSO), utilisent LDAP pour obtenir des informations sur l'identité et la politique, utilisent DNS pour détecter où se trouvent les serveurs et les services et comment s'y connecter.

Serveurs IdM

Les serveurs IdM sont des systèmes Red Hat Enterprise Linux qui répondent aux demandes d'identité, d'authentification et d'autorisation au sein d'un domaine IdM. Dans la plupart des déploiements, une autorité de certification (AC) intégrée est également installée avec le serveur IdM.

Les serveurs IdM sont les dépositaires centraux des informations relatives à l'identité et à la politique. Les serveurs IdM peuvent également héberger les services optionnels utilisés par les membres du domaine :

• Autorité de certification (AC)
• Autorité de recouvrement des clés (ARK)
• DNS
• Contrôleur de confiance Active Directory (AD)
• Agent de confiance Active Directory (AD)

Les serveurs IdM sont également des clients IdM intégrés. En tant que clients inscrits avec eux-mêmes, les serveurs fournissent les mêmes fonctionnalités que les autres clients.

Forêt Active Directory

Une forêt Active Directory (AD) est un ensemble d'une ou plusieurs arborescences de domaines qui partagent un catalogue global, un schéma d'annuaire, une structure logique et une configuration d'annuaire communs. La forêt représente la limite de sécurité à l'intérieur de laquelle les utilisateurs, les ordinateurs, les groupes et d'autres objets sont accessibles. Pour plus d'informations, voir le document Microsoft sur les forêts.

Catalogue global Active Directory

Le catalogue global est une fonctionnalité d'Active Directory (AD) qui permet à un contrôleur de domaine de fournir des informations sur n'importe quel objet de la forêt, que l'objet soit ou non membre du domaine du contrôleur de domaine. Les contrôleurs de domaine dont la fonction de catalogue global est activée sont appelés serveurs de catalogue global. Le catalogue global fournit un catalogue consultable de tous les objets de chaque domaine d'un Active Directory Domain Services (AD DS) multi-domaines.

Identifiant de sécurité Active Directory

Un identifiant de sécurité (SID) est un numéro d'identification unique attribué à un objet dans Active Directory, tel qu'un utilisateur, un groupe ou un hôte. C'est l'équivalent fonctionnel des UID et des GID sous Linux.

Jeu Ansible

Les jeux Ansible sont les éléments constitutifs des playbooks Ansible. L'objectif d'un play est de faire correspondre un groupe d'hôtes à des rôles bien définis, représentés par des tâches Ansible.

Playbook Ansible

Un cahier de jeu Ansible est un fichier qui contient une ou plusieurs séquences Ansible. Pour plus d'informations, voir la documentation officielle d'Ansible sur les playbooks.

Tâche Ansible

Les tâches Ansible sont des unités d'action dans Ansible. Une pièce Ansible peut contenir plusieurs tâches. L'objectif de chaque tâche est d'exécuter un module, avec des arguments très spécifiques. Une tâche Ansible est un ensemble d'instructions permettant d'atteindre un état défini, dans ses grandes lignes, par un rôle ou un module Ansible spécifique, et affiné par les variables de ce rôle ou de ce module. Pour plus d'informations, consultez la documentation officielle sur les tâches Ansible.

Serveur web Apache

Le serveur HTTP Apache, appelé familièrement Apache, est une application de serveur web multiplateforme libre et gratuite, publiée selon les termes de la licence Apache 2.0. Apache a joué un rôle clé dans la croissance initiale du World Wide Web et est actuellement le principal serveur HTTP. Le nom de son processus est httpd, qui est l'abréviation de HTTP daemon. Red Hat Identity Management (IdM) utilise le serveur Web Apache pour afficher l'interface Web IdM et pour coordonner la communication entre les composants, tels que le serveur de répertoire et l'autorité de certification.

Certificat

Un certificat est un document électronique utilisé pour identifier une personne, un serveur, une entreprise ou une autre entité et pour associer cette identité à une clé publique. Comme un permis de conduire ou un passeport, un certificat fournit une preuve généralement reconnue de l'identité d'une personne. La cryptographie à clé publique utilise des certificats pour résoudre le problème de l'usurpation d'identité.

Autorités de certification (AC) dans 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 :

• Autosigné. Dans ce cas, l'autorité de certification ipa est l'autorité de certification racine.
• Signature externe. Dans ce cas, l'autorité de certification ipa est subordonnée à l'autorité de certification externe.

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 :

• Signé par l'AC ipa.
• Signé par n'importe quelle AC intermédiaire entre elle-même et l'AC ipa. Le certificat d'une sous-AC ne peut pas être auto-signé.

Voir aussi Planification des services de l'AC.

Confiance dans les forêts

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.

Serveur d'annuaire

Un serveur d'annuaire centralise les informations relatives à l'identité des utilisateurs et aux applications. Il fournit un registre indépendant du système d'exploitation, basé sur le réseau, pour stocker les paramètres des applications, les profils des utilisateurs, les données des groupes, les politiques et les informations de contrôle d'accès. Chaque ressource du réseau est considérée comme un objet par le serveur d'annuaire. Les informations relatives à une ressource particulière sont stockées sous la forme d'une collection d'attributs associés à cette ressource ou à cet objet. Red Hat Directory Server est conforme aux normes LDAP.

Enregistrements DNS PTR

Les enregistrements DNS de pointeurs (PTR) permettent de résoudre l'adresse IP d'un hôte en fonction d'un nom de domaine ou d'un nom d'hôte. Les enregistrements PTR sont l'opposé des enregistrements DNS A et AAAA, qui résolvent les noms d'hôtes en adresses IP. Les enregistrements DNS PTR permettent d'effectuer des recherches DNS inversées. Les enregistrements PTR sont stockés sur le serveur DNS.

Enregistrements DNS SRV

Un enregistrement de service DNS (SRV) définit le nom d'hôte, le numéro de port, le protocole de transport, la priorité et le poids d'un service disponible dans un domaine. Vous pouvez utiliser les enregistrements SRV pour localiser les serveurs IdM et les répliques.

Contrôleur de domaine (DC)

Un contrôleur de domaine (DC) est un hôte qui répond aux demandes d'authentification de sécurité au sein d'un domaine et qui contrôle l'accès aux ressources de ce domaine. Les serveurs IdM fonctionnent comme des DC pour le domaine IdM. Un DC authentifie les utilisateurs, stocke les informations relatives aux comptes utilisateurs et applique la politique de sécurité d'un domaine. Lorsqu'un utilisateur se connecte à un domaine, le DC authentifie et valide ses informations d'identification et autorise ou refuse l'accès.

Nom de domaine complet

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.

GSSAPI

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.

Réplique cachée

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.

Serveur HTTP

Voir serveur web.

Cartographie des identifiants

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.

• Lorsque SSSD détecte un nouveau domaine AD, il lui attribue une plage d'identifiants disponibles. Par conséquent, chaque domaine AD dispose de la même plage d'identifiants sur chaque machine cliente SSSD.
• Lorsqu'un utilisateur AD se connecte pour la première fois à une machine cliente SSSD, SSSD crée une entrée pour l'utilisateur dans le cache SSSD, y compris un UID basé sur le SID de l'utilisateur et la plage d'ID pour ce domaine.
• Étant donné que les identifiants d'un utilisateur AD sont générés de manière cohérente à partir du même SID, l'utilisateur possède les mêmes UID et GID lorsqu'il se connecte à n'importe quel système Red Hat Enterprise Linux.

Plages d'identification

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 :

• IdM ID range

  Utilisez cette plage d'ID pour définir les UID et les GID des utilisateurs et des groupes dans l'ensemble de la topologie IdM. L'installation du premier serveur IdM crée la plage d'ID IdM. Vous ne pouvez pas modifier la plage d'ID IdM après l'avoir créée. Toutefois, vous pouvez créer une plage d'ID IdM supplémentaire, par exemple lorsque la plage d'origine est presque épuisée.

• Distributed Numeric Assignment (DNA) ID range

  Cette plage d'ID permet de définir les UID et les GID qu'un réplica utilise lors de la création de nouveaux utilisateurs. L'ajout d'un nouvel utilisateur ou d'une nouvelle entrée d'hôte à un réplica IdM pour la première fois attribue une plage d'ID DNA à ce réplica. Un administrateur peut modifier la plage d'ID DNA, mais la nouvelle définition doit s'inscrire dans une plage d'ID IdM existante.

  Notez que la plage IdM et la plage DNA correspondent, mais qu'elles ne sont pas interconnectées. Si vous modifiez l'une des plages, veillez à modifier l'autre pour qu'elle corresponde.

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

Vues de l'ID

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 :

• Définir des valeurs d'attributs différentes pour des environnements différents.
• Remplacer une valeur d'attribut générée précédemment par une valeur différente.

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 CA IdM

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

Noms alternatifs : CA server

Déploiement de l'IdM

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

• Votre déploiement IdM est-il un déploiement de test ou un déploiement de production ?

  • Combien de serveurs IdM avez-vous ?

• Votre déploiement IdM contient-il une autorité de certification intégrée?

  • Dans l'affirmative, l'autorité de certification intégrée est-elle auto-signée ou signée de l'extérieur ?
  • Si c'est le cas, sur quels serveurs le rôle CA est-il disponible ? Sur quels serveurs le rôle KRA est-il disponible ?

• Votre déploiement IdM contient-il un DNS intégré?

  • Si c'est le cas, sur quels serveurs le rôle DNS est-il disponible ?

• Votre déploiement IdM fait-il l'objet d'un accord de confiance avec une forêt AD?

  • Si c'est le cas, sur quels serveurs le rôle de contrôleur de confiance AD ou d'agent de confiance AD est-il disponible ?

Serveur IdM et répliques

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

Serveur de renouvellement de l'AC IdM

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

Serveur d'édition de CRL IdM

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.

Topologie de l'IdM

Un terme qui se réfère à la structure de votre solution IdM, en particulier les accords de réplication entre et au sein des centres de données individuels et des clusters.

Indicateurs d'authentification Kerberos

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 :

• otp pour l'authentification à deux facteurs (mot de passe à usage unique)
• radius pour l'authentification RADIUS (Remote Authentication Dial-In User Service) (généralement pour l'authentification 802.1x)
• pkinit pour la cryptographie à clé publique pour l'authentification initiale dans Kerberos (PKINIT), la carte à puce ou l'authentification par certificat
• hardened pour les mots de passe renforcés contre les tentatives de force brute

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

Protocole d'accord 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.

Principal Kerberos

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

Entité	Convention d'appellation	Exemple :
Utilisateurs	identifier@REALM	admin@EXAMPLE.COM
Services	service/fully-qualified-hostname@REALM	http/server.example.com@EXAMPLE.COM
Hosts	host/fully-qualified-hostname@REALM	host/client.example.com@EXAMPLE.COM

Protocole Kerberos

Kerberos est un protocole d'authentification réseau qui fournit une authentification forte pour les applications client et serveur en utilisant la cryptographie à clé secrète. IdM et Active Directory utilisent Kerberos pour authentifier les utilisateurs, les hôtes et les services.

Domaine Kerberos

Un domaine Kerberos englobe tous les mandants gérés par un centre de distribution de clés Kerberos (KDC). Dans un déploiement IdM, le domaine Kerberos comprend tous les utilisateurs, hôtes et services IdM.

Politiques de ticket 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.

Centre de distribution des clés (KDC)

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.

LDAP

Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole d'application ouvert, indépendant des fournisseurs, qui permet d'accéder à des services d'information d'annuaire distribués sur un réseau et de les gérer. Une partie de cette spécification est un arbre d'informations d'annuaire (DIT), qui représente les données dans une structure hiérarchique arborescente composée des noms distinctifs (DN) des entrées du service d'annuaire. LDAP est une version "allégée" du protocole d'accès à l'annuaire (DAP) décrit par la norme ISO X.500 pour les services d'annuaire en réseau.

Sous-CA léger

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.

Politique en matière de mot de passe

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 :

• La longueur du mot de passe
• Le nombre de classes de caractères utilisées
• Durée de vie maximale d'un mot de passe.

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

Attributs POSIX

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 :

• cnle nom de l'utilisateur
• uidle nom du compte (login)
• uidNumberun numéro d'utilisateur (UID)
• gidNumberle numéro de groupe primaire (GID)
• homeDirectoryle répertoire personnel de l'utilisateur

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

• cn, le nom du groupe
• gidNumberle numéro de groupe (GID)

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

Accord de réplication

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 :

• Accords de réplication
• Déterminer le nombre approprié de répliques
• Connexion des répliques dans une topologie
• Exemples de topologie de réplique

Carte à puce

Une carte à puce est un dispositif amovible ou une carte utilisée pour contrôler l'accès à une ressource. Il peut s'agir de cartes de crédit en plastique dotées d'un circuit intégré (CI), de petits dispositifs USB tels que Yubikey ou d'autres dispositifs similaires. Les cartes à puce peuvent fournir une authentification en permettant aux utilisateurs de connecter une carte à puce à un ordinateur hôte, et le logiciel sur cet ordinateur hôte interagit avec le matériel clé stocké sur la carte à puce pour authentifier l'utilisateur.

SSSD

Le System Security Services Daemon (SSSD) est un service système qui gère l'authentification et l'autorisation des utilisateurs sur un hôte RHEL. En option, SSSD conserve un cache des identités et des informations d'identification des utilisateurs récupérées auprès de fournisseurs distants pour l'authentification hors ligne. Pour plus d'informations, voir Comprendre SSSD et ses avantages.

Backend SSSD

Un backend SSSD, souvent également appelé fournisseur de données, est un processus enfant SSSD qui gère et crée le cache SSSD. Ce processus communique avec un serveur LDAP, effectue différentes recherches et stocke les résultats dans le cache. Il effectue également l'authentification en ligne par LDAP ou Kerberos et applique une politique d'accès et de mot de passe à l'utilisateur qui se connecte.

Ticket-granting ticket (TGT)

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.

Serveur web

Un serveur web est un logiciel informatique et un matériel sous-jacent qui accepte les demandes de contenu web, telles que des pages, des images ou des applications. Un agent utilisateur, tel qu'un navigateur web, demande une ressource spécifique en utilisant HTTP, le protocole réseau utilisé pour distribuer le contenu web, ou sa variante sécurisée HTTPS. Le serveur web répond avec le contenu de cette ressource ou un message d'erreur. Le serveur web peut également accepter et stocker des ressources envoyées par l'agent utilisateur. Red Hat Identity Management (IdM) utilise le serveur Web Apache pour afficher l'interface Web IdM et pour coordonner la communication entre les composants, tels que le serveur de répertoire et l'autorité de certification (CA). Voir Serveur web Apache.

Clients IdM

Les clients IdM sont des systèmes Red Hat Enterprise Linux enrôlés avec les serveurs et configurés pour utiliser les services IdM sur ces serveurs.

Les clients interagissent avec les serveurs IdM pour accéder aux services qu'ils fournissent. Par exemple, les clients utilisent le protocole Kerberos pour s'authentifier et obtenir des tickets pour l'authentification unique de l'entreprise (SSO), utilisent LDAP pour obtenir des informations sur l'identité et la politique, utilisent DNS pour détecter où se trouvent les serveurs et les services et comment s'y connecter.

Serveurs IdM

Les serveurs IdM sont des systèmes Red Hat Enterprise Linux qui répondent aux demandes d'identité, d'authentification et d'autorisation au sein d'un domaine IdM. Dans la plupart des déploiements, une autorité de certification (AC) intégrée est également installée avec le serveur IdM.

Les serveurs IdM sont les dépositaires centraux des informations relatives à l'identité et à la politique. Les serveurs IdM peuvent également héberger les services optionnels utilisés par les membres du domaine :

• Autorité de certification (AC)
• Autorité de recouvrement des clés (ARK)
• DNS
• Contrôleur de confiance Active Directory (AD)
• Agent de confiance Active Directory (AD)

Les serveurs IdM sont également des clients IdM intégrés. En tant que clients inscrits avec eux-mêmes, les serveurs fournissent les mêmes fonctionnalités que les autres clients.

Accords de réplication de domaine

Ces accords reproduisent les informations relatives à l'identité.

Accords de réplication de certificats

Ces accords reproduisent les informations du certificat.

Un domaine DNS distinct pour les enregistrements de service

Veillez à ce que le site primary DNS domain utilisé pour IdM ne soit partagé avec aucun autre système. Cela permet d'éviter les conflits au niveau du DNS.

Délégation correcte du nom de domaine DNS

Assurez-vous que vous disposez d'une délégation valide dans l'arborescence DNS publique pour le domaine DNS. N'utilisez pas un nom de domaine qui ne vous est pas délégué, même sur un réseau privé.

Domaine DNS multi-label

N'utilisez pas de noms de domaine à étiquette unique, par exemple .company. Le domaine IdM doit être composé d'un ou plusieurs sous-domaines et d'un domaine de premier niveau, par exemple example.com ou company.example.com.

Un nom de domaine Kerberos unique

Assurez-vous que le nom du domaine n'est pas en conflit avec un autre nom de domaine Kerberos existant, tel qu'un nom utilisé par Active Directory (AD).

Nom du domaine Kerberos en tant que version majuscule du nom DNS primaire

Envisagez de définir le nom de domaine comme une version en majuscules (EXAMPLE.COM) du nom de domaine DNS primaire (example.com).

Avertissement

Si vous ne définissez pas le nom de domaine Kerberos comme étant la version en majuscules du nom DNS primaire, vous ne pourrez pas utiliser les trusts AD.

Intégration avec le démon des services de sécurité du système (SSSD)

SSSD peut connecter un système Linux à différents systèmes d'identité et d'authentification : AD, Identity Management (IdM), ou un serveur générique LDAP ou Kerberos.

Exigences notables pour l'intégration avec SSSD :

• Lors de l'intégration avec AD, SSSD ne fonctionne par défaut qu'au sein d'une seule forêt AD. Pour une installation multi-forêts, configurez l'énumération manuelle des domaines.
• Les forêts AD distantes doivent faire confiance à la forêt locale pour que le plug-in idmap_ad gère correctement les utilisateurs des forêts distantes.

SSSD prend en charge l'intégration directe et indirecte. Il permet également de passer d'une approche d'intégration à l'autre sans coûts de migration importants.

Intégration avec Samba Winbind

Le composant Winbind de la suite Samba émule un client Windows sur un système Linux et communique avec les serveurs AD.

Exigences notables pour l'intégration avec Samba Winbind :

• L'intégration directe avec Winbind dans une configuration AD multi-forêts nécessite des trusts bidirectionnels.
• Un chemin bidirectionnel doit exister entre le domaine local d'un système Linux et le domaine d'un utilisateur dans une forêt AD distante pour permettre au plug-in idmap_ad de disposer d'informations complètes sur l'utilisateur à partir du domaine AD distant.

Intégration basée sur la confiance entre les forêts avec AD

Le serveur de gestion des identités (IdM) fait office de serveur central pour contrôler les systèmes Linux. Une confiance Kerberos inter-royaumes est établie avec AD, ce qui permet aux utilisateurs d'AD de se connecter pour accéder aux systèmes et aux ressources Linux. IdM se présente à AD comme une forêt distincte et tire parti de la confiance au niveau de la forêt prise en charge par AD.

Lors de l'utilisation d'une fiducie :

• Les utilisateurs AD peuvent accéder aux ressources IdM.
• Les serveurs et les clients IdM peuvent résoudre les identités des utilisateurs et des groupes AD.
• Les utilisateurs et les groupes AD accèdent à l'IdM dans les conditions définies par l'IdM, comme le contrôle d'accès basé sur l'hôte.
• Les utilisateurs et les groupes AD continuent d'être gérés du côté AD.

Intégration basée sur la synchronisation

Cette approche est basée sur l'outil WinSync. Un accord de réplication WinSync synchronise les comptes d'utilisateurs d'AD vers IdM.

Avertissement

WinSync n'est plus activement développé dans Red Hat Enterprise Linux 8. La solution préférée pour l'intégration indirecte est la confiance inter-forêts.

Les limites de l'intégration basée sur la synchronisation sont les suivantes :

• Les groupes ne sont pas synchronisés entre IdM et AD.
• Les utilisateurs sont dupliqués dans AD et IdM.
• WinSync ne prend en charge qu'un seul domaine AD.
• Un seul contrôleur de domaine dans AD peut être utilisé pour synchroniser les données avec une instance d'IdM.
• Les mots de passe des utilisateurs doivent être synchronisés, ce qui nécessite l'installation du composant PassSync sur tous les contrôleurs de domaine du domaine AD.
• Après avoir configuré la synchronisation, tous les utilisateurs AD doivent modifier manuellement leurs mots de passe avant que PassSync ne puisse les synchroniser.

Connecter moins de 30 à 50 systèmes (ce n'est pas une limite absolue)

Si vous connectez moins de 30 à 50 systèmes, envisagez l'intégration directe. L'intégration indirecte risque d'entraîner des frais généraux inutiles.

Connecter plus de 30 à 50 systèmes (pas de limite stricte)

Si vous connectez plus de 30 à 50 systèmes, envisagez une intégration indirecte avec la gestion des identités. Cette approche vous permet de bénéficier d'une gestion centralisée des systèmes Linux.

Gérer un petit nombre de systèmes Linux, mais s'attendre à ce que ce nombre augmente rapidement

Dans ce cas, il convient d'envisager une intégration indirecte pour éviter de devoir migrer l'environnement ultérieurement.

Déployer des systèmes "bare metal" de manière irrégulière

Si vous déployez rarement de nouveaux systèmes et qu'il s'agit généralement de systèmes "bare metal", envisagez l'intégration directe. Dans ce cas, l'intégration directe est généralement la plus simple et la plus facile.

Déploiement fréquent de systèmes virtuels

Si vous déployez souvent de nouveaux systèmes et qu'il s'agit généralement de systèmes virtuels approvisionnés à la demande, envisagez l'intégration indirecte. Avec l'intégration indirecte, vous pouvez utiliser un serveur central pour gérer les nouveaux systèmes de manière dynamique et les intégrer à des outils d'orchestration, tels que Red Hat Satellite.

Vos politiques internes prévoient-elles que tous les utilisateurs doivent s'authentifier auprès d'Active Directory ?

Vous pouvez choisir une intégration directe ou indirecte. Si vous utilisez l'intégration indirecte avec une confiance entre Identity Management et Active Directory, les utilisateurs qui accèdent aux systèmes Linux s'authentifient auprès d'Active Directory. Les politiques qui existent dans Active Directory sont exécutées et appliquées lors de l'authentification.

Contrôleurs de confiance

Serveurs IdM qui peuvent effectuer des recherches d'identité auprès des contrôleurs de domaine AD. Ils exécutent également la suite Samba afin d'établir la confiance avec AD. Les contrôleurs de domaine AD contactent les contrôleurs de confiance lorsqu'ils établissent et vérifient la confiance avec AD. Les machines inscrites à AD communiquent avec les contrôleurs de confiance IdM pour les demandes d'authentification Kerberos.

Le premier contrôleur de confiance est créé lorsque vous configurez la confiance. Si vous disposez de plusieurs contrôleurs de domaine répartis sur différents sites géographiques, utilisez la commande ipa-adtrust-install pour désigner les serveurs RHEL IdM comme contrôleurs de confiance sur ces sites.

Les contrôleurs de confiance exécutent plus de services en contact avec le réseau que les agents de confiance et présentent donc une plus grande surface d'attaque pour les intrus potentiels.

Agents de confiance

Serveurs IdM capables de résoudre les recherches d'identité effectuées par les clients RHEL IdM auprès des contrôleurs de domaine AD. Contrairement aux contrôleurs de confiance, les agents de confiance ne peuvent pas traiter les demandes d'authentification Kerberos.

auto_private_groups = false

SSSD attribue la valeur uidNumber à l'UID de l'utilisateur et la valeur gidNumber au GID de l'utilisateur. Un groupe avec ce GID doit exister dans AD, sinon vous ne pourrez pas résoudre cet utilisateur. Le tableau suivant indique si vous pourrez résoudre les utilisateurs AD en fonction des différentes configurations AD.

Tableau 7.2. Comportement de SSSD lorsque la variable auto_private_groups est définie sur false pour une plage d'ID POSIX

Configuration des utilisateurs dans AD	Sortie de id username
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber n'est pas défini Aucun groupe dans AD avec gidNumber = 4000.	SSSD ne peut pas résoudre l'utilisateur.
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber = 4000 Aucun groupe dans AD avec gidNumber = 4000.	SSSD ne peut pas résoudre l'utilisateur.
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber = 4000 AD a un groupe avec gidNumber = 4000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(adgroup@ad-domain.com) groups=4000(adgroup@ad-domain.com), …​

auto_private_groups = true

SSSD crée toujours un groupe privé dont l'adresse gidNumber correspond à l'adresse uidNumber de l'entrée de l'utilisateur AD.

Tableau 7.3. Comportement de SSSD lorsque la variable auto_private_groups est définie sur true pour une plage d'ID POSIX

Configuration des utilisateurs dans AD	Sortie de id username
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber n'est pas défini AD n'a pas de groupe avec GID=4000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber = 5000 AD n'a pas de groupe avec gidNumber = 5000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber = 4000 AD n'a pas de groupe avec gidNumber = 4000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
L'entrée utilisateur AD a : uidNumber = 4000 gidNumber = 5000 AD a un groupe avec gidNumber = 5000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​

auto_private_groups = hybrid

Si la valeur uidNumber correspond à gidNumber, mais qu'il n'y a pas de groupe avec cette valeur gidNumber, SSSD affecte un groupe privé comme groupe d'utilisateurs principal de l'utilisateur avec une valeur gidNumber qui correspond à uidNumber. Si les valeurs uidNumber et gidNumber diffèrent, et qu'il y a un groupe avec cette valeur gidNumber, SSSD utilise la valeur de gidNumber.

Tableau 7.4. Comportement de SSSD lorsque la variable auto_private_groups est définie sur hybrid pour une plage d'ID POSIX

Configuration des utilisateurs dans AD	Sortie de id username
Entrée utilisateur AD avec : uidNumber = 4000 gidNumber n'est pas défini AD n'a pas de groupe avec gidNumber = 4000.	SSSD ne peut pas résoudre l'utilisateur.
Entrée utilisateur AD avec : uidNumber = 4000 gidNumber = 5000 AD n'a pas de groupe avec gidNumber = 5000.	SSSD ne peut pas résoudre l'utilisateur.
Entrée utilisateur AD avec : uidNumber = 4000 gidNumber = 4000 AD n'a pas de groupe avec gidNumber = 4000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=4000(aduser@ad-domain.com) groups=4000(aduser@ad-domain.com), …​
Entrée utilisateur AD avec : uidNumber = 4000 gidNumber = 5000 AD a un groupe avec gidNumber = 5000.	# id aduser@AD-DOMAIN.COMuid=4000(aduser@ad-domain.com) gid=5000(aduser@ad-domain.com) groups=5000(adgroup@ad-domain.com), …​

auto_private_groups = true

SSSD crée toujours un groupe privé dont le GID correspond à l'UID, qui est basé sur le SID de l'utilisateur AD.

Tableau 7.5. Comportement de SSSD lorsque la variable auto_private_groups est définie sur true pour une plage d'ID mapping

Configuration des utilisateurs dans AD	Sortie de id username
Entrée utilisateur AD où : Le SID correspond à 7000 primaryGroupID cartes jusqu'à 8000	# id aduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=7000(aduser@ad-domain.com) groups=7000(aduser@ad-domain.com), 8000(adgroup@ad-domain.com), …​

auto_private_groups = false

Si vous donnez à l'option auto_private_groups la valeur false, SSSD utilise le numéro primaryGroupID défini dans l'entrée AD comme numéro GID. La valeur par défaut de primaryGroupID correspond au groupe Domain Users dans AD.

Tableau 7.6. Comportement de SSSD lorsque la variable auto_private_groups est définie sur false pour une plage d'ID mapping

Configuration des utilisateurs dans AD	Sortie de id username
Entrée utilisateur AD où : Le SID correspond à 7000 primaryGroupID cartes jusqu'à 8000	# id aduser@AD-DOMAIN.COMuid=7000(aduser@ad-domain.com) gid=8000(adgroup@ad-domain.com) groups=8000(adgroup@ad-domain.com), …​

Domaines DNS primaires uniques

Assurez-vous que AD et IdM ont leurs propres domaines DNS primaires configurés. Par exemple :

• ad.example.com pour AD et idm.example.com pour IdM
• example.com pour AD et idm.example.com pour IdM

La solution de gestion la plus pratique est un environnement où chaque domaine DNS est géré par des serveurs DNS intégrés, mais vous pouvez également utiliser n'importe quel autre serveur DNS conforme aux normes.

Domaines IdM et AD DNS

Les systèmes reliés à IdM peuvent être distribués sur plusieurs domaines DNS. Red Hat recommande de déployer les clients IdM dans une zone DNS différente de celles appartenant à Active Directory. Le domaine DNS IdM primaire doit avoir des enregistrements SRV appropriés pour prendre en charge les trusts AD.

Enregistrements SRV appropriés

S'assurer que le domaine DNS primaire de l'IdM dispose des enregistrements SRV appropriés pour prendre en charge les trusts AD.

Pour les autres domaines DNS qui font partie du même domaine IdM, il n'est pas nécessaire de configurer les enregistrements SRV lors de l'établissement de la confiance avec AD. En effet, les contrôleurs de domaine AD n'utilisent pas les enregistrements SRV pour découvrir les centres de distribution de clés Kerberos (KDC), mais basent plutôt la découverte des KDC sur les informations de routage des suffixes de noms pour la confiance.

Enregistrements DNS pouvant être résolus à partir de tous les domaines DNS dans la confiance

Assurez-vous que toutes les machines peuvent résoudre les enregistrements DNS de tous les domaines DNS impliqués dans la relation de confiance :

• Lors de la configuration du DNS IdM, suivez les instructions décrites dans Installation d'un serveur IdM avec une autorité de certification externe.
• Si vous utilisez IdM sans DNS intégré, suivez les instructions décrites dans Installation d'un serveur IdM sans DNS intégré.

Les noms de domaines Kerberos sont des versions en majuscules des noms de domaines DNS primaires

Assurez-vous que les noms de domaines Kerberos sont identiques aux noms de domaines DNS primaires, avec toutes les lettres en majuscules. Par exemple, si les noms de domaine sont ad.example.com pour AD et idm.example.com pour IdM, les noms de domaine Kerberos doivent être AD.EXAMPLE.COM et IDM.EXAMPLE.COM.

Lors de l'utilisation d'IdM avec DNS intégré

Par défaut, les clients utilisent la recherche automatique de services basée sur les enregistrements DNS. Dans cette configuration, vous pouvez également utiliser la fonction DNS locations pour configurer la recherche de services basée sur le DNS.

Pour remplacer la recherche automatique, vous pouvez désactiver la découverte du DNS de l'une des manières suivantes :

• Pendant l'installation du client IdM, en fournissant les paramètres de basculement à partir de la ligne de commande
• Après l'installation du client, en modifiant la configuration du System Security Services Daemon (SSSD)

En cas d'utilisation d'IdM sans DNS intégré

Vous devez configurer explicitement les clients de l'une des manières suivantes :

• Pendant l'installation du client IdM, en fournissant les paramètres de basculement à partir de la ligne de commande
• Après l'installation du client en modifiant la configuration SSSD

Sauvegarde complète du serveur

• Contains tous les fichiers de configuration du serveur liés à l'IdM et les données LDAP dans les fichiers LDAP Data Interchange Format (LDIF)
• Les services IdM doivent être accessibles à l'adresse offline.
• Suitable for reconstruire un déploiement IdM à partir de zéro.

Sauvegarde des données uniquement

• Contains Données LDAP dans les fichiers LDIF et le journal des modifications de la réplication
• Les services IdM peuvent être online or offline.
• Suitable for rétablir les données de l'IdM dans un état antérieur

Sauvegarde complète du serveur

Une archive nommée ipa-full.tar dans un répertoire nommé ipa-full-<YEAR-MM-DD-HH-MM-SS>avec l'heure spécifiée en heure GMT.

[root@server ~]# ll /var/lib/ipa/backup/ipa-full-2021-01-29-12-11-46
total 3056
-rw-r--r--. 1 root root     158 Jan 29 12:11 header
-rw-r--r--. 1 root root 3121511 Jan 29 12:11 ipa-full.tar

Sauvegarde des données uniquement

Une archive nommée ipa-data.tar dans un répertoire nommé ipa-data-<YEAR-MM-DD-HH-MM-SS>avec l'heure spécifiée en heure GMT.

[root@server ~]# ll /var/lib/ipa/backup/ipa-data-2021-01-29-12-14-23
total 1072
-rw-r--r--. 1 root root     158 Jan 29 12:14 header
-rw-r--r--. 1 root root 1090388 Jan 29 12:14 ipa-data.tar