Gestion des utilisateurs, des groupes, des hôtes et des règles de contrôle d'accès de l'IdM

Red Hat Enterprise Linux 9

Configurer les utilisateurs et les hôtes, les gérer en groupes et contrôler l'accès à l'aide de règles de contrôle d'accès basées sur l'hôte et sur le rôle

Red Hat Customer Content Services

Résumé

La principale fonctionnalité de Red Hat Identity Management (IdM) est la gestion des utilisateurs, des groupes, des hôtes et des règles de contrôle d'accès, telles que le contrôle d'accès basé sur l'hôte (HBAC) et le contrôle d'accès basé sur le rôle (RBAC). Vous pouvez les configurer à l'aide de la ligne de commande, de l'interface Web IdM et des Playbooks Ansible.
Les tâches de gestion comprennent la configuration des politiques et de la sécurité Kerberos, l'automatisation de l'appartenance aux groupes et la délégation des autorisations.

Rendre l'open source plus inclusif

Red Hat s'engage à remplacer les termes problématiques dans son code, sa documentation et ses propriétés Web. Nous commençons par ces quatre termes : master, slave, blacklist et whitelist. En raison de l'ampleur de cette entreprise, ces changements seront mis en œuvre progressivement au cours de plusieurs versions à venir. Pour plus de détails, voir le message de notre directeur technique Chris Wright.

Fournir un retour d'information sur la documentation de Red Hat

Nous apprécions vos commentaires sur notre documentation. Faites-nous savoir comment nous pouvons l'améliorer.

Soumettre des commentaires sur des passages spécifiques

  1. Consultez la documentation au format Multi-page HTML et assurez-vous que le bouton Feedback apparaît dans le coin supérieur droit après le chargement complet de la page.
  2. Utilisez votre curseur pour mettre en évidence la partie du texte que vous souhaitez commenter.
  3. Cliquez sur le bouton Add Feedback qui apparaît près du texte en surbrillance.
  4. Ajoutez vos commentaires et cliquez sur Submit.

Soumettre des commentaires via Bugzilla (compte requis)

  1. Connectez-vous au site Web de Bugzilla.
  2. Sélectionnez la version correcte dans le menu Version.
  3. Saisissez un titre descriptif dans le champ Summary.
  4. Saisissez votre suggestion d'amélioration dans le champ Description. Incluez des liens vers les parties pertinentes de la documentation.
  5. Cliquez sur Submit Bug.

Chapitre 1. Introduction aux utilitaires de la ligne de commande IdM

Les sections suivantes décrivent les bases de l'utilisation des utilitaires de ligne de commande de la gestion des identités (IdM).

Conditions préalables

  • Serveur IdM installé et accessible.

    Pour plus de détails, voir Installation de la gestion des identités.

  • Pour utiliser l'interface de ligne de commande de l'IPA, authentifiez-vous auprès de l'IdM à l'aide d'un ticket Kerberos valide.

1.1. Qu'est-ce que l'interface de ligne de commande de l'IPA ?

L'interface de ligne de commande (CLI) de l'IPA est l'interface de ligne de commande de base pour l'administration de la gestion des identités (IdM).

Il prend en charge de nombreuses sous-commandes pour la gestion de l'IdM, telles que la commande ipa user-add pour ajouter un nouvel utilisateur.

L'interface CLI de l'IPA vous permet de

  • Ajouter, gérer ou supprimer des utilisateurs, des groupes, des hôtes et d'autres objets dans le réseau.
  • Gérer les certificats.
  • Entrées de recherche.
  • Afficher et répertorier des objets.
  • Définir les droits d'accès.
  • Obtenir de l'aide sur la syntaxe correcte de la commande.

1.2. Qu'est-ce que l'aide IPA ?

L'aide IPA est un système de documentation intégré au serveur IdM.

L'interface de ligne de commande (CLI) IPA génère les rubriques d'aide disponibles à partir des modules d'extension IdM chargés. Pour utiliser l'utilitaire d'aide de l'IPA, vous devez :

  • Un serveur IdM doit être installé et fonctionner.
  • Être authentifié par un ticket Kerberos valide.

La saisie de la commande ipa help sans options affiche des informations sur l'utilisation de l'aide de base et les exemples de commandes les plus courants.

Vous pouvez utiliser les options suivantes pour les différents cas d'utilisation de ipa help:

$ ipa help [TOPIC | COMMAND | topics | commands]
  • []- Les parenthèses signifient que tous les paramètres sont facultatifs et que vous pouvez écrire seulement ipa help pour que la commande soit exécutée.
  • |- Le caractère "pipe" signifie or. Par conséquent, vous pouvez spécifier un TOPIC, un COMMAND, ou un topics, ou un commands, avec la commande de base ipa help:

    • topics- Vous pouvez exécuter la commande ipa help topics pour afficher une liste de sujets couverts par l'aide IPA, tels que user, cert, server et bien d'autres.
    • TOPIC- Le TOPIC avec des lettres majuscules est une variable. Vous pouvez donc spécifier un sujet particulier, par exemple ipa help user.
    • commands- Vous pouvez entrer la commande ipa help commands pour afficher une liste de commandes couvertes par l'aide IPA, par exemple, user-add, ca-enable, server-show et bien d'autres.
    • COMMAND- Le COMMAND avec des lettres majuscules est une variable. Vous pouvez donc spécifier une commande particulière, par exemple ipa help user-add.

1.3. Utilisation des rubriques d'aide de l'IPA

La procédure suivante décrit comment utiliser l'aide IPA dans l'interface de ligne de commande.

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Saisissez ipa help topics pour afficher une liste des sujets couverts par l'aide.

    $ ipa help topics
  3. Sélectionnez l'un des sujets et créez une commande selon le modèle suivant : ipa help [topic_name]. À la place de la chaîne topic_name, ajoutez l'un des thèmes énumérés à l'étape précédente.

    Dans l'exemple, nous utilisons le sujet suivant : user

    $ ipa help user
  4. Si l'aide IPA est trop longue et que vous ne pouvez pas voir l'intégralité du texte, utilisez la syntaxe suivante :

    $ ipa help user | less

    Vous pouvez ensuite faire défiler la page et lire l'intégralité de l'aide.

L'interface de programmation IPA affiche une page d'aide pour la rubrique user. Après avoir lu l'aperçu, vous pouvez voir de nombreux exemples avec des modèles pour travailler avec les commandes de la rubrique.

1.4. Utilisation des commandes d'aide de l'IPA

La procédure suivante décrit comment créer des commandes d'aide IPA dans l'interface de ligne de commande.

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Saisissez ipa help commands pour afficher la liste des commandes couvertes par l'aide.

    $ ipa help commands
  3. Sélectionnez l'une des commandes et créez une commande d'aide selon le modèle suivant : ipa help <COMMAND>. À la place de la chaîne <COMMAND>, ajoutez l'une des commandes énumérées à l'étape précédente.

    $ ipa help user-add

Ressources supplémentaires

  • La page de manuel ipa.

1.5. Structure des commandes IPA

L'interface de programmation IPA distingue les types de commandes suivants :

  • Built-in commands- Les commandes intégrées sont toutes disponibles dans le serveur IdM.
  • Plug-in provided commands

La structure des commandes IPA permet de gérer différents types d'objets. Par exemple :

  • Utilisateurs,
  • Hôtes,
  • Enregistrements DNS,
  • Certificats,

et bien d'autres.

Pour la plupart de ces objets, l'interface CLI de l'IPA comprend des commandes pour :

  • Ajouter (add)
  • Modifier (mod)
  • Supprimer (del)
  • Recherche (find)
  • Affichage (show)

Les commandes ont la structure suivante :

ipa user-add, ipa user-mod, ipa user-del, ipa user-find, ipa user-show

ipa host-add, ipa host-mod, ipa host-del, ipa host-find, ipa host-show

ipa dnsrecord-add, ipa dnsrecord-mod, ipa dnsrecord-del, ipa dnsrecord-find, ipa dnrecord-show

Vous pouvez créer un utilisateur à l'aide de la commande ipa user-add [options], où [options] est facultatif. Si vous n'utilisez que la commande ipa user-add, le script vous demande les détails un par un.

Pour modifier un objet existant, vous devez définir l'objet, c'est pourquoi la commande comprend également un objet : ipa user-mod USER_NAME [options].

1.6. Utilisation d'une commande IPA pour ajouter un compte d'utilisateur à IdM

La procédure suivante décrit comment ajouter un nouvel utilisateur à la base de données Identity Management (IdM) à l'aide de la ligne de commande.

Conditions préalables

  • Vous devez disposer de privilèges d'administrateur pour ajouter des comptes d'utilisateurs au serveur IdM.

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Entrez la commande pour ajouter un nouvel utilisateur :

    $ ipa user-add

    La commande exécute un script qui vous invite à fournir les données de base nécessaires à la création d'un compte utilisateur.

  3. Dans le champ First name:, entrez le prénom du nouvel utilisateur et appuyez sur la touche Enter.
  4. Dans le champ Last name:, entrez le nom de famille du nouvel utilisateur et appuyez sur la touche Enter.
  5. Dans le champ User login [suggested user name]:, entrez le nom d'utilisateur ou appuyez simplement sur la touche Enter pour accepter le nom d'utilisateur proposé.

    Le nom d'utilisateur doit être unique pour toute la base de données IdM. Si une erreur survient parce que ce nom d'utilisateur existe déjà, répétez le processus avec la commande ipa user-add et utilisez un nom d'utilisateur différent et unique.

Une fois le nom d'utilisateur ajouté, le compte d'utilisateur est ajouté à la base de données IdM et l'interface de ligne de commande (CLI) de l'API affiche la sortie suivante :

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False
Note

Par défaut, aucun mot de passe n'est défini pour le compte d'utilisateur. Pour ajouter un mot de passe lors de la création d'un compte utilisateur, utilisez la commande ipa user-add avec la syntaxe suivante :

$ ipa user-add --first=Example --last=User --password

L'interface CLI de l'IPA vous invite ensuite à ajouter ou à confirmer un nom d'utilisateur et un mot de passe.

Si l'utilisateur a déjà été créé, vous pouvez ajouter le mot de passe à l'aide de la commande ipa user-mod.

Ressources supplémentaires

  • Exécutez la commande ipa help user-add pour plus d'informations sur les paramètres.

1.7. Utilisation d'une commande IPA pour modifier un compte d'utilisateur dans IdM

Vous pouvez modifier de nombreux paramètres pour chaque compte d'utilisateur. Par exemple, vous pouvez ajouter un nouveau mot de passe à l'utilisateur.

La syntaxe de la commande de base est différente de celle de user-add car vous devez définir le compte d'utilisateur existant pour lequel vous souhaitez effectuer des modifications, par exemple, ajouter un mot de passe.

Conditions préalables

  • Vous devez disposer des droits d'administrateur pour modifier les comptes d'utilisateurs.

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Entrez la commande ipa user-mod, indiquez l'utilisateur à modifier et les options éventuelles, telles que --password pour l'ajout d'un mot de passe :

    $ ipa user-mod euser --password

    La commande lance un script dans lequel vous pouvez ajouter le nouveau mot de passe.

  3. Saisissez le nouveau mot de passe et appuyez sur la touche Enter.

L'interface de programmation de l'IPA affiche la sortie suivante :

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

Le mot de passe de l'utilisateur est maintenant défini pour le compte et l'utilisateur peut se connecter à IdM.

Ressources supplémentaires

  • Exécutez la commande ipa help user-mod pour plus d'informations sur les paramètres.

1.8. Comment fournir une liste de valeurs aux utilitaires IdM ?

La gestion de l'identité (IdM) stocke les valeurs des attributs à valeurs multiples dans des listes.

L'IdM prend en charge les méthodes suivantes pour fournir des listes à valeurs multiples :

  • Utilisation du même argument de ligne de commande plusieurs fois dans la même invocation de commande :

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • Vous pouvez également placer la liste entre accolades, auquel cas l'interpréteur de commandes procède à l'expansion :

    $ ipa permission-add --right={read,write,delete} ...

Les exemples ci-dessus montrent une commande permission-add qui ajoute des autorisations à un objet. L'objet n'est pas mentionné dans l'exemple. Au lieu de …​ vous devez ajouter l'objet pour lequel vous souhaitez ajouter des autorisations.

Lorsque vous mettez à jour de tels attributs à valeurs multiples à partir de la ligne de commande, l'IdM écrase complètement la liste précédente de valeurs par une nouvelle liste. Par conséquent, lorsque vous mettez à jour un attribut à valeurs multiples, vous devez spécifier l'ensemble de la nouvelle liste, et non pas une seule valeur que vous souhaitez ajouter.

Par exemple, dans la commande ci-dessus, la liste des autorisations comprend la lecture, l'écriture et la suppression. Lorsque vous décidez de mettre à jour la liste avec la commande permission-mod vous devez ajouter toutes les valeurs, sinon celles qui ne sont pas mentionnées seront supprimées.

Example 1:- La commande ipa permission-mod met à jour toutes les autorisations précédemment ajoutées.

$ ipa permission-mod --right=read --right=write --right=delete ...

ou

$ ipa permission-mod --right={read,write,delete} ...

Example 2- La commande ipa permission-mod supprime l'argument --right=delete car il n'est pas inclus dans la commande :

$ ipa permission-mod --right=read --right=write ...

ou

$ ipa permission-mod --right={read,write} ...

1.9. Comment utiliser les caractères spéciaux avec les utilitaires IdM ?

Lorsque vous transmettez aux commandes ipa des arguments de ligne de commande comprenant des caractères spéciaux, échappez ces caractères à l'aide d'une barre oblique inverse (\N). Par exemple, les caractères spéciaux courants sont les crochets (< et >), l'esperluette (&), l'astérisque (*) ou la barre verticale (|).

Par exemple, pour échapper à un astérisque (*) :

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

Les commandes contenant des caractères spéciaux non encapsulés ne fonctionnent pas comme prévu, car l'interpréteur de commandes ne peut pas analyser correctement ces caractères.

Chapitre 2. Gestion des comptes d'utilisateurs à l'aide de la ligne de commande

Ce chapitre comprend une description de base du cycle de vie de l'utilisateur dans le cadre de la gestion de l'identité (IdM). Les sections suivantes vous montrent comment :

  • Créer des comptes d'utilisateurs
  • Activer les comptes d'utilisateurs de l'étape
  • Préserver les comptes d'utilisateurs
  • Supprimer des comptes d'utilisateurs actifs, d'étape ou préservés
  • Restaurer les comptes d'utilisateurs conservés

2.1. Cycle de vie de l'utilisateur

La gestion des identités (IdM) prend en charge trois états de compte utilisateur :

  • Stage les utilisateurs ne sont pas autorisés à s'authentifier. Il s'agit d'un état initial. Certaines propriétés du compte utilisateur requises pour les utilisateurs actifs ne peuvent pas être définies, par exemple l'appartenance à un groupe.
  • Active les utilisateurs sont autorisés à s'authentifier. Toutes les propriétés requises du compte utilisateur doivent être définies dans cet état.
  • Preserved sont d'anciens utilisateurs actifs qui sont considérés comme inactifs et ne peuvent pas s'authentifier auprès de l'IdM. Les utilisateurs préservés conservent la plupart des propriétés du compte qu'ils avaient en tant qu'utilisateurs actifs, mais ils ne font partie d'aucun groupe d'utilisateurs.

Un organigramme affichant 4 éléments : Utilisateurs actifs - Utilisateurs en phase - Utilisateurs conservés - Utilisateurs supprimés. Les flèches indiquent les relations entre chaque type d'utilisateur : Les utilisateurs actifs peuvent être "conservés" en tant qu'utilisateurs préservés. Les utilisateurs conservés peuvent être "restaurés" en tant qu'utilisateurs actifs. Les utilisateurs préservés peuvent être "stagés" en tant qu'utilisateurs en phase et les utilisateurs en phase peuvent être "activés" en tant qu'utilisateurs actifs. Tous les utilisateurs peuvent être supprimés pour devenir des "utilisateurs supprimés".

Vous pouvez supprimer définitivement les entrées utilisateur de la base de données IdM.

Important

Les comptes d'utilisateurs supprimés ne peuvent pas être restaurés. Lorsque vous supprimez un compte d'utilisateur, toutes les informations associées à ce compte sont définitivement perdues.

Un nouvel administrateur ne peut être créé que par un utilisateur disposant de droits d'administrateur, tel que l'utilisateur admin par défaut. Si vous supprimez accidentellement tous les comptes d'administrateur, le gestionnaire de répertoire doit créer manuellement un nouvel administrateur dans le serveur de répertoire.

Avertissement

Ne pas supprimer l'utilisateur admin. Comme admin est un utilisateur prédéfini requis par l'IdM, cette opération pose des problèmes avec certaines commandes. Si vous souhaitez définir et utiliser un autre utilisateur administrateur, désactivez l'utilisateur prédéfini admin avec ipa user-disable admin après avoir accordé des droits d'administrateur à au moins un autre utilisateur.

Avertissement

N'ajoutez pas d'utilisateurs locaux à IdM. Le commutateur de service de noms (NSS) résout toujours les utilisateurs et les groupes IdM avant de résoudre les utilisateurs et les groupes locaux. Cela signifie, par exemple, que l'appartenance à un groupe IdM ne fonctionne pas pour les utilisateurs locaux.

2.2. Ajouter des utilisateurs à l'aide de la ligne de commande

Vous pouvez ajouter un utilisateur en tant que :

  • Active- les comptes d'utilisateurs qui peuvent être utilisés activement par leurs utilisateurs.
  • Stage- ne peuvent pas utiliser ces comptes. Utilisez-le si vous souhaitez préparer de nouveaux comptes d'utilisateurs. Lorsque les utilisateurs sont prêts à utiliser leurs comptes, vous pouvez les activer.

La procédure suivante décrit l'ajout d'utilisateurs actifs au serveur IdM à l'aide de la commande ipa user-add.

De la même manière, vous pouvez créer des comptes d'utilisateurs de scène à l'aide de la commande ipa stageuser-add.

Note

L'IdM attribue automatiquement un numéro d'identification unique (UID) aux nouveaux comptes d'utilisateurs. Vous pouvez également le faire manuellement, mais le serveur ne vérifie pas si le numéro UID est unique. Pour cette raison, plusieurs entrées d'utilisateurs peuvent avoir le même numéro d'ID assigné. Red Hat recommande d'éviter d'avoir plusieurs entrées avec le même UID.

Conditions préalables

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Ajoutez le login de l'utilisateur, son prénom, son nom et, éventuellement, son adresse électronique.

    $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

    IdM prend en charge les noms d'utilisateurs qui peuvent être décrits par l'expression régulière suivante :

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    Note

    Les noms d'utilisateur se terminant par le signe du dollar ($) sont pris en charge pour permettre la prise en charge des machines Samba 3.x.

    Si vous ajoutez un nom d'utilisateur contenant des caractères majuscules, l'IdM convertit automatiquement le nom en minuscules lorsqu'il est enregistré. Par conséquent, l'IdM exige toujours que les noms d'utilisateurs soient saisis en minuscules lors de l'ouverture d'une session. En outre, il n'est pas possible d'ajouter des noms d'utilisateurs qui ne diffèrent que par la casse des lettres, comme user et User.

    La longueur maximale par défaut des noms d'utilisateur est de 32 caractères. Pour la modifier, utilisez la commande ipa config-mod --maxusername. Par exemple, pour augmenter la longueur maximale des noms d'utilisateur à 64 caractères :

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    La commande ipa user-add comprend de nombreux paramètres. Pour les énumérer tous, utilisez la commande ipa help :

    ipa help user-add

    Pour plus d'informations sur la commande ipa help, voir Qu'est-ce que l'aide IPA?

Vous pouvez vérifier si le nouveau compte d'utilisateur a été créé avec succès en dressant la liste de tous les comptes d'utilisateur IdM :

ipa user-find

Cette commande dresse la liste de tous les comptes d'utilisateurs avec leurs détails.

2.3. Activation des utilisateurs à l'aide de la ligne de commande

Pour activer un compte d'utilisateur en le faisant passer de stage à actif, utilisez la commande ipa stageuser-activate.

Conditions préalables

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Activez le compte d'utilisateur à l'aide de la commande suivante :

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

Vous pouvez vérifier si le nouveau compte d'utilisateur a été créé avec succès en dressant la liste de tous les comptes d'utilisateur IdM :

ipa user-find

Cette commande dresse la liste de tous les comptes d'utilisateurs avec leurs détails.

2.4. Préserver les utilisateurs à l'aide de la ligne de commande

Vous pouvez préserver un compte d'utilisateur si vous souhaitez le supprimer, tout en conservant la possibilité de le restaurer ultérieurement. Pour préserver un compte d'utilisateur, utilisez l'option --preserve avec les commandes ipa user-del ou ipa stageuser-del.

Conditions préalables

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Préservez le compte d'utilisateur à l'aide de la commande suivante :

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------
    Note

    Bien que le résultat indique que le compte d'utilisateur a été supprimé, il a été préservé.

2.5. Suppression d'utilisateurs à l'aide de la ligne de commande

IdM (Identity Management) vous permet de supprimer des utilisateurs de façon permanente. Vous pouvez supprimer :

  • Les utilisateurs actifs avec la commande suivante : ipa user-del
  • Les utilisateurs de l'étape avec la commande suivante : ipa stageuser-del
  • Les utilisateurs préservés avec la commande suivante : ipa user-del

Lors de la suppression de plusieurs utilisateurs, utilisez l'option --continue pour forcer la commande à continuer sans tenir compte des erreurs. Un résumé des opérations réussies et échouées est imprimé sur le flux de sortie standard stdout lorsque la commande est terminée.

ipa user-del --continue user1 user2 user3

Si vous n'utilisez pas --continue, la commande procède à la suppression des utilisateurs jusqu'à ce qu'elle rencontre une erreur, après quoi elle s'arrête et sort.

Conditions préalables

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Supprimez le compte d'utilisateur à l'aide de la commande suivante :

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

Le compte d'utilisateur a été définitivement supprimé de l'IdM.

2.6. Restauration des utilisateurs à l'aide de la ligne de commande

Vous pouvez restaurer un utilisateur préservé :

  • Utilisateurs actifs : ipa user-undel
  • Utilisateurs du stade : ipa user-stage

La restauration d'un compte d'utilisateur ne rétablit pas tous les attributs précédents du compte. Par exemple, le mot de passe de l'utilisateur n'est pas restauré et doit être défini à nouveau.

Conditions préalables

Procédure

  1. Ouvrez un terminal et connectez-vous au serveur IdM.
  2. Activez le compte d'utilisateur à l'aide de la commande suivante :

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    Vous pouvez également restaurer les comptes d'utilisateurs en tant que stades :

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

Verification steps

  • Vous pouvez vérifier si le nouveau compte d'utilisateur a été créé avec succès en dressant la liste de tous les comptes d'utilisateur IdM :

    ipa user-find

    Cette commande dresse la liste de tous les comptes d'utilisateurs avec leurs détails.

Chapitre 3. Gestion des comptes d'utilisateurs à l'aide de l'interface Web IdM

La gestion des identités (IdM) propose plusieurs étapes qui peuvent vous aider à gérer les différentes situations de vie professionnelle des utilisateurs :

Création d'un compte utilisateur

Créer un compte d'utilisateur avant qu'un employé ne commence sa carrière dans votre entreprise et être prêt à l'avance pour le jour où l'employé se présentera au bureau et voudra activer le compte.

Vous pouvez omettre cette étape et créer directement le compte d'utilisateur actif. La procédure est similaire à la création d'un compte d'utilisateur de scène.

Activation d'un compte d'utilisateur
Activation du compte le premier jour ouvrable de l'employé.
Désactivation d'un compte d'utilisateur
Si l'utilisateur part en congé parental pendant quelques mois, vous devrez désactiver le compte temporairement.
Activation d'un compte d'utilisateur
Lorsque l'utilisateur revient, vous devez réactiver le compte.
Préserver un compte d'utilisateur
Si l'utilisateur souhaite quitter l'entreprise, vous devrez supprimer le compte avec la possibilité de le restaurer, car les personnes peuvent revenir dans l'entreprise après un certain temps.
Restauration d'un compte d'utilisateur
Deux ans plus tard, l'utilisateur est de retour et vous devez restaurer le compte préservé.
Suppression d'un compte d'utilisateur
Si l'employé est licencié, supprimez le compte sans sauvegarde.

3.1. Cycle de vie de l'utilisateur

La gestion des identités (IdM) prend en charge trois états de compte utilisateur :

  • Stage les utilisateurs ne sont pas autorisés à s'authentifier. Il s'agit d'un état initial. Certaines propriétés du compte utilisateur requises pour les utilisateurs actifs ne peuvent pas être définies, par exemple l'appartenance à un groupe.
  • Active les utilisateurs sont autorisés à s'authentifier. Toutes les propriétés requises du compte utilisateur doivent être définies dans cet état.
  • Preserved sont d'anciens utilisateurs actifs qui sont considérés comme inactifs et ne peuvent pas s'authentifier auprès de l'IdM. Les utilisateurs préservés conservent la plupart des propriétés du compte qu'ils avaient en tant qu'utilisateurs actifs, mais ils ne font partie d'aucun groupe d'utilisateurs.

Un organigramme affichant 4 éléments : Utilisateurs actifs - Utilisateurs en phase - Utilisateurs conservés - Utilisateurs supprimés. Les flèches indiquent les relations entre chaque type d'utilisateur : Les utilisateurs actifs peuvent être "conservés" en tant qu'utilisateurs préservés. Les utilisateurs conservés peuvent être "restaurés" en tant qu'utilisateurs actifs. Les utilisateurs préservés peuvent être "stagés" en tant qu'utilisateurs en phase et les utilisateurs en phase peuvent être "activés" en tant qu'utilisateurs actifs. Tous les utilisateurs peuvent être supprimés pour devenir des "utilisateurs supprimés".

Vous pouvez supprimer définitivement les entrées utilisateur de la base de données IdM.

Important

Les comptes d'utilisateurs supprimés ne peuvent pas être restaurés. Lorsque vous supprimez un compte d'utilisateur, toutes les informations associées à ce compte sont définitivement perdues.

Un nouvel administrateur ne peut être créé que par un utilisateur disposant de droits d'administrateur, tel que l'utilisateur admin par défaut. Si vous supprimez accidentellement tous les comptes d'administrateur, le gestionnaire de répertoire doit créer manuellement un nouvel administrateur dans le serveur de répertoire.

Avertissement

Ne pas supprimer l'utilisateur admin. Comme admin est un utilisateur prédéfini requis par l'IdM, cette opération pose des problèmes avec certaines commandes. Si vous souhaitez définir et utiliser un autre utilisateur administrateur, désactivez l'utilisateur prédéfini admin avec ipa user-disable admin après avoir accordé des droits d'administrateur à au moins un autre utilisateur.

Avertissement

N'ajoutez pas d'utilisateurs locaux à IdM. Le commutateur de service de noms (NSS) résout toujours les utilisateurs et les groupes IdM avant de résoudre les utilisateurs et les groupes locaux. Cela signifie, par exemple, que l'appartenance à un groupe IdM ne fonctionne pas pour les utilisateurs locaux.

3.2. Ajouter des utilisateurs dans l'interface web

En général, vous devez créer un nouveau compte utilisateur avant qu'un nouvel employé ne commence à travailler. Ce compte d'étape n'est pas accessible et vous devez l'activer ultérieurement.

Note

