Administrer sans amadmin : comptes LDAP et privilèges délégués

amadmin est un compte générique : tous ceux qui en connaissent le mot de passe agissent sous le même nom, et les journaux ne disent pas qui a fait quoi. C’est aussi un super-utilisateur : TOSIAM ne vérifie aucun privilège pour lui, sur aucun royaume.

Ce guide le remplace, pour l’administration courante, par des comptes nominatifs pris dans votre annuaire LDAP. Les droits ne sont pas donnés aux personnes, mais à un groupe LDAP : TOSIAM accorde des privilèges à ce groupe dans un royaume, et chaque membre du groupe les reçoit. Ajouter ou retirer un administrateur se fait alors dans l’annuaire, sans toucher à TOSIAM.

uid=dduck  ──membre de──▶  cn=admins-ref (groupe LDAP)  ──privilège RealmAdmin──▶  royaume ref

Ce que donne un privilège, selon le royaume#

Un privilège s’accorde à un groupe d’un royaume donné, et vaut pour ce royaume et ses sous-royaumes. Un groupe ne peut recevoir de privilèges que dans le royaume où il est déclaré : l’administrateur de ref est donc un utilisateur du datastore de ref, et il se connecte dans ref.

ssoadm authentifie toujours dans le royaume racine : seul un administrateur du royaume racine peut s’en servir. Un administrateur de ref passe par la console ou par l’API REST ; ses droits sur les sous-royaumes de ref s’exercent par l’API REST /json.

Étape 1 : le groupe dans l’annuaire#

Créez dans l’annuaire un groupe dont les membres seront les administrateurs de ref. Avec la classe d’objet groupOfUniqueNames, celle qu’attend TOSIAM par défaut :

dn: cn=admins-ref,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: admins-ref
description: Administrateurs du royaume ref dans TOSIAM
uniqueMember: uid=dduck,ou=people,dc=example,dc=com
uniqueMember: uid=mmouse,ou=people,dc=example,dc=com

ldapadd -H ldap://ldap.example.com -D "cn=admin,dc=example,dc=com" -W -f admins-ref.ldif

Si votre annuaire utilise déjà groupOfNames et l’attribut member (cas courant avec OpenLDAP), gardez-les : l’étape 2 indique à TOSIAM lesquels lire.

Étape 2 : faire voir le groupe au datastore#

Pour savoir si un utilisateur est membre de admins-ref, TOSIAM demande au datastore les groupes de cet utilisateur. Le datastore les trouve de deux façons :

• Nom d’attribut pour l’appartenance à un groupe renseigné (par exemple memberOf ou isMemberOf) : il lit cet attribut sur l’entrée de l’utilisateur ;
• sinon : il cherche, sous le conteneur des groupes, les entrées qui répondent au filtre de recherche de groupes et dont l’attribut membre unique contient le DN de l’utilisateur.

Dans la console, menu Datastores du royaume ref, ouvrez le datastore annuaire, onglet Configuration des groupes :

1 2 3 4 5

Ces réglages valent pour tout le datastore : avec le filtre (objectclass=groupOfNames), les groupes groupOfUniqueNames du même annuaire ne sont plus vus, et leurs membres perdent les privilèges accordés à ces groupes.

Avec ssoadm, depuis un compte du royaume racine :

ssoadm update-datastore --realm /ref --name annuaire \
  --adminid amadmin --password-file /chemin/vers/pwd.txt \
  --attributevalues \
    "sun-idrepo-ldapv3-config-groups-search-filter=(objectclass=groupOfNames)" \
    "sun-idrepo-ldapv3-config-group-objectclass=groupOfNames" \
    "sun-idrepo-ldapv3-config-group-objectclass=top" \
    "sun-idrepo-ldapv3-config-uniquemember=member"

Vérifiez le résultat dans Identités, onglet Groupes : admins-ref doit apparaître, et son onglet Membres doit lister dduck et mmouse. Si le groupe n’apparaît pas, TOSIAM ne pourra pas non plus lui accorder de privilèges.

Étape 3 : accorder les privilèges au groupe#

Connecté une dernière fois avec amadmin, sélectionnez le royaume ref, puis Identités, onglet Groupes, groupe admins-ref, onglet Privilèges. Les 21 privilèges y sont rangés en trois sections : Administration du royaume, Journalisation, Fédération et sessions. Activez Realm Admin (RealmAdmin), puis Enregistrer.

1 2

Avec ssoadm :

ssoadm add-privileges --realm /ref --idname admins-ref --idtype Group \
  --adminid amadmin --password-file /chemin/vers/pwd.txt \
  --privileges RealmAdmin

ssoadm show-privileges --realm /ref --idname admins-ref --idtype Group \
  --adminid amadmin --password-file /chemin/vers/pwd.txt

RealmAdmin est le privilège qui ouvre la console du royaume. Les autres servent à des profils plus étroits, surtout pour des comptes techniques qui appellent l’API REST :

Créez un groupe LDAP par profil (admins-ref, politiques-ref, lecteurs-ref…) plutôt que d’empiler les privilèges sur un seul groupe.

Étape 4 : se connecter avec son propre compte#

L’administrateur se connecte dans le royaume ref, avec son identifiant et son mot de passe LDAP :

