forgerock

Problème de connexion ldapsearch sur un AD LDS

vincentl — Fri, 13 May 2022 12:05:59 +0000

Problème de connexion ldapsearch sur un AD LDS

J'ai été confronté à un problème curieux d'accès à un serveur AD LDS à partir d'un container de type Forgerock DS.

Côté réseau, tout était OK, les ports ouverts d'un côté comme de l'autre.

Par contre une commande ldapsearch tombait en erreur :

/opt/opendj/bin/ldapsearch  --hostname 10.1.2.3 --port 389 -D "CN=admin,CN=Admin-Users,dc=example,dc=fr" -w admin2003 \
-b "CN=Applications,DC=example,DC=fr" "(objectclass=exApplications)"
Unable to connect to the server: 91 (Connect Error)
Additional Information:  Remote close

Pas très parlant.

Côté AD LDS, en modifiant le niveau de logs, on a :

Internal event: The LDAP server returned an error.
 
Additional Data
Error value:
00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v4563

Peu d'éléments complémentaires. Sachant qu'en plus, en local sur la machine AD LDS, la même connexion se fait sans problème.

En investiguant un peu plus, je tente une connexion en mode "startSSL", pour voir si j'ai le même comportement :

/opt/opendj/bin/ldapsearch --useStartTls --hostname 10.1.2.3

Et là, le message d'erreur côté machine cliente est différent et me met sur la piste :

An error occurred while parsing the command-line arguments:  You may not
provide both the --useStartTls and the --useSsl arguments

See "ldapsearch --help" to get more usage help

Comme je n'ai pas précisé les 2 options (useStartTls et useSsl) dans ma ligne de commande, l'option useSsl doit venir d'un paramétrage par défaut.

Et en effet, par défaut les commandes ldap utilisent un fichier de propriétés (/opt/opendj/config/tools.properties) qui définit un certain nom de paramètres par défaut.
On y trouvait notamment :

useSsl=true
trustAll=true

Du coup lorsque je tentais une connexion "en clair" sur le port 389, AD LDS recevait une requête sur un port non chiffré, mais avec une instruction qui disait que la connexion devait être chiffrée... d'où les messages d'erreur.

En utilisant l'option "--noPropertiesFile" dans le ldapsearch, on peut du coup accéder en LDAP sur le port 389, et récupérer les données.

L'autre option (plus sécurisée), serait d'utiliser du LDAPS entre les deux serveurs.

vincentl ven 13/05/2022 - 14:05

Catégorie

IAM

Tag

ldap

forgerock

Ajouter un commentaire

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

Ajouter un commentaire

OpenIDM - Sécuriser un Connecteur Database Table

vincentl — Thu, 07 Jan 2021 08:54:49 +0000

OpenIDM - Sécuriser un Connecteur Database Table

Dans un projet client qui utilise IDM 7 (après une montée de version OpenIDM 3.1 vers IDM 7 qui s'est plutôt bien passée), nous avons mis en place la gestion du cycle de vie et notamment la suppression automatique de comptes 30 jours après la fin de contrat, comme ce que l'on voit souvent.

Il a été décidé d'archiver quelques données des utilisateurs, histoire d'avoir un peu de traces.

Pour ce faire nous avons mis en place un connecteur Database Table, qui pointe sur une table d'une base PostgreSQL. La base utilisée est la même que celle qui héberge le repository IDM.

Tout fonctionnait correctement, jusqu'au moment où une insertion dans la table est tombée en erreur.

Le message d'erreur :

[122] janv. 07, 2021 9:06:00.069 AM org.identityconnectors.framework.impl.api.local.operations.CreateImpl create
GRAVE: buildSelectBasedAttributeInfo in SQL: 'SELECT * FROM openidm.archive_managed_user WHERE objectid IS NULL'
org.postgresql.util.PSQLException: FATAL: terminating connection due to administrator command
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2532)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2267)

[122] janv. 07, 2021 9:06:00.071 AM org.apache.tomcat.jdbc.pool.PooledConnection clearWarnings
AVERTISSEMENT: Unable to clear Warnings, connection will be closed.
org.postgresql.util.PSQLException: This connection has been closed.
        at org.postgresql.jdbc.PgConnection.checkClosed(PgConnection.java:865)
        at org.postgresql.jdbc.PgConnection.clearWarnings(PgConnection.java:759)
        at org.apache.tomcat.jdbc.pool.PooledConnection.clearWarnings(PooledConnection.java:837)
        at org.apache.tomcat.jdbc.pool.ConnectionPool.returnConnection(ConnectionPool.java:977)

[122] janv. 07, 2021 9:06:00.073 AM org.forgerock.openidm.quartz.SchedulerServiceJob execute
AVERTISSEMENT: Scheduled service "scheduler-service-group.delete" invocation reported failure: org.forgerock.json.resource.ForbiddenException: {code=500, reason=Internal Server Error, message=Operation CREATE failed with ConnectorException on system object}
org.forgerock.openidm.quartz.ExecutionException: org.forgerock.json.resource.ForbiddenException: {code=500, reason=Internal Server Error, message=Operation CREATE failed with ConnectorException on system object}
        at org.forgerock.openidm.script.impl.ScriptRegistryService.execute(ScriptRegistryService.java:772)
        at org.forgerock.openidm.quartz.SchedulerServiceJob.execute(SchedulerServiceJob.java:123)

Analyse de la cause

En regardant dans les logs nous nous sommes aperçus que la base était indisponible périodiquement, pour une sauvegarde offline.

Autant le "moteur" IDM était capable de reprendre son activité une fois la sauvegarde terminée et la base redémarrée, autant le connecteur n'arrivait pas à relancer une connexion.

Résolution

Après différentes recherches sur le Web et l'ouverture d'un ticket "How do I ? " chez Forgerock, j'ai pu modifier le fichier de configuration provisioner.openicf-archiveDB.json pour y modifier les paramètres suivants :