Vous pouvez également créer directement un compte d'utilisateur actif. Pour ajouter un utilisateur actif, suivez la procédure ci-dessous et ajoutez le compte utilisateur dans l'onglet Active users.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'IdM ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Stage Users.

    Vous pouvez également ajouter le compte d'utilisateur sur le site Users → Active users, mais vous ne pouvez pas ajouter de groupes d'utilisateurs à ce compte.

  3. Cliquez sur l'icône Add.
  4. Dans la boîte de dialogue Add stage user, entrez First name et Last name du nouvel utilisateur.
  5. [Facultatif] Dans le champ User login, ajoutez un nom de connexion.

    Si vous laissez ce champ vide, le serveur IdM crée le nom de connexion selon le modèle suivant : La première lettre du prénom et le nom de famille. Le nom de connexion complet peut comporter jusqu'à 32 caractères.

  6. [Dans le menu déroulant GID, sélectionnez les groupes dans lesquels l'utilisateur doit être inclus.
  7. [Facultatif] Dans les champs Password et Verify password, saisissez votre mot de passe et confirmez-le, en veillant à ce qu'il corresponde à votre mot de passe.
  8. Cliquez sur le bouton Add.

    Capture d'écran de la fenêtre contextuelle "Ajouter un utilisateur d'étape" avec les champs "Nouveau mot de passe" et "Vérifier le mot de passe" remplis. Le bouton "Ajouter" se trouve en bas à gauche.

À ce stade, vous pouvez voir le compte d'utilisateur dans la table Stage Users.

Capture d'écran de l'interface Web de l'IdM montrant les entrées d'utilisateurs dans le tableau "Stage Users". Ce tableau est sélectionné à partir de l'onglet Identité - sous-onglet Utilisateurs - et de la catégorie Utilisateurs de l'étape listée à gauche.

Note

Si vous cliquez sur le nom de l'utilisateur, vous pouvez modifier les paramètres avancés, tels que l'ajout d'un numéro de téléphone, d'une adresse ou d'une profession.

3.3. Activation des utilisateurs d'étape dans l'interface Web IdM

Un compte d'utilisateur de scène doit être activé avant que l'utilisateur puisse se connecter à IdM et avant qu'il puisse être ajouté à un groupe IdM. Cette section décrit comment activer les comptes d'utilisateurs de scène.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM ou rôle d'administrateur des utilisateurs.
  • Au moins un compte d'utilisateur en phase dans l'IdM.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Stage users.
  3. Cliquez sur la case à cocher du compte utilisateur que vous souhaitez activer.
  4. Cliquez sur le bouton Activate.

    Capture d'écran de l'interface Web IdM montrant les entrées des utilisateurs dans le tableau "Stage Users". Ce tableau est sélectionné à partir de l'onglet Identité - sous-onglet Utilisateurs - et de la catégorie Utilisateurs de l'étape listée à gauche.

  5. Dans la boîte de dialogue Confirmation, cliquez sur le bouton OK.

Si l'activation est réussie, l'interface Web IdM affiche une confirmation verte indiquant que l'utilisateur a été activé et que le compte utilisateur a été déplacé vers Active users. Le compte est actif et l'utilisateur peut s'authentifier auprès du domaine IdM et de l'interface Web IdM. L'utilisateur est invité à modifier son mot de passe lors de la première connexion.

Capture d'écran de l'interface Web IdM montrant l'entrée utilisateur "staged.user" dans le tableau "Active Users". Son statut est "enabled."

Note

À ce stade, vous pouvez ajouter le compte d'utilisateur actif aux groupes d'utilisateurs.

3.4. Désactivation des comptes d'utilisateurs dans l'interface Web

Vous pouvez désactiver les comptes d'utilisateurs actifs. La désactivation d'un compte d'utilisateur désactive le compte. Par conséquent, les comptes d'utilisateur ne peuvent pas être utilisés pour s'authentifier et utiliser les services IdM, tels que Kerberos, ou pour effectuer des tâches.

Les comptes d'utilisateurs désactivés existent toujours dans l'IdM et toutes les informations qui leur sont associées restent inchangées. Contrairement aux comptes d'utilisateurs préservés, les comptes d'utilisateurs désactivés restent actifs et peuvent être membres de groupes d'utilisateurs.

Note

Après la désactivation d'un compte d'utilisateur, les connexions existantes restent valables jusqu'à l'expiration du TGT Kerberos et des autres tickets de l'utilisateur. Après l'expiration du ticket, l'utilisateur ne pourra pas le renouveler.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Active users.
  3. Cliquez sur la case à cocher des comptes d'utilisateurs que vous souhaitez désactiver.
  4. Cliquez sur le bouton Disable.

    Capture d'écran de la page "Utilisateurs actifs" avec un tableau affichant les attributs de plusieurs utilisateurs, tels que Connexion de l'utilisateur - Prénom - Nom - Statut - UID - Adresse électronique - Numéro de téléphone - Titre du poste. L'entrée du compte "euser" a été mise en évidence, de même que les boutons "Activer" et "Désactiver" en haut à droite.

  5. Dans la boîte de dialogue Confirmation, cliquez sur le bouton OK.

Si la procédure de désactivation a réussi, vous pouvez le vérifier dans la colonne Statut du tableau Active users.

Capture d'écran de la même page "Utilisateurs actifs" avec le tableau affichant les attributs de plusieurs utilisateurs. Le compte "euser" est désormais grisé et affiche "Disabled" dans sa colonne "Status".

3.5. Activation des comptes d'utilisateurs dans l'interface Web

L'IdM permet d'activer des comptes d'utilisateurs actifs désactivés. L'activation d'un compte d'utilisateur active le compte désactivé.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Active users.
  3. Cliquez sur la case à cocher des comptes d'utilisateurs que vous souhaitez activer.
  4. Cliquez sur le bouton Enable.

    Capture d'écran de la page "Utilisateurs actifs" avec un tableau affichant les attributs de plusieurs utilisateurs, tels que Connexion de l'utilisateur - Prénom - Nom - Statut - UID - Adresse électronique - Numéro de téléphone - Titre du poste. L'entrée du compte "euser" a été mise en évidence, de même que les boutons "Activer" et "Désactiver" en haut à droite.

  5. Dans la boîte de dialogue Confirmation, cliquez sur le bouton OK.

Si la modification a été effectuée avec succès, vous pouvez le vérifier dans la colonne Statut du tableau Active users.

3.6. Préservation des utilisateurs actifs dans l'interface Web IdM

La préservation des comptes d'utilisateurs vous permet de supprimer des comptes de l'onglet Active users, tout en conservant ces comptes dans l'IdM.

Conservez le compte utilisateur si l'employé quitte l'entreprise. Si vous souhaitez désactiver les comptes d'utilisateur pendant quelques semaines ou quelques mois (congé parental, par exemple), désactivez le compte. Pour plus d'informations, voir Désactivation des comptes d'utilisateurs dans l'interface Web. Les comptes conservés ne sont pas actifs et les utilisateurs ne peuvent pas les utiliser pour accéder à votre réseau interne, mais le compte reste dans la base de données avec toutes les données.

Vous pouvez remettre les comptes restaurés en mode actif.

Note

La liste des utilisateurs dans l'état préservé peut fournir un historique des anciens comptes d'utilisateurs.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM (Identity Management) ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Active users.
  3. Cliquez sur la case à cocher des comptes d'utilisateurs que vous souhaitez conserver.
  4. Cliquez sur le bouton Delete.

    Capture d'écran de la page "Utilisateurs actifs" affichant un tableau des utilisateurs. La case de l'entrée du compte "preserved.user" a été cochée et le bouton "Delete" en haut de la page est en surbrillance.

  5. Dans la boîte de dialogue Remove users, remplacez le bouton radio Delete mode par preserve.
  6. Cliquez sur le bouton Delete.

    Capture d'écran d'une fenêtre pop-up intitulée "Supprimer les utilisateurs" Le contenu indique "Are you sure you want to delete selected entries?\N-" et précise "preserved.user\N" en dessous. Il y a une étiquette "Delete mode" (Supprimer le mode) avec deux options radiales : "Supprimer" et "Préserver" (qui est sélectionné). Des boutons "Supprimer" et "Annuler" se trouvent dans le coin inférieur droit de la fenêtre.

En conséquence, le compte d'utilisateur est déplacé vers Preserved users.

Si vous devez restaurer les utilisateurs conservés, consultez la section Restauration des utilisateurs dans l'interface Web IdM.

3.7. Restauration des utilisateurs dans l'interface Web IdM

IdM (Identity Management) vous permet de restaurer les comptes d'utilisateurs préservés à l'état actif. Vous pouvez restaurer un utilisateur préservé en tant qu'utilisateur actif ou en tant qu'utilisateur d'étape.

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Preserved users.
  3. Cliquez sur la case à cocher des comptes d'utilisateurs que vous souhaitez restaurer.
  4. Cliquez sur le bouton Restore.

    Capture d'écran de la page "Utilisateurs préservés" affichant un tableau des utilisateurs et de leurs attributs. La case située à côté de l'entrée d'un utilisateur est cochée et le bouton "Restaurer" en haut à droite est en surbrillance.

  5. Dans la boîte de dialogue Confirmation, cliquez sur le bouton OK.

L'interface Web IdM affiche une confirmation verte et déplace les comptes d'utilisateurs vers l'onglet Active users.

3.8. Suppression d'utilisateurs dans l'interface Web IdM

La suppression d'utilisateurs est une opération irréversible, qui entraîne la suppression permanente des comptes d'utilisateurs de la base de données de l'IdM, y compris les appartenances à des groupes et les mots de passe. Toute configuration externe de l'utilisateur, telle que le compte système et le répertoire personnel, n'est pas supprimée, mais n'est plus accessible par l'intermédiaire de l'IdM.

Vous pouvez supprimer :

  • Utilisateurs actifs - l'interface Web de l'IdM vous offre les options suivantes :

  • Utilisateurs de l'étape - vous pouvez supprimer définitivement les utilisateurs de l'étape.
  • Utilisateurs conservés - vous pouvez supprimer définitivement les utilisateurs conservés.

La procédure suivante décrit la suppression des utilisateurs actifs. De même, vous pouvez supprimer des comptes d'utilisateurs sur :

  • L'onglet Stage users
  • L'onglet Preserved users

Conditions préalables

  • Privilèges d'administrateur pour la gestion de l'interface Web IdM ou rôle d'administrateur des utilisateurs.

Procédure

  1. Connectez-vous à l'interface Web IdM.
  2. Allez sur l'onglet Users → Active users.

    Vous pouvez également supprimer le compte d'utilisateur sur le site Users → Stage users ou Users → Preserved users.

  3. Cliquez sur l'icône Delete.
  4. Dans la boîte de dialogue Remove users, remplacez le bouton radio Delete mode par delete.
  5. Cliquez sur le bouton Delete.

Les comptes des utilisateurs ont été définitivement supprimés de l'IdM.

Chapitre 4. Gérer les comptes d'utilisateurs à l'aide de playbooks Ansible

Vous pouvez gérer les utilisateurs dans IdM à l'aide de carnets de commande Ansible. Après avoir présenté le cycle de vie des utilisateurs, ce chapitre décrit comment utiliser les playbooks Ansible pour les opérations suivantes :

4.1. Cycle de vie de l'utilisateur

La gestion des identités (IdM) prend en charge trois états de compte utilisateur :

  • Stage les utilisateurs ne sont pas autorisés à s'authentifier. Il s'agit d'un état initial. Certaines propriétés du compte utilisateur requises pour les utilisateurs actifs ne peuvent pas être définies, par exemple l'appartenance à un groupe.
  • Active les utilisateurs sont autorisés à s'authentifier. Toutes les propriétés requises du compte utilisateur doivent être définies dans cet état.
  • Preserved sont d'anciens utilisateurs actifs qui sont considérés comme inactifs et ne peuvent pas s'authentifier auprès de l'IdM. Les utilisateurs préservés conservent la plupart des propriétés du compte qu'ils avaient en tant qu'utilisateurs actifs, mais ils ne font partie d'aucun groupe d'utilisateurs.

Un organigramme affichant 4 éléments : Utilisateurs actifs - Utilisateurs en phase - Utilisateurs conservés - Utilisateurs supprimés. Les flèches indiquent les relations entre chaque type d'utilisateur : Les utilisateurs actifs peuvent être "conservés" en tant qu'utilisateurs préservés. Les utilisateurs conservés peuvent être "restaurés" en tant qu'utilisateurs actifs. Les utilisateurs préservés peuvent être "stagés" en tant qu'utilisateurs en phase et les utilisateurs en phase peuvent être "activés" en tant qu'utilisateurs actifs. Tous les utilisateurs peuvent être supprimés pour devenir des "utilisateurs supprimés".

Vous pouvez supprimer définitivement les entrées utilisateur de la base de données IdM.

Important

Les comptes d'utilisateurs supprimés ne peuvent pas être restaurés. Lorsque vous supprimez un compte d'utilisateur, toutes les informations associées à ce compte sont définitivement perdues.

Un nouvel administrateur ne peut être créé que par un utilisateur disposant de droits d'administrateur, tel que l'utilisateur admin par défaut. Si vous supprimez accidentellement tous les comptes d'administrateur, le gestionnaire de répertoire doit créer manuellement un nouvel administrateur dans le serveur de répertoire.

Avertissement

Ne pas supprimer l'utilisateur admin. Comme admin est un utilisateur prédéfini requis par l'IdM, cette opération pose des problèmes avec certaines commandes. Si vous souhaitez définir et utiliser un autre utilisateur administrateur, désactivez l'utilisateur prédéfini admin avec ipa user-disable admin après avoir accordé des droits d'administrateur à au moins un autre utilisateur.

Avertissement

N'ajoutez pas d'utilisateurs locaux à IdM. Le commutateur de service de noms (NSS) résout toujours les utilisateurs et les groupes IdM avant de résoudre les utilisateurs et les groupes locaux. Cela signifie, par exemple, que l'appartenance à un groupe IdM ne fonctionne pas pour les utilisateurs locaux.

4.2. Assurer la présence d'un utilisateur IdM à l'aide d'un playbook Ansible

La procédure suivante décrit comment assurer la présence d'un utilisateur dans IdM à l'aide d'un playbook Ansible.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créez un fichier Ansible playbook avec les données de l'utilisateur dont vous voulez assurer la présence dans IdM. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml. Par exemple, pour créer un utilisateur nommé idm_user et ajouter Password123 comme mot de passe :

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

    Vous devez utiliser les options suivantes pour ajouter un utilisateur :

    • namele nom d'utilisateur
    • first: la chaîne de caractères du prénom
    • last: la chaîne du nom de famille

    Pour la liste complète des options disponibles pour l'utilisateur, voir le fichier Markdown de /usr/share/doc/ansible-freeipa/README-user.md.

    Note

    Si vous utilisez l'option update_password: on_create, Ansible ne crée le mot de passe de l'utilisateur que lorsqu'il crée l'utilisateur. Si l'utilisateur est déjà créé avec un mot de passe, Ansible ne génère pas de nouveau mot de passe.

  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

Verification steps

  • Vous pouvez vérifier si le nouveau compte d'utilisateur existe dans IdM en utilisant la commande ipa user-show:

    1. Connectez-vous à ipaserver en tant qu'administrateur :

      $ ssh admin@server.idm.example.com
      Password:
      [admin@server /]$
    2. Demander un ticket Kerberos pour l'administrateur :

      $ kinit admin
      Password for admin@IDM.EXAMPLE.COM:
    3. Demande d'informations sur idm_user:

      $ ipa user-show idm_user
        User login: idm_user
        First name: Alice
        Last name: Acme
        ....

    L'utilisateur nommé idm_user est présent dans IdM.

4.3. Assurer la présence de plusieurs utilisateurs IdM à l'aide de playbooks Ansible

La procédure suivante décrit comment assurer la présence de plusieurs utilisateurs dans IdM à l'aide d'un playbook Ansible.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créez un fichier Ansible playbook avec les données des utilisateurs dont vous voulez assurer la présence dans IdM. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Par exemple, pour créer les utilisateurs idm_user_1, idm_user_2, et idm_user_3, et ajouter Password123 comme mot de passe de idm_user_1:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create user idm_users
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users:
          - name: idm_user_1
            first: Alice
            last: Acme
            uid: 10001
            gid: 10011
            phone: "+555123457"
            email: idm_user@acme.com
            passwordexpiration: "2023-01-19 23:59:59"
            password: "Password123"
          - name: idm_user_2
            first: Bob
            last: Acme
            uid: 100011
            gid: 10011
          - name: idm_user_3
            first: Eve
            last: Acme
            uid: 1000111
            gid: 10011
    Note

    Si vous ne spécifiez pas l'option update_password: on_create, Ansible réinitialise le mot de passe de l'utilisateur à chaque fois que le livre de jeu est exécuté : si l'utilisateur a modifié le mot de passe depuis la dernière fois que le livre de jeu a été exécuté, Ansible réinitialise le mot de passe.

  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

Verification steps

  • Vous pouvez vérifier si le compte d'utilisateur existe dans IdM en utilisant la commande ipa user-show:

    1. Connectez-vous à ipaserver en tant qu'administrateur :

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Afficher des informations sur idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    L'utilisateur nommé idm_user_1 est présent dans IdM.

4.4. Assurer la présence de plusieurs utilisateurs IdM à partir d'un fichier JSON en utilisant les playbooks Ansible

La procédure suivante décrit comment assurer la présence de plusieurs utilisateurs dans IdM à l'aide d'un playbook Ansible. Les utilisateurs sont stockés dans un fichier JSON.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créez un fichier playbook Ansible avec les tâches nécessaires. Référencez le fichier JSON avec les données des utilisateurs dont vous voulez assurer la présence. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml:

    ---
    - name: Ensure users' presence
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users: "{{ users }}"
  3. Créez le fichier users.json et ajoutez-y les utilisateurs IdM. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple du fichier /usr/share/doc/ansible-freeipa/playbooks/user/users.json. Par exemple, pour créer les utilisateurs idm_user_1, idm_user_2, et idm_user_3, et ajouter Password123 comme mot de passe de idm_user_1:

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

Verification steps

  • Vous pouvez vérifier si les comptes d'utilisateurs sont présents dans IdM à l'aide de la commande ipa user-show:

    1. Connectez-vous à ipaserver en tant qu'administrateur :

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Afficher des informations sur idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    L'utilisateur nommé idm_user_1 est présent dans IdM.

4.5. Assurer l'absence d'utilisateurs utilisant des playbooks Ansible

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer que des utilisateurs spécifiques sont absents de l'IdM.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créez un fichier playbook Ansible avec les utilisateurs dont vous voulez garantir l'absence d'IdM. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Par exemple, pour supprimer les utilisateurs idm_user_1, idm_user_2, et idm_user_3:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

Verification steps

Vous pouvez vérifier que les comptes d'utilisateurs n'existent pas dans IdM en utilisant la commande ipa user-show:

  1. Connectez-vous à ipaserver en tant qu'administrateur :

    $ ssh administrator@server.idm.example.com
    Password:
    [admin@server /]$
  2. Demande d'informations sur idm_user_1:

    $ ipa user-show idm_user_1
    ipa: ERROR: idm_user_1: user not found

    L'utilisateur nommé idm_user_1 n'existe pas dans IdM.

4.6. Ressources supplémentaires

  • Voir le fichier Markdown de README-user.md dans le répertoire /usr/share/doc/ansible-freeipa/.
  • Voir les exemples de playbooks Ansible dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/user.

Chapitre 5. Gestion des mots de passe des utilisateurs dans l'IdM

5.1. Qui peut modifier les mots de passe des utilisateurs de l'IdM et comment ?

Les utilisateurs réguliers qui ne sont pas autorisés à modifier les mots de passe d'autres utilisateurs ne peuvent modifier que leur propre mot de passe. Le nouveau mot de passe doit être conforme aux politiques de mot de passe de l'IdM applicables aux groupes dont l'utilisateur est membre. Pour plus de détails sur la configuration des politiques de mot de passe, voir Définir les politiques de mot de passe de l'IdM.

Les administrateurs et les utilisateurs ayant le droit de modifier les mots de passe peuvent définir des mots de passe initiaux pour les nouveaux utilisateurs et réinitialiser les mots de passe des utilisateurs existants. Ces mots de passe :

Note

L'utilisateur du LDAP Directory Manager (DM) peut modifier les mots de passe des utilisateurs à l'aide des outils LDAP. Le nouveau mot de passe peut remplacer toute politique de mot de passe de l'IdM. Les mots de passe définis par DM n'expirent pas après la première connexion.

5.2. Modification du mot de passe de l'utilisateur dans l'interface Web de l'IdM

En tant qu'utilisateur de la gestion des identités (IdM), vous pouvez modifier votre mot de passe d'utilisateur dans l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Dans le coin supérieur droit, cliquez sur User name → Change password.

    Figure 5.1. Réinitialisation du mot de passe

    user change own pwd
  2. Saisissez le mot de passe actuel et le nouveau mot de passe.

5.3. Réinitialisation du mot de passe d'un autre utilisateur dans l'interface Web IdM

En tant qu'utilisateur administratif de Identity Management (IdM), vous pouvez modifier les mots de passe d'autres utilisateurs dans l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM en tant qu'utilisateur administratif.

Procédure

  1. Sélectionner IdentitéUsers.
  2. Cliquez sur le nom de l'utilisateur à modifier.
  3. Cliquez sur ActionsReset password.

    Figure 5.2. Réinitialisation du mot de passe

    pwd reset1
  4. Saisissez le nouveau mot de passe et cliquez sur Réinitialiser le mot de passe.

    Figure 5.3. Confirmation du nouveau mot de passe

    pwd reset2

5.4. Réinitialisation du mot de passe de l'utilisateur du gestionnaire de répertoire

Si vous perdez le mot de passe de l'Identity Management (IdM) Directory Manager, vous pouvez le réinitialiser.

Conditions préalables

  • Vous avez un accès root à un serveur IdM.

Procédure

  1. Générez un nouveau hachage de mot de passe à l'aide de la commande pwdhash. Par exemple :

    # pwdhash -D /etc/dirsrv/slapd-IDM-EXAMPLE-COM password
    {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...

    En spécifiant le chemin d'accès à la configuration du serveur d'annuaire, vous utilisez automatiquement le schéma de stockage du mot de passe défini dans l'attribut nsslapd-rootpwstoragescheme pour crypter le nouveau mot de passe.

  2. Sur chaque serveur IdM de votre topologie, exécutez les étapes suivantes :

    1. Arrêter tous les services IdM installés sur le serveur :

      # ipactl stop
    2. Modifiez le fichier /etc/dirsrv/IDM-EXAMPLE-COM/dse.ldif et attribuez à l'attribut nsslapd-rootpw la valeur générée par la commande pwdhash:

      nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...
    3. Démarrer tous les services IdM installés sur le serveur :
    # ipactl start

5.5. Modification du mot de passe de l'utilisateur ou réinitialisation du mot de passe d'un autre utilisateur dans l'interface CLI de l'IdM

Vous pouvez modifier votre mot de passe utilisateur à l'aide de l'interface de ligne de commande (CLI) de la gestion des identités (IdM). Si vous êtes un utilisateur administratif, vous pouvez utiliser l'interface de ligne de commande pour réinitialiser le mot de passe d'un autre utilisateur.

Conditions préalables

  • Vous avez obtenu un ticket d'attribution de ticket (TGT) pour un utilisateur IdM.
  • Si vous réinitialisez le mot de passe d'un autre utilisateur, vous devez avoir obtenu un TGT pour un utilisateur administratif dans IdM.

Procédure

  • Entrez la commande ipa user-mod avec le nom de l'utilisateur et l'option --password. La commande vous demandera le nouveau mot de passe.

    $ ipa user-mod idm_user --password
    Password:
    Enter Password again to verify:
    --------------------
    Modified user "idm_user"
    --------------------
    ...
Note

Vous pouvez également utiliser la commande ipa passwd idm_user au lieu de ipa user-mod.

5.6. Permettre la réinitialisation du mot de passe dans l'IdM sans demander à l'utilisateur de changer de mot de passe lors de la prochaine connexion

Par défaut, lorsqu'un administrateur réinitialise le mot de passe d'un autre utilisateur, le mot de passe expire après la première connexion réussie. En tant que gestionnaire de l'annuaire IdM, vous pouvez spécifier les privilèges suivants pour les administrateurs IdM individuels :

  • Ils peuvent effectuer des opérations de changement de mot de passe sans exiger des utilisateurs qu'ils modifient leur mot de passe lors de leur première connexion.
  • Ils peuvent contourner la politique en matière de mots de passe de sorte qu'aucune force ou historique n'est appliquée.
Avertissement

Le contournement de la politique de mot de passe peut constituer une menace pour la sécurité. Faites preuve de prudence lorsque vous sélectionnez les utilisateurs auxquels vous accordez ces privilèges supplémentaires.

Conditions préalables

  • Vous connaissez le mot de passe du gestionnaire de répertoire.

Procédure

  1. Sur chaque serveur de gestion des identités (IdM) du domaine, effectuez les modifications suivantes :

    1. Entrez la commande ldapmodify pour modifier les entrées LDAP. Indiquez le nom du serveur IdM et le port 389, puis appuyez sur Entrée :

      $ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
      Enter LDAP Password:
    2. Saisissez le mot de passe du gestionnaire de répertoire.
    3. Saisissez le nom distinctif de l'entrée de synchronisation du mot de passe ipa_pwd_extop et appuyez sur Entrée :

      dn : cn=ipa_pwd_extop,cn=plugins,cn=config
    4. Spécifiez le type de modification modify et appuyez sur Entrée :

      changetype : modify
    5. Indiquez le type de modification que vous souhaitez que LDAP exécute et à quel attribut. Appuyez sur Entrée :

      ajouter : passSyncManagersDNs
    6. Spécifiez les comptes d'utilisateurs administratifs dans l'attribut passSyncManagersDNs. Cet attribut a plusieurs valeurs. Par exemple, pour accorder à l'utilisateur admin les pouvoirs de réinitialisation du mot de passe de Directory Manager :

      passSyncManagersDNs: \
      uid=admin,cn=users,cn=accounts,dc=example,dc=com
    7. Appuyez deux fois sur Enter pour arrêter la modification de l'entrée.

L'ensemble de la procédure se déroule comme suit :

$ ldapmodify -x -D "cn=Directory Manager" -W -h server.idm.example.com -p 389
Enter LDAP Password:
dn: cn=ipa_pwd_extop,cn=plugins,cn=config
changetype: modify
add: passSyncManagersDNs
passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=example,dc=com

L'utilisateur admin, répertorié sous passSyncManagerDNs, dispose désormais de privilèges supplémentaires.

5.7. Vérifier si le compte d'un utilisateur IdM est verrouillé

En tant qu'administrateur de la gestion des identités (IdM), vous pouvez vérifier si le compte d'un utilisateur IdM est verrouillé. Pour ce faire, vous devez comparer le nombre maximal autorisé de tentatives de connexion infructueuses d'un utilisateur avec le nombre de connexions infructueuses réelles de l'utilisateur.

Conditions préalables

  • Vous avez obtenu le ticket d'attribution de ticket (TGT) d'un utilisateur administratif dans IdM.

Procédure

  1. Affichez le statut du compte utilisateur pour connaître le nombre d'échecs de connexion :

    $ ipa user-status example_user
    -----------------------
    Account disabled: False
    -----------------------
      Server: idm.example.com
      Failed logins: 8
      Last successful authentication: N/A
      Last failed authentication: 20220229080317Z
      Time now: 2022-02-29T08:04:46Z
    ----------------------------
    Number of entries returned 1
    ----------------------------
  2. Affiche le nombre de tentatives de connexion autorisées pour un utilisateur donné :

    1. Se connecter à l'interface Web IdM en tant qu'administrateur IdM.
    2. Ouvrez l'onglet Identity → Users → Active users.

    Capture d'écran de l'interface Web IdM affichant la page "Utilisateurs actifs", qui est une sous-page du sous-menu "Utilisateurs" de l'onglet "Identité".

    1. Cliquez sur le nom de l'utilisateur pour ouvrir les paramètres de l'utilisateur.
    2. Dans la section Password policy, localisez l'élément Max failures.
  3. Comparez le nombre d'échecs de connexion affiché dans la sortie de la commande ipa user-status avec le nombre de Max failures affiché dans l'interface Web de l'IdM. Si le nombre d'échecs de connexion est égal au nombre maximum de tentatives de connexion autorisées, le compte de l'utilisateur est verrouillé.

5.8. Déverrouillage des comptes d'utilisateurs en cas d'échec du mot de passe dans l'IdM

Si un utilisateur tente de se connecter en utilisant un mot de passe incorrect un certain nombre de fois, la gestion des identités (IdM) verrouille le compte de l'utilisateur, ce qui l'empêche de se connecter. Pour des raisons de sécurité, l'IdM n'affiche aucun message d'avertissement indiquant que le compte de l'utilisateur a été verrouillé. Au lieu de cela, l'invite CLI peut continuer à demander à l'utilisateur un mot de passe encore et encore.

L'IdM déverrouille automatiquement le compte d'utilisateur après un certain temps. Vous pouvez également déverrouiller le compte d'utilisateur manuellement en suivant la procédure suivante.

Conditions préalables

  • Vous avez obtenu le ticket d'attribution de ticket d'un utilisateur administratif de l'IdM.

Procédure

  • Pour déverrouiller un compte d'utilisateur, utilisez la commande ipa user-unlock.

    $ ipa user-unlock idm_user
    -----------------------
    Unlocked account "idm_user"
    -----------------------

    L'utilisateur peut ensuite se reconnecter.

5.9. Activation du suivi de la dernière authentification Kerberos réussie pour les utilisateurs dans IdM

Pour des raisons de performance, Identity Management (IdM) fonctionnant dans Red Hat Enterprise Linux 8 ne stocke pas l'horodatage de la dernière authentification Kerberos réussie d'un utilisateur. Par conséquent, certaines commandes, telles que ipa user-status, n'affichent pas l'horodatage.

Conditions préalables

  • Vous avez obtenu le ticket d'attribution de ticket (TGT) d'un utilisateur administratif dans IdM.
  • Vous avez un accès root au serveur IdM sur lequel vous exécutez la procédure.

Procédure

  1. Affiche les fonctions du plug-in de mot de passe actuellement activées :

    # ipa config-show | grep "Password plugin features"
      Password plugin features: AllowNThash, KDC:Disable Last Success

    La sortie montre que le plug-in KDC:Disable Last Success est activé. Le plug-in masque la dernière tentative d'authentification Kerberos réussie dans la sortie ipa user-status.

  2. Ajouter le paramètre --ipaconfigstring=feature le paramètre pour chaque fonctionnalité de la commande ipa config-mod actuellement activée, à l'exception de KDC:Disable Last Success:

    # ipa config-mod --ipaconfigstring='AllowNThash'

    Cette commande n'active que le plug-in AllowNThash. Pour activer plusieurs fonctionnalités, spécifiez le paramètre --ipaconfigstring=feature séparément pour chaque fonctionnalité.

  3. Redémarrer IdM :

    # ipactl restart

Chapitre 6. Définition des politiques de mot de passe de l'IdM

Ce chapitre décrit les politiques de mot de passe de la gestion des identités (IdM) et explique comment ajouter une nouvelle politique de mot de passe dans l'IdM à l'aide d'un playbook Ansible.

6.1. Qu'est-ce qu'une politique de mot de passe ?

Une politique de mot de passe est un ensemble de règles auxquelles les mots de passe doivent répondre. Par exemple, une politique de mot de passe peut définir la longueur minimale et la durée maximale d'un mot de passe. Tous les utilisateurs concernés par cette politique sont tenus de définir un mot de passe suffisamment long et de le modifier assez fréquemment pour satisfaire aux conditions spécifiées. De cette manière, les politiques de mot de passe contribuent à réduire le risque que quelqu'un découvre et utilise à mauvais escient le mot de passe d'un utilisateur.

6.2. Politiques en matière de mots de passe dans l'IdM

Les mots de passe sont le moyen le plus courant pour les utilisateurs de la gestion de l'identité (IdM) de s'authentifier auprès du domaine Kerberos IdM. Les stratégies de mot de passe définissent les exigences auxquelles doivent répondre les mots de passe des utilisateurs IdM.

Note

La politique de mot de passe de l'IdM est définie dans l'annuaire LDAP sous-jacent, mais c'est le centre de distribution de clés Kerberos (KDC) qui applique la politique de mot de passe.

Les attributs de la politique de mot de passe énumèrent les attributs que vous pouvez utiliser pour définir une politique de mot de passe dans IdM.

Tableau 6.1. Attributs de la politique relative aux mots de passe

AttributExplicationExemple :

Durée de vie maximale

Durée maximale en jours pendant laquelle un mot de passe est valide avant que l'utilisateur ne doive le réinitialiser.

Durée de vie maximale = 90

Les mots de passe des utilisateurs ne sont valables que pendant 90 jours. Après cette période, l'IdM invite les utilisateurs à les modifier.

Durée de vie minimale

Le temps minimum en heures qui doit s'écouler entre deux opérations de changement de mot de passe.

Durée de vie minimale = 1

Après avoir modifié leur mot de passe, les utilisateurs doivent attendre au moins une heure avant de le modifier à nouveau.

Taille de l'histoire

Le nombre de mots de passe précédents qui sont stockés. Un utilisateur ne peut pas réutiliser un mot de passe de son historique de mots de passe, mais peut réutiliser d'anciens mots de passe qui ne sont pas stockés.

Taille de l'historique = 0

Dans ce cas, l'historique des mots de passe est vide et les utilisateurs peuvent réutiliser n'importe lequel de leurs mots de passe précédents.

Classes de personnages

Le nombre de classes de caractères différentes que l'utilisateur doit utiliser dans le mot de passe. Les classes de caractères sont les suivantes :

* Caractères majuscules

* Caractères minuscules

* Chiffres

* Caractères spéciaux, tels que virgule (,), point (.), astérisque (*)

* Autres caractères UTF-8

L'utilisation d'un caractère trois fois ou plus à la suite diminue la classe du caractère d'une unité. Par exemple :

* Secret1 a 3 classes de caractères : majuscules, minuscules, chiffres

* Secret111 a 2 classes de caractères : majuscules, minuscules, chiffres, et une pénalité de -1 pour l'utilisation répétée de 1

Classes de caractères = 0

Le nombre de classes requis par défaut est de 0. Pour configurer ce nombre, exécutez la commande ipa pwpolicy-mod avec l'option --minclasses.

Voir également la note importante sous ce tableau.

Longueur minimale

Nombre minimum de caractères dans un mot de passe.

Si l'une des options de politique de mot de passe supplémentaires est définie, la longueur minimale des mots de passe est de 6, quelle que soit la valeur de l'option Longueur min.

Longueur minimale = 8

Les utilisateurs ne peuvent pas utiliser de mots de passe de moins de 8 caractères.

Défaillances maximales

Nombre maximal de tentatives de connexion échouées avant que l'IdM ne verrouille le compte de l'utilisateur.

Nombre maximal d'échecs = 6

L'IdM verrouille le compte de l'utilisateur lorsque celui-ci saisit un mot de passe erroné sept fois de suite.

Intervalle de réinitialisation des défaillances

Délai en secondes après lequel l'IdM réinitialise le nombre actuel de tentatives de connexion infructueuses.

Intervalle de réinitialisation des défaillances = 60

Si l'utilisateur attend plus d'une minute après le nombre d'échecs de connexion défini à l'adresse Max failures, il peut tenter de se connecter à nouveau sans risquer de voir son compte bloqué.

Durée du verrouillage

Durée en secondes pendant laquelle le compte de l'utilisateur est verrouillé après le nombre de tentatives de connexion infructueuses défini à l'adresse Max failures.

Durée du verrouillage = 600

Les utilisateurs dont le compte est verrouillé ne peuvent pas se connecter pendant 10 minutes.

Important

Utilisez l'alphabet anglais et les symboles courants pour les classes de caractères requises si vous disposez d'un ensemble diversifié de matériel qui peut ne pas avoir accès aux caractères et symboles internationaux. Pour plus d'informations sur les politiques de classes de caractères dans les mots de passe, voir Quels sont les caractères valides dans un mot de passe ? dans la base de connaissances de Red Hat.

6.3. Assurer la présence d'une politique de mot de passe dans IdM à l'aide d'un playbook Ansible

Cette section décrit comment assurer la présence d'une politique de mot de passe dans la gestion des identités (IdM) à l'aide d'un playbook Ansible.

Dans la politique de mot de passe global_policy par défaut dans IdM, le nombre de classes de caractères différents dans le mot de passe est fixé à 0. La taille de l'historique est également fixée à 0.

Effectuez cette procédure pour appliquer une politique de mot de passe plus stricte pour un groupe IdM à l'aide d'un playbook Ansible.

Note

Vous ne pouvez définir une politique de mot de passe que pour un groupe IdM. Vous ne pouvez pas définir une politique de mot de passe pour un utilisateur individuel.

Conditions préalables

  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Le groupe pour lequel vous vous assurez de la présence d'une politique de mot de passe existe dans IdM.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez le FQDN de votre serveur IdM dans la section [ipaserver]:

    [ipaserver]
    server.idm.example.com
  2. Créez votre fichier playbook Ansible qui définit la politique de mot de passe dont vous voulez assurer la présence. Pour simplifier cette étape, copiez et modifiez l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml:

    ---
    - name: Tests
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    Pour plus de détails sur la signification des différentes variables, voir Attributs de la politique de mot de passe.

  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Vous avez utilisé avec succès un playbook Ansible pour vous assurer qu'une politique de mot de passe pour le groupe ops est présente dans IdM.

Important

La priorité de la politique de mot de passe ops est fixée à 1, alors que la politique de mot de passe global_policy n'a pas de priorité définie. Pour cette raison, la politique ops remplace automatiquement global_policy pour le groupe ops et est appliquée immédiatement.

global_policy sert de stratégie de repli lorsqu'aucune stratégie de groupe n'est définie pour un utilisateur, et ne peut jamais avoir la priorité sur une stratégie de groupe.

Ressources supplémentaires

6.4. Options supplémentaires de politique de mot de passe dans IdM

En tant qu'administrateur Identity Management (IdM), vous pouvez renforcer les exigences en matière de mot de passe par défaut en activant des options de politique de mot de passe supplémentaires basées sur l'ensemble des fonctionnalités de libpwquality. Les options supplémentaires de stratégie de mot de passe sont les suivantes :

--maxrepeat
Spécifie le nombre maximal acceptable de caractères consécutifs identiques dans le nouveau mot de passe.
--maxsequence
Spécifie la longueur maximale des séquences de caractères monotones dans le nouveau mot de passe. Des exemples d'une telle séquence sont 12345 ou fedcb. La plupart de ces mots de passe ne passeront pas le contrôle de simplicité.
--dictcheck
Si non nul, vérifie si le mot de passe, avec d'éventuelles modifications, correspond à un mot du dictionnaire. Actuellement, libpwquality effectue la vérification du dictionnaire à l'aide de la bibliothèque cracklib.
--usercheck
S'il est différent de zéro, il vérifie si le mot de passe, avec d'éventuelles modifications, contient le nom de l'utilisateur sous une forme ou une autre. Cette vérification n'est pas effectuée pour les noms d'utilisateur de moins de 3 caractères.

Vous ne pouvez pas appliquer les options supplémentaires de politique de mot de passe aux mots de passe existants. Si vous appliquez l'une des options supplémentaires, l'IdM définit automatiquement l'option --minlength, le nombre minimum de caractères dans un mot de passe, à 6 caractères.

Note

Dans un environnement mixte avec des serveurs RHEL 7, RHEL 8 et RHEL 9, vous pouvez appliquer les paramètres supplémentaires de la stratégie de mot de passe uniquement sur les serveurs fonctionnant sous RHEL 8.4 ou une version ultérieure. Si un utilisateur est connecté à un client IdM et que ce dernier communique avec un serveur IdM fonctionnant sous RHEL 8.3 ou une version antérieure, les nouvelles exigences en matière de stratégie de mot de passe définies par l'administrateur système ne seront pas appliquées. Pour garantir un comportement cohérent, mettez à niveau ou mettez à jour tous les serveurs vers RHEL 8.4 ou une version ultérieure.

Ressources complémentaires :

6.5. Appliquer des options supplémentaires de politique de mot de passe à un groupe IdM

Cette section décrit comment appliquer des options supplémentaires de politique de mot de passe dans la gestion des identités (IdM). L'exemple décrit comment renforcer la politique de mot de passe pour le groupe managers en s'assurant que les nouveaux mots de passe ne contiennent pas les noms d'utilisateur respectifs des utilisateurs et que les mots de passe ne contiennent pas plus de deux caractères identiques à la suite.

Conditions préalables

  • Vous êtes connecté en tant qu'administrateur IdM.
  • Le groupe managers existe dans IdM.
  • La politique de mot de passe managers existe dans IdM.

Procédure

  1. Appliquer le contrôle du nom d'utilisateur à tous les nouveaux mots de passe proposés par les utilisateurs du groupe managers:

    $ ipa pwpolicy-mod --usercheck=True managers
    Note

    Si vous ne spécifiez pas le nom de la politique de mot de passe, la valeur par défaut global_policy est modifiée.

  2. Définissez le nombre maximum de caractères identiques consécutifs à 2 dans la politique de mot de passe managers:

    $ ipa pwpolicy-mod --maxrepeat=2 managers

    Un mot de passe ne sera pas accepté s'il contient plus de 2 caractères identiques consécutifs. Par exemple, la combinaison eR873mUi111YJQ est inacceptable parce qu'elle contient trois 1consécutifs.

Vérification

  1. Ajouter un utilisateur test nommé test_user:

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. Ajoutez l'utilisateur test au groupe managers:

    1. Dans l'interface Web IdM, cliquez sur IdentitéGroupesGroupes d'utilisateurs.
    2. Cliquez sur managers.
    3. Cliquez sur Add.
    4. Dans la page Add users into user group 'managers', vérifiez test_user.
    5. Cliquez sur la flèche > pour déplacer l'utilisateur dans la colonne Prospective.
    6. Cliquez sur Add.
  3. Réinitialiser le mot de passe de l'utilisateur test :

    1. Aller à IdentitéUtilisateurs.
    2. Cliquez sur test_user.
    3. Dans le menu Actions, cliquez sur Reset Password.
    4. Entrez un mot de passe temporaire pour l'utilisateur.
  4. Sur la ligne de commande, essayez d'obtenir un ticket Kerberos (TGT) pour l'adresse test_user:

    $ kinit test_user
    1. Saisissez le mot de passe temporaire.
    2. Le système vous informe que vous devez modifier votre mot de passe. Saisissez un mot de passe qui contient le nom d'utilisateur test_user:

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      Note

      Kerberos ne dispose pas d'une politique de signalement des erreurs de mot de passe très fine et, dans certains cas, ne fournit pas de raison claire pour laquelle un mot de passe a été rejeté.

    3. Le système vous informe que le mot de passe introduit a été rejeté. Introduisez un mot de passe contenant au moins trois caractères identiques successifs :

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    4. Le système vous informe que le mot de passe introduit a été rejeté. Saisissez un mot de passe qui répond aux critères de la politique de mot de passe managers:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
  5. Voir le TGT :

    $ klist
    Ticket cache: KCM:0:33945
    Default principal: test_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

La politique de mot de passe managers fonctionne désormais correctement pour les utilisateurs du groupe managers.

6.6. Utilisation d'un playbook Ansible pour appliquer des options de politique de mot de passe supplémentaires à un groupe IdM

Vous pouvez utiliser un playbook Ansible pour appliquer des options de politique de mot de passe supplémentaires afin de renforcer les exigences de la politique de mot de passe pour un groupe IdM spécifique. Vous pouvez utiliser les options de politique de mot de passe maxrepeat, maxsequence, dictcheck et usercheck à cette fin. L'exemple décrit comment définir les exigences suivantes pour le groupe managers:

  • Les nouveaux mots de passe des utilisateurs ne contiennent pas leurs noms d'utilisateur respectifs.
  • Les mots de passe ne contiennent pas plus de deux caractères identiques successifs.
  • Les séquences de caractères monotones dans les mots de passe ne doivent pas dépasser 3 caractères. Cela signifie que le système n'accepte pas un mot de passe comportant une séquence telle que 1234 ou abcd.

Conditions préalables

  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • Vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM dans le répertoire ~/MyPlaybooks/ dans le répertoire
    • Vous avez stocké votre site ipaadmin_password dans le coffre-fort secret.yml Ansible.
  • Le groupe pour lequel vous vous assurez de la présence d'une politique de mot de passe existe dans IdM.

Procédure

  1. Créez votre fichier Ansible playbook manager_pwpolicy_present.yml qui définit la politique de mot de passe dont vous voulez assurer la présence. Pour simplifier cette étape, copiez et modifiez l'exemple suivant :

    ---
    - name: Tests
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure presence of usercheck and maxrepeat pwpolicy for group managers
        ipapwpolicy:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: managers
          usercheck: True
          maxrepeat: 2
          maxsequence: 3
  2. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/manager_pwpolicy_present.yml

Vérification

  1. Ajouter un utilisateur test nommé test_user:

    $ ipa user-add test_user
    First name: test
    Last name: user
    ----------------------------
    Added user "test_user"
    ----------------------------
  2. Ajoutez l'utilisateur test au groupe managers:

    1. Dans l'interface Web IdM, cliquez sur IdentitéGroupesGroupes d'utilisateurs.
    2. Cliquez sur managers.
    3. Cliquez sur Add.
    4. Dans la page Add users into user group 'managers', vérifiez test_user.
    5. Cliquez sur la flèche > pour déplacer l'utilisateur dans la colonne Prospective.
    6. Cliquez sur Add.
  3. Réinitialiser le mot de passe de l'utilisateur test :

    1. Aller à IdentitéUtilisateurs.
    2. Cliquez sur test_user.
    3. Dans le menu Actions, cliquez sur Reset Password.
    4. Entrez un mot de passe temporaire pour l'utilisateur.
  4. Sur la ligne de commande, essayez d'obtenir un ticket Kerberos (TGT) pour l'adresse test_user:

    $ kinit test_user
    1. Saisissez le mot de passe temporaire.
    2. Le système vous informe que vous devez modifier votre mot de passe. Saisissez un mot de passe qui contient le nom d'utilisateur test_user:

      Password expired. You must change it now.
      Enter new password:
      Enter it again:
      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      Note

      Kerberos ne dispose pas d'une politique de signalement des erreurs de mot de passe très fine et, dans certains cas, ne fournit pas de raison claire pour laquelle un mot de passe a été rejeté.

    3. Le système vous informe que le mot de passe introduit a été rejeté. Introduisez un mot de passe contenant au moins trois caractères identiques successifs :

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    4. Le système vous informe que le mot de passe saisi a été rejeté. Introduisez un mot de passe qui contient une séquence de caractères monotone de plus de 3 caractères. Des exemples de telles séquences sont 1234 et fedc:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
    5. Le système vous informe que le mot de passe introduit a été rejeté. Saisissez un mot de passe qui répond aux critères de la politique de mot de passe managers:

      Password change rejected: Password not changed.
      Unspecified password quality failure while trying to change password.
      Please try again.
      
      Enter new password:
      Enter it again:
  5. Vérifiez que vous avez obtenu un TGT, ce qui n'est possible qu'après avoir introduit un mot de passe valide :

    $ klist
    Ticket cache: KCM:0:33945
    Default principal: test_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    07/07/2021 12:44:44  07/08/2021 12:44:44  krbtgt@IDM.EXAMPLE.COM@IDM.EXAMPLE.COM

Ressources supplémentaires

Chapitre 7. Gestion des notifications d'expiration de mot de passe

Vous pouvez utiliser l'outil EPN (Expiring Password Notification), fourni par le paquetage ipa-client-epn, pour établir une liste des utilisateurs de la gestion des identités (IdM) dont les mots de passe expirent dans un laps de temps configuré. Pour installer, configurer et utiliser l'outil EPN, reportez-vous aux sections correspondantes.

7.1. Qu'est-ce que l'outil de notification d'expiration du mot de passe ?

L'outil EPN (Expiring Password Notification) est un outil autonome qui permet de dresser une liste des utilisateurs de la gestion des identités (IdM) dont les mots de passe expirent dans un laps de temps donné.

Les administrateurs IdM peuvent utiliser l'EPN pour :

  • Affiche une liste des utilisateurs concernés au format JSON, qui est créée lors de l'exécution en mode "dry-run".
  • Calculez le nombre d'e-mails qui seront envoyés pour un jour ou une période donnés.
  • Envoyer aux utilisateurs des notifications par courrier électronique concernant l'expiration du mot de passe.
  • Configurez le site ipa-epn.timer pour qu'il exécute quotidiennement l'outil EPN et envoie un courrier électronique aux utilisateurs dont les mots de passe expirent dans les plages de dates futures définies.
  • Personnaliser la notification par courriel à envoyer aux utilisateurs.
Note

Si un compte d'utilisateur est désactivé, aucune notification par courrier électronique n'est envoyée si le mot de passe est sur le point d'expirer.

7.2. Installation de l'outil de notification d'expiration de mot de passe

Cette procédure décrit comment installer l'outil EPN (Expiring Password Notification).

Conditions préalables

  • Installez l'outil EPN sur un réplica Identity Management (IdM) ou un client IdM avec un serveur Postfix SMTP local configuré en tant qu'hôte intelligent.

Procédure

  • Installer l'outil EPN :

    # dnf install ipa-client-epn

7.3. Exécution de l'outil EPN pour envoyer des courriels aux utilisateurs dont les mots de passe arrivent à expiration

Cette procédure décrit comment exécuter l'outil EPN (Expiring Password Notification) pour envoyer des courriels aux utilisateurs dont le mot de passe arrive à expiration.

Note

L'outil EPN est sans état. Si l'outil EPN n'envoie pas de courrier électronique aux utilisateurs dont les mots de passe expirent un jour donné, il n'enregistre pas la liste de ces utilisateurs.

Conditions préalables

Procédure

  1. Mettez à jour le fichier de configuration epn.conf pour définir les options permettant à l'outil EPN d'avertir les utilisateurs de l'expiration prochaine de leur mot de passe.

    # vi /etc/ipa/epn.conf
  2. Mettez à jour le site notify_ttls si nécessaire. Par défaut, les utilisateurs dont les mots de passe expirent dans 28, 14, 7, 3 et 1 jour(s) sont avertis.

    notify_ttls = 28, 14, 7, 3, 1
  3. Configurez votre serveur SMTP et votre port :

    smtp_server = localhost
    smtp_port = 25
  4. Indiquez l'adresse électronique à partir de laquelle la notification d'expiration du courrier électronique est envoyée. Les courriels non délivrés sont renvoyés à cette adresse.

    mail_from =admin-email@example.com
  5. Enregistrez le fichier /etc/ipa/epn.conf.
  6. Exécutez l'outil EPN en mode "dry-run" pour générer une liste des utilisateurs auxquels la notification par e-mail de l'expiration du mot de passe serait envoyée si vous exécutiez l'outil sans l'option --dry-run.

    ipa-epn --dry-run
    [
        {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-04-17 15:51:53",
         "mail": "['user5@ipa.test']"
        }
    ]
    [
        {
         "uid": "user6",
         "cn": "user 6",
         "krbpasswordexpiration": "2020-12-17 15:51:53",
         "mail": "['user5@ipa.test']"
         }
    ]
    The IPA-EPN command was successful
    Note

    Si la liste des utilisateurs renvoyée est très importante et que vous exécutez l'outil sans l'option --dry-run, cela peut entraîner un problème avec votre serveur de messagerie.

  7. Exécutez l'outil EPN sans l'option --dry-run pour envoyer des courriels d'expiration à la liste de tous les utilisateurs renvoyés lorsque vous avez exécuté l'outil EPN en mode "dry run" :

    ipa-epn
    [
      {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-10-01 15:51:53",
         "mail": "['user5@ipa.test']"
      }
    ]
    [
      {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
      }
    ]
    The IPA-EPN command was successful
  8. Vous pouvez ajouter EPN à n'importe quel système de surveillance et l'invoquer avec les options --from-nbdays et --to-nbdays pour déterminer combien de mots de passe d'utilisateurs vont expirer dans un délai spécifique :

    # ipa-epn --from-nbdays 8 --to-nbdays 12
    Note

    Si vous invoquez l'outil EPN avec les options --from-nbdays et --to-nbdays, il est automatiquement exécuté en mode "dry-run".

Verification steps

  • Exécutez l'outil EPN et vérifiez qu'une notification par courrier électronique est envoyée.

Ressources supplémentaires

  • Voir la page de manuel ipa-epn.
  • Voir la page de manuel epn.conf.

7.4. Permettre à ipa-epn.timer d'envoyer un courrier électronique à tous les utilisateurs dont le mot de passe arrive à expiration

Cette procédure décrit comment utiliser ipa-epn.timer pour exécuter l'outil Expiring Password Notification (EPN) afin d'envoyer des courriels aux utilisateurs dont les mots de passe expirent. Le site ipa-epn.timer analyse le fichier epn.conf et envoie un courrier électronique aux utilisateurs dont les mots de passe expirent dans les plages de dates futures définies dans ce fichier.

Conditions préalables

Procédure

  • Démarrer le site ipa-epn.timer:

    systemctl start ipa-epn.timer

Une fois que vous avez lancé la minuterie, l'outil EPN est exécuté par défaut tous les jours à 1 heure du matin.

Ressources supplémentaires

  • Voir la page de manuel ipa-epn.

7.5. Modification du modèle de courriel de notification d'expiration du mot de passe

Cette procédure décrit comment personnaliser le modèle de message électronique EPN (Expiring Password Notification).

Conditions préalables

  • Le paquet ipa-client-epn est installé.

Procédure

  1. Ouvrez le modèle de message EPN :

    # vi /etc/ipa/epn/expire_msg.template
  2. Mettez à jour le texte du modèle si nécessaire.

    Hi {{ fullname }},
    
    Your password will expire on {{ expiration }}.
    
    Please change it as soon as possible.

    Vous pouvez utiliser les variables suivantes dans le modèle.

    • Identifiant de l'utilisateur : uid
    • Nom complet : nom complet
    • Prénom : prénom
    • Nom de famille : nom
    • Date d'expiration du mot de passe : expiration
  3. Sauvegarder le fichier du modèle de message.

Verification steps

  • Exécutez l'outil EPN et vérifiez que la notification par courrier électronique contient le texte mis à jour.

Ressources supplémentaires

  • Voir la page de manuel ipa-epn.

Chapitre 8. Accorder un accès sudo à un utilisateur IdM sur un client IdM

Cette section décrit comment accorder l'accès sudo aux utilisateurs dans la gestion des identités.

8.1. Accès Sudo sur un client IdM

Les administrateurs système peuvent accorder l'accès sudo pour permettre aux utilisateurs non root d'exécuter des commandes administratives qui sont normalement réservées à l'utilisateur root. Par conséquent, lorsque les utilisateurs doivent exécuter une commande administrative normalement réservée à l'utilisateur root, ils font précéder cette commande de sudo. Après avoir introduit son mot de passe, la commande est exécutée comme s'il s'agissait de l'utilisateur root. Pour exécuter une commande sudo en tant qu'autre utilisateur ou groupe, tel qu'un compte de service de base de données, vous pouvez configurer une règle RunAs alias pour sudo.

Si un hôte Red Hat Enterprise Linux (RHEL) 8 est inscrit en tant que client Identity Management (IdM), vous pouvez spécifier les règles sudo définissant quels utilisateurs IdM peuvent exécuter quelles commandes sur l'hôte de la manière suivante :

  • Localement dans le fichier /etc/sudoers
  • Au niveau central dans l'IdM

Cette section décrit la création d'un central sudo rule pour un client IdM à l'aide de l'interface de ligne de commande (CLI) et de l'interface Web IdM.

Vous pouvez également configurer l'authentification sans mot de passe pour sudo à l'aide de l'interface GSSAPI (Generic Security Service Application Programming Interface), le moyen natif pour les systèmes d'exploitation basés sur UNIX d'accéder aux services Kerberos et de les authentifier. Vous pouvez utiliser pam_sss_gss.so Pluggable Authentication Module (PAM) pour invoquer l'authentification GSSAPI via le service SSSD, ce qui permet aux utilisateurs de s'authentifier auprès de la commande sudo à l'aide d'un ticket Kerberos valide.

Ressources supplémentaires

8.2. Accorder un accès sudo à un utilisateur IdM sur un client IdM à l'aide de la CLI

Dans la gestion des identités (IdM), vous pouvez accorder l'accès sudo pour une commande spécifique à un compte d'utilisateur IdM sur un hôte IdM spécifique. Commencez par ajouter une commande sudo, puis créez une règle sudo pour une ou plusieurs commandes.

Par exemple, suivez cette procédure pour créer la règle idm_user_reboot sudo afin d'autoriser le compte idm_user à exécuter la commande /usr/sbin/reboot sur la machine idmclient.

Conditions préalables

  • Vous êtes connecté en tant qu'administrateur IdM.
  • Vous avez créé un compte utilisateur pour idm_user dans IdM et déverrouillé le compte en créant un mot de passe pour l'utilisateur. Pour plus d'informations sur l'ajout d'un nouvel utilisateur IdM à l'aide de la ligne de commande, voir Ajouter des utilisateurs à l'aide de la ligne de commande.
  • Aucun compte local idm_user n'est présent sur l'hôte idmclient. L'utilisateur idm_user n'est pas répertorié dans le fichier local /etc/passwd.

Procédure

  1. Récupérer un ticket Kerberos en tant qu'IdM admin.

    [root@idmclient ~]# kinit admin
  2. Ajouter la commande /usr/sbin/reboot à la base de données IdM des commandes sudo:

    [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
    -------------------------------------
    Added Sudo Command "/usr/sbin/reboot"
    -------------------------------------
      Sudo Command: /usr/sbin/reboot
  3. Créez une règle sudo nommée idm_user_reboot:

    [root@idmclient ~]# ipa sudorule-add idm_user_reboot
    ---------------------------------
    Added Sudo Rule "idm_user_reboot"
    ---------------------------------
      Rule name: idm_user_reboot
      Enabled: TRUE
  4. Ajoutez la commande /usr/sbin/reboot à la règle idm_user_reboot:

    [root@idmclient ~]# ipa sudorule-add-allow-command idm_user_reboot --sudocmds '/usr/sbin/reboot'
      Rule name: idm_user_reboot
      Enabled: TRUE
      Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  5. Appliquer la règle idm_user_reboot à l'hôte IdM idmclient:

    [root@idmclient ~]# ipa sudorule-add-host idm_user_reboot --hosts idmclient.idm.example.com
    Rule name: idm_user_reboot
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  6. Ajoutez le compte idm_user à la règle idm_user_reboot:

    [root@idmclient ~]# ipa sudorule-add-user idm_user_reboot --users idm_user
    Rule name: idm_user_reboot
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /usr/sbin/reboot
    -------------------------
    Number of members added 1
    -------------------------
  7. Il est possible de définir la validité de la règle idm_user_reboot:

    1. Pour définir l'heure à laquelle une règle sudo commence à être valide, utilisez la commande ipa sudorule-mod sudo_rule_name avec l'option --setattr sudonotbefore=DATE option. La valeur de DATE doit suivre le format de yyyymmddHHMMSSZ, en spécifiant explicitement les secondes. Par exemple, pour définir le début de la validité de la règle idm_user_reboot au 31 décembre 2025 12:34:00, entrez :

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotbefore=20251231123400Z
    2. Pour définir l'heure à laquelle une règle sudo cesse d'être valide, utilisez l'option --setattr sudonotafter=DATE. Par exemple, pour fixer la fin de la validité de la règle idm_user_reboot au 31 décembre 2026 12:34:00, entrez :

      [root@idmclient ~]# ipa sudorule-mod idm_user_reboot --setattr sudonotafter=20261231123400Z
Note

La propagation des changements du serveur au client peut prendre quelques minutes.

Verification steps

  1. Connectez-vous à l'hôte idmclient en tant que compte idm_user.
  2. Affiche les règles sudo que le compte idm_user est autorisé à appliquer.

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idm_user on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  3. Redémarrez la machine en utilisant sudo. Saisissez le mot de passe de idm_user lorsque vous y êtes invité :

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

8.3. Accorder un accès sudo à un utilisateur AD sur un client IdM à l'aide de la CLI

Les administrateurs du système de gestion des identités (IdM) peuvent utiliser les groupes d'utilisateurs IdM pour définir les autorisations d'accès, le contrôle d'accès basé sur l'hôte, les règles sudo et d'autres contrôles sur les utilisateurs IdM. Les groupes d'utilisateurs IdM accordent et restreignent l'accès aux ressources du domaine IdM.

Vous pouvez ajouter à la fois Active Directory (AD) users et AD groups aux groupes d'utilisateurs IdM. Pour ce faire, procédez comme suit

  1. Ajouter les utilisateurs ou groupes AD à un groupe IdM externe non-POSIX.
  2. Ajouter le groupe IdM externe non-POSIX à un groupe IdM POSIX.

Vous pouvez ensuite gérer les privilèges des utilisateurs AD en gérant les privilèges du groupe POSIX. Par exemple, vous pouvez accorder l'accès sudo pour une commande spécifique à un groupe d'utilisateurs POSIX IdM sur un hôte IdM spécifique.

Note

Il est également possible d'ajouter des groupes d'utilisateurs AD aux groupes externes IdM. Cela peut faciliter la définition de politiques pour les utilisateurs Windows, en maintenant la gestion des utilisateurs et des groupes dans le domaine unique d'AD.

Important

Ne not utilisez pas les ID overrides des utilisateurs AD pour les règles SUDO dans IdM. Les substitutions d'ID des utilisateurs AD ne représentent que les attributs POSIX des utilisateurs AD, et non les utilisateurs AD eux-mêmes.

Vous pouvez ajouter des dérogations d'ID en tant que membres d'un groupe. Toutefois, vous ne pouvez utiliser cette fonctionnalité que pour gérer les ressources IdM dans l'API IdM. La possibilité d'ajouter des dérogations d'ID en tant que membres d'un groupe n'est pas étendue aux environnements POSIX et vous ne pouvez donc pas l'utiliser pour l'appartenance à sudo ou à des règles de contrôle d'accès basées sur l'hôte (HBAC).

Cette procédure décrit comment créer la règle ad_users_reboot sudo pour accorder à l'utilisateur administrator@ad-domain.com AD la permission d'exécuter la commande /usr/sbin/reboot sur l'hôte idmclient IdM, qui est normalement réservée à l'utilisateur root. administrator@ad-domain.com est membre du groupe ad_users_external non-POSIX, qui est à son tour membre du groupe ad_users POSIX.

Conditions préalables

  • Vous avez obtenu l'IdM admin Kerberos ticket-granting ticket (TGT).
  • Une confiance inter-forêts existe entre le domaine IdM et le domaine AD ad-domain.com.
  • Aucun compte local administrator n'est présent sur l'hôte idmclient: l'utilisateur administrator n'est pas répertorié dans le fichier local /etc/passwd.

Procédure

  1. Créer le groupe ad_users qui contient le groupe ad_users_external avec le membre administrator@ad-domain:

    1. Optional: Créez ou sélectionnez un groupe correspondant dans le domaine AD à utiliser pour gérer les utilisateurs AD dans le domaine IdM. Vous pouvez utiliser plusieurs groupes AD et les ajouter à différents groupes du côté IdM.
    2. Créez le groupe ad_users_external et indiquer qu'il contient des membres extérieurs au domaine IdM en ajoutant l'option --external:

      [root@ipaserver ~]# ipa group-add --desc='AD users external map' ad_users_external --external
      -------------------------------
      Added group "ad_users_external"
      -------------------------------
        Group name: ad_users_external
        Description: AD users external map
      Note

      Assurez-vous que le groupe externe que vous spécifiez ici est un groupe de sécurité AD avec une portée de groupe global ou universal comme défini dans le document sur les groupes de sécurité Active Directory. Par exemple, les groupes de sécurité AD Domain users ou Domain admins ne peuvent pas être utilisés car leur périmètre de groupe est domain local.

    3. Créez le groupe ad_users:

      [root@ipaserver ~]# ipa group-add --desc='AD users' ad_users
      ----------------------
      Added group "ad_users"
      ----------------------
        Group name: ad_users
        Description: AD users
        GID: 129600004
    4. Ajoutez l'utilisateur AD administrator@ad-domain.com à ad_users_external en tant que membre externe :

      [root@ipaserver ~]# ipa group-add-member ad_users_external --external "administrator@ad-domain.com"
       [member user]:
       [member group]:
        Group name: ad_users_external
        Description: AD users external map
        External member: S-1-5-21-3655990580-1375374850-1633065477-513
      -------------------------
      Number of members added 1
      -------------------------

      L'utilisateur AD doit être identifié par un nom complet, tel que DOMAIN\user_name ou user_name@DOMAIN. L'identité AD est ensuite mappée au SID AD de l'utilisateur. Il en va de même pour l'ajout de groupes AD.

    5. Ajoutez ad_users_external à ad_users en tant que membre :

      [root@ipaserver ~]# ipa group-add-member ad_users --groups ad_users_external
        Group name: ad_users
        Description: AD users
        GID: 129600004
        Member groups: ad_users_external
      -------------------------
      Number of members added 1
      -------------------------
  2. Accordez aux membres de ad_users la permission d'exécuter /usr/sbin/reboot sur l'hôte idmclient:

    1. Ajouter la commande /usr/sbin/reboot à la base de données IdM des commandes sudo:

      [root@idmclient ~]# ipa sudocmd-add /usr/sbin/reboot
      -------------------------------------
      Added Sudo Command "/usr/sbin/reboot"
      -------------------------------------
        Sudo Command: /usr/sbin/reboot
    2. Créez une règle sudo nommée ad_users_reboot:

      [root@idmclient ~]# ipa sudorule-add ad_users_reboot
      ---------------------------------
      Added Sudo Rule "ad_users_reboot"
      ---------------------------------
        Rule name: ad_users_reboot
        Enabled: True
    3. Ajoutez la commande /usr/sbin/reboot à la règle ad_users_reboot:

      [root@idmclient ~]# ipa sudorule-add-allow-command ad_users_reboot --sudocmds '/usr/sbin/reboot'
        Rule name: ad_users_reboot
        Enabled: True
        Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
    4. Appliquer la règle ad_users_reboot à l'hôte IdM idmclient:

      [root@idmclient ~]# ipa sudorule-add-host ad_users_reboot --hosts idmclient.idm.example.com
      Rule name: ad_users_reboot
      Enabled: True
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
    5. Ajoutez le groupe ad_users à la règle ad_users_reboot:

      [root@idmclient ~]# ipa sudorule-add-user ad_users_reboot --groups ad_users
      Rule name: ad_users_reboot
      Enabled: TRUE
      User Groups: ad_users
      Hosts: idmclient.idm.example.com
      Sudo Allow Commands: /usr/sbin/reboot
      -------------------------
      Number of members added 1
      -------------------------
Note

La propagation des changements du serveur au client peut prendre quelques minutes.

Verification steps

  1. Connectez-vous à l'hôte idmclient en tant que administrator@ad-domain.com, un membre indirect du groupe ad_users:

    $ ssh administrator@ad-domain.com@ipaclient
    Password:
  2. Optionnellement, afficher les commandes sudo que administrator@ad-domain.com est autorisé à exécuter :

    [administrator@ad-domain.com@idmclient ~]$ sudo -l
    Matching Defaults entries for administrator@ad-domain.com on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User administrator@ad-domain.com may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  3. Redémarrez la machine en utilisant sudo. Saisissez le mot de passe de administrator@ad-domain.com lorsque vous y êtes invité :

    [administrator@ad-domain.com@idmclient ~]$ sudo /usr/sbin/reboot
    [sudo] password for administrator@ad-domain.com:

8.4. Accorder un accès sudo à un utilisateur IdM sur un client IdM à l'aide de l'interface Web IdM

Dans la gestion des identités (IdM), vous pouvez accorder l'accès sudo pour une commande spécifique à un compte d'utilisateur IdM sur un hôte IdM spécifique. Commencez par ajouter une commande sudo, puis créez une règle sudo pour une ou plusieurs commandes.

Suivez cette procédure pour créer la règle sudo idm_user_reboot afin d'autoriser le compte idm_user à exécuter la commande /usr/sbin/reboot sur la machine idmclient.

Conditions préalables

  • Vous êtes connecté en tant qu'administrateur IdM.
  • Vous avez créé un compte utilisateur pour idm_user dans IdM et déverrouillé le compte en créant un mot de passe pour l'utilisateur. Pour plus de détails sur l'ajout d'un nouvel utilisateur IdM à l'aide de l'interface de ligne de commande, voir Ajouter des utilisateurs à l'aide de la ligne de commande.
  • Aucun compte local idm_user n'est présent sur l'hôte idmclient. L'utilisateur idm_user n'est pas répertorié dans le fichier local /etc/passwd.

Procédure

  1. Ajouter la commande /usr/sbin/reboot à la base de données IdM des commandes sudo:

    1. Naviguez vers PolicySudoSudo Commands.
    2. Cliquez sur Add dans le coin supérieur droit pour ouvrir la boîte de dialogue Add sudo command.
    3. Saisissez la commande que vous souhaitez que l'utilisateur puisse exécuter en utilisant sudo: /usr/sbin/reboot.

      Figure 8.1. Ajout de la commande sudo de l'IdM

      A screenshot of a pop-up window labeled "Add sudo command." There is a required field labeled "Sudo command" with contents "/usr/sbin/reboot". A "Description" field is empty. The lower-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Cliquez sur Add.
  2. Utilisez la nouvelle entrée de commande sudo pour créer une règle sudo permettant à idm_user de redémarrer la machine idmclient:

    1. Naviguez vers PolicySudoSudo rules.
    2. Cliquez sur Add dans le coin supérieur droit pour ouvrir la boîte de dialogue Add sudo rule.
    3. Saisissez le nom de la règle sudo: idm_user_reboot.
    4. Cliquez sur Add and Edit.
    5. Spécifiez l'utilisateur :

      1. Dans la section Who, cochez le bouton radio Specified Users and Groups.
      2. Dans la sous-section User category the rule applies to, cliquez sur Add pour ouvrir la boîte de dialogue Add users into sudo rule "idm_user_reboot".
      3. Dans la boîte de dialogue Add users into sudo rule "idm_user_reboot", dans la colonne Available, cochez la case idm_user et déplacez-la dans la colonne Prospective.
      4. Cliquez sur Add.
    6. Spécifiez l'hôte :

      1. Dans la section Access this host, cochez le bouton radio Specified Hosts and Groups.
      2. Dans la sous-section Host category this rule applies to, cliquez sur Add pour ouvrir la boîte de dialogue Add hosts into sudo rule "idm_user_reboot".
      3. Dans la boîte de dialogue Add hosts into sudo rule "idm_user_reboot", dans la colonne Available, cochez la case idmclient.idm.example.com et déplacez-la dans la colonne Prospective.
      4. Cliquez sur Add.
    7. Spécifiez les commandes :

      1. Dans la sous-section Command category the rule applies to de la section Run Commands, cochez le bouton radio Specified Commands and Groups.
      2. Dans la sous-section Sudo Allow Commands, cliquez sur Add pour ouvrir la boîte de dialogue Add allow sudo commands into sudo rule "idm_user_reboot".
      3. Dans la boîte de dialogue Add allow sudo commands into sudo rule "idm_user_reboot", dans la colonne Available, cochez la case /usr/sbin/reboot et déplacez-la dans la colonne Prospective.
      4. Cliquez sur Add pour revenir à la page idm_sudo_reboot.

      Figure 8.2. Ajout d'une règle sudo à l'IdM

      A screenshot of an overview of the sudo rule that was added. There is a "Who" section with a table of users the rule applies to. There is an "Access this host" section with a table of hosts that the rule applies to. There is a "Run Commands" section with a table of commands that pertain to the rule.
    8. Cliquez sur Save dans le coin supérieur gauche.

La nouvelle règle est activée par défaut.

Note

La propagation des changements du serveur au client peut prendre quelques minutes.

Verification steps

  1. Connectez-vous à idmclient en tant que idm_user.
  2. Redémarrez la machine en utilisant sudo. Saisissez le mot de passe de idm_user lorsque vous y êtes invité :

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Si la règle sudo est configurée correctement, la machine redémarre.

8.5. Création d'une règle sudo sur la CLI qui exécute une commande en tant que compte de service sur un client IdM

Dans IdM, vous pouvez configurer une règle sudo avec une règle RunAs alias pour exécuter une commande sudo en tant qu'autre utilisateur ou groupe. Par exemple, vous pouvez avoir un client IdM qui héberge une application de base de données et vous devez exécuter des commandes en tant que compte de service local correspondant à cette application.

Utilisez cet exemple pour créer une règle sudo sur la ligne de commande appelée run_third-party-app_report afin d'autoriser le compte idm_user à exécuter la commande /opt/third-party-app/bin/report en tant que compte de service thirdpartyapp sur l'hôte idmclient.

Conditions préalables

  • Vous êtes connecté en tant qu'administrateur IdM.
  • Vous avez créé un compte utilisateur pour idm_user dans IdM et déverrouillé le compte en créant un mot de passe pour l'utilisateur. Pour plus d'informations sur l'ajout d'un nouvel utilisateur IdM à l'aide de la ligne de commande, voir Ajouter des utilisateurs à l'aide de la ligne de commande.
  • Aucun compte local idm_user n'est présent sur l'hôte idmclient. L'utilisateur idm_user n'est pas répertorié dans le fichier local /etc/passwd.
  • Vous avez une application personnalisée nommée third-party-app installée sur l'hôte idmclient.
  • La commande report pour l'application third-party-app est installée dans le répertoire /opt/third-party-app/bin/report.
  • Vous avez créé un compte de service local nommé thirdpartyapp pour exécuter les commandes de l'application third-party-app.

Procédure

  1. Récupérer un ticket Kerberos en tant qu'IdM admin.

    [root@idmclient ~]# kinit admin
  2. Ajouter la commande /opt/third-party-app/bin/report à la base de données IdM des commandes sudo:

    [root@idmclient ~]# ipa sudocmd-add /opt/third-party-app/bin/report
    ----------------------------------------------------
    Added Sudo Command "/opt/third-party-app/bin/report"
    ----------------------------------------------------
      Sudo Command: /opt/third-party-app/bin/report
  3. Créez une règle sudo nommée run_third-party-app_report:

    [root@idmclient ~]# ipa sudorule-add run_third-party-app_report
    --------------------------------------------
    Added Sudo Rule "run_third-party-app_report"
    --------------------------------------------
      Rule name: run_third-party-app_report
      Enabled: TRUE
  4. Utilisez l'option --users=<user> pour spécifier l'utilisateur RunAs pour la commande sudorule-add-runasuser:

    [root@idmclient ~]# ipa sudorule-add-runasuser run_third-party-app_report --users=thirdpartyapp
      Rule name: run_third-party-app_report
      Enabled: TRUE
      RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------

    L'utilisateur (ou le groupe spécifié avec l'option --groups=* ) peut être externe à IdM, comme un compte de service local ou un utilisateur Active Directory. N'ajoutez pas de préfixe % pour les noms de groupes.

  5. Ajoutez la commande /opt/third-party-app/bin/report à la règle run_third-party-app_report:

    [root@idmclient ~]# ipa sudorule-add-allow-command run_third-party-app_report --sudocmds '/opt/third-party-app/bin/report'
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  6. Appliquer la règle run_third-party-app_report à l'hôte IdM idmclient:

    [root@idmclient ~]# ipa sudorule-add-host run_third-party-app_report --hosts idmclient.idm.example.com
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
    -------------------------
  7. Ajoutez le compte idm_user à la règle run_third-party-app_report:

    [root@idmclient ~]# ipa sudorule-add-user run_third-party-app_report --users idm_user
    Rule name: run_third-party-app_report
    Enabled: TRUE
    Users: idm_user
    Hosts: idmclient.idm.example.com
    Sudo Allow Commands: /opt/third-party-app/bin/report
    RunAs External User: thirdpartyapp
    -------------------------
    Number of members added 1
Note

La propagation des changements du serveur au client peut prendre quelques minutes.

Verification steps

  1. Connectez-vous à l'hôte idmclient en tant que compte idm_user.
  2. Testez la nouvelle règle sudo :

    1. Affiche les règles sudo que le compte idm_user est autorisé à appliquer.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. Exécutez la commande report en tant que compte de service thirdpartyapp.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.6. Création d'une règle sudo dans l'interface Web IdM qui exécute une commande en tant que compte de service sur un client IdM

Dans IdM, vous pouvez configurer une règle sudo avec une règle RunAs alias pour exécuter une commande sudo en tant qu'autre utilisateur ou groupe. Par exemple, vous pouvez avoir un client IdM qui héberge une application de base de données et vous devez exécuter des commandes en tant que compte de service local correspondant à cette application.

Utilisez cet exemple pour créer une règle sudo dans l'IdM WebUI appelée run_third-party-app_report pour permettre au compte idm_user d'exécuter la commande /opt/third-party-app/bin/report en tant que compte de service thirdpartyapp sur l'hôte idmclient.

Conditions préalables

  • Vous êtes connecté en tant qu'administrateur IdM.
  • Vous avez créé un compte utilisateur pour idm_user dans IdM et déverrouillé le compte en créant un mot de passe pour l'utilisateur. Pour plus d'informations sur l'ajout d'un nouvel utilisateur IdM à l'aide de la ligne de commande, voir Ajouter des utilisateurs à l'aide de la ligne de commande.
  • Aucun compte local idm_user n'est présent sur l'hôte idmclient. L'utilisateur idm_user n'est pas répertorié dans le fichier local /etc/passwd.
  • Vous avez une application personnalisée nommée third-party-app installée sur l'hôte idmclient.
  • La commande report pour l'application third-party-app est installée dans le répertoire /opt/third-party-app/bin/report.
  • Vous avez créé un compte de service local nommé thirdpartyapp pour exécuter les commandes de l'application third-party-app.

Procédure

  1. Ajouter la commande /opt/third-party-app/bin/report à la base de données IdM des commandes sudo:

    1. Naviguez vers PolicySudoSudo Commands.
    2. Cliquez sur Add dans le coin supérieur droit pour ouvrir la boîte de dialogue Add sudo command.
    3. Entrez la commande : /opt/third-party-app/bin/report.

      A screenshot of a pop-up window labeled "Add sudo command." There is a required field labeled "Sudo command" with contents "/opt/third-party-app/bin/report". A "Description" field is empty. The lower-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Cliquez sur Add.
  2. Utilisez l'entrée de commande new sudo pour créer la nouvelle règle sudo:

    1. Naviguez vers PolicySudoSudo rules.
    2. Cliquez sur Add dans le coin supérieur droit pour ouvrir la boîte de dialogue Add sudo rule.
    3. Saisissez le nom de la règle sudo: run_third-party-app_report.

      A screenshot of a pop-up window labeled "Add sudo rule." There is a required field labeled "Rule name" with contents "run_third-party-app_report". The lower-right of the window has four buttons: "Add" - "Add and Add Another" - "Add and Edit" - "Cancel".
    4. Cliquez sur Add and Edit.
    5. Spécifiez l'utilisateur :

      1. Dans la section Who, cochez le bouton radio Specified Users and Groups.
      2. Dans la sous-section User category the rule applies to, cliquez sur Add pour ouvrir la boîte de dialogue Add users into sudo rule "run_third-party-app_report".
      3. Dans la boîte de dialogue Add users into sudo rule "run_third-party-app_report", dans la colonne Available, cochez la case idm_user et déplacez-la dans la colonne Prospective.

        A screenshot of a pop-up window labeled "Add users into sudo rule." You can select users from an Available list on the left and move them to a Prospective column on the right. The lower-right of the window has two buttons: "Add" - "Cancel".
      4. Cliquez sur Add.
    6. Spécifiez l'hôte :

      1. Dans la section Access this host, cochez le bouton radio Specified Hosts and Groups.
      2. Dans la sous-section Host category this rule applies to, cliquez sur Add pour ouvrir la boîte de dialogue Add hosts into sudo rule "run_third-party-app_report".
      3. Dans la boîte de dialogue Add hosts into sudo rule "run_third-party-app_report", dans la colonne Available, cochez la case idmclient.idm.example.com et déplacez-la dans la colonne Prospective.

        A screenshot of a pop-up window labeled "Add hosts into sudo rule." You can select hosts from an Available list on the left and move them to a Prospective column on the right. The lower-right of the window has two buttons: "Add" - "Cancel".
      4. Cliquez sur Add.
    7. Spécifiez les commandes :

      1. Dans la sous-section Command category the rule applies to de la section Run Commands, cochez le bouton radio Specified Commands and Groups.
      2. Dans la sous-section Sudo Allow Commands, cliquez sur Add pour ouvrir la boîte de dialogue Add allow sudo commands into sudo rule "run_third-party-app_report".
      3. Dans la boîte de dialogue Add allow sudo commands into sudo rule "run_third-party-app_report", dans la colonne Available, cochez la case /opt/third-party-app/bin/report et déplacez-la dans la colonne Prospective.

        A screenshot of a pop-up window labeled "Add allow sudo commands into sudo rule." You can select sudo commands from an Available list on the left and move them to a Prospective column on the right. The lower-right of the window has two buttons: "Add" - "Cancel".
      4. Cliquez sur Add pour revenir à la page run_third-party-app_report.
    8. Spécifiez l'utilisateur RunAs :

      1. Dans la section As Whom, cochez le bouton radio Specified Users and Groups.
      2. Dans la sous-section RunAs Users, cliquez sur Add pour ouvrir la boîte de dialogue Add RunAs users into sudo rule "run_third-party-app_report".
      3. Dans la boîte de dialogue Add RunAs users into sudo rule "run_third-party-app_report", saisissez le compte de service thirdpartyapp dans la case External et déplacez-le dans la colonne Prospective.

        A screenshot of a dialog box where you can specify the "thirdpartyapp" service account as an external user.
      4. Cliquez sur Add pour revenir à la page run_third-party-app_report.
    9. Cliquez sur Save dans le coin supérieur gauche.

La nouvelle règle est activée par défaut.

Figure 8.3. Détails de la règle sudo

A screenshot of an overview of the sudo rule that was added. The "Who" section has an entry for "idm_user." The "Access this host" section has "idmclient.idm.example.com." The "Run Commands" section has the "/opt/third-party-app/bin/report" command. The "As Whom" section lists the "thirdpartyapp" account.
Note

La propagation des changements du serveur au client peut prendre quelques minutes.

Verification steps

  1. Connectez-vous à l'hôte idmclient en tant que compte idm_user.
  2. Testez la nouvelle règle sudo :

    1. Affiche les règles sudo que le compte idm_user est autorisé à appliquer.

      [idm_user@idmclient ~]$ sudo -l
      Matching Defaults entries for idm_user@idm.example.com on idmclient:
          !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
          env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
          env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
          env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
          env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
          env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
          secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
      
      User idm_user@idm.example.com may run the following commands on idmclient:
          (thirdpartyapp) /opt/third-party-app/bin/report
    2. Exécutez la commande report en tant que compte de service thirdpartyapp.

      [idm_user@idmclient ~]$ sudo -u thirdpartyapp /opt/third-party-app/bin/report
      [sudo] password for idm_user@idm.example.com:
      Executing report...
      Report successful.

8.7. Activation de l'authentification GSSAPI pour sudo sur un client IdM

La procédure suivante décrit l'activation de l'authentification GSSAPI (Generic Security Service Application Program Interface) sur un client IdM pour les commandes sudo et sudo -i via le module PAM pam_sss_gss.so. Avec cette configuration, les utilisateurs IdM peuvent s'authentifier à la commande sudo avec leur ticket Kerberos.

Conditions préalables

  • Vous avez créé une règle sudo pour un utilisateur IdM qui s'applique à un hôte IdM. Pour cet exemple, vous avez créé la règle idm_user_reboot sudo pour accorder au compte idm_user la permission d'exécuter la commande /usr/sbin/reboot sur l'hôte idmclient.
  • Vous devez disposer des privilèges root pour modifier le fichier /etc/sssd/sssd.conf et les fichiers PAM dans le répertoire /etc/pam.d/.

Procédure

  1. Ouvrez le fichier de configuration /etc/sssd/sssd.conf.
  2. Ajoutez l'entrée suivante à la section [domain/<domain_name>] l'entrée suivante.

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
  3. Enregistrez et fermez le fichier /etc/sssd/sssd.conf.
  4. Redémarrez le service SSSD pour charger les modifications de configuration.

    [root@idmclient ~]# systemctl restart sssd
  5. Si vous utilisez RHEL 9.2 ou une version ultérieure :

    1. [Facultatif] Déterminez si vous avez sélectionné le profil sssd authselect :

      # authselect current
      Profile ID: sssd

      Le résultat indique que le profil sssd authselect est sélectionné.

    2. Si le profil sssd authselect est sélectionné, activez l'authentification GSSAPI :

      # authselect enable-feature with-gssapi
    3. Si le profil sssd authselect n'est pas sélectionné, sélectionnez-le et activez l'authentification GSSAPI :

      # authselect select sssd with-gssapi
  6. Si vous utilisez RHEL 9.1 ou une version antérieure :

    1. Ouvrez le fichier de configuration PAM de /etc/pam.d/sudo.
    2. Ajoutez l'entrée suivante comme première ligne de la section auth dans le fichier /etc/pam.d/sudo.

      #%PAM-1.0
      auth sufficient pam_sss_gss.so
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth
    3. Enregistrez et fermez le fichier /etc/pam.d/sudo.

Verification steps

  1. Connectez-vous à l'hôte en tant que compte idm_user.

    [root@idm-client ~]# ssh -l idm_user@idm.example.com localhost
    idm_user@idm.example.com's password:
  2. Vérifiez que vous disposez d'un ticket d'attribution de tickets en tant que compte idm_user.

    [idmuser@idmclient ~]$ klist
    Ticket cache: KCM:1366201107
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    01/08/2021 09:11:48  01/08/2021 19:11:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 01/15/2021 09:11:44
  3. (Optional) Si vous ne disposez pas d'informations d'identification Kerberos pour le compte idm_user, détruisez vos informations d'identification Kerberos actuelles et demandez les informations correctes.

    [idm_user@idmclient ~]$ kdestroy -A
    
    [idm_user@idmclient ~]$ kinit idm_user@IDM.EXAMPLE.COM
    Password for idm_user@idm.example.com:
  4. Redémarrez la machine à l'aide de sudo, sans spécifier de mot de passe.

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.8. Activation de l'authentification GSSAPI et application des indicateurs d'authentification Kerberos pour sudo sur un client IdM

La procédure suivante décrit l'activation de l'authentification GSSAPI (Generic Security Service Application Program Interface) sur un client IdM pour les commandes sudo et sudo -i via le module PAM pam_sss_gss.so. En outre, seuls les utilisateurs qui se sont connectés avec une carte à puce s'authentifieront à ces commandes avec leur ticket Kerberos.

Note

Vous pouvez utiliser cette procédure comme modèle pour configurer l'authentification GSSAPI avec SSSD pour d'autres services compatibles avec PAM, et restreindre davantage l'accès aux seuls utilisateurs dont le ticket Kerberos est associé à un indicateur d'authentification spécifique.

Conditions préalables

  • Vous avez créé une règle sudo pour un utilisateur IdM qui s'applique à un hôte IdM. Pour cet exemple, vous avez créé la règle idm_user_reboot sudo pour accorder au compte idm_user la permission d'exécuter la commande /usr/sbin/reboot sur l'hôte idmclient.
  • Vous avez configuré l'authentification par carte à puce pour l'hôte idmclient.
  • Vous devez disposer des privilèges root pour modifier le fichier /etc/sssd/sssd.conf et les fichiers PAM dans le répertoire /etc/pam.d/.

Procédure

  1. Ouvrez le fichier de configuration /etc/sssd/sssd.conf.
  2. Ajoutez les entrées suivantes à la section [domain/<domain_name>] les entrées suivantes.

    [domain/<domain_name>]
    pam_gssapi_services = sudo, sudo-i
    pam_gssapi_indicators_map = sudo:pkinit, sudo-i:pkinit
  3. Enregistrez et fermez le fichier /etc/sssd/sssd.conf.
  4. Redémarrez le service SSSD pour charger les modifications de configuration.

    [root@idmclient ~]# systemctl restart sssd
  5. Ouvrez le fichier de configuration PAM de /etc/pam.d/sudo.
  6. Ajoutez l'entrée suivante comme première ligne de la section auth dans le fichier /etc/pam.d/sudo.

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      system-auth
    account    include      system-auth
    password   include      system-auth
    session    include      system-auth
  7. Enregistrez et fermez le fichier /etc/pam.d/sudo.
  8. Ouvrez le fichier de configuration PAM de /etc/pam.d/sudo-i.
  9. Ajoutez l'entrée suivante comme première ligne de la section auth dans le fichier /etc/pam.d/sudo-i.

    #%PAM-1.0
    auth sufficient pam_sss_gss.so
    auth       include      sudo
    account    include      sudo
    password   include      sudo
    session    optional     pam_keyinit.so force revoke
    session    include      sudo
  10. Enregistrez et fermez le fichier /etc/pam.d/sudo-i.

Verification steps

  1. Connectez-vous à l'hôte en tant que compte idm_user et authentifiez-vous à l'aide d'une carte à puce.

    [root@idmclient ~]# ssh -l idm_user@idm.example.com localhost
    PIN for smart_card
  2. Vérifiez que vous disposez d'un ticket d'attribution de billets en tant qu'utilisateur de la carte à puce.

    [idm_user@idmclient ~]$ klist
    Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
    Default principal: idm_user@IDM.EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    02/15/2021 16:29:48  02/16/2021 02:29:48  krbtgt/IDM.EXAMPLE.COM@IDM.EXAMPLE.COM
    	renew until 02/22/2021 16:29:44
  3. Affiche les règles sudo que le compte idm_user est autorisé à appliquer.

    [idm_user@idmclient ~]$ sudo -l
    Matching Defaults entries for idmuser on idmclient:
        !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
        env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
        env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
        env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
        env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
        env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY KRB5CCNAME",
        secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
    
    User idm_user may run the following commands on idmclient:
        (root) /usr/sbin/reboot
  4. Redémarrez la machine à l'aide de sudo, sans spécifier de mot de passe.

    [idm_user@idmclient ~]$ sudo /usr/sbin/reboot

8.9. Options SSSD contrôlant l'authentification GSSAPI pour les services PAM

Vous pouvez utiliser les options suivantes pour le fichier de configuration /etc/sssd/sssd.conf afin d'ajuster la configuration GSSAPI au sein du service SSSD.

pam_gssapi_services
L'authentification GSSAPI avec SSSD est désactivée par défaut. Vous pouvez utiliser cette option pour spécifier une liste de services PAM, séparés par des virgules, qui sont autorisés à essayer l'authentification GSSAPI à l'aide du module PAM pam_sss_gss.so. Pour désactiver explicitement l'authentification GSSAPI, définissez cette option sur -.
pam_gssapi_indicators_map

Cette option ne s'applique qu'aux domaines de gestion des identités (IdM). Cette option permet de répertorier les indicateurs d'authentification Kerberos requis pour accorder à PAM l'accès à un service. Les paires doivent être au format <PAM_service>:_<required_authentication_indicator>_.

Les indicateurs d'authentification valides sont les suivants :

  • otp pour l'authentification à deux facteurs
  • radius pour l'authentification RADIUS
  • pkinit pour l'authentification par PKINIT, carte à puce ou certificat
  • hardened pour des mots de passe renforcés
pam_gssapi_check_upn
Cette option est activée et définie par défaut sur true. Si cette option est activée, le service SSSD exige que le nom d'utilisateur corresponde aux informations d'identification Kerberos. Si l'option false est activée, le module PAM pam_sss_gss.so authentifie chaque utilisateur capable d'obtenir le ticket de service requis.

Examples

Les options suivantes activent l'authentification Kerberos pour les services sudo et sudo-i, exigent que les utilisateurs de sudo s'authentifient avec un mot de passe à usage unique et que les noms d'utilisateur correspondent au principal Kerberos. Ces paramètres se trouvant dans la section [pam], ils s'appliquent à tous les domaines :

[pam]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:otp
pam_gssapi_check_upn = true

Vous pouvez également définir ces options dans des sections [domain] individuelles afin d'écraser toutes les valeurs globales dans la section [pam]. Les options suivantes appliquent des paramètres GSSAPI différents à chaque domaine :

Pour le domaine idm.example.com
  • Activez l'authentification GSSAPI pour les services sudo et sudo -i.
  • Exiger des authentificateurs de type certificat ou carte à puce pour la commande sudo.
  • Exiger des authentificateurs à mot de passe unique pour la commande sudo -i.
  • Assurer la correspondance entre les noms d'utilisateurs et les principes Kerberos.
Pour le domaine ad.example.com
  • Activez l'authentification GSSAPI uniquement pour le service sudo.
  • Ne pas imposer la correspondance entre les noms d'utilisateurs et les mandants.
[domain/idm.example.com]
pam_gssapi_services = sudo, sudo-i
pam_gssapi_indicators_map = sudo:pkinit, sudo-i:otp
pam_gssapi_check_upn = true
...

[domain/ad.example.com]
pam_gssapi_services = sudo
pam_gssapi_check_upn = false
...

Ressources supplémentaires

8.10. Dépannage de l'authentification GSSAPI pour sudo

Si vous ne parvenez pas à vous authentifier auprès du service sudo à l'aide d'un ticket Kerberos provenant de l'IdM, utilisez les scénarios suivants pour résoudre votre problème.

Conditions préalables

Procédure

  • Si l'erreur suivante s'affiche, il se peut que le service Kerberos ne soit pas en mesure de résoudre le domaine correct pour le ticket de service en se basant sur le nom d'hôte :

    Serveur introuvable dans la base de données Kerberos

    Dans ce cas, ajoutez le nom d'hôte directement à la section [domain_realm] dans le fichier de configuration Kerberos /etc/krb5.conf:

    [idm-user@idm-client ~]$ cat /etc/krb5.conf
    ...
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
     server.example.com = EXAMPLE.COM
  • Si l'erreur suivante s'affiche, vous ne disposez pas d'informations d'identification Kerberos :

    Pas d'identifiants Kerberos disponibles

    Dans ce cas, récupérez les informations d'identification Kerberos à l'aide de l'utilitaire kinit ou authentifiez-vous à l'aide de SSSD :

    [idm-user@idm-client ~]$ kinit idm-user@IDM.EXAMPLE.COM
    Password for idm-user@idm.example.com:
  • Si l'une des erreurs suivantes apparaît dans le fichier journal /var/log/sssd/sssd_pam.log, les informations d'identification Kerberos ne correspondent pas au nom d'utilisateur de l'utilisateur actuellement connecté :

    User with UPN [<UPN>] was not found.
    
    UPN [<UPN>] does not match target user [<username>].

    Dans ce cas, vérifiez que vous vous êtes authentifié avec SSSD, ou envisagez de désactiver l'option pam_gssapi_check_upn dans le fichier /etc/sssd/sssd.conf:

    [idm-user@idm-client ~]$ cat /etc/sssd/sssd.conf
    ...
    
    pam_gssapi_check_upn = false
  • Pour un dépannage supplémentaire, vous pouvez activer la sortie de débogage pour le module PAM de pam_sss_gss.so.

    • Ajoutez l'option debug à la fin de toutes les entrées pam_sss_gss.so dans les fichiers PAM, telles que /etc/pam.d/sudo et /etc/pam.d/sudo-i:

      [root@idm-client ~]# cat /etc/pam.d/sudo
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      system-auth
      account    include      system-auth
      password   include      system-auth
      session    include      system-auth
      [root@idm-client ~]# cat /etc/pam.d/sudo-i
      #%PAM-1.0
      auth       sufficient   pam_sss_gss.so   debug
      auth       include      sudo
      account    include      sudo
      password   include      sudo
      session    optional     pam_keyinit.so force revoke
      session    include      sudo
    • Essayez de vous authentifier avec le module pam_sss_gss.so et examinez la sortie de la console. Dans cet exemple, l'utilisateur n'avait pas d'identifiants Kerberos.

      [idm-user@idm-client ~]$ sudo ls -l /etc/sssd/sssd.conf
      pam_sss_gss: Initializing GSSAPI authentication with SSSD
      pam_sss_gss: Switching euid from 0 to 1366201107
      pam_sss_gss: Trying to establish security context
      pam_sss_gss: SSSD User name: idm-user@idm.example.com
      pam_sss_gss: User domain: idm.example.com
      pam_sss_gss: User principal:
      pam_sss_gss: Target name: host@idm.example.com
      pam_sss_gss: Using ccache: KCM:
      pam_sss_gss: Acquiring credentials, principal name will be derived
      pam_sss_gss: Unable to read credentials from [KCM:] [maj:0xd0000, min:0x96c73ac3]
      pam_sss_gss: GSSAPI: Unspecified GSS failure.  Minor code may provide more information
      pam_sss_gss: GSSAPI: No credentials cache found
      pam_sss_gss: Switching euid from 1366200907 to 0
      pam_sss_gss: System error [5]: Input/output error

8.11. Utilisation d'un playbook Ansible pour garantir l'accès sudo à un utilisateur IdM sur un client IdM

Dans la gestion des identités (IdM), vous pouvez vous assurer que l'accès sudo à une commande spécifique est accordé à un compte d'utilisateur IdM sur un hôte IdM spécifique.

Effectuez cette procédure pour vous assurer qu'une règle sudo nommée idm_user_reboot existe. La règle accorde à idm_user la permission d'exécuter la commande /usr/sbin/reboot sur la machine idmclient.

Conditions préalables

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaservers:

    [ipaservers]
    server.idm.example.com
  2. Ajouter une ou plusieurs commandes sudo:

    1. Créer un playbook Ansible ensure-reboot-sudocmd-is-present.yml qui assure la présence de la commande /usr/sbin/reboot dans la base de données IdM des commandes sudo. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml:

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: /usr/sbin/reboot
            state: present
    2. Exécutez le manuel de jeu :

      $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. Créez une règle sudo qui fait référence aux commandes :

    1. Créez un playbook Ansible ensure-sudorule-for-idmuser-on-idmclient-is-present.yml qui utilise l'entrée de commande sudo pour s'assurer de la présence d'une règle sudo. La règle sudo permet à idm_user de redémarrer la machine idmclient. Pour simplifier cette étape, vous pouvez copier et modifier l'exemple dans le fichier /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml:

      ---
      - name: Tests
        hosts: ipaserver
      
        vars_files:
        - /home/user_name/MyPlaybooks/secret.yml
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: "{{ ipaadmin_password }}"
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. Exécutez le manuel de jeu :

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

Verification steps

Testez que la règle sudo dont vous avez assuré la présence sur le serveur IdM fonctionne sur idmclient en vérifiant que idm_user peut redémarrer idmclient à l'aide de sudo. Notez qu'il peut s'écouler quelques minutes avant que les changements effectués sur le serveur ne prennent effet sur le client.

  1. Connectez-vous à idmclient en tant que idm_user.
  2. Redémarrez la machine en utilisant sudo. Saisissez le mot de passe de idm_user lorsque vous y êtes invité :

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Si sudo est configuré correctement, la machine redémarre.

Ressources supplémentaires

  • Voir les fichiers README-sudocmd.md, README-sudocmdgroup.md, et README-sudorule.md dans le répertoire /usr/share/doc/ansible-freeipa/.

Chapitre 9. Utilisation de ldapmodify pour gérer les utilisateurs IdM en externe

En tant qu'administrateur IdM, vous pouvez utiliser les commandes ipa pour gérer le contenu de votre annuaire. Vous pouvez également utiliser la commande ldapmodify pour atteindre des objectifs similaires. Vous pouvez utiliser cette commande de manière interactive et fournir toutes les données directement dans la ligne de commande. Vous pouvez également fournir les données du fichier au format LDAP Data Interchange Format (LDIF) à la commande ldapmodify.

9.1. Modèles pour la gestion externe des comptes d'utilisateurs IdM

Cette section décrit des modèles pour diverses opérations de gestion des utilisateurs dans IdM. Les modèles indiquent les attributs que vous devez modifier à l'aide de ldapmodify pour atteindre les objectifs suivants :

  • Ajout d'un nouvel utilisateur de l'étape
  • Modifier l'attribut d'un utilisateur
  • Activation d'un utilisateur
  • Désactivation d'un utilisateur
  • Préserver un utilisateur

Les modèles sont formatés dans le format d'échange de données LDAP (LDIF). LDIF est un format standard d'échange de données en texte clair pour représenter le contenu de l'annuaire LDAP et les demandes de mise à jour.

À l'aide des modèles, vous pouvez configurer le fournisseur LDAP de votre système de provisionnement pour gérer les comptes d'utilisateurs IdM.

Pour des exemples détaillés de procédures, voir les sections suivantes :

Modèles pour l'ajout d'un nouvel utilisateur de l'étape

  • Un modèle pour ajouter un utilisateur avec UID and GID assigned automatically. Le nom distinctif (DN) de l'entrée créée doit commencer par uid=user_login:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: user_login
    sn: surname
    givenName: first_name
    cn: full_name
  • Un modèle pour ajouter un utilisateur avec UID and GID assigned statically:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: posixaccount
    uid: user_login
    uidNumber: UID_number
    gidNumber: GID_number
    sn: surname
    givenName: first_name
    cn: full_name
    homeDirectory: /home/user_login

    Il n'est pas nécessaire de spécifier des classes d'objets IdM lors de l'ajout d'utilisateurs de scène. L'IdM ajoute ces classes automatiquement après l'activation des utilisateurs.

Modèles pour la modification des utilisateurs existants

  • Modifying a user’s attribute:

    dn: distinguished_name
    changetype: modify
    replace: attribute_to_modify
    attribute_to_modify: new_value
  • Disabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: TRUE
  • Enabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: FALSE

    La mise à jour de l'attribut nssAccountLock n'a aucun effet sur les utilisateurs de l'étape et les utilisateurs préservés. Même si l'opération de mise à jour se termine avec succès, la valeur de l'attribut reste nssAccountLock: TRUE.

  • Preserving a user:

    dn: distinguished_name
    changetype: modrdn
    newrdn: uid=user_login
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Note

Avant de modifier un utilisateur, obtenez son nom distinctif (DN) en effectuant une recherche à l'aide de son login. Dans l'exemple suivant, l'utilisateur user_allowed_to_modify_user_entries est un utilisateur autorisé à modifier les informations relatives aux utilisateurs et aux groupes, par exemple activator ou l'administrateur IdM. Le mot de passe dans l'exemple est le mot de passe de cet utilisateur :

[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com

9.2. Modèles pour la gestion externe des comptes de groupe IdM

Cette section décrit des modèles pour diverses opérations de gestion des groupes d'utilisateurs dans IdM. Les modèles indiquent les attributs que vous devez modifier à l'aide de ldapmodify pour atteindre les objectifs suivants :

  • Création d'un nouveau groupe
  • Suppression d'un groupe existant
  • Ajouter un membre à un groupe
  • Supprimer un membre d'un groupe

Les modèles sont formatés dans le format d'échange de données LDAP (LDIF). LDIF est un format standard d'échange de données en texte clair pour représenter le contenu de l'annuaire LDAP et les demandes de mise à jour.

À l'aide des modèles, vous pouvez configurer le fournisseur LDAP de votre système de provisionnement pour gérer les comptes de groupe IdM.

Création d'un nouveau groupe

dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
uid: group_name
cn: group_name
gidNumber: GID_number

Modification des groupes

  • Deleting an existing group:

    dn: group_distinguished_name
    changetype: delete
  • Adding a member to a group:

    dn: group_distinguished_name
    changetype: modify
    add: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com

    N'ajoutez pas d'utilisateurs en stage ou préservés aux groupes. Même si l'opération de mise à jour se termine avec succès, les utilisateurs ne seront pas mis à jour en tant que membres du groupe. Seuls les utilisateurs actifs peuvent appartenir à des groupes.

  • Removing a member from a group:

    dn: distinguished_name
    changetype: modify
    delete: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Note

Avant de modifier un groupe, obtenez son nom distinctif (DN) en effectuant une recherche à l'aide de son nom.

# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017

9.3. Utilisation interactive de la commande ldapmodify

Vous pouvez modifier les entrées LDAP (Lightweight Directory Access Protocol) en mode interactif.

Procédure

  1. Dans une ligne de commande, saisissez l'instruction LDAP Data Interchange Format (LDIF) après la commande ldapmodify.

    Exemple 9.1. Modifier le numéro de téléphone d'un testuser

    # ldapmodify -Y GSSAPI -H ldap://server.example.com
    dn: uid=testuser,cn=users,cn=accounts,dc=example,dc=com
    changetype: modify
    replace: telephoneNumber
    telephonenumber: 88888888

    Notez que vous devez obtenir un ticket Kerberos pour utiliser l'option -Y.

  2. Appuyez sur Ctlr D pour quitter le mode interactif.
  3. Vous pouvez également fournir un fichier LDIF après la commande ldapmodify:

    Exemple 9.2. La commande ldapmodify permet de lire les données de modification d'un fichier LDIF

    # ldapmodify -Y GSSAPI -H ldap://server.example.com -f ~/example.ldif

Ressources supplémentaires

  • Pour plus d'informations sur l'utilisation de la commande ldapmodify, voir la page de manuel ldapmodify(1).
  • Pour plus d'informations sur la structure LDIF, voir la page de manuel ldif(5).

9.4. Préservation d'un utilisateur IdM avec ldapmodify

Cette section décrit comment utiliser ldapmodify pour préserver un utilisateur IdM, c'est-à-dire comment désactiver un compte utilisateur après que l'employé a quitté l'entreprise.

Conditions préalables

  • Vous pouvez vous authentifier en tant qu'utilisateur IdM avec un rôle de préservation des utilisateurs.

Procédure

  1. Se connecter en tant qu'utilisateur IdM avec un rôle de préservation des utilisateurs :

    kinit admin
  2. Entrez dans la commande ldapmodify et indiquez Generic Security Services API (GSSAPI) comme mécanisme SASL (Simple Authentication and Security Layer) à utiliser pour l'authentification :

    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
  3. Saisissez l'adresse dn de l'utilisateur que vous souhaitez préserver :

    dn : uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
  4. Saisissez modrdn comme type de modification à effectuer :

    changetype : modrdn
  5. Spécifiez l'adresse newrdn pour l'utilisateur :

    newrdn : uid=user1
  6. Indiquez que vous souhaitez préserver l'utilisateur :

    supprimeroldrdn : 0
  7. Spécifiez le site new superior DN:

    newsuperior : cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com

    La préservation d'un utilisateur déplace l'entrée vers un nouvel emplacement dans l'arborescence des informations de répertoire (DIT). C'est pourquoi vous devez spécifier le DN de la nouvelle entrée parent comme nouveau DN supérieur.

  8. Appuyez à nouveau sur Enter pour confirmer la fin de l'entrée :

    [Enter]
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
  9. Quittez la connexion en utilisant Ctrl C .

Verification steps

  • Vérifiez que l'utilisateur a été préservé en dressant la liste de tous les utilisateurs préservés :

    $ ipa user-find --preserved=true
    --------------
    1 user matched
    --------------
      User login: user1
      First name: First 1
      Last name: Last 1
      Home directory: /home/user1
      Login shell: /bin/sh
      Principal name: user1@IDM.EXAMPLE.COM
      Principal alias: user1@IDM.EXAMPLE.COM
      Email address: user1@idm.example.com
      UID: 1997010003
      GID: 1997010003
      Account disabled: True
      Preserved user: True
    ----------------------------
    Number of entries returned 1
    ----------------------------

Chapitre 10. Recherche d'entrées IdM à l'aide de la commande ldapsearch

Vous pouvez utiliser la commande ipa find pour effectuer une recherche dans les entrées de gestion de l'identité. Pour plus d'informations sur la commande ipa, voir la section Structure des commandes IPA.

Cette section présente les bases d'une option de recherche alternative à l'aide de la commande en ligne ldapsearch par le biais des entrées de gestion de l'identité.

10.1. Utilisation de la commande ldapsearch

La commande ldapsearch a le format suivant :

# ldapsearch [-x | -Y mechanism] [options] [search_filter] [list_of_attributes]
  • Pour configurer la méthode d'authentification, spécifiez l'option -x pour utiliser des liaisons simples ou l'option -Y pour définir le mécanisme SASL (Simple Authentication and Security Layer). Notez que vous devez obtenir un ticket Kerberos si vous utilisez l'option -Y GSSAPI.
  • Les options de la commande options sont les options de la commande ldapsearch décrites dans le tableau ci-dessous.
  • Le site search_filter est un filtre de recherche LDAP.
  • Le site list_of_attributes est une liste des attributs que les résultats de la recherche renvoient.

Par exemple, vous souhaitez rechercher le nom d'utilisateur user01 dans toutes les entrées d'une arborescence LDAP de base :

# ldapsearch -x -H ldap://ldap.example.com -s sub "(uid=user01)"
  • L'option -x indique à la commande ldapsearch de s'authentifier avec le simple bind. Notez que si vous ne fournissez pas le Distinguish Name (DN) avec l'option -D, l'authentification est anonyme.
  • L'option -H vous connecte au site ldap://ldap.example.com.
  • L'option -s sub indique à la commande ldapsearch de rechercher dans toutes les entrées, à partir du DN de base, l'utilisateur portant le nom user01. L'option "(uid=user01)" est un filtre.

Notez que si vous n'indiquez pas le point de départ de la recherche avec l'option -b, la commande recherche dans l'arbre par défaut. Il est spécifié dans le paramètre BASE du fichier etc/openldap/ldap.conf.

Tableau 10.1. Les options de la commande ldapsearch

OptionDescription

-b

Le point de départ de la recherche. Si vos paramètres de recherche contiennent un astérisque (*) ou un autre caractère que la ligne de commande peut interpréter comme un code, vous devez mettre la valeur entre guillemets simples ou doubles. Par exemple, -b cn=user,ou=Product Development,dc=example,dc=com.

-D

Le Distinguished Name (DN) avec lequel vous souhaitez vous authentifier.

-H

Une URL LDAP pour se connecter au serveur. L'option -H remplace les options -h et -p.

-l

Délai en secondes pour attendre la fin d'une demande de recherche.

-s scope

L'étendue de la recherche. Vous pouvez choisir l'un des éléments suivants pour le champ d'application :

  • base ne recherche que l'entrée de l'option -b ou définie par la variable d'environnement LDAP_BASEDN.
  • one recherche uniquement les enfants de l'entrée de l'option -b.
  • sub une recherche de sous-arbres à partir du point de départ de l'option -b.

-W

Demande de mot de passe.

-x

Désactive la connexion SASL par défaut pour permettre des liaisons simples.

-Y SASL_mechanism

Définit le mécanisme SASL pour l'authentification.

-z number

Nombre maximum d'entrées dans le résultat de la recherche.

Remarque : vous devez spécifier l'un des mécanismes d'authentification avec l'option -x ou -Y dans la commande ldapsearch.

Ressources supplémentaires

  • Pour plus de détails sur l'utilisation de ldapsearch, voir la page de manuel ldapsearch(1).

10.2. Utilisation des filtres ldapsearch

Les filtres du site ldapsearch vous permettent d'affiner les résultats de la recherche.

Par exemple, vous souhaitez que le résultat de la recherche contienne toutes les entrées dont le nom commun est example:

"(cn=example)"

Dans ce cas, equal sign (=) est l'opérateur et example est la valeur.

Tableau 10.2. Les opérateurs de filtrage ldapsearch

Type de rechercheOpérateurDescription

L'égalité

=

Renvoie les entrées qui correspondent exactement à la valeur. Par exemple, cn=example.

Sous-chaîne

=string* string

Renvoie toutes les entrées contenant la sous-chaîne correspondante. Par exemple, cn=exa*l. L'astérisque (*) indique zéro (0) ou plusieurs caractères.

Supérieur ou égal à

>=

Renvoie toutes les entrées dont les attributs sont supérieurs ou égaux à la valeur. Par exemple, uidNumber >= 5000.

Inférieur ou égal à

<=

Renvoie toutes les entrées dont les attributs sont inférieurs ou égaux à la valeur. Par exemple, uidNumber <= 5000.

Présence

=*

Renvoie toutes les entrées avec un ou plusieurs attributs. Par exemple, cn=*.

Approximation

~=

Renvoie toutes les entrées dont les attributs sont similaires à ceux de la valeur. Par exemple, l~=san fransico peut renvoyer l=san francisco.

Vous pouvez utiliser les opérateurs boolean pour combiner plusieurs filtres à la commande ldapsearch.

Tableau 10.3. Les opérateurs booléens du filtre ldapsearch

Type de rechercheOpérateurDescription

ET

&

Renvoie toutes les entrées pour lesquelles toutes les affirmations des filtres sont vraies. Par exemple, (&(filter)(filter)(filter)…​).

OU

|

Renvoie toutes les entrées pour lesquelles au moins une déclaration dans les filtres est vraie. Par exemple, (|(filter)(filter)(filter)…​).

PAS

!

Renvoie toutes les entrées pour lesquelles l'énoncé du filtre n'est pas vrai. Par exemple, (!(filter)).

Chapitre 11. Configuration de l'IdM pour le provisionnement externe des utilisateurs

En tant qu'administrateur système, vous pouvez configurer la gestion des identités (IdM) pour prendre en charge le provisionnement des utilisateurs par une solution externe de gestion des identités.

Plutôt que d'utiliser l'utilitaire ipa, l'administrateur du système de provisionnement externe peut accéder au LDAP IdM à l'aide de l'utilitaire ldapmodify. L'administrateur peut ajouter des utilisateurs de scène individuels à partir de l'interface de ligne de commande en utilisant ldapmodify ou en utilisant un fichier LDIF.

L'hypothèse est que vous, en tant qu'administrateur IdM, faites entièrement confiance à votre système de provisionnement externe pour n'ajouter que des utilisateurs validés. Toutefois, vous ne souhaitez pas attribuer aux administrateurs du système de provisionnement externe le rôle IdM de User Administrator pour leur permettre d'ajouter directement de nouveaux utilisateurs actifs.

Vous pouvez configurer un script pour déplacer automatiquement les utilisateurs en phase créés par le système de provisionnement externe vers des utilisateurs actifs.

Ce chapitre contient les sections suivantes :

  1. Préparation de la gestion des identités (IdM) à l'utilisation d'un système de provisionnement externe pour ajouter des utilisateurs d'étape à IdM.
  2. Création d'un script pour faire passer les utilisateurs ajoutés par le système de provisionnement externe du statut d'utilisateurs actifs à celui d'utilisateurs actifs.
  3. Utilisation d'un système de provisionnement externe pour ajouter un utilisateur de l'étape IdM. Vous pouvez le faire de deux manières :

11.1. Préparation des comptes IdM pour l'activation automatique des comptes d'utilisateurs de l'étape

Cette procédure montre comment configurer deux comptes d'utilisateur IdM pour qu'ils soient utilisés par un système de provisionnement externe. En ajoutant les comptes à un groupe avec une politique de mot de passe appropriée, vous permettez au système de provisionnement externe de gérer le provisionnement des utilisateurs dans IdM. Dans ce qui suit, le compte d'utilisateur à utiliser par le système externe pour ajouter des utilisateurs de stage est nommé provisionator. Le compte d'utilisateur à utiliser pour activer automatiquement les utilisateurs de l'étape est nommé activator.

Conditions préalables

  • L'hôte sur lequel vous effectuez la procédure est enrôlé dans IdM.

Procédure

  1. Se connecter en tant qu'administrateur IdM :

    kinit admin
  2. Créez un utilisateur nommé provisionator avec les privilèges d'ajouter des utilisateurs de scène.

    1. Ajouter le compte utilisateur du provisionneur :
    ipa user-add provisionator --first=provisioning --last=account --password
    1. Accorder à l'utilisateur du provisionneur les privilèges requis.

      1. Créez un rôle personnalisé, System Provisioning, pour gérer l'ajout d'utilisateurs de l'étape :

        $ ipa role-add --desc \N- "Responsable de l'approvisionnement des utilisateurs de l'étape\N" \N- "Provisionnement du système\N"
      2. Ajoutez le privilège Stage User Provisioning au rôle. Ce privilège permet d'ajouter des utilisateurs de scène :

        $ ipa role-add-privilege \N "System Provisioning" --privileges=\N "Stage User Provisioning" $ ipa role-add-privilege \N "System Provisioning" --privileges=\N "Stage User Provisioning"
      3. Ajouter l'utilisateur du provisionneur au rôle :

        $ ipa role-add-member --users=provisionator "System Provisioning"
      4. Vérifier que le provisionneur existe dans IdM :
      $ ipa user-find provisionator --all --raw
      --------------
      1 user matched
      --------------
        dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com
        uid: provisionator
        [...]
  3. Créez un utilisateur, activator, avec les privilèges nécessaires pour gérer les comptes d'utilisateurs.

    1. Ajouter le compte utilisateur de l'activateur :

      $ ipa user-add activator --first=activation --last=account --password
    2. Accordez à l'utilisateur de l'activateur les privilèges requis en ajoutant l'utilisateur au rôle par défaut User Administrator:

      $ ipa role-add-member --users=activator "User Administrator"
  4. Créer un groupe d'utilisateurs pour les comptes d'application :

    ipa group-add application-accounts
  5. Mettez à jour la politique de mot de passe pour le groupe. La politique suivante empêche l'expiration du mot de passe et le verrouillage du compte, mais compense les risques potentiels en exigeant des mots de passe complexes :

    $ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --history=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  6. (Facultatif) Vérifier que la politique de mot de passe existe dans IdM :

    $ ipa pwpolicy-show application-accounts
      Group: application-accounts
      Max lifetime (days): 10000
      Min lifetime (hours): 0
      History size: 0
    [...]
  7. Ajoutez les comptes de provisionnement et d'activation au groupe des comptes d'application :

    $ ipa group-add-member application-accounts --users={provisionator,activator}
  8. Modifier les mots de passe des comptes utilisateurs :

    $ kpasswd provisionator
    $ kpasswd activator

    La modification des mots de passe est nécessaire car les mots de passe des nouveaux utilisateurs de l'IdM expirent immédiatement.

11.2. Configuration de l'activation automatique des comptes d'utilisateurs de l'étape IdM

Cette procédure montre comment créer un script pour activer les utilisateurs de l'étape. Le système exécute automatiquement le script à des intervalles de temps spécifiés. Cela garantit que les nouveaux comptes d'utilisateurs sont automatiquement activés et disponibles peu de temps après leur création.

Important

La procédure suppose que le propriétaire du système de provisionnement externe a déjà validé les utilisateurs et qu'ils n'ont pas besoin d'une validation supplémentaire du côté de l'IdM avant que le script ne les ajoute à l'IdM.

Il suffit d'activer le processus d'activation sur un seul de vos serveurs IdM.

Conditions préalables

Procédure

  1. Générer un fichier keytab pour le compte d'activation :

    # ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab

    Si vous souhaitez activer le processus d'activation sur plusieurs serveurs IdM, générez le fichier keytab sur un seul serveur. Copiez ensuite le fichier keytab sur les autres serveurs.

  2. Créez un script, /usr/local/sbin/ipa-activate-all, avec le contenu suivant pour activer tous les utilisateurs :

    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. Modifiez les autorisations et la propriété du script ipa-activate-all pour le rendre exécutable :

    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. Créez un fichier d'unité systemd, /etc/systemd/system/ipa-activate-all.service, avec le contenu suivant :

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. Créez un timer systemd, /etc/systemd/system/ipa-activate-all.timer, avec le contenu suivant :

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. Recharger la nouvelle configuration :

    # systemctl daemon-reload
  7. Activer ipa-activate-all.timer:

    # systemctl enable ipa-activate-all.timer
  8. Démarrer ipa-activate-all.timer:

    # systemctl start ipa-activate-all.timer
  9. (Facultatif) Vérifiez que le démon ipa-activate-all.timer est en cours d'exécution :

    # systemctl status ipa-activate-all.timer
    ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated
       Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled)
       Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago
      Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left
    
    Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.

11.3. Ajout d'une étape IdM définie par l'utilisateur dans un fichier LDIF

Cette section décrit comment un administrateur d'un système de provisionnement externe peut accéder à IdM LDAP et utiliser un fichier LDIF pour ajouter des utilisateurs d'étape. L'exemple ci-dessous montre l'ajout d'un seul utilisateur, mais plusieurs utilisateurs peuvent être ajoutés dans un fichier en mode groupé.

Conditions préalables

  • L'administrateur IdM a créé le compte provisionator et un mot de passe. Pour plus de détails, voir Préparation des comptes IdM pour l'activation automatique des comptes d'utilisateurs de scène.
  • En tant qu'administrateur externe, vous connaissez le mot de passe du compte provisionator.
  • Vous pouvez accéder au serveur IdM par SSH à partir de votre serveur LDAP.
  • Vous êtes en mesure de fournir l'ensemble minimal d'attributs qu'un utilisateur de la phase IdM doit posséder pour permettre le traitement correct du cycle de vie de l'utilisateur, à savoir :

    • Le site distinguished name (dn)
    • The common name (cn)
    • The last name (sn)
    • Les uid

Procédure

  1. Sur le serveur externe, créez un fichier LDIF contenant des informations sur le nouvel utilisateur :

    dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: stageidmuser
    sn: surname
    givenName: first_name
    cn: full_name
  2. Transférer le fichier LDIF du serveur externe vers le serveur IdM :

    $ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/
    Password:
    add-stageidmuser.ldif                                                                                          100%  364   217.6KB/s   00:00
  3. Utilisez le protocole SSH pour vous connecter au serveur IdM en tant que provisionator:

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  4. Sur le serveur IdM, obtenez le ticket Kerberos (TGT) pour le compte du provisionneur :

    [provisionator@server ~]$ kinit provisionator
  5. Saisir la commande ldapadd avec l'option -f et le nom du fichier LDIF. Spécifiez le nom du serveur IdM et le numéro de port :

    ~]$ ldapadd -h server.idm.example.com -p 389 -f  add-stageidmuser.ldif
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
    adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"

11.4. Ajout d'un utilisateur d'étape IdM directement à partir de l'interface de dialogue en ligne à l'aide de ldapmodify

Cette section décrit comment un administrateur d'un système de provisionnement externe peut accéder au LDAP de la gestion des identités (IdM) et utiliser l'utilitaire ldapmodify pour ajouter un utilisateur de scène.

Conditions préalables

  • L'administrateur IdM a créé le compte provisionator et un mot de passe. Pour plus de détails, voir Préparation des comptes IdM pour l'activation automatique des comptes d'utilisateurs de scène.
  • En tant qu'administrateur externe, vous connaissez le mot de passe du compte provisionator.
  • Vous pouvez accéder au serveur IdM par SSH à partir de votre serveur LDAP.
  • Vous êtes en mesure de fournir l'ensemble minimal d'attributs qu'un utilisateur de la phase IdM doit posséder pour permettre le traitement correct du cycle de vie de l'utilisateur, à savoir :

    • Le site distinguished name (dn)
    • The common name (cn)
    • The last name (sn)
    • Les uid

Procédure

  1. Utilisez le protocole SSH pour vous connecter au serveur IdM en utilisant votre identité et vos informations d'identification IdM :

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. Obtenir le TGT du compte provisionator, un utilisateur IdM ayant le rôle d'ajouter de nouveaux utilisateurs de scène :

    $ kinit provisionator
  3. Entrez dans la commande ldapmodify et spécifiez Generic Security Services API (GSSAPI) comme mécanisme SASL (Simple Authentication and Security Layer) à utiliser pour l'authentification. Indiquez le nom du serveur IdM et le port :

    # ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 56
    SASL data security layer installed.
  4. Saisissez l'adresse dn de l'utilisateur que vous ajoutez :

    dn : uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
  5. Saisissez add comme type de modification à effectuer :

    changetype : add
  6. Spécifier les catégories de classes d'objets LDAP requises pour permettre le traitement correct du cycle de vie de l'utilisateur :

    objectClass: top
    objectClass: inetorgperson

    Vous pouvez spécifier des classes d'objets supplémentaires.

  7. Saisissez l'adresse uid de l'utilisateur :

    uid : stageuser
  8. Saisissez l'adresse cn de l'utilisateur :

    cn : Babs Jensen
  9. Saisissez le nom de famille de l'utilisateur :

    sn : Jensen
  10. Appuyez à nouveau sur Enter pour confirmer la fin de l'entrée :

    [Enter]
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
  11. Quittez la connexion en utilisant Ctrl C .

Verification steps

Vérifiez le contenu de l'entrée de scène pour vous assurer que votre système de provisionnement a ajouté tous les attributs POSIX requis et que l'entrée de scène est prête à être activée.

  • Pour afficher les attributs LDAP du nouvel utilisateur de l'étape, entrez la commande ipa stageuser-show --all --raw:

    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
      uid: stageuser
      sn: Jensen
      cn: Babs Jensen
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    1. Notez que l'utilisateur est explicitement désactivé par l'attribut nsaccountlock.

11.5. Ressources supplémentaires

Chapitre 12. Renforcer la sécurité de Kerberos avec les informations du PAC

Les sections suivantes expliquent comment la gestion des identités (IdM) fonctionne avec les informations du certificat d'attributs de privilèges (PAC) par défaut depuis RHEL 8.5. Vous pouvez également activer les identificateurs de sécurité (SID) dans les déploiements IdM installés avant RHEL 8.5.

12.1. Utilisation du certificat d'attribut de privilège (PAC) dans l'IdM

Pour renforcer la sécurité, RHEL Identity Management (IdM) émet désormais des tickets Kerberos avec des informations de certificat d'attribut de privilège (PAC) par défaut dans les nouveaux déploiements. Un PAC contient de nombreuses informations sur un principal Kerberos, notamment son identifiant de sécurité (SID), l'appartenance à un groupe et des informations sur le répertoire personnel.

Les SID, que Microsoft Active Directory (AD) utilise par défaut, sont des identifiants uniques au niveau mondial qui ne sont jamais réutilisés. Les SID expriment plusieurs espaces de noms : chaque domaine a un SID, qui est un préfixe dans le SID de chaque objet.

À partir de RHEL 8.5, lorsque vous installez un serveur IdM ou un réplica, le script d'installation génère par défaut des SID pour les utilisateurs et les groupes. Cela permet à IdM de travailler avec des données PAC. Si vous avez installé IdM avant RHEL 8.5 et que vous n'avez pas configuré de confiance avec un domaine AD, il se peut que vous n'ayez pas généré de SID pour vos objets IdM. Pour plus d'informations sur la génération de SID pour vos objets IdM, voir Activation des identifiants de sécurité (SID) dans IdM.

En évaluant les informations PAC dans les tickets Kerberos, vous pouvez contrôler l'accès aux ressources de manière beaucoup plus détaillée. Par exemple, le compte Administrateur d'un domaine a un SID différent de celui du compte Administrateur d'un autre domaine. Dans un environnement IdM avec une confiance dans un domaine AD, vous pouvez définir des contrôles d'accès basés sur des SID uniques au niveau mondial plutôt que sur de simples noms d'utilisateur ou UID qui peuvent se répéter à différents endroits, comme par exemple chaque compte Linux root ayant un UID de 0.

12.2. Activation des identificateurs de sécurité (SID) dans l'IdM

Si vous avez installé IdM avant RHEL 8.5 et que vous n'avez pas configuré de confiance avec un domaine AD, il se peut que vous n'ayez pas généré d'identifiants de sécurité (SID) pour vos objets IdM. En effet, auparavant, le seul moyen de générer des SID était d'exécuter la commande ipa-adtrust-install pour ajouter le rôle Trust Controller à un serveur IdM.

À partir de RHEL 8.6, Kerberos dans IdM exige que vos objets IdM aient des SID, qui sont nécessaires pour la sécurité basée sur les informations du certificat d'accès aux privilèges (PAC).

Conditions préalables

  • Vous avez installé IdM avant RHEL 8.5.
  • Vous n'avez pas exécuté la tâche ipa-sidgen, qui fait partie de la configuration d'une confiance avec un domaine Active Directory.
  • Vous pouvez vous authentifier en tant que compte administrateur IdM.

Procédure

  • Activez l'utilisation des SID et déclenchez la tâche SIDgen pour générer des SID pour les utilisateurs et les groupes existants. Cette tâche peut être gourmande en ressources :

    [root@server ~]# ipa config-mod --enable-sid --add-sids

Vérification

  • Vérifiez que l'entrée du compte utilisateur IdM admin a un attribut ipantsecurityidentifier avec un SID qui se termine par -500, le SID réservé à l'administrateur du domaine :

    [root@server ~]# ipa user-show admin --all | grep ipantsecurityidentifier
      ipantsecurityidentifier: S-1-5-21-2633809701-976279387-419745629-500

Chapitre 13. Gestion des politiques de tickets Kerberos

Les politiques de tickets Kerberos dans la gestion des identités (IdM) définissent des restrictions sur l'accès, la durée et le renouvellement des tickets Kerberos. Vous pouvez configurer les politiques de tickets Kerberos pour le Centre de distribution de clés (KDC) fonctionnant sur votre serveur IdM.

Ce chapitre présente les sujets et les tâches suivants relatifs à la gestion des tickets Kerberos :

13.1. Le rôle du KDC IdM

Les mécanismes d'authentification de la gestion de l'identité utilisent l'infrastructure Kerberos établie par le centre de distribution de clés (KDC). Le KDC est l'autorité de confiance qui stocke les informations d'identification et garantit l'authenticité des données provenant des entités du réseau IdM.

Chaque utilisateur, service et hôte IdM agit comme un client Kerberos et est identifié par une adresse Kerberos unique principal:

  • Pour les utilisateurs : identifier@REALM, tels que admin@EXAMPLE.COM
  • Pour les services : service/fully-qualified-hostname@REALM, tels que http/server.example.com@EXAMPLE.COM
  • Pour les hôtes : host/fully-qualified-hostname@REALM, tels que host/client.example.com@EXAMPLE.COM

L'image suivante est une simplification de la communication entre un client Kerberos, le KDC et une application Kerberisée avec laquelle le client veut communiquer.

Kerberos KDC flow of communication
  1. Un client Kerberos s'identifie auprès du KDC en s'authentifiant en tant que principal Kerberos. Par exemple, un utilisateur IdM effectue kinit username et fournit son mot de passe.
  2. Le KDC vérifie la présence du principal dans sa base de données, authentifie le client et évalue les politiques de tickets Kerberos afin de déterminer s'il convient d'accéder à la demande.
  3. Le KDC délivre au client un ticket d'attribution de ticket (TGT) avec un cycle de vie et des indicateurs d'authentification conformément à la politique de ticket appropriée.
  4. Avec le TGT, le client demande une adresse service ticket au KDC pour communiquer avec un service Kerberisé sur un hôte cible.
  5. Le KDC vérifie si le TGT du client est toujours valide et évalue la demande de ticket de service par rapport aux politiques de ticket.
  6. Le KDC délivre au client une adresse service ticket.
  7. Avec le ticket de service, le client peut initier une communication cryptée avec le service sur l'hôte cible.

13.2. Types de politiques de ticket IdM Kerberos

Les politiques de ticket Kerberos de l'IdM mettent en œuvre les types de politique de ticket suivants :

Politique de connexion

Pour protéger les services Kerberisés avec différents niveaux de sécurité, vous pouvez définir des stratégies de connexion pour appliquer des règles basées sur le mécanisme de préauthentification qu'un client a utilisé pour récupérer un ticket d'attribution de ticket (TGT).

Par exemple, vous pouvez exiger une authentification par carte à puce pour vous connecter à client1.example.com, et exiger une authentification à deux facteurs pour accéder à l'application testservice sur client2.example.com.

Pour appliquer les politiques de connexion, associez authentication indicators aux services. Seuls les clients dont les demandes de tickets de service contiennent les indicateurs d'authentification requis peuvent accéder à ces services. Pour plus d'informations, voir Indicateurs d'authentification Kerberos.

Politique relative au cycle de vie des billets

Chaque ticket Kerberos a une lifetime et une renewal age potentielle : vous pouvez renouveler un ticket avant qu'il n'atteigne sa durée de vie maximale, mais pas après qu'il ait dépassé son âge maximal de renouvellement.

La durée de vie globale par défaut des tickets est d'un jour (86400 secondes) et l'âge maximum de renouvellement global par défaut est d'une semaine (604800 secondes). Pour ajuster ces valeurs globales, voir Configuration de la politique globale de cycle de vie des tickets.

Vous pouvez également définir vos propres politiques de cycle de vie des tickets :

13.3. Indicateurs d'authentification Kerberos

Le centre de distribution de clés Kerberos (KDC) associe authentication indicators à un ticket d'attribution de ticket (TGT) en fonction du mécanisme de préauthentification utilisé par le client pour prouver son identité :

otp
authentification à deux facteurs (mot de passe à usage unique)
radius
Authentification RADIUS (généralement pour l'authentification 802.1x)
pkinit
Authentification par PKINIT, carte à puce ou certificat
hardened
mots de passe renforcés (SPAKE ou FAST)[1]

Le KDC attache ensuite les indicateurs d'authentification du TGT à toutes les demandes de tickets de service qui en découlent. Le KDC applique des politiques telles que le contrôle d'accès aux services, la durée de vie maximale des tickets et l'âge maximal de renouvellement sur la base des indicateurs d'authentification.

Indicateurs d'authentification et services IdM

Si vous associez un service ou un hôte à un indicateur d'authentification, seuls les clients qui ont utilisé le mécanisme d'authentification correspondant pour obtenir un TGT pourront y accéder. Le KDC, et non l'application ou le service, vérifie la présence d'indicateurs d'authentification dans les demandes de tickets de service et accorde ou refuse les demandes en fonction des politiques de connexion Kerberos.

Par exemple, pour exiger une authentification à deux facteurs pour se connecter à un réseau privé virtuel (VPN), associez l'indicateur d'authentification otp à ce service. Seuls les utilisateurs qui ont utilisé un mot de passe à usage unique pour obtenir leur TGT initial auprès du KDC pourront se connecter au réseau privé virtuel :

Figure 13.1. Exemple de service VPN nécessitant l'indicateur d'authentification otp

auth indicators

Si aucun indicateur d'authentification n'est attribué à un service ou à un hôte, celui-ci acceptera les tickets authentifiés par n'importe quel mécanisme.



[1] Un mot de passe renforcé est protégé contre les attaques par force brute du dictionnaire de mots de passe en utilisant la pré-authentification SPAKE (Single-Party Public-Key Authenticated Key Exchange) et/ou l'armure FAST (Flexible Authentication via Secure Tunneling).

13.4. Renforcement des indicateurs d'authentification pour un service IdM

Les mécanismes d'authentification pris en charge par la gestion des identités (IdM) varient en termes de force d'authentification. Par exemple, l'obtention du ticket initial Kerberos (TGT) à l'aide d'un mot de passe à usage unique (OTP) en combinaison avec un mot de passe standard est considérée comme plus sûre que l'authentification à l'aide d'un mot de passe standard uniquement.

En associant des indicateurs d'authentification à un service IdM particulier, vous pouvez, en tant qu'administrateur IdM, configurer le service de sorte que seuls les utilisateurs qui ont utilisé ces mécanismes de préauthentification spécifiques pour obtenir leur ticket initial (TGT) puissent accéder au service.

De cette façon, vous pouvez configurer différents services IdM de manière à ce que :

  • Seuls les utilisateurs qui ont utilisé une méthode d'authentification plus forte pour obtenir leur TGT initial, comme un mot de passe à usage unique (OTP), peuvent accéder à des services essentiels à la sécurité, comme un VPN.
  • Les utilisateurs qui ont utilisé des méthodes d'authentification plus simples pour obtenir leur TGT initial, comme un mot de passe, ne peuvent accéder qu'à des services non critiques, comme les connexions locales.

Figure 13.2. Exemple d'authentification à l'aide de différentes technologies

auth indicators

Cette procédure décrit la création d'un service IdM et sa configuration pour exiger des indicateurs d'authentification Kerberos particuliers pour les demandes de tickets de service entrantes.

13.4.1. Création d'une entrée de service IdM et de son keytab Kerberos

L'ajout d'une entrée IdM service à IdM pour un service fonctionnant sur un hôte IdM crée un principal Kerberos correspondant et permet au service de demander un certificat SSL, un keytab Kerberos ou les deux.

La procédure suivante décrit la création d'une entrée de service IdM et la génération d'un keytab Kerberos associé pour chiffrer la communication avec ce service.

Conditions préalables

  • Votre service peut stocker un principal Kerberos, un certificat SSL ou les deux.

Procédure

  1. Ajoutez un service IdM avec la commande ipa service-add pour créer un principal Kerberos associé à ce service. Par exemple, pour créer l'entrée du service IdM pour l'application testservice qui s'exécute sur l'hôte client.example.com:

    [root@client ~]# ipa service-add testservice/client.example.com
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Managed by: client.example.com
  2. Générer et stocker un keytab Kerberos pour le service sur le client.

    [root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com
    Keytab successfully retrieved and stored in: /etc/testservice.keytab

Verification steps

  1. Affichez des informations sur un service IdM à l'aide de la commande ipa service-show.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Keytab: True
      Managed by: client.example.com
  2. Affichez le contenu de la base de données Kerberos du service avec la commande klist.

    [root@server etc]# klist -ekt /etc/testservice.keytab
    Keytab name: FILE:/etc/testservice.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)

13.4.2. Associer des indicateurs d'authentification à un service IdM à l'aide de la CLI IdM

En tant qu'administrateur Identity Management (IdM), vous pouvez configurer un hôte ou un service pour exiger qu'un ticket de service présenté par l'application cliente contienne un indicateur d'authentification spécifique. Par exemple, vous pouvez vous assurer que seuls les utilisateurs qui ont utilisé un jeton d'authentification à deux facteurs IdM valide avec leur mot de passe lors de l'obtention d'un ticket Kerberos (TGT) pourront accéder à cet hôte ou à ce service.

Cette procédure décrit la configuration d'un service pour qu'il exige des indicateurs d'authentification Kerberos particuliers dans les demandes de tickets de service entrantes.

Conditions préalables

Avertissement

Ne not assigner des indicateurs d'authentification aux services IdM internes. Les services IdM suivants ne peuvent pas effectuer les étapes d'authentification interactive requises par PKINIT et les méthodes d'authentification multifactorielle :

host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM

Procédure

  • Utilisez la commande ipa service-mod pour spécifier un ou plusieurs indicateurs d'authentification requis pour un service, identifié par l'argument --auth-ind.

    Méthode d'authentification--auth-ind valeur

    Authentification à deux facteurs

    otp

    Authentification RADIUS

    radius

    Authentification par PKINIT, carte à puce ou certificat

    pkinit

    Mots de passe renforcés (SPAKE ou FAST)

    hardened

    Par exemple, pour exiger qu'un utilisateur ait été authentifié par carte à puce ou par OTP pour récupérer un ticket de service pour le principal testservice sur l'hôte client.example.com:

    [root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Managed by: client.example.com
Note

Pour supprimer tous les indicateurs d'authentification d'un service, il faut fournir une liste vide d'indicateurs :

[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
  Principal name: testservice/client.example.com@EXAMPLE.COM
  Principal alias: testservice/client.example.com@EXAMPLE.COM
  Managed by: client.example.com

Verification steps

  • La commande ipa service-show permet d'afficher des informations sur un service IdM, y compris les indicateurs d'authentification qu'il requiert.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Keytab: True
      Managed by: client.example.com

13.4.3. Associer des indicateurs d'authentification à un service IdM à l'aide de l'interface Web IdM

En tant qu'administrateur Identity Management (IdM), vous pouvez configurer un hôte ou un service pour qu'un ticket de service présenté par l'application cliente contienne un indicateur d'authentification spécifique. Par exemple, vous pouvez vous assurer que seuls les utilisateurs qui ont utilisé un jeton d'authentification à deux facteurs IdM valide avec leur mot de passe lors de l'obtention d'un ticket Kerberos (TGT) pourront accéder à cet hôte ou à ce service.

Cette procédure décrit comment utiliser l'interface Web IdM pour configurer un hôte ou un service afin qu'il exige des indicateurs d'authentification Kerberos particuliers pour les demandes de tickets entrantes.

Conditions préalables

  • Vous vous êtes connecté à l'interface Web IdM en tant qu'utilisateur administratif.

Procédure

  1. Sélectionner IdentitéHôtes ou D'identitéServices.
  2. Cliquez sur le nom de l'hôte ou du service requis.
  3. Sous Authentication indicators, sélectionnez la méthode d'authentification requise.

    • Par exemple, la sélection de OTP garantit que seuls les utilisateurs qui ont utilisé un jeton d'authentification à deux facteurs IdM valide avec leur mot de passe lors de l'obtention d'un TGT Kerberos pourront accéder à l'hôte ou au service.
    • Si vous sélectionnez à la fois OTP et RADIUS, les utilisateurs qui ont utilisé un jeton d'authentification à deux facteurs IdM valide avec leur mot de passe lors de l'obtention d'un TGT Kerberos and qui ont utilisé le serveur RADIUS pour obtenir leur TGT Kerberos seront autorisés à accéder à l'application.
  4. Cliquez sur Enregistrer en haut de la page.

13.4.4. Récupération d'un ticket de service Kerberos pour un service IdM

La procédure suivante décrit la récupération d'un ticket de service Kerberos pour un service IdM. Vous pouvez utiliser cette procédure pour tester les politiques relatives aux tickets Kerberos, par exemple en imposant la présence de certains indicateurs d'authentification Kerberos dans un ticket d'attribution de ticket (TGT).

Conditions préalables

Procédure

  • Utilisez la commande kvno avec l'option -S pour récupérer un ticket de service et spécifier le nom du service IdM et le nom de domaine complet de l'hôte qui le gère.

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
Note

Si vous devez accéder à un service IdM et que votre ticket d'attribution de ticket (TGT) actuel ne possède pas les indicateurs d'authentification Kerberos requis qui lui sont associés, effacez votre cache d'informations d'identification Kerberos actuel à l'aide de la commande kdestroy et récupérez un nouveau TGT :

[root@server ~]# kdestroy

Par exemple, si vous avez initialement récupéré un TGT en vous authentifiant avec un mot de passe et que vous devez accéder à un service IdM auquel est associé l'indicateur d'authentification pkinit, détruisez votre cache d'informations d'identification actuel et authentifiez-vous à nouveau avec une carte à puce. Voir les indicateurs d'authentification Kerberos.

Verification steps

  • Utilisez la commande klist pour vérifier que le ticket de service se trouve dans le cache d'informations d'identification Kerberos par défaut.

    [root@server etc]# klist_
    Ticket cache: KCM:1000
    Default principal: admin@EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    04/01/2020 12:52:42  04/02/2020 12:52:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM

13.4.5. Ressources supplémentaires

13.5. Configuration de la politique globale de cycle de vie des tickets

La politique de ticket globale s'applique à tous les tickets de service et aux utilisateurs pour lesquels aucune politique de ticket par utilisateur n'a été définie.

La procédure suivante décrit l'ajustement de la durée de vie maximale des tickets et de l'âge maximal de renouvellement des tickets pour la stratégie globale de tickets Kerberos à l'aide de la commande ipa krbtpolicy-mod.

Lors de l'utilisation de la commande ipa krbtpolicy-mod, spécifiez au moins l'un des arguments suivants :

  • --maxlife pour la durée de vie maximale du ticket en secondes
  • --maxrenew pour l'âge maximum renouvelable en secondes

Procédure

  1. Pour modifier la politique globale en matière de tickets :

    [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
      Max life: 28800
      Max renew: 86400

    In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).

  2. Facultatif : Pour rétablir les valeurs d'installation par défaut de la politique globale en matière de tickets Kerberos :

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

Verification steps

  • Afficher la politique globale en matière de tickets :

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

13.6. Configuration des politiques de tickets globales par indicateur d'authentification

Cette procédure décrit le réglage de la durée de vie maximale globale du ticket et de l'âge maximal renouvelable pour chaque indicateur d'authentification. Ces paramètres s'appliquent aux utilisateurs pour lesquels aucune politique de ticket par utilisateur n'a été définie.

Utilisez la commande ipa krbtpolicy-mod pour spécifier la durée de vie maximale globale ou l'âge maximal renouvelable des tickets Kerberos en fonction des indicateurs d'authentification qui leur sont associés.

Procédure

  • Par exemple, pour définir les valeurs globales de durée de vie et d'âge de renouvellement du ticket à deux facteurs à une semaine, et les valeurs globales de durée de vie et d'âge de renouvellement du ticket de carte à puce à deux semaines :

    [root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800

Verification steps

  • Afficher la politique globale en matière de tickets :

    [root@server ~]# ipa krbtpolicy-show
      Max life: 86400
      OTP max life: 604800
      PKINIT max life: 172800
      Max renew: 604800
      OTP max renew: 604800
      PKINIT max renew: 172800

    Notez que les valeurs OTP et PKINIT sont différentes des valeurs globales par défaut Max life et Max renew.

13.7. Configuration de la politique de billetterie par défaut pour un utilisateur

Vous pouvez définir une politique de ticket Kerberos unique qui ne s'applique qu'à un seul utilisateur. Ces paramètres par utilisateur remplacent la politique de ticket globale pour tous les indicateurs d'authentification.

Utilisez la commande ipa krbtpolicy-mod username et spécifiez au moins l'un des arguments suivants :

  • --maxlife pour la durée de vie maximale du ticket en secondes
  • --maxrenew pour l'âge maximum renouvelable en secondes

Procédure

  1. Par exemple, pour définir la durée de vie maximale du ticket de l'utilisateur IdM admin à deux jours et l'âge maximal de renouvellement à deux semaines :

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  2. Optionnel : Pour réinitialiser la politique de ticket d'un utilisateur :

    [root@server ~]# ipa krbtpolicy-reset admin

Verification steps

  • Afficher la politique de ticket Kerberos effective qui s'applique à un utilisateur :

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

13.8. Configurer des politiques de tickets d'indicateurs d'authentification individuels pour un utilisateur

En tant qu'administrateur, vous pouvez définir des politiques de tickets Kerberos pour un utilisateur qui diffèrent selon l'indicateur d'authentification. Par exemple, vous pouvez configurer une politique permettant à l'utilisateur IdM admin de renouveler un ticket pendant deux jours s'il a été obtenu par authentification OTP, et pendant une semaine s'il a été obtenu par authentification par carte à puce.

Ces paramètres par indicateur d'authentification remplaceront la politique de ticket par défaut user’s, la politique de ticket par défaut global et toute politique de ticket d'indicateur d'authentification global.

Utilisez la commande ipa krbtpolicy-mod username pour définir des valeurs personnalisées de durée de vie maximale et d'âge maximal renouvelable pour les tickets Kerberos d'un utilisateur en fonction des indicateurs d'authentification qui leur sont associés.

Procédure

  1. Par exemple, pour permettre à l'utilisateur d'IdM admin de renouveler un ticket Kerberos pendant deux jours s'il a été obtenu avec l'authentification par mot de passe à usage unique, définissez l'option --otp-maxrenew:

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  2. Optionnel : Pour réinitialiser la politique de ticket d'un utilisateur :

    [root@server ~]# ipa krbtpolicy-reset username

Verification steps

  • Afficher la politique de ticket Kerberos effective qui s'applique à un utilisateur :

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

13.9. Options de l'indicateur d'authentification pour la commande krbtpolicy-mod

Spécifiez les valeurs des indicateurs d'authentification avec les arguments suivants.

Tableau 13.1. Options de l'indicateur d'authentification pour la commande krbtpolicy-mod

Indicateur d'authentificationArgument en faveur d'une durée de vie maximaleArgument en faveur d'un âge maximal de renouvellement

otp

--otp-maxlife

--otp-maxrenew

radius

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

hardened

--hardened-maxlife

--hardened-maxrenew

Chapitre 14. Gestion des fichiers keytab Kerberos de l'IdM

La documentation suivante explique ce que sont les fichiers keytab Kerberos et comment la gestion des identités (IdM) les utilise pour permettre aux services de s'authentifier de manière sécurisée avec Kerberos.

Vous pouvez utiliser ces informations pour comprendre pourquoi vous devez protéger ces fichiers sensibles et pour résoudre les problèmes de communication entre les services IdM.

Cette section aborde les sujets suivants :

Cette section explique également comment afficher le type de cryptage de votre clé principale IdM.

14.1. Comment la gestion des identités utilise les fichiers keytab de Kerberos

Un keytab Kerberos est un fichier contenant les principaux Kerberos et les clés de chiffrement correspondantes. Les hôtes, les services, les utilisateurs et les scripts peuvent utiliser les keytabs pour s'authentifier auprès du centre de distribution de clés Kerberos (KDC) en toute sécurité, sans nécessiter d'interaction humaine.

Chaque service IdM sur un serveur IdM a un principe Kerberos unique stocké dans la base de données Kerberos. Par exemple, si les serveurs IdM east.idm.example.com et west.idm.example.com fournissent des services DNS, l'IdM crée 2 principes DNS Kerberos uniques pour identifier ces services, qui suivent la convention de dénomination <service>/host.domain.com@REALM.COM:

  • DNS/east.idm.example.com@IDM.EXAMPLE.COM
  • DNS/west.idm.example.com@IDM.EXAMPLE.COM

IdM crée un fichier keytab sur le serveur pour chacun de ces services afin de stocker une copie locale des clés Kerberos, ainsi que leur numéro de version de clé (KVNO). Par exemple, le fichier keytab par défaut /etc/krb5.keytab stocke le principal host, qui représente cette machine dans le domaine Kerberos et est utilisé pour l'authentification de connexion. Le KDC génère des clés de chiffrement pour les différents algorithmes de chiffrement qu'il prend en charge, tels que aes256-cts-hmac-sha1-96 et aes128-cts-hmac-sha1-96.

Vous pouvez afficher le contenu d'un fichier keytab à l'aide de la commande klist:

[root@idmserver ~]# klist -ekt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia128-cts-cmac)
   2 02/24/2022 20:28:09 host/idmserver.idm.example.com@IDM.EXAMPLE.COM (camellia256-cts-cmac)

14.2. Vérification de la synchronisation des fichiers keytab Kerberos avec la base de données IdM

Lorsque vous modifiez un mot de passe Kerberos, IdM génère automatiquement une nouvelle clé Kerberos correspondante et incrémente son numéro de version de clé (KVNO). Si un keytab Kerberos n'est pas mis à jour avec la nouvelle clé et le KVNO, les services qui dépendent de ce keytab pour récupérer une clé valide risquent de ne pas pouvoir s'authentifier auprès du centre de distribution de clés Kerberos (KDC).

Si l'un de vos services IdM ne peut pas communiquer avec un autre service, utilisez la procédure suivante pour vérifier que vos fichiers keytab Kerberos sont synchronisés avec les clés stockées dans la base de données IdM. S'ils ne sont pas synchronisés, récupérez un fichier keytab Kerberos avec une clé et un KVNO mis à jour. Cet exemple compare et récupère un principal DNS mis à jour pour un serveur IdM.

Conditions préalables

  • Vous devez vous authentifier en tant que compte administrateur IdM pour récupérer les fichiers keytab
  • Vous devez vous authentifier en tant que compte root pour modifier les fichiers keytab appartenant à d'autres utilisateurs

Procédure

  1. Affichez le KVNO des mandants dans le keytab que vous vérifiez. Dans l'exemple suivant, le fichier /etc/named.keytab contient la clé du principal DNS/server1.idm.example.com@EXAMPLE.COM avec un KVNO de 2.

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 11/26/2021 13:51:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. Afficher le KVNO du principal stocké dans la base de données IdM. Dans cet exemple, le KVNO de la clé dans la base de données IdM ne correspond pas au KVNO dans la base de données.

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 3
  3. S'authentifier en tant que compte administrateur IdM.

    [root@server1 ~]# kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  4. Récupérez une clé Kerberos mise à jour pour le principal et stockez-la dans son keytab. Effectuez cette étape en tant qu'utilisateur root afin de pouvoir modifier le fichier /etc/named.keytab, qui appartient à l'utilisateur named.

    [root@server1 ~]# ipa-getkeytab -s server1.idm.example.com -p DNS/server1.idm.example.com -k /etc/named.keytab

Vérification

  1. Affiche le KVNO mis à jour du principal dans la base de données des clés.

    [root@server1 ~]# klist -ekt /etc/named.keytab
    Keytab name: FILE:/etc/named.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       4 08/17/2022 14:42:11 DNS/server1.idm.example.com@EXAMPLE.COM (camellia256-cts-cmac)
  2. Afficher le KVNO du principal stocké dans la base de données IdM et s'assurer qu'il correspond au KVNO de la base de données.

    [root@server1 ~]# kvno DNS/server1.idm.example.com@EXAMPLE.COM
    DNS/server1.idm.example.com@EXAMPLE.COM: kvno = 4

14.3. Liste des fichiers keytab Kerberos de l'IdM et de leur contenu

Le tableau suivant indique l'emplacement, le contenu et l'objectif des fichiers keytab IdM Kerberos.

Tableau 14.1. Tableau

Emplacement des touchesContenuObjectif

/etc/krb5.keytab

host principal

Vérification des informations d'identification de l'utilisateur lors de la connexion, utilisée par NFS s'il n'y a pas de principal nfs

/etc/dirsrv/ds.keytab

ldap principal

Authentification des utilisateurs de la base de données IdM, réplication sécurisée du contenu de la base de données entre les répliques IdM

/var/lib/ipa/gssproxy/http.keytab

HTTP principal

Authentification au serveur Apache

/etc/named.keytab

DNS principal

Mise à jour sécurisée des enregistrements DNS

/etc/ipa/dnssec/ipa-dnskeysyncd.keytab

ipa-dnskeysyncd principal

Synchronisation d'OpenDNSSEC avec LDAP

/etc/pki/pki-tomcat/dogtag.keytab

dogtag principal

Communiquer avec l'autorité de certification (AC)

/etc/samba/samba.keytab

cifs et host directeurs d'école

Communiquer avec le service Samba

/var/lib/sss/keytabs/ad-domain.com.keytab

Contrôleurs de domaine (DC) Active Directory (AD) sous la forme suivante HOSTNAME$@AD-DOMAIN.COM

Communication avec les AD DC par l'intermédiaire d'une confiance IdM-AD

14.4. Visualisation du type de cryptage de votre clé maîtresse IdM

En tant qu'administrateur Identity Management (IdM), vous pouvez afficher le type de cryptage de votre clé principale IdM, qui est la clé que le Centre de distribution Kerberos (KDC) IdM utilise pour crypter tous les autres principaux lorsqu'ils sont stockés au repos. La connaissance du type de cryptage vous aide à déterminer la compatibilité de votre déploiement avec les normes FIPS.

À partir de RHEL 8.7, le type de chiffrement est aes256-cts-hmac-sha384-192. Ce type de chiffrement est compatible avec la politique cryptographique FIPS par défaut de RHEL 9 visant à se conformer à la norme FIPS 140-3.

Les types de chiffrement utilisés sur les versions précédentes de RHEL ne sont pas compatibles avec les systèmes RHEL 9 qui adhèrent aux normes FIPS 140-3. Pour rendre les systèmes RHEL 9 en mode FIPS compatibles avec un déploiement RHEL 8 FIPS 140-2, activez la politique cryptographique FIPS:AD-SUPPORT sur les systèmes RHEL 9.

Note

L'implémentation Active Directory de Microsoft ne prend pas encore en charge les types de chiffrement Kerberos RFC8009 qui utilisent SHA-2 HMAC. Si une confiance IdM-AD est configurée, l'utilisation de la sous-politique cryptographique FIPS:AD-SUPPORT est donc requise même si le type de chiffrement de votre clé principale IdM est aes256-cts-hmac-sha384-192.

Conditions préalables

  • Vous avez accès à root à n'importe laquelle des répliques RHEL 8 dans le déploiement IdM.

Procédure

  • Sur le réplica, affichez le type de chiffrement sur l'interface de ligne de commande :

    # kadmin.local getprinc K/M | grep -E '^Key:'
    Key: vno 1, aes256-cts-hmac-sha1-96

    La clé aes256-cts-hmac-sha1-96 dans le résultat indique que le déploiement IdM a été installé sur un serveur fonctionnant sous RHEL 8.6 ou une version antérieure. La présence d'une clé aes256-cts-hmac-sha384-192 dans le résultat indique que le déploiement de l'IdM a été installé sur un serveur exécutant RHEL 8.7 ou une version ultérieure.

Chapitre 15. Utilisation du proxy KDC dans IdM

Certains administrateurs peuvent choisir de rendre les ports Kerberos par défaut inaccessibles dans leur déploiement. Pour permettre aux utilisateurs, aux hôtes et aux services d'obtenir des informations d'identification Kerberos, vous pouvez utiliser le service HTTPS comme un proxy qui communique avec Kerberos via le port 443 de HTTPS.

Dans le cadre de la gestion de l'identité (IdM), le site Kerberos Key Distribution Center Proxy (KKDCP) offre cette fonctionnalité.

Sur un serveur IdM, KKDCP est activé par défaut et disponible à l'adresse suivante https://server.idm.example.com/KdcProxy. Sur un client IdM, vous devez modifier sa configuration Kerberos pour accéder au KKDCP.

15.1. Configuration d'un client IdM pour l'utilisation de KKDCP

En tant qu'administrateur du système de gestion des identités (IdM), vous pouvez configurer un client IdM pour qu'il utilise le Kerberos Key Distribution Center Proxy (KKDCP) sur un serveur IdM. Ceci est utile si les ports Kerberos par défaut ne sont pas accessibles sur le serveur IdM et que le port 443 de HTTPS est le seul moyen d'accéder au service Kerberos.

Conditions préalables

  • Vous avez un accès root au client IdM.

Procédure

  1. Ouvrez le fichier /etc/krb5.conf pour le modifier.
  2. Dans la section [realms], entrez l'URL du KKDCP pour les options kdc, admin_server et kpasswd_server:

    [realms]
    EXAMPLE.COM = {
      kdc = https://kdc.example.com/KdcProxy
      admin_server = https://kdc.example.com/KdcProxy
      kpasswd_server = https://kdc.example.com/KdcProxy
      default_domain = example.com
    }

    Pour des raisons de redondance, vous pouvez ajouter les paramètres kdc, admin_server, et kpasswd_server plusieurs fois pour indiquer différents serveurs KKDCP.

  3. Redémarrez le service sssd pour que les modifications soient prises en compte :

    ~]# systemctl restart sssd

15.2. Vérification de l'activation de KKDCP sur un serveur IdM

Sur un serveur Identity Management (IdM), le Kerberos Key Distribution Center Proxy (KKDCP) est automatiquement activé à chaque démarrage du serveur web Apache si la paire d'attributs et de valeurs ipaConfigString=kdcProxyEnabled existe dans le répertoire. Dans ce cas, le lien symbolique /etc/httpd/conf.d/ipa-kdc-proxy.conf est créé.

Vous pouvez vérifier si le KKDCP est activé sur le serveur IdM, même en tant qu'utilisateur non privilégié.

Procédure

  • Vérifiez que le lien symbolique existe :
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

La sortie confirme que le KKDCP est activé.

15.3. Désactivation de KKDCP sur un serveur IdM

En tant qu'administrateur du système de gestion des identités (IdM), vous pouvez désactiver le Kerberos Key Distribution Center Proxy (KKDCP) sur un serveur IdM.

Conditions préalables

  • Vous avez un accès root au serveur IdM.

Procédure

  1. Supprimer la paire d'attributs et de valeurs ipaConfigString=kdcProxyEnabled du répertoire :

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-disable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. Redémarrez le service httpd:

    # systemctl restart httpd.service

KKDCP est maintenant désactivé sur le serveur IdM actuel.

Verification steps

  • Vérifiez que le lien symbolique n'existe pas :

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    ls: cannot access '/etc/httpd/conf.d/ipa-kdc-proxy.conf': No such file or directory

15.4. Réactivation de KKDCP sur un serveur IdM

Sur un serveur IdM, le Kerberos Key Distribution Center Proxy (KKDCP) est activé par défaut et disponible à l'adresse suivante https://server.idm.example.com/KdcProxy.

Si KKDCP a été désactivé sur un serveur, vous pouvez le réactiver.

Conditions préalables

  • Vous avez un accès root au serveur IdM.

Procédure

  1. Ajoutez la paire d'attributs et de valeurs ipaConfigString=kdcProxyEnabled au répertoire :

    # ipa-ldap-updater /usr/share/ipa/kdcproxy-enable.uldif
    Update complete
    The ipa-ldap-updater command was successful
  2. Redémarrez le service httpd:

    # systemctl restart httpd.service

KKDCP est maintenant activé sur le serveur IdM actuel.

Verification steps

  • Vérifiez que le lien symbolique existe :

    $ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf
    lrwxrwxrwx. 1 root root 36 Jun 21  2020 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf

15.5. Configuration du serveur KKDCP I

La configuration suivante permet d'utiliser TCP comme protocole de transport entre le KKDCP de l'IdM et le domaine Active Directory (AD), lorsque plusieurs serveurs Kerberos sont utilisés.

Conditions préalables

  • Vous avez accès à root.

Procédure

  1. Dans la section [global] du fichier /etc/ipa/kdcproxy/kdcproxy.conf, le paramètre use_dns doit être réglé sur false.

    [global]
    use_dns = false
  2. Placez les informations relatives à la zone mandataire dans le fichier /etc/ipa/kdcproxy/kdcproxy.conf. Par exemple, pour la zone [AD.EXAMPLE.COM] avec proxy, listez les paramètres de configuration de la zone comme suit :

    [AD.EXAMPLE.COM]
    kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88
    kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
    Important

    Les paramètres de configuration du domaine doivent énumérer plusieurs serveurs séparés par un espace, contrairement à /etc/krb5.conf et kdc.conf, dans lesquels certaines options peuvent être spécifiées plusieurs fois.

  3. Redémarrer les services de gestion des identités (IdM) :

    # ipactl restart

Ressources supplémentaires

15.6. Configuration du serveur KKDCP II

La configuration de serveur suivante s'appuie sur les enregistrements du service DNS pour trouver les serveurs Active Directory (AD) avec lesquels communiquer.

Conditions préalables

  • Vous avez accès à root.

Procédure

  1. Dans le fichier /etc/ipa/kdcproxy/kdcproxy.conf, à la section [global], le paramètre use_dns est remplacé par true.

    [global]
    configs = mit
    use_dns = true

    Le paramètre configs permet de charger d'autres modules de configuration. Dans ce cas, la configuration est lue à partir de la bibliothèque MIT libkrb5.

  2. Optional: Si vous ne souhaitez pas utiliser les enregistrements de service DNS, ajoutez des serveurs AD explicites à la section [realms] du fichier /etc/krb5.conf. Si le domaine avec proxy est, par exemple, AD.EXAMPLE.COM, vous ajoutez :

    [realms]
    AD.EXAMPLE.COM = {
        kdc = ad-server.ad.example.com
        kpasswd_server = ad-server.ad.example.com
    }
  3. Redémarrer les services de gestion des identités (IdM) :

    # ipactl restart

Ressources supplémentaires

Chapitre 16. Gérer les règles de libre-service dans l'IdM à l'aide du CLI

Ce chapitre présente les règles en libre-service dans la gestion des identités (IdM) et décrit comment créer et modifier des règles d'accès en libre-service dans l'interface de ligne de commande (CLI).

16.1. Contrôle d'accès en libre-service dans l'IdM

Les règles de contrôle d'accès en libre-service définissent les opérations qu'une entité de gestion des identités (IdM) peut effectuer sur son entrée du serveur d'annuaire IdM : par exemple, les utilisateurs IdM ont la possibilité de mettre à jour leurs propres mots de passe.

Cette méthode de contrôle permet à une entité IdM authentifiée de modifier des attributs spécifiques dans son entrée LDAP, mais n'autorise pas les opérations add ou delete sur l'ensemble de l'entrée.

Avertissement

Soyez prudent lorsque vous utilisez des règles de contrôle d'accès en libre-service : une mauvaise configuration des règles de contrôle d'accès peut entraîner une élévation involontaire des privilèges d'une entité.

16.2. Création de règles en libre-service à l'aide de l'interface de ligne de commande

Cette procédure décrit la création de règles d'accès en libre-service dans IdM à l'aide de l'interface de ligne de commande (CLI).

Conditions préalables

Procédure

  • Pour ajouter une règle de libre-service, utilisez la commande ipa selfservice-add et spécifiez les deux options suivantes :

    --permissions
    définit les autorisations read et write accordées par l'instruction de contrôle d'accès (ACI).
    --attrs
    établit la liste complète des attributs auxquels l'ACI accorde une autorisation.

Par exemple, pour créer une règle de libre-service permettant aux utilisateurs de modifier les détails de leur propre nom :

$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

16.3. Modification des règles de libre-service à l'aide de l'interface de ligne de commande

Cette procédure décrit la modification des règles d'accès en libre-service dans IdM à l'aide de l'interface de ligne de commande (CLI).

Conditions préalables

Procédure

  1. Optional: Affichez les règles de libre-service existantes à l'aide de la commande ipa selfservice-find.
  2. Optional: Affiche les détails de la règle de libre-service que vous souhaitez modifier à l'aide de la commande ipa selfservice-show.
  3. Utilisez la commande ipa selfservice-mod pour modifier une règle de libre-service.

Par exemple :

$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
Important

L'utilisation de la commande ipa selfservice-mod écrase les autorisations et les attributs définis précédemment. Il convient donc de toujours inclure la liste complète des autorisations et des attributs existants, ainsi que les nouvelles autorisations et les nouveaux attributs que vous souhaitez définir.

Verification steps

  • Utilisez la commande ipa selfservice-show pour afficher la règle de libre-service que vous avez modifiée.
$ ipa selfservice-show "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials

16.4. Suppression des règles de libre-service à l'aide de l'interface de ligne de commande

Cette procédure décrit la suppression des règles d'accès en libre-service dans IdM à l'aide de l'interface de ligne de commande (CLI).

Conditions préalables

Procédure

  • Utilisez la commande ipa selfservice-del pour supprimer une règle de libre-service.

Par exemple :

$ ipa selfservice-del "Users can manage their own name details"
-----------------------------------------------------------
Deleted selfservice "Users can manage their own name details"
-----------------------------------------------------------

Verification steps

  • Utilisez la commande ipa selfservice-find pour afficher toutes les règles de libre-service. La règle que vous venez de supprimer devrait être absente.

Chapitre 17. Gestion des règles de libre-service à l'aide de l'interface Web IdM

Ce chapitre présente les règles en libre-service dans la gestion des identités (IdM) et décrit comment créer et modifier des règles d'accès en libre-service dans l'interface web (IdM Web UI).

17.1. Contrôle d'accès en libre-service dans l'IdM

Les règles de contrôle d'accès en libre-service définissent les opérations qu'une entité de gestion des identités (IdM) peut effectuer sur son entrée du serveur d'annuaire IdM : par exemple, les utilisateurs IdM ont la possibilité de mettre à jour leurs propres mots de passe.

Cette méthode de contrôle permet à une entité IdM authentifiée de modifier des attributs spécifiques dans son entrée LDAP, mais n'autorise pas les opérations add ou delete sur l'ensemble de l'entrée.

Avertissement

Soyez prudent lorsque vous utilisez des règles de contrôle d'accès en libre-service : une mauvaise configuration des règles de contrôle d'accès peut entraîner une élévation involontaire des privilèges d'une entité.

17.2. Création de règles en libre-service à l'aide de l'interface Web IdM

Cette procédure décrit comment créer des règles d'accès en libre-service dans IdM à l'aide de l'interface web (IdM Web UI).

Conditions préalables

Procédure

  1. Ouvrez le sous-menu Role-Based Access Control dans l'onglet IPA Server et sélectionnez Self Service Permissions.
  2. Cliquez sur Add en haut à droite de la liste des règles d'accès en libre-service :

    Ajout d'une règle en libre-service

  3. La fenêtre Add Self Service Permission s'ouvre. Saisissez le nom de la nouvelle règle de libre-service dans le champ Self-service name. Les espaces sont autorisés :

    Formulaire d'ajout d'une règle en libre-service

  4. Cochez les cases en regard des attributs que vous souhaitez que les utilisateurs puissent modifier.
  5. Optional: Si un attribut auquel vous souhaitez donner accès n'est pas répertorié, vous pouvez en ajouter un :

    1. Cliquez sur le bouton Add.
    2. Saisissez le nom de l'attribut dans le champ de texte Attribute de la fenêtre suivante Add Custom Attribute.
    3. Cliquez sur le bouton OK pour ajouter l'attribut
    4. Vérifier que le nouvel attribut est sélectionné
  6. Cliquez sur le bouton Add au bas du formulaire pour enregistrer la nouvelle règle de libre-service.
    Vous pouvez également enregistrer et continuer à modifier la règle de libre-service en cliquant sur le bouton Add and Edit, ou enregistrer et ajouter d'autres règles en cliquant sur le bouton Add and Add another.

17.3. Modification des règles de libre-service à l'aide de l'interface Web IdM

Cette procédure décrit comment modifier les règles d'accès en libre-service dans IdM à l'aide de l'interface web (IdM Web UI).

Conditions préalables

Procédure

  1. Ouvrez le sous-menu Role-Based Access Control dans l'onglet IPA Server et sélectionnez Self Service Permissions.
  2. Cliquez sur le nom de la règle de libre-service que vous souhaitez modifier.

    Modification d'une règle de libre-service existante

  3. La page d'édition vous permet uniquement de modifier la liste des attributs que vous souhaitez ajouter ou supprimer de la règle de libre-service. Cochez ou décochez les cases appropriées.
  4. Cliquez sur le bouton Save pour enregistrer les modifications apportées à la règle de libre-service.

17.4. Suppression des règles de libre-service à l'aide de l'interface Web IdM

Cette procédure décrit comment supprimer les règles d'accès en libre-service dans IdM à l'aide de l'interface web (IdM Web UI).

Conditions préalables

Procédure

  1. Ouvrez le sous-menu Role-Based Access Control dans l'onglet IPA Server et sélectionnez Self Service Permissions.
  2. Cochez la case en regard de la règle que vous souhaitez supprimer, puis cliquez sur le bouton Delete à droite de la liste.

    Suppression d'une règle de libre-service

  3. Une boîte de dialogue s'ouvre, cliquez sur Delete pour confirmer.

Chapitre 18. Utiliser les playbooks Ansible pour gérer les règles de self-service dans l'IdM

Cette section présente les règles en libre-service dans la gestion des identités (IdM) et décrit comment créer et modifier des règles d'accès en libre-service à l'aide des playbooks Ansible. Les règles de contrôle d'accès en libre-service permettent à une entité IdM d'effectuer des opérations spécifiques sur son entrée du serveur d'annuaire IdM.

Cette section couvre les sujets suivants :

18.1. Contrôle d'accès en libre-service dans l'IdM

Les règles de contrôle d'accès en libre-service définissent les opérations qu'une entité de gestion des identités (IdM) peut effectuer sur son entrée du serveur d'annuaire IdM : par exemple, les utilisateurs IdM ont la possibilité de mettre à jour leurs propres mots de passe.

Cette méthode de contrôle permet à une entité IdM authentifiée de modifier des attributs spécifiques dans son entrée LDAP, mais n'autorise pas les opérations add ou delete sur l'ensemble de l'entrée.

Avertissement

Soyez prudent lorsque vous utilisez des règles de contrôle d'accès en libre-service : une mauvaise configuration des règles de contrôle d'accès peut entraîner une élévation involontaire des privilèges d'une entité.

18.2. Utiliser Ansible pour s'assurer qu'une règle de libre-service est présente

La procédure suivante décrit comment utiliser un playbook Ansible pour définir des règles de libre-service et assurer leur présence sur un serveur de gestion des identités (IdM). Dans cet exemple, la nouvelle règle Users can manage their own name details permet aux utilisateurs de modifier leurs propres attributs givenname, displayname, title et initials. Cela leur permet, par exemple, de modifier leur nom d'affichage ou leurs initiales s'ils le souhaitent.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'au répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Faites une copie du fichier selfservice-present.yml situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-present.yml selfservice-present-copy.yml
  3. Ouvrez le fichier selfservice-present-copy.yml Ansible playbook pour l'éditer.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaselfservice task :

    • Définissez la variable ipaadmin_password avec le mot de passe de l'administrateur IdM.
    • Définissez la variable name avec le nom de la nouvelle règle de libre-service.
    • Attribuez à la variable permission une liste de permissions à accorder, séparées par des virgules : read et write.
    • Définissez la variable attribute avec une liste d'attributs que les utilisateurs peuvent gérer eux-mêmes : givenname, displayname, title, et initials.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Self-service present
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is present
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          permission: read, write
          attribute:
          - givenname
          - displayname
          - title
          - initials
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-present-copy.yml

Ressources supplémentaires

18.3. Utiliser Ansible pour s'assurer qu'une règle de libre-service est absente

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer qu'une règle de libre-service spécifiée est absente de votre configuration IdM. L'exemple ci-dessous décrit comment s'assurer que la règle de libre-service Users can manage their own name details n'existe pas dans IdM. Cela garantit que les utilisateurs ne peuvent pas, par exemple, modifier leur propre nom d'affichage ou leurs initiales.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'au répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Faites une copie du fichier selfservice-absent.yml situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-absent.yml selfservice-absent-copy.yml
  3. Ouvrez le fichier selfservice-absent-copy.yml Ansible playbook pour l'éditer.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaselfservice task :

    • Définissez la variable ipaadmin_password avec le mot de passe de l'administrateur IdM.
    • Définissez la variable name avec le nom de la règle de libre-service.
    • Fixer la variable state à absent.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Self-service absent
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure self-service rule "Users can manage their own name details" is absent
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          state: absent
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-absent-copy.yml

Ressources supplémentaires

  • Voir Contrôle d'accès en libre-service dans IdM.
  • Voir le fichier README-selfservice.md dans le répertoire /usr/share/doc/ansible-freeipa/.
  • Voir les exemples de playbooks dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice.

18.4. Utiliser Ansible pour s'assurer qu'une règle de libre-service possède des attributs spécifiques

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer qu'une règle de libre-service existante possède des paramètres spécifiques. Dans l'exemple, vous vous assurez que la règle de libre-service Users can manage their own name details possède également l'attribut de membre surname.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • La règle de libre-service Users can manage their own name details existe dans IdM.

Procédure

  1. Naviguez jusqu'au répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Faites une copie du fichier selfservice-member-present.yml situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-present.yml selfservice-member-present-copy.yml
  3. Ouvrez le fichier selfservice-member-present-copy.yml Ansible playbook pour l'éditer.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaselfservice task :

    • Définissez la variable ipaadmin_password avec le mot de passe de l'administrateur IdM.
    • Définissez la variable name avec le nom de la règle de libre-service à modifier.
    • Fixer la variable attribute à surname.
    • Fixer la variable action à member.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Self-service member present
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attribute surname is present
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          attribute:
          - surname
          action: member
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-member-present-copy.yml

Ressources supplémentaires

  • Voir Contrôle d'accès en libre-service dans IdM.
  • Voir le fichier README-selfservice.md disponible dans le répertoire /usr/share/doc/ansible-freeipa/.
  • Voir les exemples de playbooks dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice.

18.5. Utiliser Ansible pour s'assurer qu'une règle de libre-service n'a pas d'attributs spécifiques

La procédure suivante décrit comment utiliser une séquence Ansible pour s'assurer qu'une règle de libre-service n'a pas de paramètres spécifiques. Vous pouvez utiliser ce livre de lecture pour vous assurer qu'une règle de libre-service n'accorde pas d'accès indésirable. Dans l'exemple, vous vous assurez que la règle de libre-service Users can manage their own name details n'a pas les attributs de membre givenname et surname.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • La règle de libre-service Users can manage their own name details existe dans IdM.

Procédure

  1. Naviguez jusqu'au répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Faites une copie du fichier selfservice-member-absent.yml situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/selfservice/selfservice-member-absent.yml selfservice-member-absent-copy.yml
  3. Ouvrez le fichier selfservice-member-absent-copy.yml Ansible playbook pour l'éditer.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaselfservice task :

    • Définissez la variable ipaadmin_password avec le mot de passe de l'administrateur IdM.
    • Définissez la variable name avec le nom de la règle de libre-service que vous souhaitez modifier.
    • Fixez la variable attribute à givenname et surname.
    • Fixer la variable action à member.
    • Fixer la variable state à absent.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Self-service member absent
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure selfservice "Users can manage their own name details" member attributes givenname and surname are absent
        ipaselfservice:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: "Users can manage their own name details"
          attribute:
          - givenname
          - surname
          action: member
          state: absent
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory selfservice-member-absent-copy.yml

Ressources supplémentaires

  • Voir Contrôle d'accès en libre-service dans IdM.
  • Voir le fichier README-selfservice.md dans le répertoire /usr/share/doc/ansible-freeipa/.
  • Voir les exemples de playbooks dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/selfservice.

Chapitre 19. Gestion des groupes d'utilisateurs dans l'interface CLI de l'IdM

Ce chapitre présente la gestion des groupes d'utilisateurs à l'aide de la CLI IdM.

Un groupe d'utilisateurs est un ensemble d'utilisateurs ayant des privilèges, des politiques de mot de passe et d'autres caractéristiques communes.

Dans le cadre de la gestion des identités (IdM), un groupe d'utilisateurs peut inclure :

  • Utilisateurs de l'IdM
  • d'autres groupes d'utilisateurs de l'IdM
  • les utilisateurs externes, c'est-à-dire les utilisateurs qui existent en dehors de l'IdM

19.1. Les différents types de groupes dans l'IdM

IdM prend en charge les types de groupes suivants :

Groupes POSIX (par défaut)

Les groupes POSIX prennent en charge les attributs Linux POSIX pour leurs membres. Notez que les groupes qui interagissent avec Active Directory ne peuvent pas utiliser les attributs POSIX.

Les attributs POSIX identifient les utilisateurs en tant qu'entités distinctes. Parmi les exemples d'attributs POSIX concernant les utilisateurs, on peut citer uidNumber, un numéro d'utilisateur (UID), et gidNumber, un numéro de groupe (GID).

Groupes non-POSIX

Les groupes non-POSIX ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tous les membres de ce type de groupe doivent appartenir au domaine IdM.

Groupes externes

Utilisez les groupes externes pour ajouter des membres de groupes qui existent dans un magasin d'identité en dehors du domaine IdM, par exemple :

  • Un système local
  • Un domaine Active Directory
  • Un service d'annuaire

Les groupes externes ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tableau 19.1. Groupes d'utilisateurs créés par défaut

Nom du groupeMembres du groupe par défaut

ipausers

Tous les utilisateurs de l'IdM

admins

Utilisateurs disposant de privilèges administratifs, y compris l'utilisateur par défaut admin

editors

Il s'agit d'un groupe ancien qui ne bénéficie plus de privilèges particuliers

trust admins

Utilisateurs ayant des privilèges pour gérer les trusts Active Directory

Lorsque vous ajoutez un utilisateur à un groupe d'utilisateurs, celui-ci bénéficie des privilèges et des règles associés au groupe. Par exemple, pour accorder des privilèges administratifs à un utilisateur, ajoutez-le au groupe admins.

Avertissement

Ne pas supprimer le groupe admins. Comme admins est un groupe prédéfini requis par IdM, cette opération pose des problèmes avec certaines commandes.

En outre, IdM crée user private groups par défaut chaque fois qu'un nouvel utilisateur est créé dans IdM. Pour plus d'informations sur les groupes privés, voir Ajouter des utilisateurs sans groupe privé.

19.2. Membres directs et indirects du groupe

Les attributs des groupes d'utilisateurs dans l'IdM s'appliquent à la fois aux membres directs et indirects : lorsque le groupe B est membre du groupe A, tous les utilisateurs du groupe B sont considérés comme des membres indirects du groupe A.

Par exemple, dans le diagramme suivant :

  • L'utilisateur 1 et l'utilisateur 2 sont direct members du groupe A.
  • L'utilisateur 3, l'utilisateur 4 et l'utilisateur 5 sont indirect members du groupe A.

Figure 19.1. Appartenance directe et indirecte à un groupe

A chart with Group A (with 2 users) and Group B (with 3 users). Group B is nested inside Group A so Group A contains a total of 5 users.

Si vous définissez une politique de mot de passe pour le groupe d'utilisateurs A, cette politique s'applique également à tous les utilisateurs du groupe d'utilisateurs B.

19.3. Ajout d'un groupe d'utilisateurs à l'aide de la CLI IdM

Cette section décrit comment ajouter un groupe d'utilisateurs à l'aide de la CLI IdM.

Conditions préalables

Procédure

  • Ajoutez un groupe d'utilisateurs à l'aide de la commande ipa group-add group_name pour ajouter un groupe d'utilisateurs. Par exemple, pour créer le groupe_a :

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    Par défaut, ipa group-add ajoute un groupe d'utilisateurs POSIX. Pour spécifier un autre type de groupe, ajoutez des options à ipa group-add:

    Vous pouvez spécifier un GID personnalisé lors de l'ajout d'un groupe d'utilisateurs en utilisant l'option --gid=custom_GID pour ajouter un groupe d'utilisateurs. Dans ce cas, veillez à éviter les conflits d'identifiants. Si vous ne spécifiez pas de GID personnalisé, IdM attribue automatiquement un GID à partir de la plage d'ID disponible.

Avertissement

N'ajoutez pas de groupes locaux à IdM. Le commutateur de service de noms (NSS) résout toujours les utilisateurs et les groupes IdM avant de résoudre les utilisateurs et les groupes locaux. Cela signifie, par exemple, que l'appartenance à un groupe IdM ne fonctionne pas pour les utilisateurs locaux.

19.4. Recherche de groupes d'utilisateurs à l'aide de la CLI IdM

Cette section décrit comment rechercher des groupes d'utilisateurs existants à l'aide de l'interface CLI de l'IdM.

Procédure

  • Affichez tous les groupes d'utilisateurs à l'aide de la commande ipa group-find. Pour spécifier un type de groupe, ajoutez des options à ipa group-find:

    • Affichez tous les groupes POSIX à l'aide de la commande ipa group-find --posix.
    • Affichez tous les groupes non-POSIX à l'aide de la commande ipa group-find --nonposix.
    • Affichez tous les groupes externes à l'aide de la commande ipa group-find --external.

      Pour plus d'informations sur les différents types de groupes, voir Les différents types de groupes dans IdM.

19.5. Suppression d'un groupe d'utilisateurs à l'aide de la CLI IdM

Cette section décrit comment supprimer un groupe d'utilisateurs à l'aide de l'interface CLI de l'IdM. Notez que la suppression d'un groupe ne supprime pas les membres du groupe de l'IdM.

Conditions préalables

Procédure

  • Supprimez un groupe d'utilisateurs à l'aide de la commande ipa group-del group_name pour supprimer un groupe d'utilisateurs. Par exemple, pour supprimer le groupe_a :

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

19.6. Ajout d'un membre à un groupe d'utilisateurs à l'aide de la CLI IdM

Cette section décrit comment ajouter un membre à un groupe d'utilisateurs à l'aide de la CLI IdM. Vous pouvez ajouter des utilisateurs et des groupes d'utilisateurs en tant que membres d'un groupe d'utilisateurs. Pour plus d'informations, voir Les différents types de groupes dans IdM et Les membres directs et indirects d'un groupe.

Conditions préalables

Procédure

  • Ajoutez un membre à un groupe d'utilisateurs à l'aide de la commande ipa group-add-member.

    Spécifiez le type de membre à l'aide de ces options :

    • --users ajoute un utilisateur IdM
    • --external ajoute un utilisateur qui existe en dehors du domaine IdM, au format DOMAIN\user_name ou user_name@domain
    • --groups ajoute un groupe d'utilisateurs IdM

    Par exemple, pour ajouter le groupe_b comme membre du groupe_a :

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    Les membres du groupe_b sont désormais des membres indirects du groupe_a.

Important

Lorsque vous ajoutez un groupe en tant que membre d'un autre groupe, ne créez pas de groupes récursifs. Par exemple, si le groupe A est membre du groupe B, n'ajoutez pas le groupe B comme membre du groupe A. Les groupes récursifs peuvent avoir un comportement imprévisible.

Note

Après avoir ajouté un membre à un groupe d'utilisateurs, la mise à jour peut prendre un certain temps avant de se propager à tous les clients de votre environnement de gestion des identités. En effet, lorsqu'un hôte donné résout des utilisateurs, des groupes et des groupes nets, le site System Security Services Daemon (SSSD) consulte d'abord son cache et n'effectue des recherches sur le serveur qu'en cas d'enregistrements manquants ou périmés.

19.7. Ajout d'utilisateurs sans groupe privé d'utilisateurs

Par défaut, l'IdM crée des groupes privés d'utilisateurs (UPG) chaque fois qu'un nouvel utilisateur est créé dans l'IdM. Les UPG sont un type de groupe spécifique :

  • L'UPG porte le même nom que l'utilisateur nouvellement créé.
  • L'utilisateur est le seul membre de l'UPG. L'UPG ne peut pas contenir d'autres membres.
  • Le GID du groupe privé correspond à l'UID de l'utilisateur.

Il est toutefois possible d'ajouter des utilisateurs sans créer de GUP.

19.7.1. Utilisateurs sans groupe privé d'utilisateurs

Si un groupe NIS ou un autre groupe système utilise déjà le GID qui serait attribué à un groupe privé d'utilisateurs, il faut éviter de créer un UPG.

Vous pouvez le faire de deux manières :

Dans les deux cas, l'IdM exigera la spécification d'un GID lors de l'ajout de nouveaux utilisateurs, sinon l'opération échouera. En effet, l'IdM a besoin d'un GID pour le nouvel utilisateur, mais le groupe d'utilisateurs par défaut ipausers est un groupe non-POSIX et n'a donc pas de GID associé. Le GID que vous spécifiez ne doit pas nécessairement correspondre à un groupe déjà existant.

Note

La spécification du GID ne crée pas de nouveau groupe. Elle définit uniquement l'attribut GID pour le nouvel utilisateur, car cet attribut est requis par l'IdM.

19.7.2. Ajout d'un utilisateur sans groupe privé lorsque les groupes privés sont globalement activés

Vous pouvez ajouter un utilisateur sans créer de groupe privé d'utilisateurs (UPG), même si les UPG sont activés sur le système. Pour ce faire, vous devez définir manuellement un GID pour le nouvel utilisateur. Pour plus de détails sur les raisons de cette opération, voir Utilisateurs sans groupe privé d'utilisateurs.

Procédure

  • Pour empêcher l'IdM de créer un UPG, ajoutez l'option --noprivate à la commande ipa user-add.

    Notez que pour que la commande aboutisse, vous devez spécifier un GID personnalisé. Par exemple, pour ajouter un nouvel utilisateur avec le GID 10000 :

    $ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

19.7.3. Désactivation globale des groupes privés d'utilisateurs pour tous les utilisateurs

Vous pouvez désactiver globalement les groupes privés d'utilisateurs (UPG). Cela empêche la création de groupes privés d'utilisateurs pour tous les nouveaux utilisateurs. Les utilisateurs existants ne sont pas affectés par cette modification.

Procédure

  1. Obtenir les privilèges d'administrateur :

    kinit admin
  2. IdM utilise le plug-in Directory Server Managed Entries pour gérer les UPG. Dressez la liste des instances du plug-in :

    $ ipa-managed-entries --list
  3. Pour s'assurer que IdM ne crée pas d'UPG, désactivez l'instance de plug-in responsable de la gestion des groupes privés d'utilisateurs :

    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    Note

    Pour réactiver l'instance UPG Definition ultérieurement, utilisez la commande ipa-managed-entries -e "UPG Definition" enable.

  4. Redémarrez Directory Server pour charger la nouvelle configuration.

    sudo systemctl restart dirsrv.target

    Pour ajouter un utilisateur après la désactivation des UPG, vous devez spécifier un GID. Pour plus d'informations, voir Ajouter un utilisateur lorsque les groupes privés d'utilisateurs sont globalement désactivés

Verification steps

  • Pour vérifier si les UPG sont globalement désactivés, utilisez à nouveau la commande disable :

    $ ipa-managed-entries -e "UPG Definition" disable
    Plugin already disabled

19.7.4. Ajout d'un utilisateur lorsque les groupes privés d'utilisateurs sont globalement désactivés

Lorsque les groupes privés d'utilisateurs (UPG) sont désactivés globalement, l'IdM n'attribue pas automatiquement un GID à un nouvel utilisateur. Pour ajouter un utilisateur avec succès, vous devez attribuer un GID manuellement ou à l'aide d'une règle automember. Pour plus d'informations, voir Utilisateurs sans groupe privé d'utilisateurs.

Conditions préalables

Procédure

  • Pour s'assurer que l'ajout d'un nouvel utilisateur réussit lorsque la création d'UPG est désactivée, choisissez l'une des options suivantes :

    • Spécifiez un GID personnalisé lors de l'ajout d'un nouvel utilisateur. Le GID ne doit pas nécessairement correspondre à un groupe d'utilisateurs existant.

      Par exemple, lorsque vous ajoutez un utilisateur à partir de la ligne de commande, ajoutez l'option --gid à la commande ipa user-add.

    • Utilisez une règle automember pour ajouter l'utilisateur à un groupe existant avec un GID.

19.8. Ajout d'utilisateurs ou de groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de la CLI IdM

Cette section décrit comment ajouter des utilisateurs ou des groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de la CLI IdM. Les gestionnaires membres peuvent ajouter des utilisateurs ou des groupes aux groupes d'utilisateurs IdM, mais ne peuvent pas modifier les attributs d'un groupe.

Conditions préalables

  • Vous devez être connecté en tant qu'administrateur. Pour plus de détails, voir Utilisation de kinit pour se connecter manuellement à l'IdM.
  • Vous devez disposer du nom de l'utilisateur ou du groupe que vous ajoutez en tant que membres gestionnaires et du nom du groupe que vous souhaitez qu'ils gèrent.

Procédure

  • Ajouter un utilisateur en tant que gestionnaire membre d'un groupe d'utilisateurs IdM à l'aide de la commande ipa group-add-member-manager.

    Par exemple, pour ajouter l'utilisateur test en tant que membre gestionnaire de group_a:

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    L'utilisateur test peut désormais gérer les membres de group_a.

  • Ajouter un groupe en tant que gestionnaire membre d'un groupe d'utilisateurs IdM à l'aide de la commande ipa group-add-member-manager.

    Par exemple, pour ajouter le groupe group_admins en tant que gestionnaire membre de group_a:

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    Le groupe group_admins peut désormais gérer les membres de group_a.

Note

Après avoir ajouté un gestionnaire membre à un groupe d'utilisateurs, la mise à jour peut prendre un certain temps avant de se propager à tous les clients de votre environnement de gestion des identités.

Verification steps

  • Utiliser la commande ipa group-show pour vérifier que l'utilisateur et le groupe ont été ajoutés en tant que gestionnaires membres.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

Ressources supplémentaires

  • Voir ipa group-add-member-manager --help pour plus de détails.

19.9. Visualisation des membres d'un groupe à l'aide de la CLI IdM

Cette section décrit comment visualiser les membres d'un groupe à l'aide de l'interface CLI de l'IdM. Vous pouvez visualiser les membres directs et indirects d'un groupe. Pour plus d'informations, voir Membres directs et indirects d'un groupe.

Procédure :

  • Pour dresser la liste des membres d'un groupe, utilisez la commande ipa group-show group_name pour obtenir la liste des membres d'un groupe. Par exemple :

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b
    Note

    La liste des membres indirects ne comprend pas les utilisateurs externes des domaines Active Directory de confiance. Les objets utilisateurs de confiance Active Directory ne sont pas visibles dans l'interface de gestion des identités car ils n'existent pas en tant qu'objets LDAP dans la gestion des identités.

19.10. Suppression d'un membre d'un groupe d'utilisateurs à l'aide de la CLI IdM

Cette section décrit comment supprimer un membre d'un groupe d'utilisateurs à l'aide de l'interface CLI de l'IdM.

Conditions préalables

Procédure

  1. Optional. Utilisez la commande ipa group-show pour confirmer que le groupe inclut le membre que vous souhaitez supprimer.
  2. Supprimer un membre d'un groupe d'utilisateurs à l'aide de la commande ipa group-remove-member.

    Spécifiez les membres à supprimer à l'aide de ces options :

    • --users supprime un utilisateur IdM
    • --external supprime un utilisateur qui existe en dehors du domaine IdM, sous le format DOMAIN\user_name ou user_name@domain
    • --groups supprime un groupe d'utilisateurs IdM

    Par exemple, pour supprimer user1, user2 et group1 d'un groupe appelé group_name:

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

19.11. Suppression d'utilisateurs ou de groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de la CLI IdM

Cette section décrit comment supprimer des utilisateurs ou des groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de la CLI IdM. Les gestionnaires membres peuvent supprimer des utilisateurs ou des groupes de groupes d'utilisateurs IdM, mais ne peuvent pas modifier les attributs d'un groupe.

Conditions préalables

Procédure

  • Supprimer un utilisateur en tant que gestionnaire membre d'un groupe d'utilisateurs IdM à l'aide de la commande ipa group-remove-member-manager.

    Par exemple, pour supprimer l'utilisateur test en tant que gestionnaire membre de group_a:

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    L'utilisateur test ne peut plus gérer les membres de group_a.

  • Supprimer un groupe en tant que gestionnaire membre d'un groupe d'utilisateurs IdM à l'aide de la commande ipa group-remove-member-manager.

    Par exemple, pour supprimer le groupe group_admins en tant que gestionnaire membre de group_a:

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    Le groupe group_admins ne peut plus gérer les membres de group_a.

Note

Après avoir supprimé un gestionnaire membre d'un groupe d'utilisateurs, la mise à jour peut prendre un certain temps avant de se propager à tous les clients de votre environnement de gestion des identités.

Verification steps

  • Utiliser la commande ipa group-show pour vérifier que l'utilisateur et le groupe ont été supprimés en tant que gestionnaires membres.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

Ressources supplémentaires

  • Voir ipa group-remove-member-manager --help pour plus de détails.

Chapitre 20. Gestion des groupes d'utilisateurs dans l'interface Web IdM

Ce chapitre présente la gestion des groupes d'utilisateurs à l'aide de l'interface web IdM.

Un groupe d'utilisateurs est un ensemble d'utilisateurs ayant des privilèges, des politiques de mot de passe et d'autres caractéristiques communes.

Dans le cadre de la gestion des identités (IdM), un groupe d'utilisateurs peut inclure :

  • Utilisateurs de l'IdM
  • d'autres groupes d'utilisateurs de l'IdM
  • les utilisateurs externes, c'est-à-dire les utilisateurs qui existent en dehors de l'IdM

20.1. Les différents types de groupes dans l'IdM

IdM prend en charge les types de groupes suivants :

Groupes POSIX (par défaut)

Les groupes POSIX prennent en charge les attributs Linux POSIX pour leurs membres. Notez que les groupes qui interagissent avec Active Directory ne peuvent pas utiliser les attributs POSIX.

Les attributs POSIX identifient les utilisateurs en tant qu'entités distinctes. Parmi les exemples d'attributs POSIX concernant les utilisateurs, on peut citer uidNumber, un numéro d'utilisateur (UID), et gidNumber, un numéro de groupe (GID).

Groupes non-POSIX

Les groupes non-POSIX ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tous les membres de ce type de groupe doivent appartenir au domaine IdM.

Groupes externes

Utilisez les groupes externes pour ajouter des membres de groupes qui existent dans un magasin d'identité en dehors du domaine IdM, par exemple :

  • Un système local
  • Un domaine Active Directory
  • Un service d'annuaire

Les groupes externes ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tableau 20.1. Groupes d'utilisateurs créés par défaut

Nom du groupeMembres du groupe par défaut

ipausers

Tous les utilisateurs de l'IdM

admins

Utilisateurs disposant de privilèges administratifs, y compris l'utilisateur par défaut admin

editors

Il s'agit d'un groupe ancien qui ne bénéficie plus de privilèges particuliers

trust admins

Utilisateurs ayant des privilèges pour gérer les trusts Active Directory

Lorsque vous ajoutez un utilisateur à un groupe d'utilisateurs, celui-ci bénéficie des privilèges et des règles associés au groupe. Par exemple, pour accorder des privilèges administratifs à un utilisateur, ajoutez-le au groupe admins.

Avertissement

Ne pas supprimer le groupe admins. Comme admins est un groupe prédéfini requis par IdM, cette opération pose des problèmes avec certaines commandes.

En outre, IdM crée user private groups par défaut chaque fois qu'un nouvel utilisateur est créé dans IdM. Pour plus d'informations sur les groupes privés, voir Ajouter des utilisateurs sans groupe privé.

20.2. Membres directs et indirects du groupe

Les attributs des groupes d'utilisateurs dans l'IdM s'appliquent à la fois aux membres directs et indirects : lorsque le groupe B est membre du groupe A, tous les utilisateurs du groupe B sont considérés comme des membres indirects du groupe A.

Par exemple, dans le diagramme suivant :

  • L'utilisateur 1 et l'utilisateur 2 sont direct members du groupe A.
  • L'utilisateur 3, l'utilisateur 4 et l'utilisateur 5 sont indirect members du groupe A.

Figure 20.1. Appartenance directe et indirecte à un groupe

A chart with Group A (with 2 users) and Group B (with 3 users). Group B is nested inside Group A so Group A contains a total of 5 users.

Si vous définissez une politique de mot de passe pour le groupe d'utilisateurs A, cette politique s'applique également à tous les utilisateurs du groupe d'utilisateurs B.

20.3. Ajout d'un groupe d'utilisateurs à l'aide de l'interface Web IdM

Cette section décrit comment ajouter un groupe d'utilisateurs à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Cliquez sur Identity → Groups, et sélectionnez User Groups dans la barre latérale gauche.
  2. Cliquez sur Add pour commencer à ajouter le groupe.
  3. Complétez les informations sur le groupe. Pour plus d'informations sur les types de groupes d'utilisateurs, voir Les différents types de groupes dans IdM.

    Vous pouvez spécifier un GID personnalisé pour le groupe. Dans ce cas, veillez à éviter les conflits d'identifiants. Si vous ne spécifiez pas de GID personnalisé, IdM attribue automatiquement un GID à partir de la plage d'ID disponible.

    Screenshot of the "Add user group" pop-up window with the following fields: Group name (which is a required field) - Description - Group Type - GID. The "Add" button is at the bottom.
  4. Cliquez sur Add pour confirmer.

20.4. Suppression d'un groupe d'utilisateurs à l'aide de l'interface Web IdM

Cette section décrit comment supprimer un groupe d'utilisateurs à l'aide de l'interface Web de l'IdM. Notez que la suppression d'un groupe ne supprime pas les membres du groupe de l'IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Cliquez sur Identity → Groups et sélectionnez User Groups.
  2. Sélectionnez le groupe à supprimer.
  3. Cliquez sur Delete.
  4. Cliquez sur Delete pour confirmer.

20.5. Ajouter un membre à un groupe d'utilisateurs à l'aide de l'interface Web IdM

Vous pouvez ajouter des utilisateurs et des groupes d'utilisateurs en tant que membres d'un groupe d'utilisateurs. Pour plus d'informations, voir Les différents types de groupes dans IdM et Les membres directs et indirects d'un groupe.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Cliquez sur Identity → Groups et sélectionnez User Groups dans la barre latérale gauche.
  2. Cliquez sur le nom du groupe.
  3. Sélectionnez le type de membre du groupe que vous souhaitez ajouter : Users, User Groups, ou External.

    A screenshot of the "User Group" page highlighting the three buttons for the three categories of group members you can add: "Users" - "User Groups" - "External users".
  4. Cliquez sur Add.
  5. Cochez la case à côté d'un ou plusieurs membres que vous souhaitez ajouter.
  6. Cliquez sur la flèche vers la droite pour déplacer les membres sélectionnés vers le groupe.

    A screenshot of the "Add users into user group group_a" pop-up window with a column to the left with "Available users" logins that can be checked. There is a right-arrow you can click to add users to the "Prospective" list on the right.
  7. Cliquez sur Add pour confirmer.

20.6. Ajout d'utilisateurs ou de groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de l'interface Web

Cette section décrit comment ajouter des utilisateurs ou des groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de l'interface Web. Les gestionnaires membres peuvent ajouter des utilisateurs ou des groupes aux groupes d'utilisateurs IdM, mais ne peuvent pas modifier les attributs d'un groupe.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez disposer du nom de l'utilisateur ou du groupe que vous ajoutez en tant que membres gestionnaires et du nom du groupe que vous souhaitez qu'ils gèrent.

Procédure

  1. Cliquez sur Identity → Groups et sélectionnez User Groups dans la barre latérale gauche.
  2. Cliquez sur le nom du groupe.
  3. Sélectionnez le type de gestionnaire de groupe que vous souhaitez ajouter : Users ou User Groups.

    groups add member manager
  4. Cliquez sur Add.
  5. Cochez la case à côté d'un ou plusieurs membres que vous souhaitez ajouter.
  6. Cliquez sur la flèche vers la droite pour déplacer les membres sélectionnés vers le groupe.

    groups add member managers users
  7. Cliquez sur Add pour confirmer.
Note

Après avoir ajouté un gestionnaire membre à un groupe d'utilisateurs, la mise à jour peut prendre un certain temps avant de se propager à tous les clients de votre environnement de gestion des identités.

Verification steps

  • Vérifiez que l'utilisateur ou le groupe d'utilisateurs nouvellement ajouté a été ajouté à la liste des utilisateurs ou des groupes d'utilisateurs du gestionnaire des membres :

    groups member manager added

Ressources supplémentaires

  • Voir ipa group-add-member-manager --help pour plus d'informations.

20.7. Visualisation des membres d'un groupe à l'aide de l'interface Web IdM

Cette section décrit comment visualiser les membres d'un groupe à l'aide de l'interface Web IdM. Vous pouvez afficher les membres directs et indirects d'un groupe. Pour plus d'informations, voir Membres directs et indirects d'un groupe.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Sélectionnez Identity → Groups.
  2. Sélectionnez User Groups dans la barre latérale gauche.
  3. Cliquez sur le nom du groupe que vous souhaitez consulter.
  4. Passer de Direct Membership à Indirect Membership.

    A screenshot showing radial buttons next to the "Direct Membership" and "Indirect Membership" options next to "Show Results."

20.8. Suppression d'un membre d'un groupe d'utilisateurs à l'aide de l'interface Web IdM

Cette section décrit comment supprimer un membre d'un groupe d'utilisateurs à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.

Procédure

  1. Cliquez sur Identity → Groups et sélectionnez User Groups dans la barre latérale gauche.
  2. Cliquez sur le nom du groupe.
  3. Sélectionnez le type de membre du groupe que vous souhaitez supprimer : Users, User Groups, ou External.

    A screenshot of the "User Group" page highlighting the three buttons for the three categories of group members you can add: "Users" - "User Groups" - "External users".
  4. Cochez la case en regard du membre que vous souhaitez supprimer.
  5. Cliquez sur Delete.
  6. Cliquez sur Delete pour confirmer.

20.9. Suppression d'utilisateurs ou de groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de l'interface Web

Cette section décrit comment supprimer des utilisateurs ou des groupes en tant que gestionnaires membres d'un groupe d'utilisateurs IdM à l'aide de l'interface Web. Les gestionnaires membres peuvent supprimer des utilisateurs ou des groupes de groupes d'utilisateurs IdM, mais ne peuvent pas modifier les attributs d'un groupe.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez disposer du nom de l'utilisateur ou du groupe existant que vous supprimez et du nom du groupe qu'il gère.

Procédure

  1. Cliquez sur Identity → Groups et sélectionnez User Groups dans la barre latérale gauche.
  2. Cliquez sur le nom du groupe.
  3. Sélectionnez le type de gestionnaire de membres que vous souhaitez supprimer : Users ou User Groups.

    groups add member manager
  4. Cochez la case en regard du gestionnaire de membres que vous souhaitez supprimer.
  5. Cliquez sur Delete.
  6. Cliquez sur Delete pour confirmer.
Note

Après avoir supprimé un gestionnaire membre d'un groupe d'utilisateurs, la mise à jour peut prendre un certain temps avant de se propager à tous les clients de votre environnement de gestion des identités.

Verification steps

  • Vérifiez que l'utilisateur ou le groupe d'utilisateurs a été supprimé de la liste des utilisateurs ou des groupes d'utilisateurs du gestionnaire des membres :

    groups member manager removed

Ressources supplémentaires

  • Voir ipa group-add-member-manager --help pour plus de détails.

Chapitre 21. Gérer les groupes d'utilisateurs à l'aide de playbooks Ansible

Cette section présente la gestion des groupes d'utilisateurs à l'aide des playbooks Ansible.

Un groupe d'utilisateurs est un ensemble d'utilisateurs ayant des privilèges, des politiques de mot de passe et d'autres caractéristiques communes.

Dans le cadre de la gestion des identités (IdM), un groupe d'utilisateurs peut inclure :

  • Utilisateurs de l'IdM
  • d'autres groupes d'utilisateurs de l'IdM
  • les utilisateurs externes, c'est-à-dire les utilisateurs qui existent en dehors de l'IdM

La section comprend les sujets suivants :

21.1. Les différents types de groupes dans l'IdM

IdM prend en charge les types de groupes suivants :

Groupes POSIX (par défaut)

Les groupes POSIX prennent en charge les attributs Linux POSIX pour leurs membres. Notez que les groupes qui interagissent avec Active Directory ne peuvent pas utiliser les attributs POSIX.

Les attributs POSIX identifient les utilisateurs en tant qu'entités distinctes. Parmi les exemples d'attributs POSIX concernant les utilisateurs, on peut citer uidNumber, un numéro d'utilisateur (UID), et gidNumber, un numéro de groupe (GID).

Groupes non-POSIX

Les groupes non-POSIX ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tous les membres de ce type de groupe doivent appartenir au domaine IdM.

Groupes externes

Utilisez les groupes externes pour ajouter des membres de groupes qui existent dans un magasin d'identité en dehors du domaine IdM, par exemple :

  • Un système local
  • Un domaine Active Directory
  • Un service d'annuaire

Les groupes externes ne prennent pas en charge les attributs POSIX. Par exemple, ces groupes n'ont pas de GID défini.

Tableau 21.1. Groupes d'utilisateurs créés par défaut

Nom du groupeMembres du groupe par défaut

ipausers

Tous les utilisateurs de l'IdM

admins

Utilisateurs disposant de privilèges administratifs, y compris l'utilisateur par défaut admin

editors

Il s'agit d'un groupe ancien qui ne bénéficie plus de privilèges particuliers

trust admins

Utilisateurs ayant des privilèges pour gérer les trusts Active Directory

Lorsque vous ajoutez un utilisateur à un groupe d'utilisateurs, celui-ci bénéficie des privilèges et des règles associés au groupe. Par exemple, pour accorder des privilèges administratifs à un utilisateur, ajoutez-le au groupe admins.

Avertissement

Ne pas supprimer le groupe admins. Comme admins est un groupe prédéfini requis par IdM, cette opération pose des problèmes avec certaines commandes.

En outre, IdM crée user private groups par défaut chaque fois qu'un nouvel utilisateur est créé dans IdM. Pour plus d'informations sur les groupes privés, voir Ajouter des utilisateurs sans groupe privé.

21.2. Membres directs et indirects du groupe

Les attributs des groupes d'utilisateurs dans l'IdM s'appliquent à la fois aux membres directs et indirects : lorsque le groupe B est membre du groupe A, tous les utilisateurs du groupe B sont considérés comme des membres indirects du groupe A.

Par exemple, dans le diagramme suivant :

  • L'utilisateur 1 et l'utilisateur 2 sont direct members du groupe A.
  • L'utilisateur 3, l'utilisateur 4 et l'utilisateur 5 sont indirect members du groupe A.

Figure 21.1. Appartenance directe et indirecte à un groupe

A chart with Group A (with 2 users) and Group B (with 3 users). Group B is nested inside Group A so Group A contains a total of 5 users.

Si vous définissez une politique de mot de passe pour le groupe d'utilisateurs A, cette politique s'applique également à tous les utilisateurs du groupe d'utilisateurs B.

21.3. Assurer la présence de groupes IdM et de membres de groupes à l'aide de playbooks Ansible

La procédure suivante décrit comment assurer la présence de groupes IdM et de membres de groupes - à la fois des utilisateurs et des groupes d'utilisateurs - à l'aide d'un playbook Ansible.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • Les utilisateurs que vous souhaitez référencer dans votre manuel de jeu Ansible existent dans IdM. Pour plus de détails sur la façon de garantir la présence des utilisateurs à l'aide d'Ansible, voir Gérer les comptes d'utilisateurs à l'aide de carnets de commande Ansible.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créez un fichier playbook Ansible avec les informations nécessaires sur l'utilisateur et le groupe :

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: ops
          group:
          - sysops
          - appops
  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml

Verification steps

Vous pouvez vérifier si le groupe ops contient sysops et appops en tant que membres directs et idm_user en tant que membre indirect en utilisant la commande ipa group-show:

  1. Connectez-vous à ipaserver en tant qu'administrateur :

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Afficher des informations sur ops:

    ipaserver]$ ipa group-show ops
      Group name: ops
      GID: 1234
      Member groups: sysops, appops
      Indirect Member users: idm_user

    Les groupes appops et sysops - ce dernier comprenant l'utilisateur idm_user - existent dans IdM.

Ressources supplémentaires

  • Voir le fichier Markdown de /usr/share/doc/ansible-freeipa/README-group.md.

21.4. Utiliser Ansible pour permettre aux utilisateurs AD d'administrer IdM

Cette section décrit comment utiliser un playbook Ansible pour s'assurer qu'un remplacement d'ID d'utilisateur est présent dans un groupe de gestion des identités (IdM). Le remplacement de l'ID utilisateur est le remplacement d'un utilisateur Active Directory (AD) que vous avez créé dans la vue de confiance par défaut après avoir établi une confiance avec AD. Suite à l'exécution du playbook, un utilisateur AD, par exemple un administrateur AD, est en mesure d'administrer entièrement l'IdM sans avoir deux comptes et mots de passe différents.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez installé un trust avec AD.
  • Le remplacement de l'ID de l'utilisateur AD existe déjà dans l'IdM. Si ce n'est pas le cas, créez-le avec la commande ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com commande.
  • Le groupe auquel vous ajoutez le remplacement de l'ID utilisateur existe déjà dans IdM.
  • Vous utilisez la version 4.8.7 d'IdM ou une version ultérieure. Pour connaître la version d'IdM installée sur votre serveur, entrez ipa --version.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Créez un playbook add-useridoverride-to-group.yml avec le contenu suivant :

    ---
    - name: Playbook to ensure presence of users in a group
      hosts: ipaserver
    
    
      - name: Ensure the ad_user@ad.example.com user ID override is a member of the admins group:
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: admins
          idoverrideuser:
          - ad_user@ad.example.com

    Dans l'exemple :

    • Secret123 est le mot de passe de l'IdM admin.
    • admins est le nom du groupe POSIX IdM auquel vous ajoutez l'annulation de l'ID ad_user@ad.example.com. Les membres de ce groupe disposent de tous les privilèges d'administrateur.
    • ad_user@ad.example.com est le remplacement de l'ID utilisateur d'un administrateur AD. L'utilisateur est stocké dans le domaine AD avec lequel une confiance a été établie.
  3. Enregistrer le fichier.
  4. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory add-useridoverride-to-group.yml

Ressources supplémentaires

21.5. Assurer la présence de gestionnaires membres dans les groupes d'utilisateurs IdM à l'aide de playbooks Ansible

La procédure suivante décrit comment assurer la présence des gestionnaires membres de l'IdM - à la fois les utilisateurs et les groupes d'utilisateurs - à l'aide d'un playbook Ansible.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • Vous devez disposer du nom de l'utilisateur ou du groupe que vous ajoutez en tant que membres gestionnaires et du nom du groupe que vous souhaitez qu'ils gèrent.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créer un fichier playbook Ansible avec les informations nécessaires à la gestion des utilisateurs et des membres du groupe :

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_group: group_admins
  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

Verification steps

Vous pouvez vérifier si le groupe group_a contient test en tant que gestionnaire membre et si group_admins est un gestionnaire membre de group_a en utilisant la commande ipa group-show:

  1. Connectez-vous à ipaserver en tant qu'administrateur :

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Afficher des informations sur managergroup1:

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

Ressources supplémentaires

  • Voir ipa host-add-member-manager --help.
  • Voir la page de manuel ipa.

21.6. Assurer l'absence de membres gestionnaires dans les groupes d'utilisateurs IdM à l'aide de playbooks Ansible

La procédure suivante décrit comment garantir l'absence de gestionnaires membres de l'IdM - à la fois des utilisateurs et des groupes d'utilisateurs - à l'aide d'un playbook Ansible.

Conditions préalables

  • Vous connaissez le mot de passe de l'administrateur IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.
  • Vous devez disposer du nom de l'utilisateur ou du groupe existant que vous supprimez et du nom du groupe qu'il gère.

Procédure

  1. Créez un fichier d'inventaire, par exemple inventory.file, et définissez-y ipaserver:

    [ipaserver]
    server.idm.example.com
  2. Créer un fichier playbook Ansible avec les informations nécessaires à la gestion des utilisateurs et des membres du groupe :

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
    
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. Exécutez le manuel de jeu :

    $ ansible-playbook --vault-password-file=password_file -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

Verification steps

Vous pouvez vérifier que le groupe group_a ne contient pas test en tant que gestionnaire membre et group_admins en tant que gestionnaire membre de group_a en utilisant la commande ipa group-show:

  1. Connectez-vous à ipaserver en tant qu'administrateur :

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Afficher des informations sur le groupe_a :

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

Ressources supplémentaires

  • Voir ipa host-remove-member-manager --help.
  • Voir la page de manuel ipa.

Chapitre 22. Automatisation de l'appartenance à un groupe à l'aide de la CLI IdM

L'utilisation de l'appartenance automatique à un groupe vous permet d'affecter automatiquement des utilisateurs et des hôtes à des groupes en fonction de leurs attributs. Par exemple, vous pouvez

  • Répartissez les entrées utilisateur des employés dans des groupes en fonction du responsable de l'employé, de son lieu de travail ou de tout autre attribut.
  • Divisez les hôtes en fonction de leur classe, de leur lieu de résidence ou de tout autre attribut.
  • Ajouter tous les utilisateurs ou tous les hôtes à un seul groupe global.

Ce chapitre couvre les sujets suivants :

22.1. Avantages de l'adhésion automatique à un groupe

L'utilisation de l'adhésion automatique pour les utilisateurs vous permet de

  • Reduce the overhead of manually managing group memberships

    Il n'est plus nécessaire d'affecter manuellement chaque utilisateur et chaque hôte à des groupes.

  • Improve consistency in user and host management

    Les utilisateurs et les hôtes sont affectés à des groupes sur la base de critères strictement définis et évalués automatiquement.

  • Simplify the management of group-based settings

    Divers paramètres sont définis pour les groupes, puis appliqués aux membres individuels du groupe, par exemple les règles sudo, l'automount ou le contrôle d'accès. L'ajout automatique d'utilisateurs et d'hôtes à des groupes facilite la gestion de ces paramètres.

22.2. Règles de l'Automember

Lors de la configuration de l'appartenance automatique à un groupe, l'administrateur définit des règles d'appartenance automatique. Une règle automember s'applique à un groupe cible d'utilisateurs ou d'hôtes spécifique. Elle ne peut pas s'appliquer à plusieurs groupes à la fois.

Après avoir créé une règle, l'administrateur y ajoute des conditions. Celles-ci précisent quels utilisateurs ou hôtes sont inclus ou exclus du groupe cible :

  • Inclusive conditions

    Lorsqu'une entrée utilisateur ou hôte remplit une condition d'inclusion, elle est incluse dans le groupe cible.

  • Exclusive conditions

    Lorsqu'une entrée utilisateur ou hôte remplit une condition d'exclusivité, elle n'est pas incluse dans le groupe cible.

Les conditions sont spécifiées sous forme d'expressions régulières au format PCRE (Perl-compatible regular expressions). Pour plus d'informations sur PCRE, voir la page de manuel pcresyntax(3).

Note

L'IdM évalue les conditions exclusives avant les conditions inclusives. En cas de conflit, les conditions exclusives l'emportent sur les conditions inclusives.

Une règle automember s'applique à toutes les entrées créées à l'avenir. Ces entrées seront automatiquement ajoutées au groupe cible spécifié. Si une entrée remplit les conditions spécifiées dans plusieurs règles automember, elle sera ajoutée à tous les groupes correspondants.

Les entrées existantes sont not affectées par la nouvelle règle. Si vous souhaitez modifier des entrées existantes, reportez-vous à la section Application des règles automember aux entrées existantes à l'aide de l'interface CLI de l'IdM.

22.3. Ajout d'une règle d'appartenance automatique à l'aide de la CLI d'IdM

Cette section décrit l'ajout d'une règle de membre automatique à l'aide de l'interface CLI de l'IdM. Pour plus d'informations sur les règles d'appartenance à un groupe, voir Règles d'appartenance à un groupe.

Après avoir ajouté une règle automember, vous pouvez y ajouter des conditions en suivant la procédure décrite dans la section Ajout d'une condition à une règle automember.

Note

Les entrées existantes sont not affectées par la nouvelle règle. Si vous souhaitez modifier des entrées existantes, reportez-vous à la section Application des règles automember aux entrées existantes à l'aide de l'interface CLI de l'IdM.

Conditions préalables

Procédure

  1. Entrez la commande ipa automember-add pour ajouter une règle automember.
  2. Lorsque vous y êtes invité, précisez :

    • Automember rule. Il s'agit du nom du groupe cible.
    • Grouping Type. Ceci indique si la règle cible un groupe d'utilisateurs ou un groupe d'hôtes. Pour cibler un groupe d'utilisateurs, entrez group. Pour cibler un groupe d'hôtes, entrez hostgroup.

    Par exemple, pour ajouter une règle automember pour un groupe d'utilisateurs nommé user_group:

    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
        Automember Rule: user_group

Verification steps

22.4. Ajout d'une condition à une règle de membre automatique à l'aide de la CLI IdM

Cette section décrit comment ajouter une condition à une règle automember à l'aide de l'interface CLI de l'IdM. Pour plus d'informations sur les règles d'appartenance à un groupe, voir Règles d'appartenance à un groupe.

Conditions préalables

Procédure

  1. Définissez une ou plusieurs conditions inclusives ou exclusives à l'aide de la commande ipa automember-add-condition.
  2. Lorsque vous y êtes invité, précisez :

    • Automember rule. Il s'agit du nom de la règle cible. Voir Règles Automember pour plus de détails.
    • Attribute Key. Ceci spécifie l'attribut d'entrée auquel le filtre s'appliquera. Par exemple, uid pour les utilisateurs.
    • Grouping Type. Ceci indique si la règle cible un groupe d'utilisateurs ou un groupe d'hôtes. Pour cibler un groupe d'utilisateurs, entrez group. Pour cibler un groupe d'hôtes, entrez hostgroup.
    • Inclusive regex et Exclusive regex. Elles spécifient une ou plusieurs conditions sous forme d'expressions régulières. Si vous ne souhaitez spécifier qu'une seule condition, appuyez sur Enter lorsque vous êtes invité à spécifier l'autre condition.

    Par exemple, la condition suivante vise tous les utilisateurs ayant une valeur quelconque (.*) dans leur attribut de connexion (uid).

    $ ipa automember-add-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ----------------------------------
    Added condition(s) to "user_group"
    ----------------------------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------

    Autre exemple, vous pouvez utiliser une règle d'appartenance automatique pour cibler tous les utilisateurs Windows synchronisés à partir d'Active Directory (AD). objectClass Pour ce faire, créez une condition qui cible tous les utilisateurs dont l'attribut ntUser est partagé par tous les utilisateurs AD :

    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------

Verification steps

22.5. Visualisation des règles existantes pour les membres automatiques à l'aide de la CLI IdM

Cette section décrit comment visualiser les règles automember existantes à l'aide de la CLI IdM.

Conditions préalables

Procédure

  1. Entrez la commande ipa automember-find.
  2. Lorsque vous y êtes invité, indiquez l'adresse Grouping type:

    • Pour cibler un groupe d'utilisateurs, entrez group.
    • Pour cibler un groupe d'hôtes, entrez hostgroup.

      Par exemple :

    $ ipa automember-find
    Grouping Type: group
    ---------------
    1 rules matched
    ---------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of entries returned 1
    ----------------------------

22.6. Suppression d'une règle automember à l'aide de la CLI IdM

Cette section décrit comment supprimer une règle automember à l'aide de l'interface CLI de l'IdM.

La suppression d'une règle membre automatique supprime également toutes les conditions associées à la règle. Pour supprimer uniquement des conditions spécifiques d'une règle, voir Suppression d'une condition d'une règle automember à l'aide de l'interface CLI d'IdM.

Conditions préalables

Procédure

  1. Entrez la commande ipa automember-del.
  2. Lorsque vous y êtes invité, précisez :

    • Automember rule. Il s'agit de la règle que vous souhaitez supprimer.
    • Grouping rule. Indique si la règle à supprimer concerne un groupe d'utilisateurs ou un groupe d'hôtes. Saisissez group ou hostgroup.

22.7. Suppression d'une condition d'une règle de membre automatique à l'aide de l'interface CLI de l'IdM

Cette section explique comment supprimer une condition spécifique d'une règle automember.

Conditions préalables

Procédure

  1. Entrez la commande ipa automember-remove-condition.
  2. Lorsque vous y êtes invité, précisez :

    • Automember rule. Il s'agit du nom de la règle dont vous souhaitez supprimer une condition.
    • Attribute Key. Il s'agit de l'attribut de l'entrée cible. Par exemple, uid pour les utilisateurs.
    • Grouping Type. Indique si la condition à supprimer concerne un groupe d'utilisateurs ou un groupe d'hôtes. Saisissez group ou hostgroup.
    • Inclusive regex et Exclusive regex. Ils indiquent les conditions que vous souhaitez supprimer. Si vous ne souhaitez spécifier qu'une seule condition, appuyez sur Enter lorsque l'on vous demande l'autre condition.

      Par exemple :

    $ ipa automember-remove-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    -----------------------------------
    Removed condition(s) from "user_group"
    -----------------------------------
      Automember Rule: user_group
    ------------------------------
    Number of conditions removed 1
    ------------------------------

22.8. Appliquer des règles d'appartenance automatique à des entrées existantes à l'aide de l'interface CLI de l'IdM

Les règles Automember s'appliquent automatiquement aux entrées utilisateur et hôte créées après l'ajout des règles. Elles ne s'appliquent pas rétroactivement aux entrées qui existaient avant l'ajout des règles.

Pour appliquer les règles d'automember aux entrées ajoutées précédemment, vous devez reconstruire manuellement l'adhésion automatique. La reconstruction de l'adhésion automatique réévalue toutes les règles automember existantes et les applique soit à toutes les entrées d'utilisateurs ou d'hôtes, soit à des entrées spécifiques.

Note

Reconstruction de l'adhésion automatique does not supprimer les entrées utilisateur ou hôte des groupes, même si les entrées ne correspondent plus aux conditions d'inclusion du groupe. Pour les supprimer manuellement, voir Supprimer un membre d'un groupe d'utilisateurs à l'aide du CLI Id M ou Supprimer les membres d'un groupe d'hôtes IdM à l'aide du CLI.

Conditions préalables

Procédure

  • Pour rétablir l'adhésion automatique, entrez la commande ipa automember-rebuild. Utilisez les options suivantes pour spécifier les entrées à cibler :

    • Pour rétablir l'adhésion automatique de tous les utilisateurs, utilisez l'option --type=group:

      $ ipa automember-rebuild --type=group
      --------------------------------------------------------
      Automember rebuild task finished. Processed (9) entries.
      --------------------------------------------------------
    • Pour rétablir l'adhésion automatique pour tous les hôtes, utilisez l'option --type=hostgroup.
    • Pour rétablir l'affiliation automatique pour un ou plusieurs utilisateurs spécifiés, utilisez l'option --users=target_user pour reconstruire l'adhésion automatique pour l'utilisateur ou les utilisateurs spécifiés :

      $ ipa automember-rebuild --users=target_user1 --users=target_user2
      --------------------------------------------------------
      Automember rebuild task finished. Processed (2) entries.
      --------------------------------------------------------
    • Pour reconstruire l'adhésion automatique pour un ou plusieurs hôtes spécifiés, utilisez l'option --hosts=client.idm.example.com pour reconstruire l'adhésion automatique d'un ou plusieurs hôtes.

22.9. Configuration d'un groupe de membres par défaut à l'aide de la CLI IdM

Lorsque vous configurez un groupe de membres automatiques par défaut, les nouvelles entrées d'utilisateurs ou d'hôtes qui ne correspondent à aucune règle de membres automatiques sont automatiquement ajoutées à ce groupe par défaut.

Conditions préalables

Procédure

  1. Entrez la commande ipa automember-default-group-set pour configurer un groupe de membres automatiques par défaut.
  2. Lorsque vous y êtes invité, précisez :

    • Default (fallback) Groupqui spécifie le nom du groupe cible.
    • Grouping Typequi précise si la cible est un groupe d'utilisateurs ou un groupe d'hôtes. Pour cibler un groupe d'utilisateurs, entrez group. Pour cibler un groupe d'hôtes, entrez hostgroup.

      Par exemple :

      $ ipa automember-default-group-set
      Default (fallback) Group: default_user_group
      Grouping Type: group
      ---------------------------------------------------
      Set default (fallback) group for automember "default_user_group"
      ---------------------------------------------------
        Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
    Note

    Pour supprimer le groupe automember par défaut actuel, entrez la commande ipa automember-default-group-remove.

Verification steps

  • Pour vérifier que le groupe est correctement défini, entrez la commande ipa automember-default-group-show. La commande affiche le groupe automember par défaut actuel. Par exemple :

    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

Chapitre 23. Automatisation de l'appartenance à un groupe à l'aide de l'interface Web IdM

L'utilisation de l'appartenance automatique à un groupe vous permet d'affecter automatiquement des utilisateurs et des hôtes à des groupes en fonction de leurs attributs. Par exemple, vous pouvez

  • Répartissez les entrées utilisateur des employés dans des groupes en fonction du responsable de l'employé, de son lieu de travail ou de tout autre attribut.
  • Divisez les hôtes en fonction de leur classe, de leur lieu de résidence ou de tout autre attribut.
  • Ajouter tous les utilisateurs ou tous les hôtes à un seul groupe global.

Ce chapitre couvre les sujets suivants :

23.1. Avantages de l'adhésion automatique à un groupe

L'utilisation de l'adhésion automatique pour les utilisateurs vous permet de

  • Reduce the overhead of manually managing group memberships

    Il n'est plus nécessaire d'affecter manuellement chaque utilisateur et chaque hôte à des groupes.

  • Improve consistency in user and host management

    Les utilisateurs et les hôtes sont affectés à des groupes sur la base de critères strictement définis et évalués automatiquement.

  • Simplify the management of group-based settings

    Divers paramètres sont définis pour les groupes, puis appliqués aux membres individuels du groupe, par exemple les règles sudo, l'automount ou le contrôle d'accès. L'ajout automatique d'utilisateurs et d'hôtes à des groupes facilite la gestion de ces paramètres.

23.2. Règles de l'Automember

Lors de la configuration de l'appartenance automatique à un groupe, l'administrateur définit des règles d'appartenance automatique. Une règle automember s'applique à un groupe cible d'utilisateurs ou d'hôtes spécifique. Elle ne peut pas s'appliquer à plusieurs groupes à la fois.

Après avoir créé une règle, l'administrateur y ajoute des conditions. Celles-ci précisent quels utilisateurs ou hôtes sont inclus ou exclus du groupe cible :

  • Inclusive conditions

    Lorsqu'une entrée utilisateur ou hôte remplit une condition d'inclusion, elle est incluse dans le groupe cible.

  • Exclusive conditions

    Lorsqu'une entrée utilisateur ou hôte remplit une condition d'exclusivité, elle n'est pas incluse dans le groupe cible.

Les conditions sont spécifiées sous forme d'expressions régulières au format PCRE (Perl-compatible regular expressions). Pour plus d'informations sur PCRE, voir la page de manuel pcresyntax(3).

Note

L'IdM évalue les conditions exclusives avant les conditions inclusives. En cas de conflit, les conditions exclusives l'emportent sur les conditions inclusives.

Une règle automember s'applique à toutes les entrées créées à l'avenir. Ces entrées seront automatiquement ajoutées au groupe cible spécifié. Si une entrée remplit les conditions spécifiées dans plusieurs règles automember, elle sera ajoutée à tous les groupes correspondants.

Les entrées existantes sont not affectées par la nouvelle règle. Si vous souhaitez modifier des entrées existantes, reportez-vous à la section Application des règles automember aux entrées existantes à l'aide de l'interface Web IdM.

23.3. Ajout d'une règle de membre automatique à l'aide de l'interface Web IdM

Cette section décrit l'ajout d'une règle de membre automatique à l'aide de l'interface Web IdM. Pour plus d'informations sur les règles de membre automatique, voir Règles de membre automatique.

Note

Les entrées existantes sont not affectées par la nouvelle règle. Si vous souhaitez modifier des entrées existantes, reportez-vous à la section Application des règles automember aux entrées existantes à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.
  • Le groupe cible de la nouvelle règle existe dans IdM.

Procédure

  1. Cliquez sur Identity → Automember, puis sélectionnez User group rules ou Host group rules.
  2. Cliquez sur Add.
  3. Dans le champ Automember rule, sélectionnez le groupe auquel la règle s'appliquera. Il s'agit du nom du groupe cible.

    Screenshot of the "Add Rule" window displaying the drop-down field for the Automember Rule where you can choose between rules you have previously defined.
  4. Cliquez sur Add pour confirmer.
  5. Facultatif : vous pouvez ajouter des conditions à la nouvelle règle en suivant la procédure décrite dans la section Ajout d'une condition à une règle automember à l'aide de l'interface Web IdM.

23.4. Ajout d'une condition à une règle de membre automatique à l'aide de l'interface Web IdM

Cette section explique comment ajouter une condition à une règle d'appartenance à un groupe à l'aide de l'interface Web de l'IdM. Pour plus d'informations sur les règles de membre automatique, voir Règles de membre automatique.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.
  • La règle cible existe dans l'IdM.

Procédure

  1. Cliquez sur Identity → Automember, puis sélectionnez User group rules ou Host group rules.
  2. Cliquez sur la règle à laquelle vous souhaitez ajouter une condition.
  3. Dans les sections Inclusive ou Exclusive, cliquez sur Ajouter.

    A screenshot of the User group rule page displaying attributes for the user_group rule. The "Inclusive" section has a table with an "Attribute" column and an "Expression" column with an entry for the Attribute "uid" and its Expression is ".*". At the bottom is the Exclusive section which also has a table with an Attribute column and an Expression column but it has no entries.
  4. Dans le champ Attribute, sélectionnez l'attribut requis, par exemple uid.
  5. Dans le champ Expression, définissez une expression régulière.
  6. Cliquez sur Add.

    Par exemple, la condition suivante vise tous les utilisateurs dont l'attribut d'identification de l'utilisateur (uid) contient une valeur quelconque (.*).

    Screenshot of the "Add Condition into automember" pop-up window displaying a drop-down menu for an Attribute (uid is selected) and a field for the corresponding "Expression" (which is required and .* has been entered). The "Add" button is at the bottom of the window.

23.5. Visualisation des règles et conditions existantes pour les membres automatiques à l'aide de l'interface Web IdM

Cette section décrit comment visualiser les règles et conditions existantes pour les membres de l'association à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.

Procédure

  1. Cliquez sur Identity → Automember, et sélectionnez User group rules ou Host group rules pour afficher les règles respectives des membres automatiques.
  2. Facultatif : Cliquez sur une règle pour afficher les conditions de cette règle dans les sections Inclusive ou Exclusive.

    A screenshot of the details of the user group rule "user_group." There is a "General" section displaying the name of the Automember rule and a "Description." There is an "Inclusive" section at the bottom with a table displaying entries with columns labeled "Attribute" and "Expression." This table has one entry with uid as the Attribute and .* as the Expression. At the very bottom there is an "Exclusive" section with a table that matches the structure of the "Inclusive" table but it has no entries.

23.6. Suppression d'une règle de membre automatique à l'aide de l'interface Web IdM

Cette section décrit comment supprimer une règle automember à l'aide de l'interface Web IdM.

La suppression d'une règle automember supprime également toutes les conditions associées à la règle. Pour supprimer uniquement des conditions spécifiques d'une règle, voir Suppression d'une condition d'une règle automember à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.

Procédure

  1. Cliquez sur Identity → Automember, et sélectionnez User group rules ou Host group rules pour afficher les règles respectives des membres automatiques.
  2. Cochez la case en regard de la règle que vous souhaitez supprimer.
  3. Cliquez sur Delete.

    A screenshot of the "User group rules" page displaying a table of automember rules. The checkbox for the "user_group" entry has been selected and the "Delete" button has been highlighted.
  4. Cliquez sur Delete pour confirmer.

23.7. Suppression d'une condition d'une règle de membre automatique à l'aide de l'interface Web IdM

Cette section décrit comment supprimer une condition spécifique d'une règle automember à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.

Procédure

  1. Cliquez sur Identity → Automember, et sélectionnez User group rules ou Host group rules pour afficher les règles respectives des membres automatiques.
  2. Cliquez sur une règle pour voir les conditions de cette règle dans les sections Inclusive ou Exclusive.
  3. Cochez la case en regard des conditions que vous souhaitez supprimer.
  4. Cliquez sur Delete.

    A screenshot of the "User group rule" page displaying information for "user_group". An entry in the "Inclusive" section has its checkbox checked and the "Delete" button that pertains to the "Inclusive" section is highlighted.
  5. Cliquez sur Delete pour confirmer.

23.8. Application de règles d'appartenance à un membre automatique à des entrées existantes à l'aide de l'interface Web de l'IdM

Les règles Automember s'appliquent automatiquement aux entrées utilisateur et hôte créées après l'ajout des règles. Elles ne s'appliquent pas rétroactivement aux entrées qui existaient avant l'ajout des règles.

Pour appliquer les règles d'automember aux entrées ajoutées précédemment, vous devez reconstruire manuellement l'adhésion automatique. La reconstruction de l'adhésion automatique réévalue toutes les règles automember existantes et les applique soit à toutes les entrées d'utilisateurs ou d'hôtes, soit à des entrées spécifiques.

Note

Reconstruction de l'adhésion automatique does not supprimer les entrées d'utilisateurs ou d'hôtes des groupes, même si les entrées ne correspondent plus aux conditions d'inclusion du groupe. Pour les supprimer manuellement, voir Supprimer un membre d'un groupe d'utilisateurs à l'aide de l'interface Web d'IdM ou Supprimer les membres d'un groupe d'hôtes dans l'interface Web d'IdM.

23.8.1. Reconstruction de l'adhésion automatique pour tous les utilisateurs ou hôtes

Cette section décrit comment rétablir l'affiliation automatique pour toutes les entrées d'utilisateurs ou d'hôtes.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.

Procédure

  1. Sélectionnez IdentityUsers ou Hosts.
  2. Cliquez sur ActionsRebuild auto membership.

    A screenshot highlighting that "Rebuild auto membership" is an option from the "Actions" drop-down menu.

23.8.2. Reconstruction de l'adhésion automatique pour un seul utilisateur ou hôte

Cette section décrit comment reconstruire l'adhésion automatique pour une entrée utilisateur ou hôte spécifique.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.

Procédure

  1. Sélectionnez IdentityUsers ou Hosts.
  2. Cliquez sur le nom d'utilisateur ou d'hôte requis.
  3. Cliquez sur ActionsRebuild auto membership.

    A screenshot highlighting the "Rebuild auto membership" option among many others in the contents of the "Actions" drop-down menu.

23.9. Configuration d'un groupe d'utilisateurs par défaut à l'aide de l'interface Web IdM

Lorsque vous configurez un groupe d'utilisateurs par défaut, les nouvelles entrées d'utilisateurs qui ne correspondent à aucune règle automember sont automatiquement ajoutées à ce groupe par défaut.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.
  • Le groupe d'utilisateurs cible que vous souhaitez définir par défaut existe dans l'IdM.

Procédure

  1. Cliquez sur Identity → Automember, puis sélectionnez User group rules.
  2. Dans le champ Default user group, sélectionnez le groupe que vous souhaitez définir comme groupe d'utilisateurs par défaut.

    Setting a default user group

23.10. Configuration d'un groupe d'hôtes par défaut à l'aide de l'interface Web IdM

Lorsque vous configurez un groupe d'hôtes par défaut, les nouvelles entrées d'hôtes qui ne correspondent à aucune règle automember sont automatiquement ajoutées à ce groupe par défaut.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM.
  • Vous devez être membre du groupe admins.
  • Le groupe d'hôtes cible que vous souhaitez définir par défaut existe dans IdM.

Procédure

  1. Cliquez sur Identity → Automember, puis sélectionnez Host group rules.
  2. Dans le champ Default host group, sélectionnez le groupe que vous souhaitez définir comme groupe d'hôtes par défaut.

    Setting a default host group

Chapitre 24. Utiliser Ansible pour automatiser l'appartenance à un groupe dans IdM

L'appartenance automatique à un groupe vous permet d'affecter aux utilisateurs et aux hôtes des groupes d'utilisateurs et des groupes d'hôtes automatiquement, en fonction de leurs attributs. Par exemple, vous pouvez

  • Répartissez les entrées utilisateur des employés dans des groupes en fonction du responsable, de la localisation, du poste ou de tout autre attribut de l'employé. Vous pouvez dresser la liste de tous les attributs en saisissant ipa user-add --help sur la ligne de commande.
  • Divisez les hôtes en groupes en fonction de leur classe, de leur emplacement ou de tout autre attribut. Vous pouvez dresser la liste de tous les attributs en entrant ipa host-add --help dans la ligne de commande.
  • Ajouter tous les utilisateurs ou tous les hôtes à un seul groupe global.

Vous pouvez utiliser Red Hat Ansible Engine pour automatiser la gestion de l'appartenance automatique à un groupe dans Identity Management (IdM).

Cette section couvre les sujets suivants :

24.1. Préparation du nœud de contrôle Ansible pour la gestion de l'IdM

En tant qu'administrateur système gérant la gestion des identités (IdM), lorsque vous travaillez avec Red Hat Ansible Engine, il est recommandé de procéder comme suit :

  • Créez un sous-répertoire dédié aux playbooks Ansible dans votre répertoire personnel, par exemple ~/MyPlaybooks.
  • Copiez et adaptez les exemples de playbooks Ansible des répertoires et sous-répertoires /usr/share/doc/ansible-freeipa/* et /usr/share/doc/rhel-system-roles/* dans votre répertoire ~/MyPlaybooks.
  • Incluez votre fichier d'inventaire dans votre répertoire ~/MyPlaybooks.

En suivant cette pratique, vous pouvez trouver tous vos playbooks en un seul endroit et vous pouvez exécuter vos playbooks sans invoquer les privilèges root.

Note

Vous n'avez besoin que des privilèges root sur les nœuds gérés pour exécuter les rôles ipaserver, ipareplica, ipaclient, ipabackup, ipasmartcard_server et ipasmartcard_client ansible-freeipa . Ces rôles nécessitent un accès privilégié aux répertoires et au gestionnaire de paquets logiciels dnf.

Cette section décrit comment créer le répertoire ~/MyPlaybooks et le configurer de manière à ce que vous puissiez l'utiliser pour stocker et exécuter des playbooks Ansible.

Conditions préalables

  • Vous avez installé un serveur IdM sur vos nœuds gérés, server.idm.example.com et replica.idm.example.com.
  • Vous avez configuré le DNS et le réseau pour pouvoir vous connecter aux nœuds gérés, server.idm.example.com et replica.idm.example.comdirectement à partir du nœud de contrôle.
  • Vous connaissez le mot de passe de l'IdM admin.

Procédure

  1. Créez un répertoire pour votre configuration Ansible et vos playbooks dans votre répertoire personnel :

    $ mkdir ~/MyPlaybooks/
  2. Allez dans le répertoire ~/MyPlaybooks/:

    $ cd ~/MyPlaybooks
  3. Créez le fichier ~/MyPlaybooks/ansible.cfg avec le contenu suivant :

    [defaults]
    inventory = /home/your_username/MyPlaybooks/inventory
    
    [privilege_escalation]
    become=True
  4. Créez le fichier ~/MyPlaybooks/inventory avec le contenu suivant :

    [ipaserver]
    server.idm.example.com
    
    [ipareplicas]
    replica1.idm.example.com
    replica2.idm.example.com
    
    [ipacluster:children]
    ipaserver
    ipareplicas
    
    [ipacluster:vars]
    ipaadmin_password=SomeADMINpassword
    
    [ipaclients]
    ipaclient1.example.com
    ipaclient2.example.com
    
    [ipaclients:vars]
    ipaadmin_password=SomeADMINpassword

    Cette configuration définit deux groupes d'hôtes, eu et us, pour les hôtes de ces sites. En outre, cette configuration définit le groupe d'hôtes ipaserver, qui contient tous les hôtes des groupes eu et us.

  5. [Facultatif] Créez une clé publique et une clé privée SSH. Pour simplifier l'accès dans votre environnement de test, ne définissez pas de mot de passe pour la clé privée :

    $ ssh-keygen
  6. Copiez la clé publique SSH dans le compte IdM admin sur chaque nœud géré :

    $ ssh-copy-id admin@server.idm.example.com
    $ ssh-copy-id admin@replica.idm.example.com

    Vous devez saisir le mot de passe IdM admin lorsque vous entrez dans ces commandes.

24.2. Utiliser Ansible pour s'assurer qu'une règle automember pour un groupe d'utilisateurs IdM est présente

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer de l'existence d'une règle automember pour un groupe de gestion des identités (IdM). Dans l'exemple, la présence d'une règle automember est assurée pour le groupe d'utilisateurs testing_group.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Le groupe d'utilisateurs testing_group existe dans IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Copiez le fichier automember-group-present.yml Ansible playbook situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/automember/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-present.yml automember-group-present-copy.yml
  3. Ouvrez le fichier automember-group-present-copy.yml pour le modifier.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaautomember task :

    • Fixer la variable ipaadmin_password au mot de passe de l'IdM admin.
    • Fixer la variable name à testing_group.
    • Fixer la variable automember_type à group.
    • Assurez-vous que la variable state est définie sur present.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Automember group present example
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure group automember rule admins is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: present
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-group-present-copy.yml

Ressources supplémentaires

24.3. Utiliser Ansible pour s'assurer qu'une condition spécifiée est présente dans une règle de membre automatique d'un groupe d'utilisateurs IdM

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer qu'une condition spécifiée existe dans une règle automember pour un groupe de gestion des identités (IdM). Dans l'exemple, la présence d'une condition liée à l'UID dans la règle automember est assurée pour le groupe testing_group. En spécifiant la condition .*, vous vous assurez que tous les futurs utilisateurs IdM deviennent automatiquement membres du groupe testing_group.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Le groupe d'utilisateurs testing_group et la règle du groupe d'utilisateurs automember existent dans IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Copiez le fichier automember-hostgroup-rule-present.yml Ansible playbook situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/automember/ et nommez-le, par exemple, automember-usergroup-rule-present.yml:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-usergroup-rule-present.yml
  3. Ouvrez le fichier automember-usergroup-rule-present.yml pour le modifier.
  4. Adapter le fichier en modifiant les paramètres suivants :

    • Renommez le playbook pour qu'il corresponde à votre cas d'utilisation, par exemple : Automember user group rule member present.
    • Renommez la tâche pour qu'elle corresponde à votre cas d'utilisation, par exemple : Ensure an automember condition for a user group is present.
    • Définissez les variables suivantes dans la section ipaautomember task :

      • Fixer la variable ipaadmin_password au mot de passe de l'IdM admin.
      • Fixer la variable name à testing_group.
      • Fixer la variable automember_type à group.
      • Assurez-vous que la variable state est définie sur present.
      • Assurez-vous que la variable action est définie sur member.
      • Fixez la variable inclusive key à UID.
      • Fixer la variable inclusive expression à .*

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: present
          action: member
          inclusive:
            - key: UID
              expression: .*
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-usergroup-rule-present.yml

Verification steps

  1. Se connecter en tant qu'administrateur IdM.

    $ kinit admin
  2. Ajouter un utilisateur, par exemple :

    $ ipa user-add user101 --first user --last 101
    -----------------------
    Added user "user101"
    -----------------------
      User login: user101
      First name: user
      Last name: 101
      ...
      Member of groups: ipausers, testing_group
      ...

Ressources supplémentaires

24.4. Utiliser Ansible pour s'assurer qu'une condition est absente d'une règle de membre automatique d'un groupe d'utilisateurs IdM

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer qu'une condition est absente d'une règle automember pour un groupe de gestion des identités (IdM). Dans l'exemple, l'absence d'une condition dans la règle automember est garantie et spécifie que les utilisateurs dont initials est dp doivent être inclus. La règle automember est appliquée au groupe testing_group. En appliquant la condition, vous vous assurez qu'aucun futur utilisateur IdM dont les initiales sont dp ne devienne membre du groupe testing_group.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Le groupe d'utilisateurs testing_group et la règle du groupe d'utilisateurs automember existent dans IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Copiez le fichier automember-hostgroup-rule-absent.yml Ansible playbook situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/automember/ et nommez-le, par exemple, automember-usergroup-rule-absent.yml:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-absent.yml automember-usergroup-rule-absent.yml
  3. Ouvrez le fichier automember-usergroup-rule-absent.yml pour le modifier.
  4. Adapter le fichier en modifiant les paramètres suivants :

    • Renommez le playbook pour qu'il corresponde à votre cas d'utilisation, par exemple : Automember user group rule member absent.
    • Renommez la tâche pour qu'elle corresponde à votre cas d'utilisation, par exemple : Ensure an automember condition for a user group is absent.
    • Définissez les variables suivantes dans la section ipaautomember task :

      • Fixer la variable ipaadmin_password au mot de passe de l'IdM admin.
      • Fixer la variable name à testing_group.
      • Fixer la variable automember_type à group.
      • Assurez-vous que la variable state est définie sur absent.
      • Assurez-vous que la variable action est définie sur member.
      • Fixez la variable inclusive key à initials.
      • Fixez la variable inclusive expression à dp.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Automember user group rule member absent
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is absent
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: absent
          action: member
          inclusive:
            - key: initials
              expression: dp
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-usergroup-rule-absent.yml

Verification steps

  1. Se connecter en tant qu'administrateur IdM.

    $ kinit admin
  2. Affichez le groupe automember :

    $ ipa automember-show --type=group testing_group
     Automember Rule: testing_group

L'absence d'une entrée Inclusive Regex: initials=dp dans la sortie confirme que la règle de membre automatique testing_group ne contient pas la condition spécifiée.

Ressources supplémentaires

24.5. Utiliser Ansible pour s'assurer qu'une règle automember pour un groupe d'utilisateurs IdM est absente

La procédure suivante décrit comment utiliser un playbook Ansible pour s'assurer qu'une règle automember est absente pour un groupe de gestion d'identité (IdM). Dans l'exemple, l'absence d'une règle automember est garantie pour le groupe testing_group.

Note

La suppression d'une règle de membre automatique supprime également toutes les conditions associées à la règle. Pour ne supprimer que des conditions spécifiques d'une règle, voir Utiliser Ansible pour s'assurer qu'une condition est absente d'une règle de membre automatique d'un groupe d'utilisateurs IdM.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Copiez le fichier automember-group-absent.yml Ansible playbook situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/automember/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-group-absent.yml automember-group-absent-copy.yml
  3. Ouvrez le fichier automember-group-absent-copy.yml pour le modifier.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaautomember task :

    • Fixer la variable ipaadmin_password au mot de passe de l'IdM admin.
    • Fixer la variable name à testing_group.
    • Fixer la variable automember_type à group.
    • Assurez-vous que la variable state est définie sur absent.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Automember group absent example
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure group automember rule admins is absent
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: testing_group
          automember_type: group
          state: absent
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-group-absent.yml

Ressources supplémentaires

24.6. Utiliser Ansible pour s'assurer qu'une condition est présente dans une règle de membre automatique d'un groupe d'hôtes IdM

Cette section décrit comment utiliser Ansible pour s'assurer qu'une condition est présente dans une règle de membre automatique de groupe d'hôtes IdM. L'exemple décrit comment s'assurer que les hôtes dont le FQDN est .*.idm.example.com sont membres du groupe d'hôtes primary_dns_domain_hosts et que les hôtes dont le FQDN est .*.example.org ne sont pas membres du groupe d'hôtes primary_dns_domain_hosts.

Conditions préalables

  • Vous connaissez le mot de passe de l'IdM admin.
  • Le groupe d'hôtes primary_dns_domain_hosts et la règle du groupe d'hôtes automember existent dans IdM.
  • Vous avez configuré votre nœud de contrôle Ansible pour qu'il réponde aux exigences suivantes :

    • Vous utilisez la version 2.8 ou ultérieure d'Ansible.
    • Vous avez installé le paquetage ansible-freeipa sur le contrôleur Ansible.
    • L'exemple suppose que dans le répertoire ~/MyPlaybooks/ vous avez créé un fichier d'inventaire Ansible avec le nom de domaine complet (FQDN) du serveur IdM.
    • L'exemple suppose que le coffre-fort secret.yml Ansible stocke votre ipaadmin_password.

Procédure

  1. Naviguez jusqu'à votre répertoire ~/MyPlaybooks/ répertoire :

    $ cd ~/MyPlaybooks/
  2. Copiez le fichier automember-hostgroup-rule-present.yml Ansible playbook situé dans le répertoire /usr/share/doc/ansible-freeipa/playbooks/automember/:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/automember/automember-hostgroup-rule-present.yml automember-hostgroup-rule-present-copy.yml
  3. Ouvrez le fichier automember-hostgroup-rule-present-copy.yml pour le modifier.
  4. Adaptez le fichier en définissant les variables suivantes dans la section ipaautomember task :

    • Fixer la variable ipaadmin_password au mot de passe de l'IdM admin.
    • Fixer la variable name à primary_dns_domain_hosts.
    • Fixer la variable automember_type à hostgroup.
    • Assurez-vous que la variable state est définie sur present.
    • Assurez-vous que la variable action est définie sur member.
    • Assurez-vous que la variable inclusive key est fixée à fqdn.
    • Définissez la variable inclusive expression correspondante à .*.idm.example.com.
    • Fixez la variable exclusive key à fqdn.
    • Définissez la variable exclusive expression correspondante à .*.example.org.

    Il s'agit du fichier playbook Ansible modifié pour l'exemple actuel :

    ---
    - name: Automember user group rule member present
      hosts: ipaserver
      vars_files:
      - /home/user_name/MyPlaybooks/secret.yml
      tasks:
      - name: Ensure an automember condition for a user group is present
        ipaautomember:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: primary_dns_domain_hosts
          automember_type: hostgroup
          state: present
          action: member
          inclusive:
            - key: fqdn
              expression: .*.idm.example.com
          exclusive:
            - key: fqdn
              expression: .*.example.org
  5. Enregistrer le fichier.
  6. Exécutez le playbook Ansible. Spécifiez le fichier du livre de jeu, le fichier contenant le mot de passe protégeant le fichier secret.yml et le fichier d'inventaire :

    $ ansible-playbook --vault-password-file=password_file -v -i inventory automember-hostgroup-rule-present-copy.yml

Ressources supplémentaires

24.7. Ressources supplémentaires

Chapitre 25. Délégation de permissions à des groupes d'utilisateurs pour gérer les utilisateurs à l'aide de la CLI IdM

La délégation est l'une des méthodes de contrôle d'accès dans IdM, avec les règles en libre-service et le contrôle d'accès basé sur les rôles (RBAC). Vous pouvez utiliser la délégation pour attribuer des autorisations à un groupe d'utilisateurs afin de gérer des entrées pour un autre groupe d'utilisateurs.

Cette section couvre les sujets suivants :

25.1. Règles de délégation

Vous pouvez déléguer des autorisations à des groupes d'utilisateurs pour gérer les utilisateurs en créant delegation rules.

Les règles de délégation permettent à un groupe d'utilisateurs spécifique d'effectuer des opérations d'écriture (modification) sur des attributs spécifiques pour les utilisateurs d'un autre groupe d'utilisateurs. Cette forme de règle de contrôle d'accès se limite à la modification des valeurs d'un sous-ensemble d'attributs que vous spécifiez dans une règle de délégation ; elle ne permet pas d'ajouter ou de supprimer des entrées entières ni de contrôler des attributs non spécifiés.

Les règles de délégation accordent des autorisations aux groupes d'utilisateurs existants dans IdM. Vous pouvez utiliser la délégation pour, par exemple, permettre au groupe d'utilisateurs managers de gérer certains attributs des utilisateurs du groupe d'utilisateurs employees.

25.2. Création d'une règle de délégation à l'aide de l'interface CLI de l'IdM

Cette section décrit comment créer une règle de délégation à l'aide de la CLI IdM.

Conditions préalables

  • Vous êtes connecté en tant que membre du groupe admins.

Procédure

  • Entrez la commande ipa delegation-add. Spécifiez les options suivantes :

    • --group: le groupe qui is being granted permissions aux entrées des utilisateurs dans le groupe d'utilisateurs.
    • --membergroup: le groupe whose entries can be edited par les membres du groupe de délégation.
    • --permissions: si les utilisateurs auront le droit de voir les attributs donnés (read) et d'ajouter ou de modifier les attributs donnés (write). Si vous ne spécifiez pas de permissions, seule la permission write sera ajoutée.
    • --attrs: les attributs que les utilisateurs du groupe de membres sont autorisés à voir ou à modifier.

    Par exemple :

$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeetype, employeenumber
  Member user group: employees
  User group: managers

25.3. Visualisation des règles de délégation existantes à l'aide de la CLI IdM

Cette section décrit comment visualiser les règles de délégation existantes à l'aide de la CLI IdM.

Conditions préalables

  • Vous êtes connecté en tant que membre du groupe admins.

Procédure

  • Entrez la commande ipa delegation-find:
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeenumber, employeetype
  Member user group: employees
  User group: managers
----------------------------
Number of entries returned 1
----------------------------

25.4. Modification d'une règle de délégation à l'aide de la CLI IdM

Cette section décrit comment modifier une règle de délégation existante à l'aide de l'interface CLI de l'IdM.

Important

L'option --attrs écrase la liste précédente des attributs pris en charge. Il faut donc toujours inclure la liste complète des attributs ainsi que les nouveaux attributs. Ceci s'applique également à l'option --permissions.

Conditions préalables

  • Vous êtes connecté en tant que membre du groupe admins.

Procédure

  • Entrez la commande ipa delegation-mod avec les modifications souhaitées. Par exemple, pour ajouter l'attribut displayname à la règle d'exemple basic manager attributes:

    $ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname
    ----------------------------------------------
    Modified delegation "basic manager attributes"
    ----------------------------------------------
      Delegation name: basic manager attributes
      Permissions: read, write
      Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname
      Member user group: employees
      User group: managers

25.5. Suppression d'une règle de délégation à l'aide de la CLI IdM

Cette section décrit comment supprimer une règle de délégation existante à l'aide de l'interface CLI de l'IdM.

Conditions préalables

  • Vous êtes connecté en tant que membre du groupe admins.

Procédure

  • Entrez la commande ipa delegation-del.
  • Lorsque vous y êtes invité, saisissez le nom de la règle de délégation que vous souhaitez supprimer :

    $ ipa delegation-del
    Delegation name: basic manager attributes
    ---------------------------------------------
    Deleted delegation "basic manager attributes"
    ---------------------------------------------

Chapitre 26. Délégation de permissions à des groupes d'utilisateurs pour gérer les utilisateurs à l'aide de l'interface Web IdM

La délégation est l'une des méthodes de contrôle d'accès dans IdM, avec les règles en libre-service et le contrôle d'accès basé sur les rôles (RBAC). Vous pouvez utiliser la délégation pour attribuer des autorisations à un groupe d'utilisateurs afin de gérer des entrées pour un autre groupe d'utilisateurs.

Cette section couvre les sujets suivants :

26.1. Règles de délégation

Vous pouvez déléguer des autorisations à des groupes d'utilisateurs pour gérer les utilisateurs en créant delegation rules.

Les règles de délégation permettent à un groupe d'utilisateurs spécifique d'effectuer des opérations d'écriture (modification) sur des attributs spécifiques pour les utilisateurs d'un autre groupe d'utilisateurs. Cette forme de règle de contrôle d'accès se limite à la modification des valeurs d'un sous-ensemble d'attributs que vous spécifiez dans une règle de délégation ; elle ne permet pas d'ajouter ou de supprimer des entrées entières ni de contrôler des attributs non spécifiés.

Les règles de délégation accordent des autorisations aux groupes d'utilisateurs existants dans IdM. Vous pouvez utiliser la délégation pour, par exemple, permettre au groupe d'utilisateurs managers de gérer certains attributs des utilisateurs du groupe d'utilisateurs employees.

26.2. Création d'une règle de délégation à l'aide de l'interface Web IdM

Cette section décrit comment créer une règle de délégation à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM en tant que membre du groupe admins.

Procédure

  1. Dans le menu IPA Server, cliquez sur Role-Based Access ControlDelegations.
  2. Cliquez sur Add.

    A screenshot of the IdM Web UI displaying contents of the "Role-Based Access Control" drop-down submenu from the "IPA Server" tab. There are five options in the "Role-Based Access Control" drop-down menu: Roles - Privileges - Permissions - Self Service Permissions - Delegations.
  3. Dans la fenêtre Add delegation, procédez comme suit :

    1. Nommez la nouvelle règle de délégation.
    2. Définissez les autorisations en cochant les cases qui indiquent si les utilisateurs auront le droit de voir les attributs donnés (read) et d'ajouter ou de modifier les attributs donnés (write).
    3. Dans le menu déroulant Groupe d'utilisateurs, sélectionnez le groupe who is being granted permissions pour afficher ou modifier les entrées des utilisateurs du groupe membre.
    4. Dans le menu déroulant Member user group, sélectionnez le groupe whose entries can be edited par les membres du groupe de délégation.
    5. Dans la case attributs, cochez les cases des attributs auxquels vous souhaitez accorder des autorisations.

      A screenshot of the "Add delegation" pop-up window where you can enter details for a delegation. The entry options include a text field for the Delegation name and checkboxes for "read" and "write" permissions. There is also a drop-down menu for the User group - a drop-down menu for the Member user group - and many checkboxes for Attributes (such as departmentnumber - employeenumber - businesscategory - employeetype).
    6. Cliquez sur le bouton Add pour enregistrer la nouvelle règle de délégation.

26.3. Visualisation des règles de délégation existantes à l'aide de l'interface Web IdM

Cette section décrit comment visualiser les règles de délégation existantes à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM en tant que membre du groupe admins.

Procédure

  • Dans le menu IPA Server, cliquez sur Role-Based Access ControlDelegations.

    A screenshot of the IdM Web UI displaying the "Delegations" page from the "Role-Based Access Control" submenu of the "IPA Server" tab. There is a table displaying Delegations organized by their "Delegation name."

26.4. Modifier une règle de délégation à l'aide de l'interface Web IdM

Cette section décrit comment modifier une règle de délégation existante à l'aide de l'interface Web IdM.

Conditions préalables

  • Vous êtes connecté à l'interface Web IdM en tant que membre du groupe admins.

Procédure

  1. Dans le menu IPA Server, cliquez sur Role-Based Access ControlDelegations.

    A screenshot of the IdM Web UI displaying the Role-Based Access Control sub page from the IPA Server tab. The Delegations page displays a table with an entry for the "basic manager attributes" Delegation name.
  2. Cliquez sur la règle que vous souhaitez modifier.
  3. Effectuez les modifications souhaitées :

    • Modifier le nom de la règle.
    • Modifiez les autorisations accordées en cochant les cases qui indiquent si les utilisateurs auront le droit de voir les attributs donnés (read) et d'ajouter ou de modifier les attributs donnés (write).
    • Dans le menu déroulant Groupe d'utilisateurs, sélectionnez le groupe who is being granted permissions pour afficher ou modifier les entrées des utilisateurs du groupe membre.
    • Dans le menu déroulant Member user group, sélectionnez le groupe whose entries can be edited par les membres du groupe de délégation.
    • Dans la case attributs, cochez les cases des attributs auxquels vous souhaitez accorder des autorisations. Pour supprimer les autorisations d'un attribut, décochez la case correspondante.