ds

Pass-Through Authentication et migration des mots de passe

vincentl — Mon, 04 Apr 2022 15:09:40 +0000

Pass-Through Authentication et migration des mots de passe

Contexte

Dans un projet de migration d'un annuaire AD LDS vers un Forgerock DS, le principal problème est de pouvoir récupérer les mots de passe.

En effet, AD LDS (et AD DS) ne permettent pas d'exporter le hash du mot de passe en LDIF, et il n'est pas possible non plus simplement de les récupérer, même en passant par des outils tels que creddump , ntdsextract ou autre.

Du coup, l'idée peut être intéressante de paramétrer l'annuaire Forgerock DS en mode pass through authentication, d'activer le cache, et ensuite d'utiliser le mot de passe local, une fois la première authentification correcte réalisée sur l'AD LDS (ou n'importe quel annuaire).

Pré-requis : import du certificat

Dans un premier temps, il faut importer le certificat de l'annuaire d'authentification. On peut récupérer le certificat avec une commande openssl :

openssl s_client -connect authserver:2636

Une fois le certificat sauvegardé, on va l'intégrer avec keytool :

keytool -importcert  -alias authserver -keystore /opt/opendj/config/keystore -file ~/authserver.pem

Création d'un "fournisseur de confiance"

Via la commande dsconfig, on va déclarer le serveur d'authentification distant comme "fournisseur de confiance"

dsconfig \
  create-trust-manager-provider \
  --hostname localhost \
  --port 4444 \
  --bindDN uid=admin \
  --bindPassword password \
  --provider-name AuthServerPKCS12 \
  --type file-based \
  --set enabled:true \
  --set trust-store-type:PKCS12 \
  --set trust-store-file:config/keystore \
  --set trust-store-pin:"&{file:config/keystore.pin}" \
  --usePkcs12TrustStore /opt/opendj/config/keystore \
  --trustStorePassword:file /opt/opendj/config/keystore.pin \
  --no-prompt

Paramétrage du mode PTA

Il faut ensuite créer une politique d'authentification

dsconfig \
create-password-policy \
--hostname localhost \
--port 4444 \
--bindDN uid=admin \
--bindPassword password \
--policy-name "AuthServer_PTA_Policy" \
--type ldap-pass-through \
--set primary-remote-ldap-server:authserver:636 \
--set mapped-attribute:uid \
--set mapped-search-base-dn:"cn=Users,dc=example,dc=com" \
--set mapped-search-bind-dn:"uid=ad-bind-account,cn=admins,dc=example,dc=com" \
--set mapped-search-bind-password:ZmQ5OWUw-ADpassword \
--set trust-manager-provider:AuthServerPKCS12 \
--set mapping-policy:mapped-search \
--set use-password-caching:true \
--set cached-password-storage-scheme:PBKDF2-HMAC-SHA256 \
--set cache-password-ttl:24h \
--set use-ssl:true \
--usePkcs12TrustStore /opt/opendj/config/keystore \
--trustStorePassword:file /opt/opendj/config/keystore.pin \
--no-prompt

On précise notamment :

le hostname et le port du serveur d'authentification (dans notre exemple, authserver, qui écoute sur le port 636)
la base de recherche pour les utilisateurs
l'attribut commun entre le compte local et le compte sur le serveur d'authentification, dans l'exemple on utilise uid (il faut donc que l'attribut soit bien unique et identique sur les 2 serveurs)
le DN du compte sur le serveur distant
le mot de passe du compte distant
Le trust manager (déclaré ci-avant)

En optionnel, on active le "password caching", qui permet, lors d'une première authentification réalisée avec succès, de cacher le mot de passe en local pour éviter les multiples accès sur le serveur d'authentification distant. Pour ceci, il faut également définir le schéma de stockage du mot de passe caché.

On positionne la valeur du cache (TTL) à 24 heures.

Assignation de la password policy à un utilisateur

Pour que la politique de type "pass through" soit appliquée à l'utilisateur, il faut l'assigner de manière explicite, par exemple via un fichier ldif :