"validationInterval" : "30000" (permet de limiter la fréquence de validation)
"validationQueryTimeout" : "30" (time-out pour les requêtes de validation)
"validationQuery" : "SELECT 1 FROM archive_managed_user" (requête SQL utilisée pour la validation)
"testOnConnect" : true (permet de valider avant la connection)
"testOnBorrow" : true (permet de valider avant d'utiliser une connection dans le pool)

Ce sont surtout les paramètres validationQuery et testOnBorrow qui permettent de gérer les cas de déconnexion.

Une fois la nouvelle configuration mise en place, le connecteur devient fault-tolerant et peut reprendre son activité même après une perte de connexion à la base de données.

vincentl jeu 07/01/2021 - 09:54

Catégorie

Tag

Ajouter un commentaire

Forgerock OpenDJ / DS - Supprimer les contrôles de syntaxe

Vincent — Wed, 09 Dec 2020 10:30:28 +0000

Forgerock OpenDJ / DS - Supprimer les contrôles de syntaxe

Par défaut les nouveaux annuaires LDAP issus des sources OpenDS (tels que OpenDJ / DS chez Forgerock, mais aussi Ping Directory) renforcent les contrôles sur la syntaxe des attributs, le schéma, etc.

Ceci empêche par exemple d'avoir un objet avec de multiples classes structurelles non hiérarchiques (par exemple inetorgperson et country).

Par contre lorsqu'on importe des données d'un annuaire un peu moins strict (type Sun / Oracle DSEE), on se heurte souvent à des erreurs.

La solution la plus propre est de modifier le fichier LDIF pour remettre au carré les données :

supprimer / modifier les attributs non conformes
modifier le schéma pour éviter les héritages multiples

Mais ceci n'est pas toujours faisable.

On peut alors relâcher les contrôles effectuer, en utilisant l'utilitaire dsconfig (testé depuis la version OpenDJ 2.6 jusque DS 7) :

#!/bin/bash

PORT=5444
HOST=djlyreco
BINDPASS="SuperPa$$w0rd"

cd /path/to//opendj

# Do not check schema

bin/dsconfig set-global-configuration-prop --hostname $HOST --port ${PORT} --bindDN "cn=Directory Manager" \
--bindPassword ${BINDPASS} --set check-schema:false --trustAll --no-prompt

# Allows multiple structural object classes (warning only)
bin/dsconfig set-global-configuration-prop --hostname $HOST --port ${PORT} --bindDN "cn=Directory Manager" \
--bindPassword ${BINDPASS} --set single-structural-objectclass-behavior:warn --trustAll --no-prompt

# Allows invalid attribute syntax
bin/dsconfig set-global-configuration-prop --hostname $HOST --port ${PORT} \
--bindDN "cn=Directory Manager" --bindPassword ${BINDPASS} --set invalid-attribute-syntax-behavior:warn --trustAll --no-prompt

# Allow pre-encoded passwords : pour l'import de compte avec des mots de passe existant
bin/dsconfig -p ${PORT} -h $HOST -D "cn=Directory Manager" -w ${BINDPASS} \
 set-password-policy-prop --policy-name "Default Password Policy" --set allow-pre-encoded-passwords:true -X -n

La dernière ligne permet également d'importer des mots de passe pré-encodés. C'est utile en cas de migration de données entre annuaires, pour garder les mêmes mots de passe.

Vincent mer 09/12/2020 - 11:30

Catégorie

Tag

Ajouter un commentaire

Upgrade Forgerock OpenDJ / DS

vincentl — Fri, 14 Dec 2018 21:06:26 +0000

Upgrade Forgerock OpenDJ / DS

Deux scénarios de migration / upgrade seront étudiés :

upgrade "en place" d'un annuaire en version inférieure
ajout dans la topologie de réplication d'un annuaire en version supérieure.

Dans cet exemple, on va procéder à une migration de la version OpenDJ 3.5.1 à la version DS 6.5.

Environnement

L'environnement de test est le suivant :

3 serveurs : dj1.id-num.com, dj2.id-num.com, dj3.id-num.com.

Dans un premier temps, seuls les serveurs dj1 et dj2 sont installés, en mode multi-maîtres :

O.S. CentOS 7
Java jre 1.8
OpenDJ 3.5.1, avec 2 annuaires répliqués
Schéma de données custom avec attributs et classes d'objets spécifiques
Annuaire installé dans le répertoire /opt/opendj
Index créé sur le serveur dj2, sur l'attribut company

Script d'installation

L'installation sur les 2 serveurs a été faite avec le script suivant :

#!/bin/sh
#
# Installation Forgerock OpenDJ 3.5.1
#
#---------------------------------------
LDAPPORT=1389
PASS=ldapMaster
REPLADM=replicationAdmin
REPLPASS=replicationPassword
ADMINPORT=4445

HOST1=dj1.id-num.com
HOST2=dj2.id-num.com
HOST3=dj3.id-num.com

JAVAHOME=/opt/jre1.8.0_144
BASEDN="o=example"
BASEDIR=/opt/opendj
BINDIR=${BASESDIR}/bin
export JAVA_HOME=${JAVAHOME}
export OPENDJ_JAVA_HOME=${JAVAHOME}

${BASEDIR}/setup \
  --cli \
  --baseDN ${BASEDN} \
  --addBaseEntry \
  --ldapPort ${LDAPPORT} \
  --adminConnectorPort ${ADMINPORT} \
  --rootUserDN cn=Directory\ Manager \
  --rootUserPassword ${PASS} \
  --acceptLicense \
  --no-prompt \
  --noPropertiesFile

Script de réplication

La réplication est mise en place entre les serveurs dj1 et dj2, via la commande :

${BINDIR}/dsreplication enable \
--host1 ${HOST1} --port1 ${ADMINPORT} \
--bindDN1 "cn=Directory Manager" \
--bindPassword1 ${PASS} \
--replicationPort1 8989 \
--host2 ${HOST2} --port2 ${ADMINPORT} \
--bindDN2 "cn=Directory Manager" \
--bindPassword2 ${PASS} \
--replicationPort2 8989 \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}   \
--trustAll \
--no-prompt

On peut ensuite lancer l'init, pour tous les serveurs de la topologie :

${BINDIR}/dsreplication \
initialize-all \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}  \
--hostname $(hostname) \
--port ${ADMINPORT} \
--trustAll \
--no-prompt

On vérifie, avec l'option status :

${BINDIR}/dsreplication status \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--port ${ADMINPORT} \
--trustAll \
--no-prompt


Suffix DN            : Server              : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : M.C. (2) : A.O.M.C. (3) : Security (4)
---------------------:---------------------:---------:---------------------:-------:-------:-------------:----------:--------------:-------------
cn=Directory Manager : dj2.id-num.com:4445 :         :                     :       :       :             :          :              : 
o=example            : dj1.id-num.com:4445 : 45      : true                : 14774 : 27576 : 8989        : 0        :              : false
o=example            : dj2.id-num.com:4445 :         : true                : 29513 : 481   : 8989        : 0        :              : false

Schéma spécifique

