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.