dn: cn=user1,ou=Externes,ou=People,dc=example,dc=com
changetype: modify
add: ds-pwp-password-policy-dn
ds-pwp-password-policy-dn: cn=AuthServer_PTA_Policy,cn=Password Policies,cn=config

Si l'utilisateur tente ensuite de se connecter au serveur DS, on peut voir les logs sur le serveur d'authentification (ici il s'agit des logs d'une autre instance Forgerock DS, utilisée pour les tests):

{"eventName":"DJ-LDAP","client":{"ip":"127.0.0.1","port":60984},"server":{"ip":"127.0.0.1","port":2636},"request":{"protocol":"LDAPS","operation":"SEARCH","connId":8,"msgId":9,"dn":"cn=Users,dc=example,dc=com","scope":"sub","filter":"(uid=1189670333702hawl)","attrs":["1.1"]},"transactionId":"0a31b37e-b7f3-4854-9154-5ebad695ff24-488","response":{"status":"SUCCESSFUL","statusCode":"0","elapsedTime":1,"elapsedTimeUnits":"MILLISECONDS","nentries":1},"userId":"uid=ad-bind-account,ou=admins,dc=example,dc=com","timestamp":"2022-04-04T14:15:36.803Z","_id":"0a31b37e-b7f3-4854-9154-5ebad695ff24-490"}
{"eventName":"DJ-LDAP","client":{"ip":"127.0.0.1","port":60986},"server":{"ip":"127.0.0.1","port":2636},"request":{"protocol":"LDAPS","operation":"BIND","connId":9,"msgId":8,"version":"3","dn":"cn=user1,cn=Users,dc=example,dc=com","authType":"SIMPLE"},"transactionId":"0a31b37e-b7f3-4854-9154-5ebad695ff24-491","response":{"status":"SUCCESSFUL","statusCode":"0","elapsedTime":1,"elapsedTimeUnits":"MILLISECONDS","additionalItems":{"ssf":"256"}},"userId":"cn=user1,cn=Users,dc=example,dc=com","timestamp":"2022-04-04T14:15:36.805Z","_id":"0a31b37e-b7f3-4854-9154-5ebad695ff24-493"}

Si on a activé le cache, on peut constater qu'après une première authentification correcte, l'annuaire distant n'est plus sollicité lors des authentifications suivantes, sauf si le mot de passe ne correspond plus à la valeur en cache.

Au niveau local, le mot de passe est stocké dans un attribut opérationnel : ds-pta-cached-password. On y trouve également la date de mise en cache du mot de passe.

Par exemple :

dn: cn=user1,ou=Externes,ou=People,dc=example,dc=com
ds-pta-cached-password: {SSHA512}CpdBFPCD2LrQpDOFK+hjOifS+hwRz79yWYjMFS543iyAmHZIliBgHnoKjY+HhERC61eQMqNmkgEvrlXYtkmhyK9HK+0gqQQBraFUUd2TViM=
ds-pta-cached-password-time: 20220404141914Z
ds-pwp-password-policy-dn: cn=AuthServer_PTA_Policy,cn=Password Policies,cn=config

Migration progressive des mots de passe

En utilisant le mécanisme de cache et l'authentification en mode pass through, on pourra donc envisager de migrer progressivement les mots de passe de la manière suivante :

pour tous les utilisateurs qui doivent être migrés, assigner la politique de mot de passe de type "PTA Policy"
pour les autres, on peut se reposer sur les politiques de mots de passe par défaut, ou celles définies dans les données (de type subentry)

Il faudra ensuite avoir un traitement complémentaire, qui sera lancé à intervalle régulier, et avec une fréquence supérieure à la durée de cache, qui va réaliser le traitement suivant :

rechercher les comptes qui ont l'attribut ds_pta-cached-password positionné, avec la politique de mot de passe "PTA"
Pour ces comptes :
mettre à jour l'attribut userPassword avec la valeur de l'attribut de cache
supprimer l'assignation de la politique de mot de passe, pour récupérer celle définie par défaut.