Le schéma est modifié avec l'ajout de 2 attributs et une classe d'objet :

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( partneruid-oid NAME 'partneruid' SUP name X-ORIGIN 'user Defined' )
attributeTypes: ( company-oid NAME 'company' SUP name X-ORIGIN 'user Defined' )
-
add: objectclasses
objectClasses: ( partnerperson-oid NAME 'partnerPerson' SUP inetorgperson MUST ( company ) MAY ( partneruid) )

Version OpenDJ / DS

On peut vérifier la version actuelle avec la commande :

/opt/opendj/bin/dsconfig --version
3.5.1 (revision 23b322a7502f029b6d3725212c162de36f038122)

Upgrade "en place"

Il faut tout d'abord vérifier la trajectoire de migration supportée.

Pour Directory Services 6.5, sorti fin 2018, la migration est supportée depuis la version OpenDJ 2.6 et supérieure.

La version de Java est également à vérifier : Java 8 ou 11 pour DS 6.5. Nous utilisons une version 8 ce qui convient donc.

Forgerock recommande de faire une sauvegarde physique du serveur à upgrader, en arrêtant l'annuaire et en faisant un backup de toute l'arborescence :

/opt/opendj/bin/stop-ds
tar zcf opendj-3.5.tgz opendj

Note : l'upgrade en place nécessite d'arrêter l'instance d'annuaire qui va être migrée.

Procédure de migration

La procédure est simple ; elle consiste essentiellement à :

extraire l'archive de la nouvelle version au dessus de l'ancienne
lancer la commande upgrade
vérifier et éventuellement adapter le paramétrage.

En détail :

cd /opt
unzip /path/to/Software/Forgerock/DS-6.6.0.zip
Archive:  DS-6.6.0.zip
   creating: opendj/legal-notices/third-party-licenses/
   creating: opendj/template/extlib/
   creating: opendj/template/setup-profiles/
.../...
   creating: opendj/template/setup-profiles/IDM/repo/6.5/
   creating: opendj/template/setup-profiles/IDM/repo/6.5/schema/
replace opendj/snmp/mib/rfc2605.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: y

Répondre "A" pour écraser / remplacer les anciennes versions de fichiers.

Lancer ensuite l'upgrade :

/opt/opendj/upgrade

>>>> OpenDJ Upgrade Utility

 * OpenDJ configuration will be upgraded from version
 3.5.1.23b322a7502f029b6d3725212c162de36f038122 to
 6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3
 * OpenDJ data will be upgraded from version 6.0.0 to
 6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3
 * See '/opt/opendj/logs/upgrade.log' for a detailed log of this operation

>>>> Preparing to upgrade

  OpenDJ 5.5.0 changed the indexing algorithm for JSON equality matching
  rules. All JSON based attribute indexes must be rebuilt which may take a
  long time. Do you want to rebuild the indexes automatically at the end of
  the upgrade? (yes/no) [no]: yes

  OpenDJ 6.5.0 changed the indexing algorithm for replication metadata. Its
  index must be rebuilt which may take a long time; without a working index
  every server start will take longer than normal. Do you want to rebuild the
  index automatically at the end of the upgrade? (yes/no) [no]: yes

  The upgrade is ready to proceed. Do you wish to continue? (yes/no) [yes]: 

>>>> Performing upgrade

  Adding configuration for schema providers...........................   100%     
  Adding configuration entry 'dn: cn=Core Schema,cn=Schema
  Providers,cn=config'................................................   100%     
  Removing top configuration entry for matching rules.................   100%     
  Removing configuration for syntaxes.................................   100%

.../...
  Replacing schema file '02-config.ldif'..............................   100%     
  Archiving concatenated schema.......................................   100%     
  Migrating replication changelog files to 6.5.0 format...............   100%     

>>>> OpenDJ configuration was successfully upgraded from version
3.5.1.23b322a7502f029b6d3725212c162de36f038122 to
6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3


>>>> OpenDJ data was successfully upgraded from version 6.0.0 to
6.5.0.e2a029a050cc6908fd144a6ca9c687e01ad56ea3


>>>> Performing post upgrade tasks

  Rebuilding index(es) '[.caseIgnoreJsonQueryMatch,
  .caseExactJsonQueryMatch,
  ds-sync-hist.changeSequenceNumberOrderingMatch]' for base dn(s)
  '[o=example]'.......................................................   100%     

>>>> Post upgrade tasks complete

Les logs de la migration se trouvent dans $DSHOME/logs/upgrade.log.

On peut ensuite démarrer l'instance, via la commande bin/start-ds

L'annuaire est bien passé en version supérieure :

/opt/opendj/bin/dsconfig --version
6.5.0 (revision e2a029a050cc6908fd144a6ca9c687e01ad56ea3)

Post Upgrade

Si on part d'une version inférieure à la version 5.5, Forgerock rcommande de donner des privilèges spécifiques au compte de réplication. Les privilèges à ajouter sont les suivants :

bypass-lockdown
monitor-read
server-lockdown

Ceci peut être fait en LDIF. Dans notre cas, le compte utilisé est replicationAdmin :

dn: cn=replicationAdmin,cn=Administrators,cn=admin data
changetype: modify
add: ds-privilege-name
ds-privilege-name: bypass-lockdown
ds-privilege-name: monitor-read
ds-privilege-name: server-lockdown

La modification n'est à faire qu'une seule fois, les données étant répliquées.

L'upgrade peut ensuite être fait pour tous les serveurs de la topologie.

Ajout d'un nouveau serveur dans la topologie

Dans cette option, on va ajouter un nouveau serveur dans la topologie de réplication. Ceci peut donc être fait sans interruption de service.

Installation de DS 6.5

L'installation ds DS 6.5 se fait quasiment de la même manière que OpenDJ 3.5. Les seules différences : pas d'option --cli et l'option --hostname qui est obligatoire.

LDAPPORT=1389
PASS=ldapMaster
REPLADM=replicationAdmin
REPLPASS=replicationPassword
ADMINPORT=4445

HOST1=dj1.id-num.com
HOST2=dj2.id-num.com
HOST3=dj3.id-num.com

JAVAHOME=/opt/jre1.8.0_144
BASEDN="o=example"
BASEDIR=/opt/opendj
BINDIR=${BASESDIR}/bin
export JAVA_HOME=${JAVAHOME}
export OPENDJ_JAVA_HOME=${JAVAHOME}
/opt/opendj/setup \
  --hostname ${HOST3} \
  --baseDN ${BASEDN} \
  --addBaseEntry \
  --ldapPort ${LDAPPORT} \
  --adminConnectorPort ${ADMINPORT} \
  --rootUserDN cn=Directory\ Manager \
  --rootUserPassword ${PASS} \
  --acceptLicense

