Migration Sun DSEE vers un autre annuaire LDAP

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.

Catégorie: 

Tag: 

Add new comment