Enterprise Users et iPlanet /*+Round 2 (FIN!)*/

Et... Ca marche ! Avec Oracle 10g, les "username/password" des Enterprise Users peuvent être validé dans OID même si le mot de passe n'est pas alimenté en clair mais en SHA-1 (ce qui est le cas lorsqu'on on récupère les informations de iPlanet dans le paramètrage que j'effectue). Ce que j'ai fait :

• J'ai paramétré EUS de sorte que j'arrive à me connecter sous greg/manager1
• J'ai modifié le mot de passe avec "LDAP Browser /Editor" mais au lieu de saisir le mot de passe en clair, j'ai saisi sa forme hashée par l'algorithme SHA-1 (i.e. : {SHA}eeJHX4GmMXJ2v3y7OViyDSibeN8= au lieu de greg, cf image ci-dessus)
• Je constate que l'attribut orclpassword n'est pas renseigné (cf image ci-dessus). L'attribut authpassword;orclcommonpwd contient uniquement la valeur saisie (i.e. {SHA}eeJHX4GmMXJ2v3y7OViyDSibeN8 ).
• Quand je me connecte avec SQL*Plus 10.2 avec le mot de passe greg (Ca marche ! YES !) alors que si je me connecte avec l'ancien mot de passe (manager1), ça ne marche plus.

Et alors ?
L'étape d'après c'est de valider que ça marche avec la delegated authentication plugin si on ne veut pas faire la synchronisation du mot de passe dans OID mais laisser une seule version du mot de passe dans iPlanet. Quoiqu'il en soit, les restrictions liées à Oracle9i sont désormais levées dans la version 10g...

Avec quels clients ça marche ? J'ai testé avec SQL*Plus 10.1.0.4.2 et 10.2.0.2 avec succès. Par contre, il faut noter que :

• Les drivers JDBC Thin 10.2.0.2 sans paramétrages spécifiques ne fonctionnent pas si le mot de passe est stocké directement en SHA-1 dans OID (et donc l'attribut orclpassword non renseigné). L'erreur générée est "ORA-28274: No ORACLE password attribute corresponding to user nickname exists.". D'après ma compréhension, c'est une théorie pour l'instant, le client "hashe" lui-même le mot de passe et le transmet à la base de données. Il est probable qu'il faille (a) soit faire un paramétrage spécifique du client, (b) soit attendre une version ultérieure si l'algorithme n'est pas encore implémenté. J'ai ouvert un appel pour vérifier ce point.
  
• Comme on peut s'y attendre, les drivers OCI de la version 9i ne fonctionnent pas non plus et pour les mêmes raisons. Le même message d'erreur s'affiche lorsque vous essayez de vous connecter et que le mot de passe n'a pas été saisi en clair mais à partir de sa forme hashée en SHA-1: "ORA-28274: No ORACLE password attribute corresponding to user nickname exists".
  

Conclusion...
A quelques restrictions prêt (Utiliser l'Instant Client avec JDBC OCI plutôt que JDBC Thin) et avec Oracle 10.2, il est possible de gérer des utilisateurs de base de données de manière centralisée dans un annuaire tiers comme iPlanet et ceci, même si l'annuaire existe déjà et que les mots de passe y sont stockés en SHA-1. On pourra ensuite remplacer iPlanet par OID, non ?

GarK !

Nota Bene:

• En SSHA (Salted SHA) je n'ai pas trouvé le moyen de le faire fonctionner la synchronisation. Je pense qu'il n'est pas possible de partager les clé de "Salted" entre plusieurs annuaires (En fait, ça reste une question plus qu'une affirmation).
• La complexité du mot de passe n'est pas vérifiée par OID lorsque le mot de passe est écrit directement en SHA-1 dans le champ userpassword. Ceci est logique puisque l'algorithme n'est pas réversible et on voit mal comment OID pourrait faire ce test !
• Une dernière bonne nouvelle : on n'est pas obligé d'utiliser un certificat pour la connexion entre la base 10.2 et OID 10.1.2. Un simple paramétrage / fonctionne et ça m'a pris moins de 1 heure pour mettre en place EUS avec ma base de données !

Enterprise Users et iPlanet /*+Round 2*/

Il y a quelques mois et après plusieurs jours de tests laborieux, nous avons fini par comprendre pourquoi Enterprise Users Security (EUS pour les intimes !) d'Oracle9i ne pouvaient pas valider leurs credentials dans un référentiel iPlanet. La raison est simple :

• Le mot de passe est stocké dans iPlanet sous une forme hashée avec un algorithme standard (e.g. SHA-1)
• Oracle9i n'est pas capable d'utiliser un autre algorithme que l'algorithme propriétaire et historique d'Oracle (i.e. O3LOGON)

Avec Oracle 10g R2, tout est censé *en théorie au moins* changer ! Deux indices bien cachés, nous mettent sur la voie :

• la note metalink N°272196.1 indique que le mot de passe des utilisateurs d'EUS d'Oracle 10.2 n'est plus validé sur l'attribut orclpassword d'OID (qui contient la forme O3LOGON du mot de passe) mais sur l'attribut authpassword qui contient une forme multi-valuée par des mots de passe (Cette forme peut par exemple contenir le mot de passe hashé sous la forme SHA-1)
• La documentation "Oracle® Database Enterprise User Administrator's Guide - 10g Release 2 (10.2) - Part Number B14269-01" indique dans les nouveautés d'Oracle 10.2 que la gestion des utilisateurs dans un annuaire tiers est supporté et notamment du fait que les algorithmes standards de vérification ont été introduit dans le produit

J'ai commencé à tester... J'ai installé OID (depuis le CD d'Oracle Application Server 10g), une base 10.2. Il faut également installer le client de la base de données qui contient Enterprise Security Manager (ESM) nécessaire au setup : je dois downloader le client de la base de données et je ne peux pas récupérer la distrib depuis chez moi... Pour visualiser le contenu d'OID et mettre à jour les attributs, j'ai téléchargé et installé LDAP Browser/Editor (LBE) (http://www-unix.mcs.anl.gov/~gawor/ldap/index.html).

J'ai créé un utilisateur et avec LBE, j'ai vérifié qu'en modifiant le mot de passe avec sa forme SHA-1 (seule forme que je peux récupérer d'iPlanet), je mets à null l'attribut orclpassword de l'utilisateur et la forme multi-valué de authpassword ne contient que la forme SHA-1 du mot de passe, soit pour "manager1", la chaine {SHA}pcKXwV5ArDiB21EndhOuo3MbZzo=

La semaine prochaine, je paramètre EUS et je vérifie si... oui ou non ma théorie est correcte de manière pratique : pour l'instant rien n'indique le contraire ! La suite, bientôt...

GarK!