11.9.9.7. Autorisation et chargement de groupes avec LDAP
Dans l'annuaire LDAP, il est prévu qu'il y ait des entrées pour les comptes d'utilisateurs et les groupes, celles-ci sont ensuite vérifiées par l'utilisation d'attributs. Les attributs utilisés pour vérifier les deux peuvent consister en une référence pour vérifier l'entrée du compte utilisateur en fonction de l'entrée du groupe ou un attribut sur le groupe référençant les utilisateurs qui sont membres du groupe. Sur certains serveurs, les deux formes de renvoi existent.
Il est également fréquent qu'un utilisateur soit authentifié auprès du serveur à l'aide d'un simple nom utilisateur. Lorsqu'il recherche les informations d'appartenance de groupe, selon le serveur de répertoires utilisé, les recherches d'utilisation peuvent être effectuées à l'aide de ce simple nom ou peuvent être réalisées en utilisant le nom unique d'entrée utilisateur du répertoire.
L'étape d'authentification d'un utilisateur qui se connecte au serveur a toujours lieu en premier. C'est seulement une fois qu'il a été décidé que l'utilisateur est bien authentifié que le serveur se déplace pour charger un groupe d'utilisateurs. Tant que l'étape d'authentification et que l'étape d'autorisation utilisent une connexion au serveur LDAP, le domaine contient une optimisation qui consiste à ce que n'importe quelle connexion utilisée pour l'authentification soit réutilisée pour l'étape de chargement de groupe. Tel qu'il apparaît dans les étapes de configuration ci-dessous, il est possible de définir des règles au sein de la section autorisation pour convertir un nom d'utilisateur simple en nom unique d'utilisateur. C'est potentiellement dupliquer une recherche qui aurait eu lieu au cours de l'étape d'authentification, donc si une recherche de nom d'utilisateur à nom unique a déjà été effectuée, le résultat de cette recherche sera mis en cache et réutilisé sans répétition.
<authorization>
<ldap connection="...">
<username-to-dn> <!-- OPTIONAL -->
<!-- Only one of the following. -->
<username-is-dn />
<username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." />
<advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." />
</username-to-dn>
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
<!-- One of the following -->
<group-to-principal base-dn="..." recursive="..." search-by="...">
<membership-filter principal-attribute="..." />
</group-to-principal>
<principal-to-group group-attribute="..." />
</group-search>
</ldap>
</authorization>Important
Certains de ces exemples indiquent des attributs qui utilisent des valeurs par défaut. Ces valeurs sont indiquées ici pour clarifier. Les attributs qui contiennent les valeurs par défaut sont supprimées de la configuration quand c'est persisté sur le serveur.
username-to-dn
Comme mentionné plus tôt, il peut parfois être utile de définir dans la configuration d'autorisation le mappage du nom de l'utilisateur authentifié au nom unique de leur entrée dans le répertoire LDAP. L'élément de
username-to-dn indique comment elle est définie. Cet élément est uniquement nécessaire si ce qui suit est bien le cas :
- L'étape d'authentification n'a pas eu lieu avec LDAP.
- La recherche de groupe utilise le nom unique pendant la recherche.
- 1:1 username-to-dn
- Il s'agit de la forme de configuration de base et elle est utilisée pour spécifier que le nom d'utilisateur saisi par l'utilisateur éloigné est le nom unique de l'utilisateur.
<username-to-dn> <username-is-dn /> </username-to-dn>
Comme cela définit un mappage 1:1, il n'y a pas de configuration supplémentaire possible. - username-filter
- La prochaine option est très semblable à la simple option décrite ci-dessus dans l'étape d'authentification. Un attribut est spécifié et on recherche une correspondance avec le nom d'utilisateur fourni.
<username-to-dn> <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" /> </username-to-dn>Les attributs qui peuvent être définis sont les suivants :base-dn: le nom distinctif du contexte pour commencer la recherche.recursive: indique si la recherche va s'étendre à des sous-contextes. La valeur par défaut estfalse.attribute: l'attribut de l'entrée de l'utilisateur à faire correspondre avec le nom d'utilisateur fourni. La valeur par défaut estuid.user-dn-attribute: l'attribut à lire pour obtenir les noms distinctifs d'utilisateurs. La valeur par défaut estdn.
- advanced-filter
- L'option finale est de spécifier un filtre avancé. Comme dans la section authentification, c'est l'opportunité d'utiliser un filtre personnalisé pour trouver le nom unique de l'utilisateur.
<username-to-dn> <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" /> </username-to-dn>Pour les attributs qui correspondent à ceux du username-filter, le sens et les valeurs par défaut sont les mêmes. Il y a un nouvel attribut :filter: filtre personnalisé utilisé pour chercher une entrée d'utilisateur quand le nom d'utilisateur est substitué dans l'espace réservé{0}
Important
Le code XML doit rester valide une fois que le filtre est défini donc si des caractères spéciaux comme&sont utilisés, assurez-vous que la forme qui convient soit utilisée. Par exemple& amp ;pour le caractère&.
La recherche de groupe
Comme décrit ci-dessus, il existe deux styles différents qui puissent être utilisés lors de la recherche d'informations d'appartenance de groupe. Le premier style est quand l'entrée d'utilisateur contient un attribut qui référence les groupes dont l'utilisateur est membre. Le second style est quand le groupe contient un attribut référençant l'entrée des utilisateurs
Lorsqu'il y a un choix sur le style à utiliser, Red Hat recommande que la configuration d'entrée utilisateur référençant le groupe soit utilisée. C'est parce qu'avec cette méthode, l'information de groupe peut être chargée par la lecture des attributs des noms uniques connus sans avoir à effectuer les recherches. L'autre approche nécessite des recherches extensives pour identifier les groupes qui référencent l'utilisateur.
Avant de décrire la configuration, voici quelques exemples LDIF pour illustrer cela.
Exemple 11.21. Principal à Groupe - Exemple LDIF
Cet exemple illustre un cas où nous avons un utilisateur
TestUserOne, qui est membre de GroupOne, GroupOne est alors à son tour membre de GroupFive. L'appartenance au groupe est démontrée par l'utilisation d'un attribut memberOf qui est défini sur le nom unique du groupe dont l'utilisateur est membre.
Ce n'est pas affiché ici, mais un utilisateur peut avoir plusieurs attributs
memberOf définis, un pour chaque groupe dont l'utilisateur est un membre direct.
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ== dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupOne distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org objectClass: extensibleObject objectClass: top objectClass: groupMember objectClass: group objectClass: uidObject uid: GroupFive distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
Exemple 11.22. Groupe à Principal - Exemple LDIF
Cet exemple montre le même utilisateur
TestUserOne qui est un membre de GroupOne, qui est à son tour membre de GroupFive - cependant dans ce cas, c'est un attribut uniqueMember du groupe à l'utilisateur utilisé pour la référence croisée.
Encore une fois, l'attribut utilisé pour la mise en correspondance de l'appartenance à un groupe peut être répété, si vous regardez GroupFive, il y a également une référence à un autre utilisateur TestUserFive qui n'est pas visible ici.
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: inetOrgPerson objectClass: uidObject objectClass: person objectClass: organizationalPerson cn: Test User One sn: Test User One uid: TestUserOne userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ== dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group One uid: GroupOne uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org objectClass: top objectClass: groupOfUniqueNames objectClass: uidObject cn: Group Five uid: GroupFive uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
Recherche de groupe standard
Avant de chercher des exemples pour les deux approches montrées ci-dessus, nous devons tout d'abord définir les attributs communs aux deux approches.
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
...
</group-search>group-name: cet attribut est utilisé pour indiquer le formulaire qui doit être utilisé pour le nom de groupe retourné comme liste de groupes dont l'utilisateur est membre, cela peut être sous la simple forme de nom du groupe ou le nom unique du groupe, si le nom unique est nécessaire, cet attribut peut être défini àDISTINGUISHED_NAME. Valeur par défautSIMPLE.itérative: cet attribut est utilisé pour indiquer si, après avoir identifié les groupes qui appartiennent à un utilisateur, on doit rechercher également de manière itérative basée sur les groupes afin d'identifier quels groupes appartiennent à quels groupes. Si la recherche itérative est activée, nous continuons jusqu'à ce que nous rejoignions un groupe qui ne soit pas membre si aucun autre groupe ou cycle est détecté. Par défaut,false.
L'appartenance à un groupe cyclique n'est pas un problème. Il existe un registre de chaque recherche pour empêcher les groupes qui ont déjà été fouillés d'être recherchés à nouveau.
Important
Pour une recherche itérative, les entrées de groupe doivent ressembler aux entrées utilisateur. La même approche qui permet d'identifier les groupes auxquels appartiennent un utilisateur est alors utilisée pour identifier les groupes auxquel le groupe appartient. Ce ne serait pas possible si, une fois que nous parlons d'appartenance inter groupes, le nom de l'attribut utilisé pour la référence croisée changeait ou si la direction de la référence changeait.
group-dn-attribute: sur une entrée pour un groupe dont l'attribut est son nom unique. La valeur par défaut estdn.group-name-attribute: sur une entrée pour un groupe dont l'attribut est son simple nom. La valeur par défautuid.
Exemple 11.23. Configuration d'exemple de Principal à Groupe
Basé sur l'exemple LDIF ci-dessus, voici un exemple de configuration chargeant itérativement un groupe d'utilisateurs où l'attribut utilisé pour référence est l'attribut
memberOf de l'utilisateur.
<authorization>
<ldap connection="LocalLdap">
<username-to-dn>
<username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
</username-to-dn>
<group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
<principal-to-group group-attribute="memberOf" />
</group-search>
</ldap>
</authorization>
L'aspect le plus important de cette configuration est que l'élément
principal-to-group a été ajouté avec un seul attribut.
group-attribute: le nom de l'attribut sur l'entrée d'utilisateur qui correspond au nom unique du groupe qui appartient à l'utilisateur. La valeur par défautmemberOf.
Exemple 11.24. Configuration d'exemple de Groupe à Principal
Cet exemple vous montre une recherche interactive pour l'exemple groupe à principal LDIF montré ci-dessus.
<authorization>
<ldap connection="LocalLdap">
<username-to-dn>
<username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
</username-to-dn>
<group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
<group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME">
<membership-filter principal-attribute="uniqueMember" />
</group-to-principal>
</group-search>
</ldap>
</authorization>
Un élément
group-to-principal est ajouté ici. Cet élément est utilisé pour définir comment les recherches de groupes qui référencent l'entrée de l'utilisateur seront exécutées. Les attributs suivants sont définis :
base-dn: le nom unique du contexte à utiliser pour commencer la recherche.recursive: indique si les sous-contextes peuvent également être recherchés. La valeur par défaut estfalse.search-by: la forme du nom de rôle utilisé dans les recherches. Valeurs validesSIMPLEetDISTINGUISHED_NAME. Valeur par défautDISTINGUISHED_NAME.
Dans l'élément group-to-principal, il y a un élément membership-filter pour définir la correspondance.
principal-attribute: le nom de l'attribut d'entrée de groupe qui référence l'entrée utilisateur. La valeur par défaut estmember.