https://login.example.com/tosiam/XUI/?realm=/ref#login/

Après la connexion, il arrive sur la console, sur le royaume ref. Un utilisateur de ref qui n’est pas membre d’un groupe privilégié est renvoyé vers son profil (XUI/#profile), comme avant.

1 2

Les menus de la configuration globale (Services globaux, Serveurs…) restent affichés, mais le serveur refuse ces appels à un administrateur de royaume, comme ceux qui visent un autre royaume (403).

Pour vérifier les droits sans navigateur, authentifiez-vous puis lisez le profil de l’utilisateur avec sa propre session : la liste roles contient ui-realm-admin pour un administrateur du royaume, et aussi ui-global-admin pour un administrateur du royaume racine.

TOKEN=$(curl -s -X POST "https://login.example.com/tosiam/json/ref/authenticate" \
  -H "Content-Type: application/json" -H "X-Requested-With: XMLHttpRequest" \
  -H "X-OpenAM-Username: dduck" -H "X-OpenAM-Password: $MOT_DE_PASSE" \
  | jq -r .tokenId)

curl -s "https://login.example.com/tosiam/json/ref/users/dduck" \
  -H "iPlanetDirectoryPro: $TOKEN" -H "X-Requested-With: XMLHttpRequest" | jq -c .roles

["ui-realm-admin","ui-self-service-user"]

Sans privilège, la liste ne contient que ui-self-service-user. Les actions de dduck sont désormais tracées sous son nom dans les journaux d’audit, et non plus sous celui d’amadmin.

Étape 5 : imposer une authentification forte aux administrateurs#

Par défaut, un administrateur délégué obtient ses droits quelle que soit la façon dont il s’est connecté : un simple mot de passe sur la page de connexion des utilisateurs suffit. Pour exiger plus (un second facteur, une clé d’accès…), créez une chaîne réservée aux administrateurs, par exemple admin-mfa, puis réglez deux attributs du service d’authentification du royaume ref :

Ces réglages sont dans la console legacy, royaume ref, Authentification › Paramètres, onglet Core :

1 2

Ou avec ssoadm :

ssoadm set-realm-svc-attrs --realm /ref --servicename iPlanetAMAuthService \
  --adminid amadmin --password-file /chemin/vers/pwd.txt \
  --attributevalues iplanet-am-auth-admin-auth-module=admin-mfa authAdminChainRequired=true

Un administrateur de ref n’obtient alors ses droits, dans la console comme dans l’API, que si sa session a été créée avec la chaîne admin-mfa. Il se connecte par :

https://login.example.com/tosiam/XUI/?realm=/ref&service=adminconsoleservice#login/

Le paramètre service=adminconsoleservice désigne la configuration d’authentification des administrateurs du royaume, quel que soit son nom. Une session ouverte avec une autre chaîne reste valide pour les applications, mais sans aucun droit d’administration : par l’URL de connexion habituelle, dduck arrive sur son profil et non sur la console. Pour l’API REST, ajoutez ?authIndexType=service&authIndexValue=adminconsoleservice à l’appel authenticate.

Le contrôle est fait à chaque appel d’administration, sur le royaume où la session a été créée. Si Authentification des administrateurs obligatoire est activé sans configuration d’authentification des administrateurs, le réglage est ignoré et un avertissement est écrit dans le journal.

Un administrateur global sans amadmin#

Pour la configuration globale (serveurs, sites, services globaux, création de royaumes), refaites les étapes 1 à 5 dans le royaume racine : un groupe admins-tosiam dans l’annuaire du royaume racine, le privilège RealmAdmin accordé à ce groupe dans le royaume racine. Ses membres se connectent sans paramètre realm et reçoivent aussi le rôle ui-global-admin.

Ce sont aussi les seuls comptes, avec amadmin, qui peuvent utiliser ssoadm. Le fichier de mot de passe doit être lisible par son seul propriétaire (chmod 400) :

ssoadm list-realms --realm / --adminid admin.tosiam --password-file ~/.tosiam-pwd

Avec un compte d’un sous-royaume, comme dduck, ssoadm répond Login failed.

Que faire d’amadmin#

amadmin ne se supprime pas : TOSIAM s’en sert pour lui-même et il reste le recours si l’annuaire LDAP est injoignable, puisque les comptes délégués en dépendent. Traitez-le comme un compte de secours :

• remplacez son mot de passe par une valeur longue et aléatoire, gardée dans un coffre et connue de deux personnes au plus ;
• ne l’utilisez plus pour l’administration courante, ni dans les scripts : donnez aux scripts un compte LDAP technique du royaume racine, membre d’un groupe qui n’a que les privilèges nécessaires ;
• surveillez ses connexions dans le journal d’audit des authentifications : en temps normal, il n’y en a aucune.

Retirer un administrateur#

Retirez l’utilisateur du groupe dans l’annuaire. Le retrait vaut dès la requête suivante, y compris pour une session déjà ouverte : la console et l’API lui répondent 403. De même, un utilisateur ajouté au groupe reçoit les droits dès sa connexion suivante, sans délai.

Retirer le privilège au groupe, dans l’onglet Privilèges ou avec ssoadm remove-privileges, retire les droits à tous ses membres.

Dépannage#