|
|
|
Posted
about 1 month
ago
by
Clément OUDOT
|
|
Posted
about 1 month
ago
by
KPTN
Des nouvelles pas très fraîches... En effet, la version 2.0 de LSC est sortie en juillet 2012, il y a plus de 8 mois. Je profite de la sortie la semaine dernière de la version 2.0.2 (deuxième version mineure de la branche 2.0) pour
... [More]
présenter ce projet très bien connu des administrateurs LDAP qui savent installer des logiciels java, donc globalement inconnu...
LSC et toi tu le sais pas ?
Commençons par le début, c'est quoi LSC ? LSC signifie LDAP Synchronization Connector, ce qui devient plus significatif sur son utilité : c'est un moteur de synchronisation LDAP.
LSC permet de synchroniser des fichiers plats (CSV), des bases de données et des annuaires, dans les deux sens. Il s'agit d'une vraie synchronisation avec une phase de comparaison des données sources et des données cibles afin de calculer les modifications à appliquer sur la destination.
LSC permet par exemple de synchroniser une base de données RH avec son annuaire d'entreprise, de synchroniser OpenLDAP et Active Directory (et avec quelques subtilités, en incluant les mots de passe), de générer des mots de passe Samba, d'importer des fichiers CSV dans un annuaire ou encore de pousser des données LDAP dans une bases de données.
LSC ne propose pas d'interface graphique, tout se fait comme au siècle dernier, à la main, mais rassurez-vous il s'agit bien d'une technologie très évoluée !
LSC strikes back
La nouvelle version n'est pas une version 2.0 de complaisance, les évolutions depuis la version 1.2 sont assez significatives. Les plus importantes sont les suivantes :
Modification du format de configuration (fini le fichier de properties java, place au XML)
Support de la synchronisation au fil de l'eau avec un annuaire compatible SyncRepl en source
Script de démarrage et d'arrêt
Nouveaux scripts de supervision avec gestion des données de performances (oh les beaux graphiques)
Bases de données en destination
Support de groovy
La configuration en XML peut sembler un choix discutable, mais elle a le mérite de clarifier le paramétrage du connecteur et de permettre une meilleure séparation des informations de connexion et de la définition des tâches de synchronisation.
De plus, un validateur permet facilement de s'assurer que la configuration est consistante avant de lancer le connecteur.
La documentation en ligne détaille toutes les balises qui peuvent être utilisées.
Test me if you can
Vous n'êtes pas convaincu ? D'avance vaincu ? Allons, le plus simple est de tester. LSC propose un tutoriel très simple permettant de synchroniser un fichier CSV dans un annuaire LDAP OpenDJ.
Et comme vous m'êtes sympathiques, voici ce tutoriel en français.
Première étape, télécharger LSC. Là c'est très simple, il suffit d'aller sur la page de téléchargement. On suppose que vous avez java en version 6 minimale installée sur votre poste ou votre serveur de test.
Installer LSC :
$ unzip lsc-core-2.0*-dist.zip
$ cd lsc-2.0*
Maintenant on se rend dans le dossier du tutoriel :
$ cd sample/hsqldb
Le fichier sample.csv contient les données que nous allons synchroniser dans l'annuaire. Si, si, vous pouvez vérifier.
Ces données doivent être importées dans la base de données interne (HSQLDB) :
$ bin/lsc-sample --import sample.csv
À présent, lancer l'annuaire de démonstration dans une autre console (la commande ne rend pas la main) :
$ bin/lsc-sample --start-ldap-server
Puis lancer la synchronisation depuis la première console :
$ bin/lsc-sample --run
Et voilà, les données sont synchronisées. Si vous ne me croyez pas, ouvrez un navigateur LDAP sur l'annuaire de test, supprimez des données et relancez la synchronisation.
Et pour d'autres tests, vous pouvez également modifier le fichier CSV d'entrée. Dans ce cas il faut penser à le réinsérer dans la base avec :
$ bin/lsc-sample --import sample.csv
Voilà, LSC fini
Vous savez désormais qu'il existe une solution de remplacement pour tous vos scripts maison en Perl, Ruby, ou pire PHP qui synchronisent vos données entre votre annuaire et le reste du monde. Je ne peux que vous inviter à rejoindre la communauté et nous aider à améliorer le produit ou la documentation ! [Less]
|
|
Posted
2 months
ago
by
Clément OUDOT
|
|
Posted
4 months
ago
by
KPTN
Dynamique de groupe Les groupes dynamiques en LDAP sont une fonctionnalité très intéressante, permettant de lister les membres d'un groupe par rapport à un filtre LDAP, ce qui évite de maintenir la liste des membres de manière
... [More]
statique.
Par exemple :
dn: cn=test,ou=groups,dc=example,dc=com
objectClass: groupOfURLs
objectClass: top
cn: test
memberURL: ldap:///ou=users,dc=example,dc=com??one?(description=*test*)
Ce groupe contiendra toutes les entrées de la branche ou=users,dc=example,dc=com possédant test dans l'attribut description.
Au vert lait
Dans OpenLDAP, les groupes dynamiques ne sont pas activés par défaut, il faut pour les utiliser charger l'overlay dynlist. Et pour utiliser la classe d'objet groupOfURLs, il faut également charger un schéma.
Cela peut-être fait simplement dans cn=config avec le LDIF suivant :
dn: cn=dyngroup,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: dyngroup
olcObjectIdentifier: {0}NetscapeRoot 2.16.840.1.113730
olcObjectIdentifier: {1}NetscapeLDAP NetscapeRoot:3
olcObjectIdentifier: {2}NetscapeLDAPattributeType NetscapeLDAP:1
olcObjectIdentifier: {3}NetscapeLDAPobjectClass NetscapeLDAP:2
olcObjectIdentifier: {4}OpenLDAPExp11 1.3.6.1.4.1.4203.666.11
olcObjectIdentifier: {5}DynGroupBase OpenLDAPExp11:8
olcObjectIdentifier: {6}DynGroupAttr DynGroupBase:1
olcObjectIdentifier: {7}DynGroupOC DynGroupBase:2
olcAttributeTypes: {0}( NetscapeLDAPattributeType:198 NAME 'memberURL' DESC 'I
dentifies an URL associated with each member of a group. Any type of labeled
URL can be used.' SUP labeledURI )
olcAttributeTypes: {1}( DynGroupAttr:1 NAME 'dgIdentity' DESC 'Identity to use
when processing the memberURL' SUP distinguishedName SINGLE-VALUE )
olcAttributeTypes: {2}( DynGroupAttr:2 NAME 'dgAuthz' DESC 'Optional authoriza
tion rules that determine who is allowed to assume the dgIdentity' EQUALITY a
uthzMatch SYNTAX 1.3.6.1.4.1.4203.666.2.7 X-ORDERED 'VALUES' )
olcObjectClasses: {0}( NetscapeLDAPobjectClass:33 NAME 'groupOfURLs' SUP top S
TRUCTURAL MUST cn MAY ( memberURL $ businessCategory $ description $ o $ ou $
owner $ seeAlso ) )
olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY
( dgIdentity $ dgAuthz ) )
dn: olcOverlay=dynlist,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: dynlist
olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember
Comme vous êtes des lecteurs avisés, vous aurez noté qu'on peut utiliser d'autres classes d'objet que groupOfURLs, puisque cela dépend de la configuration de l'overlay dynlist (attribut olcDlAttrSet). Pour plus de détails, voir la page de manuel de l'overlay dynlist (man slapo-dynlist).
Tri sélectif
Cet overlay fonctionne bien sur des petits volumes mais les performances s'écroulent dès le le groupe dynamique doit contenir plusieurs milliers d'utilisateurs.
Le secret réside dans l'option sortvals (olcSortVals dans cn=config) qui active le tri des valeurs sur certains attributs. D'après le manuel :
olcSortVals <attr> [...]
Specify a list of multi-valued attributes whose values will always be maintained in sorted order. Using
this option will allow Modify, Compare, and filter evaluations on these attributes to be performed more
efficiently. The resulting sort order depends on the attributes' syntax and matching rules and may not
correspond to lexical order or any other recognizable order. This setting is only allowed in the frontend
entry.
Dans notre cas, nous allons trier les valeurs de l'attribut uniqueMember :
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcSortVals
olcSortVals: uniqueMember
Dès l'application de ce paramètre, l'affichage de groupes dynamiques de plusieurs milliers d'utilisateurs ne prendra que quelques secondes ! [Less]
|
|
Posted
7 months
ago
by
Clément OUDOT
|
|
Posted
7 months
ago
by
Clément OUDOT
|
|
Posted
7 months
ago
by
Clément OUDOT
|
|
Posted
7 months
ago
by
Clément OUDOT
|
|
Posted
9 months
ago
by
Clément OUDOT
|
|
Posted
11 months
ago
by
KPTN
Big Brother is watching you Bien, pour débuter cet article, la première question qui se pose est : pourquoi mémoriser la date de dernière authentification ? Une des raisons pourrait être de tracer l'activité des
... [More]
utilisateurs, pour être certain qu'ils se connectent au système et qu'ils travaillent... Mais le vrai intérêt est plutôt inverse : cette date permet d'identifier les comptes qui sont obsolètes dans l'annuaire, par exemple qui n'ont pas été utilisés pour s'authentifier depuis plusieurs mois.
Pas si simple
On pourrait croire que cette information est simple à récupérer, surtout dans OpenLDAP, l'annuaire LDAP de référence.
Jusqu'à récemment, les seules solutions étaient d'analyser les logs systèmes (avec un niveau de log OpenLDAP à 256), ou de mettre en place l'overlay accesslog, qui stocke dans une base LDAP les opérations effectuées sur l'annuaire. Cette base devait alors être analysée pour retrouver la date de dernière authentification (opération BIND).
Les contributions, c'est bon
OpenLDAP est avant tout un logiciel libre avec une communauté active. Il existe dans le code source d'OpenLDAP un répertoire dédié aux contributions : ces modules ne sont pas maintenus par l'équipe principale du projet, mais assez matures pour être distribués avec le logiciel. Toutefois, cela signifie que si vous ne compilez pas explicitement ces modules, il ne seront pas disponibles pour votre installation OpenLDAP.
Parmi ces modules contribués, il y a l'overlay lastbind. Cet overlay a été écrit par Jonathan Clarke, ancien salarié de Linagora et l'un des fondateurs de la société Normation. Cet overlay permet de stocker dans l'attribut authTimestamp la date dernière authentification.
Assez parlé
Il est temps de passer aux travaux pratiques. Certains modules contribués sont désormais disponibles dans les RPMs fournis par le projet LDAP Tool Box. Le paquet en question s'appelle openldap-ltb-contrib-overlays et peut être téléchargé ici.
Une fois installé, on peu alors modifier la configuration d'OpenLDAP pour charger cet overlay :
# vi /usr/local/openldap/etc/openldap/slapd.conf
Tout d'abord, modifier le répertoire de chargement des modules, et charger le module :
modulepath /usr/local/openldap/lib:/usr/local/openldap/libexec/openldap
moduleload lastbind.so
On notera qu'on peut indiquer plusieurs répertoires pour le chargement des modules. Dans notre cas, le premier sert à charger le module password policy checker, et le second pour l'overlay lastbind.
Ensuite, il reste à instancier l'overlay au niveau de la base LDAP souhaitée :
overlay lastbind
Et c'est tout ! Pour les plus assidus, on pourra ajouter un paramètre de configuration, permettant de ne pas mettre à jour la date à chaque authentification, mais de limiter la précision à un certain nombre de secondes :
lastbind-precision 60
Bien entendu, l'overlay peut aussi être configuré par la branche cn=config.
Initialisation
Une fois l'overlay chargé et OpenLDAP redémarré, pour toute nouvelle authentification, une date sera stockée dans l'attribut authTimestamp, par exemple :
authtimestamp: 20120612073806Z
Seulement, il s'agit d'un attribut opérationnel, et il n'est donc pas possible de le modifier, ou de l'ajouter aux entrées qui n'en possèdent pas encore.
Enfin, rien n'est jamais impossible... OpenLDAP a implémenté le contrôle relax, qui permet d'effectuer des opérations d'administration sur les données, en particulier modifier des attributs opérationnels.
Par exemple, on peut créer le fichier LDIF suivant :
dn: uid=coudot,ou=users,dc=example,dc=com
changetype: modify
replace: authtimestamp
authtimestamp: 20120511144318Z
Et importer ce fichier dans l'annuaire :
$ ldapmodify -D cn=manager,dc=example,dc=com -W -e relax -f authtimestamp.ldif
Finalement, c'est simple, non ? [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.