Afin d'améliorer les performances, on pourra créer un index sur l'attribut :

create-backend-index --backend-name amIdentityStore --index-name ds-pta-cached-password --type generic --set index-type:presence

Ceci peut donc permettre d'utiliser les mots de passe actuels, tout en déconnectant au fil de l'eau le lien avec l'ancien annuaire.

Au bout d'un certain temps, on pourra considérer que les comptes qui ont encore l'ancienne politique de mots de passe (ou qui n'ont pas encore d'attribut userPassword) ne sont pas utilisés, et on pourra faire un peu de "ménage", ou faire une campagne de renouvellement de mots de passe.

vincentl lun 04/04/2022 - 17:09

Catégorie

IAM

Tag

forgerock

opendj

Ajouter un commentaire

Utilisation d'attributs Json dans Forgerock DS

vincentl — Fri, 04 Mar 2022 13:55:34 +0000

Utilisation d'attributs Json dans Forgerock DS

Problématique

Il arrive des cas où l'utilisation des attributs "simples", qu'ils soient mono ou multi-valués, n'est pas satisfaisante par rapport aux besoins des utilisateurs.

Prenons le cas suivant : on veut gérer des délégations pour X types de profils et chacun avec des rôles spécifiques.

Soit :

délégation pour une société S1, avec les rôles RS1, RS2, RS3
délégation pour une société S2, avec les rôles RS1, RS3
délégation pour un utilisateur U1, avec les rôles RU1, RU2

Si on utilise un attribut de type chaîne de caractères, on peut s'en sortir avec des concaténations et des caractères de séparation. Par exemple :

type|identifiant du type|role1-role2-role3

Dans ce cas on doit déjà gérer 2 types de séparateurs :le "|" pour les différents éléments, et le "-" pour les rôles.

Dans notre exemple, ça donnerait :

societe|S1|RS1-RS2-RS3
societe|S2|RS1-RS3
utilisateur|U1|RU1-RU2

Par contre pour les recherches, ça devient plus compliqué, sauf à pré-calculer un filtre, en jouant avec les séparateurs.

Attribut Json

Depuis la version 5.5 (au moins), Forgerock permet d'utiliser une syntaxe Json dans les attributs, ce qui permet de gérer des données structurées à l'intérieur d'un attribut.

Déclaration dans le schéma

L'ajout d'un attribut de type JSON se fait de manière traditionnelle, en utilisant une syntaxe spécifique (1.3.6.1.4.1.36733.2.1.3.1).

On ajoute ensuite les attributs dans le schéma :

attributeTypes: ( 1.3.6.1.4.1.18472.2.101 NAME 'delegations' SYNTAX 1.3.6.1.4.1.36733.2.1.3.1 EQUALITY caseIgnoreJsonQueryMatch X-ORIGIN 'Mes tests json' )
attributeTypes: ( 1.3.6.1.4.1.18472.2.102 NAME 'jsonId' SYNTAX 1.3.6.1.4.1.36733.2.1.3.1 EQUALITY caseIgnoreJsonIdMatch SINGLE-VALUE X-ORIGIN 'Mes tests json' )

On doit également préciser le type de règle d'égalité qui sera utilisée. Il en existe 4 pré-définies :

caseIgnoreJsonQueryMatch : 2 objets sont identiques si tous leurs champs sont les mêmes, à la casse près
caseExactJsonQueryMatch : 2 objets sont identiques si tous leurs champs sont les mêmes, avec la même casse de caractères
caseIgnoreJsonIdMatch : 2 objets sont identiques si leur champ "_id" est identique, quelle que soit la casse de caractères
caseExactJsonIdMatch : 2 objets sont identiques si leur champ "_id" est identique, avec la même casse de caractères.

Quelques exemples pour illustrer les cas. En supposant que j'ai 2 entrées dans l'annuaire LDAP, avec :

{"_id":"json","type":"user","value":"user123"}
{"_id":"Json","type":"User","value":"USER123"}
{"_id":"json","type":"user","value":"user345"}
{"_id":"Json","type":"User","value":"USER345"}

