Home > IAM, Security, Sysadmin > Petite surprise en LDAP: last successful bind

Petite surprise en LDAP: last successful bind

April 28th, 2009 Leave a comment Go to comments

Un rapide poste qui je l’espère fera suite à d’autres pour exposer une petite surprise que j’ai eu avec LDAP (enfin de manière plus précises avec les serveurs). Lors d’un projet pour mon nouvel employeur, on me demanda d’installer un OpenSSO pour authentifier des utilisateurs et obtenir leurs attributs LDAP. Bon, jusqu’ici rien d’anormal. Néanmoins, dans les attributs utilisateurs, il est demandé un attribut fournissant la date de la dernière connexion d’un utilisateur (en pratique la date d’un dernier bind opéré avec succès). Sur le moment, je n’ai pas percuté. Ce n’est qu’au moment de revenir sur mon poste, et par acquis de conscience, que j’ai commencé à me renseigner.

Et quelle ne fut pas ma surprise lorsque je me suis rendu que :

  • OpenSSO ne le permet pas de base. Après une rapide rechercher, il semblerait qu’une manière simple (c’est tout relatif) est d’écrire une classe (Java) qui sera exécutée après une authentification utilisateur.
  • Active Directory semble fournir cette fonctionnalité de base (via l’attribut lastlogon)
  • Sun Directory Directory Server Entreprise Edition (DSEE pour faire court) ne semble à priori pas le supporter dans toutes ses versions (>= 6.2 de mémoire, à prendre avec grande précaution) (tests en court)
  • OpenDS le supporte (tests en court)
  • Sun iPlanet 5.x ne le supporte tout simplement pas
  • Je n’ai pas regardé pour les autres serveurs, si jamais vous avez des retours dessus, je suis preneur.

Évidemment, je vous laisse deviner quel serveur j’utilise. Donc, je me suis retrouvé à écrire un plugin (en C) pour iPlanet, j’avoue que cela est assez intéressant (enfin il y a bien pire comme tâche :). Je vais mettre à disposition le code de ce plugin d’ici quelques jours, même si je doute qu’en Avril 2009 cela intéresse encore beaucoup de gens !

Pour information, pour obtenir cette fonctionnalité avec DSEE et OpenDS, il faut utiliser les password policies, et n’activer que la partie concernée. Cela va mettre à jour le champ ds-pwp-last-login-time (au moins vrai pour OpenDS).

Néannmoins, j’avoue que je suis assez surpris que cela ne soit pas de base, partout, dans tous les serveurs LDAP. Certes, cela demande un minimum de performances supplémentaires. En effet, cela provoque une écriture (opération considérée comme lente sur un annuaire LDAP) à chaque opération d’authentification réussie (mais on pourrait imaginer de vouloir l’équivalent pour un last failure). Mais au point de vue gestion d’identité, c’est quand même une information qui peut être très intéressante. Au hasard, sur un portail public, d’obtenir rapidement, et simplement, la liste des utilisateurs qui ne se sont pas connectés depuis une année.

Categories: IAM, Security, Sysadmin Tags: ,
  1. April 28th, 2009 at 21:31 | #1

    Bruno,

    Il y a plusieurs raisons pour laquelle tous les serveurs n’implementent pas ce service.
    La premiere est que cela ne fait pas partie du Standard LDAPv3. Donc toute implementation est propriétaire.
    La seconde est que garder le “last-login-time” transforme une authentification (operation de lecture) en une operation d’ecriture dans l’annuaire. Cela a un impact sur les performances de l’annuaire.
    Mais surtout pour des raisons de simplicité du service, les administrateurs de service LDAP voient cet attribut comme etant repliqué et identique sur tous les serveurs. Ce qui veut dire que, soit tous les serveurs sont des masters qui acceptent les ecritures, soit un replica en lecture retransmet l’operation d’ecriture vers un Master qui la replique a son tour.
    Dans OpenDS, tous les serveurs sont des masters. Mais aussi, il est possible de specifier la precision du ‘Last-login-time’ pour eviter des ecritures toutes les secondes ou meme toutes les minutes.
    Avec Sun Directory Server Enterprise Edition 6.x (et bientot 7), tous les serveurs sur lesquels les authentifications sont effectuées doivent etre des Masters. Il est possible de deployer la fonctionnalité dans un environnement Master – Slave avec un Directory Proxy Server en Front-end et du routage par operation.

  2. Jonathan Clarke
    April 29th, 2009 at 09:32 | #2

    Très intérressant ce petit tour d’horizon, merci Bruno !

    Petite précision sur Active Directory, l’information est stockée dans deux attributs : lastLogon et lastLogonTimestamp. Le premier est l’historique, mais est local à chaque contrôleur de domaine et non répliqué… Le deuxième est apparu depuis Windows Server 2003, et est répliqué mais peut avoir une “mise à jour décalée” jusqu’à 14 jours… Attention donc à la précision de cette information !

    Concernant OpenLDAP, aucun mécanisme n’est intégré par défaut, hormis les logs qui tracent chaque opération avec son résultat. Deux overlays peuvent être utiles néanmoins.

    L’overlay de politiques de mots de passe (ppolicy) stocke les last failures dont tu fais mention, dans l’entrée de l’utilisateur.

    L’overlay accesslog, lui, peut tracer toutes les opérations avec leur timestamp, y compris les binds réussis. En revanche, il les stocke dans un arbre indépendant des données, donc l’information ne se trouve pas dans l’entrée de l’utilisateur.

    Finalement, il serait assez simple d’écrire un overlay pour le faire, en C aussi, surement comme tu fais pour iPlanet. Dans ce cas là, il peut être utile de se donner une “précision” de l’information, comme AD le fait, pour ne pas imposer une charge d’écriture à chaque bind…

  1. No trackbacks yet.