itds

IBM Directory Server : gestion des mots de passe

vincentl — Mon, 13 Apr 2020 15:42:22 +0000

IBM Directory Server : gestion des mots de passe

L'installation par défaut de l'annuaire ISDS ne semble pas "terminée" en ce qui concerne la gestion des mots de passe : pas de politique de mot de passe par défaut, pas d'activation non plus. Et une modification par ldapmodify stocke le mot de passe en clair (tout au moins, il ressort en clair dans un ldapsearch).

Autoriser le changement de mot de passe par l'utilisateur

Par défaut, l'utilisateur ne peut pas modifier lui-même son mot de passe. Par exemple, en utilisant la commande ldapchangepwd renvoie une erreur :

/opt/ibm/ldap/V6.3/bin/ldapchangepwd -D uid=jdoe,ou=people,o=example.com -w secret -n SuperSecret
ldap_simple_bind:  Error, Password must be changed after reset
changing password for entry uid=jdoe,ou=people,o=example.com
Insufficient access --- Error, Password may not be modified

Pour résoudre ce problème, il faut :

ajouter une ACL permettant le changement de mot de passe en mode "Self"
permettre le changement de mot de passe par l'utilisateur lui-même dans la politique de mot de passe (qu'il faut créer)

Ajout d'une politique de mot de passe par défaut

On va créer un fichier LDIF qui contient la définition de la politique globale :

dn: cn=pwdpolicy,cn=ibmpolicies
objectclass: container
objectclass: pwdPolicy
objectclass: ibm-pwdPolicyExt
objectclass: ibm-pwdGroupAndIndividualPolicies
objectclass: top
cn: pwdPolicy
pwdAttribute: userPassword
pwdGraceLoginLimit: 0
pwdLockoutDuration: 0
pwdFailureCountInterval: 0
passwordMaxRepeatedChars: 0
passwordMaxConsecutiveRepeatedChars: 0
pwdMaxAge: 0
pwdMinAge: 0
pwdExpireWarning: 0
passwordMinAlphaChars: 0
passwordMinOtherChars: 0
passwordMinDiffChars: 0
pwdLockout: false
pwdAllowUserChange: true
pwdMustChange: true
pwdSafeModify: false
ibm-pwdGroupAndIndividualEnabled: false
ibm-pwdPolicy: true
pwdCheckSyntax: 1
pwdInHistory: 5
pwdMaxFailure: 3
pwdMinLength: 6

Le fichier sera ensuite ajouté à l'annuaire via ldapadd avec un compte administrateur.

Ajout d'une ACL permettant le changement

On va également ajouter une ACL sur l'arborescence qui contient les comptes

dn: ou=people,o=example.com
changetype: modify
add: aclentry
aclentry: access-id:CN=THIS:at.userPassword:rwsc:normal:rsc

Et on l'ajoute avec un ldapmodify

Suite à cela, la modification du mot de passe fonctionne correctement, par l'utilisateur lui-même.

/opt/ibm/ldap/V6.3/bin/ldapchangepwd -D uid=jdoe,ou=people,o=example.com -w secret -n SuperSecret
changing password for entry uid=jdoe,ou=people,o=example.com

Par contre, si on récupère avec un ldapsearch, la valeur est renvoyée en clair...

/opt/ibm/ldap/V6.3/bin/ldapsearch -D uid=jdoe,ou=people,o=example.com -w SuperSecret -b o=example.com uid=jdoe userpassword
uid=jdoe,ou=people,o=example.com
userpassword=SuperSecret

Modifier l'algorithme d'encryption

Par défaut, les mots de passe sont chiffrées avec l'algorithme AES256, qui est symétrique. Du coup, le mot de passe est décodé par le moteur de l'annuaire avant d'être affiché.

Il vaut mieux donc utiliser un algorithme asymétrique type SSHA ou SHA2-x.

dn: cn=configuration
changetype: modify
replace: ibm-slapdPwEncryption
ibm-slapdPwEncryption: ssha

Si on redémarre l'annuaire (ou si on utilise la commande idsldapexop), on voit que le mot de passe est alors stocké de manière irréversible.

/opt/ibm/ldap/V6.3/bin/ldapchangepwd -D uid=jdoe,ou=people,o=example.com -w SuperSecret-n Pa55word
changing password for entry uid=jdoe,ou=people,o=example.com