A ce stade, on a donc un annuaire en mode "standby". Nous pouvons l'inclure dans le domaine de réplication.

Ajout dans la réplication

Forgerock recommande d'utiliser la commande dsreplication du nouveau serveur pour l'ajouter dans une topologie de réplication existante.

La commande pour configurer une nouvelle réplication utilise maintenant l'option configure plutôt que enable :

${BINDIR}/dsreplication configure \
--host1 ${HOST1} --port1 4445 \
--bindDN1 "cn=Directory Manager" \
--bindPassword1 ${PASS} \
--replicationPort1 8989 \
--host2 ${HOST3} --port2 4445 \
--bindDN2 "cn=Directory Manager" \
--bindPassword2 ${PASS} \
--replicationPort2 8989 \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}   \
--trustAll \
--no-prompt

Initialisation de la réplication

On peut maintenant lancer l'initialisation de la réplication sur un seul serveur. Avec l'option initialize plutôt que initialize-all il faut préciser les serveurs sources et destinations :

${BINDIR}/dsreplication initialize \
--adminUID ${REPLADM} \
--adminPassword ${REPLPASS} \
--baseDN ${BASEDN}  \
--hostSource ${HOST1} \
--portSource ${ADMINPORT} \
--hostDestination ${HOST2} \
--portDestination ${ADMINPORT} \
--trustAll \
--no-prompt

On peut ensuite vérifier :

Suffix DN : Server              : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : Delay (ms) : Security (2)
----------:---------------------:---------:---------------------:-------:-------:-------------:------------:-------------
o=example : dj1.id-num.com:4445 : 2025    : true                : 14774 : 27576 : 8989        : N/A        : false
o=example : dj2.id-num.com:4445 : 2025    : true                : 29513 : 481   : 8989        : 0          : false
o=example : dj3.id-num.com:4445 : 2025    : true                : 706   : 30128 : 8989        : 0          : false

Une fois que l'on a ajouté le nouveau serveur, il faut éventuellement paramétrer les éléments propres à l'instance (par exemple les index) qui sont positionnés via l'utilitaire dsconfig.

Adaptations et différences

On peut trouver quelques différences entre OpenDJ 3.5 et DS 6.5. A première vue, on peut citer :

les options des commandes dsconfig ou dsreplication
les fichiers de définition du schéma qui ont migré de DJ_HOME/config/schema à DS_HOME/db/schema

Synthèse

Nous avons vu que deux possibilités sont offertes pour faire un upgrade, de manière assez simple.

L'upgrade "en place" est intéressant pour récupérer toute la configuration spécifique de l'instance (paramètres positionnés par l'utilitaire dsconfig et qui ne sont pas répliqués). Dans ce cas, on garde le même serveur, et donc la même version d'O.S., de java, et d'adresse IP.

Cependant, ceci nécessite d'arrêter l'une des instances de la topologie de réplication.

L'ajout d'une nouvelle instance peut se justifier si on veut changer de version d'O.S. et/ou limiter au maximum les interruptions de service. Cela permet aussi d'adapter les scripts aux nouvelles versions d'outils (même si l'environnement de Test est fait pour cela). Par contre, ceci implique de reprendre le paramétrage de la configuration.

Méthode	Avantages	Inconvénients
Upgrade en place	Pas de changement d'adresse IP Récupération de la configuration	Arrêt de l'instance
Ajout d'une nouvelle instance	Possibilité de monter de version d'O.S. Pas d'arrêt de serveur Possibilité de tester les outils	Nouveau serveur à provisionner Nouvelle adresse IP à gérer Pas de récupération du paramétrage spécifique

vincentl ven 14/12/2018 - 22:06

Catégorie

IAM

Tag

forgerock

opendj

Migration Sun DSEE vers un autre annuaire LDAP

vincentl — Sun, 29 Jul 2018 09:47:52 +0000

Migration Sun DSEE vers un autre annuaire LDAP

Suite au rachat (déjà ancien) de Sun par Oracle, l'annuaire LDAP Sun DSEE, devenu Oracle DSEE depuis, arrive en fin de support. Ce produit a eu ses beaux jours en entreprise, à l'époque c'était probablement l'un des meilleurs, capable de gérer des centaines de milliers d'entrées, avec une architecture assez simple.

Depuis, pas mal de concurrents sont arrivés, et les entreprises se lancent vers des migrations d'annuaires LDAP Sun / Oracle DSEE vers d'autres solutions plus récentes, soit sur un modèle Open Source (OpenLDAP généralement) ou propriétaires. La migration d'annuaire LDAP peut se faire assez rapidement.

Les points d'attention sont les éléments non couverts par le standard LDAP, à savoir :