Selon les cas :

avec la règle caseIgnoreJsonQueryMatch, les objets 1 et 2, et les objets 3 et 4 sont identiques
avec la règle caseExactJsonQueryMatch, il n'y a pas de correspondance
avec la règle caseIgnoreJsonIdMatch, les 4 objets sont identiques (ils ont le même _id)
avec la règle caseExactJsonIdMatch, les objets 1 et 3 sont considérés identiques, ainsi que 2 et 4

Indexation

Lorsqu'on indexe un attribut JSON, le comportement par défaut de Forgerock DS est de maintenir des clés pour chaque champ JSON. De ce fait, si l'attribut JSON contient de nombreux champs différents (et qui ne font pas l'objet de recherches) on peut choisir de n'indexer que ces champs. Dans ce cas, il faudra définir soi-même une règle (de type json-equality-matching-rule).

Si on utilise une règle de comparaison basée sur l'ID uniquement, c'est ce champ qui sera indexé, et pas les autres.

Recherche

La syntaxe du filtre de recherche est la même que celle utilisée pour les API REST Forgerock (communément appelées CREST = Common REST).

Quelques exemples de filtres, sur la base de nos attributs delegations et jsonId déclarés précédemment :

delegations: {"type":"societe","attributions":[{"id":"societe1","roles":["role-soc1","role-soc2","role-soc3"]},{"id":"societe2","roles":["role-soc4"]}]}
delegations: {"type":"utilisateur","attributions":[{"id":"user1","roles":["role-usr1","role-usr2"]},{"id":"user2","roles":["role-usr4"]}]}
delegations: {"type":"org","attributions":[{"id":"org1","roles":["role-org1","role-org2","role-org4"]}] }
jsonId: {"_id":"json","type":"user","value":"user123"}
jsonId: {"_id":"Json","type":"User","value":"USER123"}
jsonId: {"_id":"json","type":"user","value":"user345"}
jsonId: {"_id":"Json","type":"User","value":"USER345"}

(delegations=*) : va renvoyer toutes les entrées qui ont un attribut delegations
(jsonid=_id eq 'json') va renvoyer les entrées qui ont la valeur 'json' dans le champ "_id" de l'attribut
(delegations=type eq 'utilisateur' or type eq 'societe') : va renvoyer les objets ayant l'une ou l'autre valeur dans le champ type

Limitations sur les filtres de recherche

Il n'est pas possible de faire une recherche dans un tableau qui contient plusieurs objets (attributions dans notre exemple).

(delegations=id eq "user2")

ne ramène rien (on n'y accède pas directement, il faudrait passer par attributions->id).

Par contre, si on a une structure dont l'un des attributs est un tableau, qui ne contient que des valeurs, cela fonctionne.

Si on a des attributs comme ceci :

delegations: {"type":"utilisateur","id":"user1","roles":["role-usr1","role-usr2"]}
delegations: {"type":"utilisateur","id":"user2","roles":["role-usr4","role-usr2"]}
delegations: {"type":"societe","id":"societe1","roles":["role-soc1","role-soc2","role-soc3"]}
delegations: {"type":"societe","id":"societe2","roles":["role-soc4"]}
delegations: {"type":"org","id":"org2","roles":["role-org1","role-org2","role-org4"]}

On peut bien faire des recherches de type :

ldapsearch -b ou=people,dc=example,dc=com '(delegations=id eq "user2")'

Si on veut éviter des collisions entre les différents types, on peut combiner plusieurs recherches. Si elles portent sur plusieurs éléments de l'attribut json, il faut utiliser le filtre adéquat. Par exemple :

(delegations=id eq "2" and type eq "societe")

La recherche dans un tableau fonctionne également. On peut ainsi rechercher tout les objets LDAP qui ont un role "role-usr4" :

(delegations=roles eq "role-usr4")

Idem pour les objets avec un type "societe" et un rôle "role-soc1" :

(delegations=type eq "societe" and roles eq "role-soc1")

vincentl ven 04/03/2022 - 14:55

Catégorie

Tag