/opt/ibm/ldap/V6.3/bin/ldapsearch -D uid=jdoe,ou=people,o=example.com -w SuperSecret -b o=example.com uid=jdoe userpassword uid=jdoe,ou=people,o=example.com
userpassword={SSHA}4EqpfNQFq1aWqT+ouD5bEKFPyrIiFSd7AEQORENiet0xYiqgJLi73Q==

Import de mots de passe hachés

Si on migre les données d'un autre annuaire, via un fichier LDIF par exempe, avec un mot de passe chiffré dans un autre algorithme, ITDS utilise alors cet algorithme, et pas celui défini par défaut.

Attention, si on a activé l'option pwdMustChange, dans la politique de mot de passe, l'utilisateur sera obligé de modifier son mot de passe à la première connexion.

Ce paramètre est dynamique, on peut donc le repasser à False si nécessaire.

vincentl lun 13/04/2020 - 17:42

Catégorie

IAM

Tag

itds

ibm

ldap

Ajouter un commentaire

ITDS : modifier le schéma en live

vincentl — Wed, 20 Jan 2016 15:18:44 +0000

ITDS : modifier le schéma en live

Par défaut, le schéma de données de ITDS (IBM Tivoli Directory Server) est chargé au démarrage, à partir du fichier V3.modifiedschema, présent dans le répertoire /etc de l'instance d'annuaire.

Par exemple, pour une instance nommé idsldap, le fichier sera dans le répertoire /product/ldap/idsslapd-idsldap/etc.

Si on veut ajouter un attribut ou une classe d'objet à notre schéma, il est évidemment possible d'arrêter le serveur, modifier le fichier V3.modifiedschema, puis redémarrer ITDS.

Mais on peut aussi vouloir faire une mise à jour sans arrêter le service, en passant par la commande ldapmodify et un fichier ldif.

Par exemple, si on veut ajouter un attribut "customPostLink' et une classe d'objet 'customBlogPost', on pourra utiliser un fichier ldif customBlog.ldif :

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: (
  1.3.6.1.4.1.16832.123.7.10
  NAME 'customPostLink'
  DESC 'Link to blog post'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  USAGE userApplications
  )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: (
  1.3.6.1.4.1.16832.123.8.10
  NAME 'customBlogPost'
  DESC 'A custom Blog post'
  SUP top
  STRUCTURAL
  MUST ( title $ description $ uid )
  MAY ( customPostLink)
  )

Puis pour modifier le schéma, utiliser ldapmodify :

/opt/ibm/ldap/V6.2/bin/ldapmodify -D cn=root -w secret -f customBlog.ldif

On peut ensuite vérifier que la modification est bien prise en compte :