Formalisme du schéma (attributs et classes d'objets)
Réplication
ACI
Privilèges et droits des comptes
Politiques de mots de passe

Les données elles-mêmes peuvent être relativement facilement, avec un export et import LDIF. Selon la méthode utilisée (ldapsearch ou fonction export de l'annuaire), on peut ou non récupérer des attributs opérationnels.

Schéma de données

Sun DSEE permet de gérer des OID alphanumériques, par exemple :

attributeTypes: (sitename-oid NAME 'sitename'  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )

Si on veut être conforme aux RFC - par exemple dans le cas de OpenLDAP - il faut utiliser des OID numériques. La bonne pratique demande aussi d'utiliser sa propre classe d'OID avec une demande auprès de l'IANA. Dans ce cas, l'OID serait, par exemple :

attributeTypes: (1.3.6.1.4.1.31488.2.3.51 NAME 'sitename'  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )

A part cela, la syntaxe elle-même est différente entre Sun DSEE et OpenLDAP. Les objets du schéma OpenLDAD sont préfixés par olc

Exemple Sun DSEE

Les éléments spécifique du schéma (attributs et classes d'objets) sont définis dans le fichier [DIRECTORY_HOME]/config/schema/99-user.ldif, au format suivant :

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
attributeTypes: (sitename-oid NAME 'sitename'  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
objectClasses: (1.3.6.1.4.1.31488.2.4.18 NAME 'ocSite' SUP top STRUCTURAL MUST (cn $ description) MAY ( sitename $ c $ l $ telephonenumber ) X-ORIGIN 'user defined' )

Dans le cas d'une migration vers Forgerock, Ping Directory (et généralement tous les annuaires issus des sources de OpenDS), on peut réutiliser la même définition pour les attributs et classes d'objets.

Exemple avec OpenLDAP

OpenLDAP utilise une syntaxe un peu différente, en dehors des OID numériques. On doit notamment préciser le DN complet pour l'objet du schéma. Par exemple :

dn: cn=myschema,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: myschema
olcattributeTypes: ( 1.3.6.1.4.1.31488.2.3.110 NAME 'sitename' DESC 'Site name'
 EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE)
olcobjectClasses: ( 1.3.6.1.4.1.31488.2.4.18 NAME 'ocSite' SUP top STRUCTURAL
 MUST (cn $ description) MAY ( sitename $ c $ l $ telephonenumber ) )

Différences sur des classes d'objet issues du standard

Suite à une migration à partir de Sun DSEE, je me suis aperçu que Ping Directory & Forgerock définissent également des types différents pour certaines classes d'objet, notamment celles liées aux objets Posix :

objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top STRUCTURAL
  DESC 'Abstraction of an account with POSIX attributes'
  MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
  MAY ( authPassword $ userPassword $ loginShell $ gecos $ description )
  X-ORIGIN 'draft-howard-rfc2307bis' )
objectClasses: ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL
  DESC 'Abstraction of a group of accounts' MUST gidNumber
  MAY ( cn $ authPassword $ userPassword $ memberUid $ description )
  X-ORIGIN 'draft-howard-rfc2307bis' )

Si dans les données, on utilise ce type d'objets, il peut y avoir des modifications à apporter, sachant qu'il est recommandé d'activer les contrôles de cohérence / validité du schéma lors des imports initiaux, pour avoir une meilleur qualité de données.

vincentl dim 29/07/2018 - 11:47

Catégorie

Tag

Création de comptes Administrateurs dans OpenDJ / Ping Directory

vincentl — Wed, 04 Apr 2018 08:08:30 +0000

Création de comptes Administrateurs dans OpenDJ / Ping Directory

Lorsqu'on installe un annuaire LDAP, on crée un compte (souvent "cn=Directory Manager" par défaut) qui a tous les privilèges, qui n'est pas soumis aux ACI, bref, un superAdmin avec tous les privilèges.

Il vaut donc mieux éviter d'utiliser ce compte pour des opérations. On peut toujours utiliser des comptes "utilisateurs", mais dans ce cas, le DN du compte change selon le baseDN.

Si on veut industrialiser le monitoring de l'annuaire, par exemple, il est intéressant d'avoir toujours le même compte, quel que soit l'instance et donc le baseDN.

C'est ici qu'interviennent les Root DNs, qui sont stockés dans la configuration (le cn=config).

Avantage : le DN sera le même sur tous les annuaires
Inconvénient : le cn=config n'étant pas répliqué, il faut répéter la création sur chaque instance

OpenDJ et Ping Directory sont des annuaires "cousins", bâtis sur les sources de OpenDS après le rachat de Sun Microsystems par Oracle. Les deux produits ont divergé au fil du temps, mais les principes restent similaires. Nous allons voir les commandes à lancer sur les 2 produits.

OpenDJ

Avec OpenDJ, il faut ajouter une entrée dans le cn=config, via un fichier LDIF et un ldapmodify :

cat /tmp/monitor.ldif

dn: cn=LDAP Monitoring,cn=Root DNs,cn=config
changetype: add
objectClass: ds-cfg-root-dn-user
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
sn: Monitoring
cn: LDAP Monitoring
givenName: LDAP
ds-privilege-name: config-read
ds-privilege-name: metrics-read
ds-privilege-name: unindexed-search
ds-cfg-alternate-bind-dn: cn=ldapMonitoring
userPassword: Ld@pM0n|T0R1n6

On intègre ensuite les données :

/opt/opendj/bin/ldapmodify -D "cn=Directory Manager" -w secret -f /tmp/monitor.ldif

A ce niveau on peut se connecter avec cn=ldapMonitoring, sans devoir passer le DN complet.

On peut par exemple récupérer les informations du cn=monitor :

ldapsearch -x -h localhost -p 1389 -D cn=ldapMonitoring -w Ld@pM0n|T0R1n6 -b cn=monitor (objectclass=ds-monitor-entry)

Ping Directory

Ping Directory a nettement enrichi l'utilitaire dsconfig, en ajoutant des dizaines d'option par rapport à ses prédécesseurs.

La création d'un compte de type Root DN passe maintenant par l'utilitaire dsconfig, avec l'option create-root-dn-user.

/opt/ping/bin/dsconfig create-root-dn-user --bindDN "cn=Directory Manager" --bindPassword secret --user-name ldapMonitoring \
 --set alternate-bind-dn:cn=ldapMonitoring --set first-name:LDAP --set inherit-default-root-privileges:false --set last-name:Monitoring \
 --set 'password:Ld@pM0n|T0R1n6' --set privilege:config-read --set privilege:metrics-read --set privilege:unindexed-search --no-prompt

Par rapport à OpenDJ, sur lequel tous les utilisateurs authentifiés peuvent accéder aux données de cn=monitor, Ping Directory ne donne pas d'accès par défaut. Il faut donc ajouter une global ACI sur cette entrée :

/opt/ping/bin/dsconfig set-access-control-handler-prop --bindPassword secret \
 --add global-aci:'(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Allow access to the monitor tree by ldapMonitoring"; allow(all) userdn="ldap:///cn=ldapMonitoring,cn=Root DNS,cn=config";)' --no-prompt

vincentl mer 04/04/2018 - 10:08

Catégorie

Tag

OpenDJ : mise en place du suivi des connexions

vincentl — Tue, 19 Dec 2017 09:42:42 +0000

OpenDJ : mise en place du suivi des connexions

Par défaut, il n'est pas possible de déterminer la date de dernière connexion réussie sur un annuaire LDAP (last login time). Seules les erreurs de connexion peuvent être détectées dans les politiques de mots de passe.

Parfois cependant, il est intéressant de connaître la date de dernière connexion, afin de pouvoir supprimer - ou bloquer - des comptes inutilisés depuis plusieurs mois.

Certains annuaire permettent de modifier les politiques de mots de passe pour tracer les connexions réussies, mais ceci a un impact sur les authentifications. En effet, à chaque authentification réussie, l'annuaire doit écrire la date de connexion sur l'objet utilisateur. On passe donc d'une suite d'opérations search and bind à une suite search and bind and mod.

Quel est donc l'impact de ce suivi sur les performances d'un annuaire ? C'est l'objet de ce test, réalisé sur un annuaire LDAP Forgerock Opendj (DS 5.5).

Configuration utilisée

La configuration utilisée est la suivante :

2 vCPU Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
16 Go de RAM

Le jeu de test est constitué d'un fichier LDIF de 481 Mo, comprenant 220 000 entrées utilisateur.

Parmi ces 220 000 entrées, 50 000 sont situées dans une OU (organizational unit) spécifique : ou=People,ou=FR,o=example.

Politique de mots de passe par défaut

La politique de mot de passe par défaut est utilisée, avec le chargement des entrées.

Property                                  : Value(s)
------------------------------------------:------------------------------------
account-status-notification-handler       : -
allow-expired-password-changes            : false
allow-multiple-password-values            : false
allow-pre-encoded-passwords               : false
allow-user-password-changes               : true
default-password-storage-scheme           : Salted SHA-512
deprecated-password-storage-scheme        : -
expire-passwords-without-warning          : false
force-change-on-add                       : false
force-change-on-reset                     : false
grace-login-count                         : 0
idle-lockout-interval                     : 0 s
java-class                                : org.opends.server.core.PasswordPolicyFactory
last-login-time-attribute                 : -
last-login-time-format                    : -
lockout-duration                          : 0 s
lockout-failure-count                     : 0
lockout-failure-expiration-interval       : 0 s
max-password-age                          : 25 w 5 d
max-password-reset-age                    : 0 s
min-password-age                          : 0 s
password-attribute                        : userPassword
password-change-requires-current-password : false
password-expiration-warning-interval      : 5 d
password-generator                        : Random Password Generator
password-history-count                    : 5
password-history-duration                 : 0 s
password-validator                        : Length-Based Password Validator
previous-last-login-time-format           : -
require-change-by-time                    : -
require-secure-authentication             : false
require-secure-password-changes           : false
skip-validation-for-administrators        : false
state-update-failure-policy               : reactive

Outils de benchmark

Les tests sont lancés avec les utilitaires authrate et searchrate, qui sont intégrés aux binaires de l'annuaire.

Pour la recherche :

/opt/opendj/bin/searchrate -h 10.150.29.161 -p 1389 -D 'uid=user.1,ou=people,ou=fr,o=example' -w password -F -c 10 -b o=example -m 300000 -g 'rand(100,49000)' '(uid=user.%d)'

Pour les authentifications, en mode search + bind :

/opt/opendj/bin/authrate -h 10.150.29.161 -p 1389 -D '%2$s' -w password -f -c 10 -b ou=people,ou=fr,o=example -s sub -m 300000 -g 'rand(100,49000)' '(uid=user.%d)'

Procédure de tests

La procédure de tests est la suivante :

démarrage de l'annuaire
lancement d'un premier test de type searchrate, qui permet de cacher les entrées en RAM
lancement d'un test d'authentification avec authrate en mode search + bind

Mesures sans suivi de la date de dernière connexion

Avec le paramétrage par défaut, on obtient un débit moyen de 4283 authentifications par seconde, avec un temps de réponse moyen de 2.131 millisecondes.

------------------------------------------------------------------------------
     Throughput                            Response Time                      
   (ops/second)                           (milliseconds)                      
recent  average  recent  average  99.9%  99.99%  99.999%  err/sec  bind time %
------------------------------------------------------------------------------
3901.6   3907.1   2.573    2.573  25.304  162.729  167.620      0.0         44.4
4186.4   4047.8   2.372    2.469  26.546  166.949  195.819      0.0         46.6
4540.4   4212.9   2.183    2.365  23.388  166.223  195.819      0.0         44.2
4624.0   4315.7   2.147    2.307  22.435  162.729  195.819      0.0         42.6
4609.7   4374.6   2.156    2.275  22.083  160.540  172.100      0.0         43.0
4663.1   4422.7   2.130    2.250  21.634  158.399  172.100      0.0         42.5
4765.9   4471.7   2.088    2.225  21.431  154.617  172.100      0.0         42.8
4764.9   4508.4   2.089    2.207  20.982  141.395  172.100      0.0         42.0
4864.1   4547.9   2.050    2.188  21.024  39.778  169.393      0.0         42.2
4811.6   4574.2   2.077    2.177  20.934  34.832  169.393      0.0         42.0
4777.0   4592.6   2.091    2.169  20.525  32.932  169.393      0.0         41.8
4825.5   4611.9   2.072    2.160  20.090  32.724  169.393      0.0         41.9
4101.4   4572.6   1.898    2.142  19.807  32.213  169.393      0.0         41.7
 530.8   4283.0   0.869    2.131  19.703  32.118  167.620      0.0         41.0

La CPU est utilisée à 90 % environ sur le serveur cible (qui dispose de 2 vCPU).

Mise en place du suivi du last login time

Création d'un attribut spécifique

La mise en place du suivi demande tout d'abord de créer un attribut qui sera utilisé pour stocker la date de dernière connexion. La documentation donne justement un exemple de politique de mots de passe qui met en oeuvre le suivi.

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( lastLoginTime-oid
  NAME 'lastLoginTime'
  DESC 'Last time the user logged in'
  EQUALITY generalizedTimeMatch
  ORDERING generalizedTimeOrderingMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
  SINGLE-VALUE
  NO-USER-MODIFICATION
  USAGE directoryOperation
  X-ORIGIN 'OpenDJ example documentation' )

On ajoute l'attribut au schéma via la commande ldapmodify :

ldapmodify \
--hostname localhost \
--port 1389 \
--bindDN "cn=Directory Manager" \
--bindPassword password \
lastLoginTime.ldif

Création d'une politique de mots de passe spécifique

Si on veut cibler certains comptes utilisateurs, on peut créer une politique de mots de passe spécifiquement pour cet usage :

/opt/opendj/bin/dsconfig \
create-password-policy \
--hostname localhost --port 4444 \
--bindDN "cn=Directory Manager" \
--bindPassword password \
--policy-name "Track Last Login Time" \
--type password-policy \
--set default-password-storage-scheme:"Salted SHA-512" \
--set password-attribute:userPassword \
--set last-login-time-attribute:lastLoginTime \
--set last-login-time-format:"yyyyMMddHH'Z'" \
--trustAll \
--no-prompt

Modification de la politique de mots de passe

On peut créer une nouvelle politique de mots de passe, ou modifier la politique existante. Dans ce cas, la commande à utiliser est la suivante :

/opt/opendj/bin/dsconfig set-password-policy-prop \
   --policy-name Default\ Password\ Policy \
   --set last-login-time-attribute:lastLoginTime \
   --set last-login-time-format:"yyyyMMddHH'Z'" \
   --hostname localhost \
   --port 4444 \
   --bindDn cn=Directory\ Manager \
   --bindPassword password \
   --trustAll \
   --no-prompt

Test sur une entrée

Si on fait une requête avec un utilisateur en se connectant, on peut ensuite récupérer la date de dernière connexion sur son entrée, à condition de disposer des droits adéquats.

Par exemple :

ldapsearch  -x -h localhost -p 1389 -D 'cn=Directory Manager' -w password -b o=example '(uid=user.2)' lastLoginTime
dn: uid=user.2,ou=People,ou=FR,o=example
lastLoginTime: 2017121909Z

On constate que la date est bien au format déclaré, c'est à dire comprenant l'année, le mois, le jour et l'heure. En effet, il n'est pas nécessaire de suivre les connexions à la minute près.

Mesures AVEC suivi de la date de dernière connexion

Avec le nouveau paramétrage, incluant la mise à jour de la dernière date de connexion, on obtient un débit maximum de 2860 authentifications par seconde en moyenne, avec un temps de réponse moyen de 3.382 millisecondes.

La charge CPU sur le serveur d'annuaire oscille entre 50 et 95%, avec des I/O wait.

On a bien un impact assez fort, avec notamment des phases pendant laquelle l'annuaire est en I/O wait, révélateur des mises à jour effectuées sur les entrées.

------------------------------------------------------------------------------
     Throughput                            Response Time                      
   (ops/second)                           (milliseconds)                      
recent  average  recent  average  99.9%  99.99%  99.999%  err/sec  bind time %
------------------------------------------------------------------------------
1570.3   1573.1   6.421    6.421  152.833  177.026  177.026      0.0         63.6
2308.4   1942.2   4.325    5.170  53.701  176.974  177.026      0.0         57.0
2479.4   2122.0   4.023    4.722  49.889  165.267  177.026      0.0         53.3
1025.2   1847.4   3.712    4.581  48.670  165.267  177.026      0.0         51.6
   0.0   1477.0       -    4.581  48.670  165.267  177.026      0.0          NaN
1013.4   1399.8  25.871    7.149  50.589  11195.648  11204.023      0.0         93.5
2996.8   1627.5   3.332    6.147  46.142  11193.992  11204.023      0.0         49.8
3301.1   1836.1   3.028    5.447  44.262  11187.622  11204.023      0.0         48.4
3329.9   2001.8   2.737    4.948  41.735  11165.580  11204.023      0.0         47.0
   0.0   1800.9       -    4.948  41.735  11165.580  11204.023      0.0          NaN
  92.4   1645.4  226.166    6.078  43.042  11156.315  11204.023      0.0         99.2
4024.9   1843.1   2.485    5.426  39.488  10339.090  11203.705      0.0         45.4
4193.7   2023.6   2.382    4.942  38.478  10328.566  11203.705      0.0         44.3
4487.2   2199.3   2.227    4.547  36.814  10316.059  11203.705      0.0         43.1
4496.0   2352.3   2.222    4.251  35.540  10313.618  11203.705      0.0         43.3
4530.5   2488.3   2.207    4.018  34.530  10213.330  11203.705      0.0         43.0
4535.5   2608.8   2.204    3.833  33.649  168.792  11202.112      0.0         43.3
4479.8   2712.7   2.230    3.686  33.112  163.941  11202.112      0.0         42.7
4722.0   2818.5   2.116    3.547  32.285  160.038  11202.112      0.0         42.6
4710.9   2913.1   2.108    3.431  31.666  79.285  11202.112      0.0         42.5
1816.5   2860.5   1.834    3.382  31.418  75.221  11195.866      0.0         42.9

Note : ceci est cependant à modérer, puisque notre première campagne de tir va déclencher une écriture pour chaque utilisateur qui s'authentifie. Si on relance un deuxième tir dans l'heure (qui est l'unité minimale de suivi de la date de connexion), on retrouve des résultats quasiment identiques au premier cas : un débit de 4291 authentifications par seconde, et un temps de réponse de 2.195 ms. Si on regarde la charge sur le serveur d'annuaire, on ne constate plus d'écritures sur disque.

------------------------------------------------------------------------------
     Throughput                            Response Time                      
   (ops/second)                           (milliseconds)                      
recent  average  recent  average  99.9%  99.99%  99.999%  err/sec  bind time %
------------------------------------------------------------------------------
3988.3   3994.8   2.514    2.514  23.066  163.522  167.640      0.0         42.6
.../...
4628.0   4525.7   2.159    2.206  18.978  28.433  158.819      0.0         42.9
4327.2   4510.4   2.219    2.207  19.051  28.221  158.819      0.0         43.0
1450.9   4291.0   1.721    2.195  18.968  28.071  158.406      0.0         42.1

Conclusion

Si l'impact du suivi de la date de dernière connexion n'est pas anodin, surtout dans le cas d'un test, en situation réelle, l'impact peut être relativement négligeable, notamment si les authentifications se font au fil de l'eau.

vincentl mar 19/12/2017 - 10:42

Catégorie

Tag

OpenIDM : purge des tables audit

vincentl — Wed, 14 Dec 2016 08:31:54 +0000

OpenIDM : purge des tables audit

Contexte

Dans un environnement client OpenIDM 3.1 en production depuis plusieurs mois, l'accès à l'écran d'administration des mappings met de plus en plus longtemps à s'afficher.

English Summary

It may help : if the access time to mapping administration form in OpenIDM becomes very slow, then check the numbers of lines in auditrecon table, and delete old records.

Analyse du problème

En regardant les échanges avec le serveur (via la console du navigateur), on voit que l'URL "endpoint/mappingDetails" est celle qui prend le plus de temps.
Ce endpoint appelle un script Javascript, ./bin/defaults/script/ui/mappingDetails.js, qui lance une requête SQL permettant de récupérer la date de dernière réconciliation, et ce pour chaque mapping :

  lastRecon = openidm.query("audit/recon", {
    "_queryId": "audit-last-recon-for-mapping",
    "mapping": m.name,
    "formatted": false
  });

En regardant dans le fichier conf/repo.jdbc.json, on peut récupérer le détail de la requête :

audit-last-recon-for-mapping" : "SELECT * FROM ${_dbSchema}.auditrecon WHERE entryType = 'start' 
AND mapping = ${mapping} and reconaction <> 'reconById' ORDER BY activitydate DESC LIMIT 1"

C'est cette requête qui pose problème, notamment car la table auditrecon n'a jamais été purgée.

Si on regarde le nombre de lignes par type de mapping, on peut avoir une idée de la volumétrie :

select mapping, count(1) from auditrecon group by mapping ;
+-------------------------------------+----------+
| mapping                             | count(1) |
+-------------------------------------+----------+
| AdOrganizationalUnit_Officelocation |     3956 |
| ldapFunctionnal_Orga                |   482874 |
+-------------------------------------+----------+
2 rows in set (3.36 sec)

On peut alors tester la requête lancée par le script mappingDetails.js :

SELECT * FROM auditrecon WHERE entryType = 'start' AND mapping = 'ldapFunctionnal_Orga' and reconaction <> 'reconById' ORDER BY activitydate DESC LIMIT 1 ;

Le nombre élevé s'explique car il s'agit d'une réconciliation lancée à intervalle régulier (toutes les 15 minutes), pour récupérer des objets de type 'organisation' : départements, fonctions, sections.
De ce fait, on arrive rapidement à un nombre élevé de lignes, sachant que chaque réconciliation traite près de 500 lignes, soit 4*24*500 = 48 000 lignes par jour !

On peut tenter d'en savoir un peu plus sur la volumétrie. Pour avoir la taille des tables :

SELECT table_name, table_rows as 'Rows #', data_length /1024 as 'Data size KB', index_length/1024 as 'Index size KB' , 
  round( (data_length + index_length) / 1024 / 1024,2 ) as 'Taille MB' 
  FROM information_schema.tables WHERE table_schema = 'openidm' AND table_name like 'audit%';

+---------------+--------+--------------+---------------+-----------+
| table_name    | Rows # | Data size KB | Index size KB | Taille MB |
+---------------+--------+--------------+---------------+-----------+
| auditaccess   |   6153 |    2080.0000 |     2144.0000 |      4.13 |
| auditactivity |    843 |   22544.0000 |     1056.0000 |     23.05 |
| auditrecon    | 449959 |  541952.0000 |   592448.0000 |   1107.81 |
| auditsync     |    797 |    7696.0000 |        0.0000 |      7.52 |
+---------------+--------+--------------+---------------+-----------+
4 rows in set (0.15 sec)

Note : s'agissant de tables utilisant le moteur InnoDB, le nombre de lignes donnés par cette requête peut varier. Il vaut mieux utiliser un SELECT COUNT pour avoir le nombre réel de lignes. La volumétrie en KB, par contre, semble stable.

Epuration des tables d'audit

Il existe une tâche programmée qui permet de lancer un nettoyage régulier des tables d'audit. Sur une installation OpenIDM 3.1, le fichier de définition se trouve dans samples/schedules/schedule-autoPurgeAuditRecon.json :

{
    "enabled" : false,
    "type" : "cron",
    "schedule" : "0 0 */12 * * ?",
    "persisted" : true,
    "misfirePolicy" : "doNothing",
    "invokeService" : "script",
    "invokeContext" : {
        "script" : {
            "type" : "text/javascript",
            "file" : "audit/autoPurgeAuditRecon.js",
            "input" : {
                "mappings" : [ "%" ],
                "purgeType" : "purgeByNumOfReconsToKeep",
                "numOfRecons" : 1,
                "intervalUnit" : "minutes",
                "intervalValue" : 1
            }
        }
    }
}

Dans la configuration par défaut, on limite à un nombre fini de réconciliations. Si on veut garder un nombre de jours limité, il faut modifier la définition pour utiliser le type de purge purgeByExpired :

{
    "enabled" : true,
    "type" : "cron",
    "schedule" : "0 0 22 * * ?",
    "persisted" : true,
    "misfirePolicy" : "doNothing",
    "invokeService" : "script",
    "invokeContext" : {
        "script" : {
            "type" : "text/javascript",
            "file" : "audit/autoPurgeAuditRecon.js",
            "input" : {
                "mappings" : [
                    "%"
                ],
                "purgeType" : "purgeByExpired",
                "numOfRecons" : 1,
                "intervalUnit" : "days",
                "intervalValue" : 30
            }
        }
    }
}

Le souci étant dans ce cas que, puisqu'on n'a jamais lancé de purge, la requête tombe en time-out...

Dans ce cas, On peut aussi utiliser une méthode plus radicale, consistant à supprimer les lignes dans la table, de la manière suivante :

DELETE FROM auditaccess WHERE activitydate < 'YYYY-MM-DD' ;

On peut générer les instructions avec un script shell, qui va calculer la date (ce qui est plus rapide que d'utiliser les fonctions MySQL) :

#!/bin/bash
# -----------------------------
# Purge OpenIDM audit database
# -----------------------------
#
# Please stop openidm first, and there remove felix-cache content before restarting
#-----------------------------------------------------------------------------------

# Set data retention period here 
LongTimeAgo=$(date -d 'now -6 months' +'%Y-%m-%d')

echo "DELETE FROM auditaccess WHERE activitydate < '$LongTimeAgo' ;" > /tmp/purge.sql
echo "DELETE FROM auditactivity WHERE activitydate < '$LongTimeAgo' ;" >> /tmp/purge.sql
echo "DELETE FROM auditrecon WHERE activitydate < '$LongTimeAgo' ;" >> /tmp/purge.sql
echo "DELETE FROM auditsync WHERE activitydate < '$LongTimeAgo' ;" >> /tmp/purge.sql

# Ou utiliser la commande mysql en ligne 

echo "SELECT table_name, data_length /1024 AS 'Data size KB',  index_length/1024 AS 'Index size KB' , round( (data_length + index_length) / 1024 / 1024,2 ) AS 'Taille MB' FROM information_schema.tables WHERE table_schema = 'openidm' and table_name like 'audit%'; " >> /tmp/purge.sql

echo "exit" >> /tmp/purge.sql

SQLUSER=openidm
SQLPWD=openidm
SQLDB=openidm
DBHOST=db.mydomain.com
DBPORT=3306

mysql -h ${DBHOST} -P ${DBPORT} -u ${SQLUSER} -p${SQLPWD} ${SQLDB} < /tmp/purge.sql

#
# --- End of script
#

Il ne reste plus qu'à lancer le script shell, de manière réguliere (une fois par semaine par exemple), pour limiter le nombre de lignes dans la table, et retrouver un temps de réponse correct lorsqu'on passe par l'écran de gestion des mappings

En conclusion

Si l'accès à la page Mappings de la console d'administration OpenIDM est de plus en plus long, vérifier le nombre de lignes dans la table auditrecon, et lancer régulièrement une purge de cette table, soit via le schedule-autoPurgeAuditRecon, soit directement en SQL.

vincentl mer 14/12/2016 - 09:31

Catégorie

Tag