grep custom V3.modifiedschema
( 1.3.6.1.4.1.16832.123.8.10 NAME 'customBlogPost' DESC 'A custom Blog post' SUP top STRUCTURAL MUST ( description $ title $ uid ) MAY customPostLink )
( 1.3.6.1.4.1.16832.123.7.10 NAME 'customPostLink' DESC 'Link to blog post' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

On peut de la même manière modifier la définition d'un attribut ou d'une classe d'objet. Mais dans ce cas, il convient de s'assurer que les modifications n'ont pas d'impact sur les objets déjà existants.

vincentl mer 20/01/2016 - 16:18

Catégorie

Tag

[ITDS] Modification de la longueur d'un attribut

vincentl — Fri, 13 Dec 2013 15:05:01 +0000

[ITDS] Modification de la longueur d'un attribut

Modification de la longueur d'un attribut ITDS

Lors du lancement d'un traitement sur un annuaire IBM Tivoli Directory Server (ITDS), on remarque ceci dans les logs (ibmslapd.log) :

07/11/2013 03:26:23 PM GLPRDB069E Attribute IIRUSERATTRIB8 has a maximum value length of 240. Current attribute value is of length 242.

Voyons ce que dit le schéma de l'annuaire :

cd /product/ldap/idsslapd-idsldap/etc

grep -i IIRUSERATTRIB8 CustomSchema.at

( 1.3.6.1.4.1.16832.123.2.108 NAME 'iirUserAttrib8' DESC 'User Attribute 8' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

La déclaration de l'attribut pour DB2 (DBNAME) ne comprend pas de longueur explicite => c'est la longueur par défaut = 240 caractères.

On peut le vérifier en accédant à la base de données :

idsldap > db2 connect to idsldap

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.0
 SQL authorization ID   = IDSLDAP
 Local database alias   = IDSLDAP

idsldap > db2 describe table IIRUSERATTRIB8

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
EID                             SYSIBM    INTEGER                      4     0 No    
IIRUSERATTRIB8                  SYSIBM    VARCHAR                    240     0 No    
RIIRUSERATTRIB8                 SYSIBM    VARCHAR                    240     0 Yes   

  3 record(s) selected.

Modification de la longueur

Le changement de longueur sur un attribut ITDS DOIT se faire via un fichier LDIF et une commande idsldapmodify, ou via l'interface d'administration de l'annuaire.
Par exemple, voici le contenu du fichier ChangeLength.ldif :

dn: cn=schema
changetype: modify
replace: attributetypes
attributetypes: ( 1.3.6.1.4.1.16832.123.2.108 NAME 'iirUserAttrib8' DESC 'User Attribute 8' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
-
replace: ibmattributetypes
ibmattributetypes: ( 1.3.6.1.4.1.16832.123.2.108 DBNAME ('iirUserAttrib8' 'iirUserAttrib8') LENGTH 384 SUBSTR )

On modifie le schéma avec la commande :

idsldapmodify -D cn=root -w MotDePasse -f ChangeLength.ldif
Operation 0 modifying entry cn=schema

On peut vérifier que le changement de longueur a bien été pris en compte dans les fichiers de configuration ITDS :

grep -i iiruserattrib8 /product/ldap/idsslapd-idsldap/etc/*

/product/ldap/idsslapd-idsldap/etc/CustomSchema.at:( 1.3.6.1.4.1.16832.123.2.108 NAME 'iirUserAttrib8' DESC 'User Attribute 8' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
/product/ldap/idsslapd-idsldap/etc/CustomSchema.at:( 1.3.6.1.4.1.16832.123.2.108 DBNAME ( 'iirUserAttrib8' 'iirUserAttrib8' ) LENGTH 384 SUBSTR )

Et le contenu de la base de données :

idsldap > db2 describe table IIRUSERATTRIB8
 db2 describe table IIRUSERATTRIB8

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
EID                             SYSIBM    INTEGER                      4     0 No    
IIRUSERATTRIB8                  SYSIBM    VARCHAR                    384     0 No    
IIRUSERATTRIB8_T                SYSIBM    VARCHAR                    240     0 No    
RIIRUSERATTRIB8_T               SYSIBM    VARCHAR                    240     0 No    

  4 record(s) selected.

La longueur de la colonne a bien été augmentée à 384 caractères.

DB2 ajoute des colonnes *_T qui sont utilisées pour la recherche et l'indexation.

La colonne R[attribute_name]_T est la chaîne de caractère renversée et tronquée à 240, pour les filtres de recherche qui sont de la forme "attribut=*valeur".

Références IBM

vincentl ven 13/12/2013 - 16:05

Catégorie

IAM

Tag

itds

Plantage ITDS sur certaines transactions ITIM

vincentl — Wed, 27 Mar 2013 14:57:46 +0000

Plantage ITDS sur certaines transactions ITIM

Gros problème ces temps-ci, alors qu'on voulait démarrer en production : lors de certaines opérations dans ITIM, l'annuaire ITDS crash sans message dans ses logs. J'avais déjà remarqué des soucis relativement similaires sur notre plate-forme de développement, que j'avais mis sur le compte de mises à jour nombreuses et pas forcément très carrées...

Lorsque l'annuaire s'arrête, on n'a aucun message dans son fichier ibmslapd.log. Par contre, on constate dans le fichier /var/log/messages :

Mar 27 13:59:59 lnxfr99720434 kernel: ibmslapd[1999]: segfault at 0000000000000040 rip 00002b568d7e08ec rsp 00000000434342c0 error 4

Ceci n'arrive que pour certains recherches. Par exemple la recherche d'utilisateurs sur leur code XX* donne bien la liste des utilisateurs donc le matricule commence par XX. La même recherche sur * fait crasher l'annuaire.

L'audit a été mis en place sur ITDS, mais aucune erreur n'est remontée. On voit passer la requête incriminée, sans autre détail.

Diagnostic du problème

Après quelques recherche sur le web, je suis tombé sur un article qui m'a mis sur la piste. Référence : http://www-01.ibm.com/support/docview.wss?uid=swg21499819

Il donne notamment des pistes pour diagnostiquer le problème.

Lancement de ITDS en mode console

On lance ITDS en mode console, ce qui permettra peut-être d'avoir plus d'informations lors du crash :

/opt/ibm/ldap/V6.2/sbin/ibmslapd -I idsldap -c
...
GLPSRV048I Started 15 worker threads to handle client requests.
/opt/ibm/ldap/V6.2/sbin/ibmslapd[1101]: eval: line 1: 22892: Memory fault

Effectivement, lorsque ITDS s'arrête brutalement on a une indication supplémentaire : il s'agit d'un problème mémoire.

Vérification de la mémoire et de l'environnement

cat /proc/meminfo 
MemTotal:     24659144 kB
MemFree:       8321348 kB

Il reste 8 Go de RAM libre. Donc pas de souci côté O.S.

$ idsilist -a
Directory server instances:

--------------------------------------
Instance 1:

Name: idsldap
Version: 6.2
Location: /product/ldap
Description: IBM Tivoli Directory Server Instance V6.2
IP Addresses: All available
Port: 389
Secure Port: 636
Admin Server Port: 3538
Admin Server Secure Port: 3539
Type: Directory Server

Une seule instance LDAP, en version 6.2.

Génération d'un core Dump

Nous allons tenter de générer un core dump, pour analyser le problème. Les variables d'environnement sont positionnées pour générer le fichier de dump, et on effectue la transaction ITIM qui pose problème :

ulimit -c unlimited
ulimit -Sc unlimited
/opt/ibm/ldap/V6.2/sbin/ibmslapd -I idsldap -c
.../...
GLPCOM003I Non-SSL port initialized to 389.
GLPRPL137I Restricted Access to the replication topology is set to false.
GLPSRV098I Directory server audit logging started.
GLPSRV009I 6.2.0.3	server started.
GLPRPL136I Replication conflict resolution mode is set to true.
GLPSRV048I Started 15 worker threads to handle client requests.
/opt/ibm/ldap/V6.2/sbin/ibmslapd[1101]: eval: line 1: 25475: Memory fault(coredump)

Core dump generated : /product/ldap/idsslapd-idsldap/workdir/core.1856

Le problème a bien généré un fichier, que l'on va pouvoir analyser.

Analyse du core dump

L'analyse nécessite l'installation de gdb. Sur notre plate-forme CentOS / RedHat, ceci se fait par un

# yum install gdb

L'analyse du fichier dump se fait via la commande :

# cd /product/ldap/idsslapd-idsldap/workdir 
# gdb /opt/ibm/ldap/V6.2/sbin/64/ibmslapd core.1856 
Core was generated by `/opt/ibm/ldap/V6.2/sbin/64/ibmslapd -I idsldap -c'. Program terminated with signal 11, Segmentation fault. #0 0x00002b568d7e08ec in attr_cache_complete_complex_filter_resolution(vec_base**, vec_base**, int, filter*) () from /opt/ibm/ldap/V6.2/lib64/libback-rdbm.so

Le problème est donc lié à la librairie du back-end DB2, dans une fonction qui semble liée à un cache d'attributs...

Détermination de la cause

Les problèmes sont survenus suite à une séance d'optimisation des performances. En suivant les indications du document de tuning IBM, certains paramètres ITDS ont été modifiés.

Dans le fichier de configuration de l'instance LDAP ibmslapd.conf, le cache d'attribut était positionné en Auto Adjust, suite aux optimisations réalisées sur la plate-forme, via les scripts ITIM :

ibm-slapdCachedAttributeAutoAdjust: TRUE
ibm-slapdCachedAttributeSize: 262144

En modifiant l'auto-ajustement à FALSE, on résout le problème :

ibm-slapdCachedAttributeAutoAdjust: FALSE
ibm-slapdCachedAttributeSize: 262144

Ce paramétrage était issu du document : IBM - Performance Tuning and Capacity Planning Guide - Tivoli Directory Server - Version 6.3, page 17. Je cite :

For automatic attribute caching for the directory database:

dn: cn=Directory, cn=RDBM Backends, cn=IBM Directory,
cn=Schemas, cn=Configuration
changetype: modify
replace: ibm-SlapdCachedAttributeSize
ibm-SlapdCachedAttributeSize: 262144
-
replace: ibm-slapdCachedAttributeAutoAdjust
ibm-slapdCachedAttributeAutoAdjust: TRUE

Conclusion

L'optimisation des performances est à manier avec précaution... Et même en suivant les recommandations de l'éditeur, il convient de tester par la suite et de noter les changements réalisés.

Ceci est d'autant plus bizarre que les requêtes, passées via un ldapbrowser, se passaient correctement, et que d'autres opérations dans la console ITIM ne renvoyaient pas d'erreur.

vincentl mer 27/03/2013 - 15:57

Catégorie

Tag