Uubu.org

Systèmes d'information: une approche OpenSource

OpenLDAP - le Schéma

Définition d'un schéma de base pour OpenLDAP

Le 02 mai 2014 , Aucun commentaire pour cet article


Dans cet article, je vais faire une présentation sommaire du schéma embarqué, et des différents schémas standards utiles afin de se familiariser avec le schéma LDAP.

 

Intéressons nous d'abord au schéma embarqué:

OpenLDAP contient tout d'abord les définitions d'attributs et de classes d'objet destinées à sa propre configuration. Préfixés avec 'olc', ils servent à la configuration globale, au schéma, modules et bases de données.

Les autres définitions d'attributs présentes sont nécessaires au fonctionnement interne de l'annuaire, dont un certain nombre d'attributs opérationnels. On trouve logiquement la rfc4512, le userPassword de la rfc4519, et quelques autres définitions issues d'autres standards. On peut retrouver ces définitions dans les sources d'OpenLdap: les attributs de configuration du serveur dans servers/slapd/bconfig.c, les attributs dynamique dans servers/slapd/schema_prep et les autres attributs dans servers/slapd/schema_init.c.

À noter la présence de la classe top, mère de tous les autres.

Ici, nous allons définir un schéma, basé sur les standards, rfc par rfc. Les définitions étant contraintes par les dépendances, je les décris dans l'ordre d'importation.

rfc4512

Comme indiqué plus haut, ce schéma est inclus entièrement dans le schéma embarqué, puisqu'il décrit tous les objets de base, objectClass, attributeTypes, alias, dITContentRules, etc.

 

rfc4519

cn, description, distinguishedName, name, seeAlso, uid, usedPassword sont déjà embarqués. Cette rfc définis un schéma pour les applications utilisateurs, il y est définis les classes d'objet person, organizationalPerson, organizationalRole, organizationalUnit, residentialPerson, uidObject, organization, dcObject, groupOfNames, groupOfUniqueNames et quelques autres.

dcObject et organization sont intéressants puisqu'ils peuvent être utilisés dans la racine d'un contexte de nommage. dcObject ne possède qu'un attribut: dc

olcAttributetypes: ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

olcObjectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )

organization est plus complet:

olcObjectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

 

rfc4524

Ce standard définis des éléments utiles pour les comptes machines, la gestion de documents, et une autre classe qui peut être utilisé pour notre contexte de nommage: domain, qui définis une entrée représentant un domaine DNS.

olcObjectClasses: ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $   internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $   physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) )

Point intérressant de cette classe, elle rassemble les attributs de dcObjet et organization et est plus orientée grandes entreprises.

 

rfc3112

Ce standard n'est pas pris en charge par OpenLDAP. Il définis en effet authPassword, non géré par le serveur. Cependant, pour que posixAccount soit conforme à la rfc2307, cet attribut doit être définis. Vu que la règle de correspondance n'est pas définie dans OpenLDAP, nous ne pouvons le définir comme tel. À la place, définissons le comme userPassword, et désactivons le:

olcAttributeTypes: ( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword' DESC 'password authentication information' OBSOLETE EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
olcObjectClasses: ( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject' DESC 'authentication password mix in class' OBSOLETE AUXILIARY MAY authPassword )

 

rfc2307bis02

le schéma de mappage unix NIS. uidNumber et gidNumber sont déjà dans de schéma embarqué. Ce schéma est utilisé pour que les utilisateurs puissent s'authentifier sur les machines avec un compte dans l'annuaire.

 

rfc2589

Les extensions pour les services d'annuaire dynamique. Ces définitions sont présente dans le schéma embarqué et gérés par l'overlay dds

 

rfc3671

Les définitions pour les attributs collectifs. collectiveAttributeSubentries et collectiveExclusions ne peuvent pas être définis, mais ils sont pris en charge par l'overlay.

 

rfc4130

entryUUID est déjà présent dans le schéma embarqué.

olcAttributeTypes: ( 1.3.6.1.1.16.4 NAME 'entryUUID' DESC 'UUID of the entry' EQUALITY UUIDMatch ORDERING UUIDOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

 

rfc5020

entryDN est déjà présent dans le schéma embarqué

olcAttributeTypes: ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

 

rfc4523

Le schéma des certificats x.509. À noter que OpenLDAP ne gère pas encore le règles certificatePairExactMatch et algorithmIdentifierMatch, donc les définitions de crossCertificatePair ec supportedAlgorithms doivent être dérivées de l'ancienne rfc2256.

 

rfc2798

inetOrgPerson est une classe structurelle contenant des attributs utiles pour les comptes utilisateurs. A noter que audio et photo sont définis dans l'ancienne rfc1274.

 

 

À ce stade, vous avez toutes les définitions de base pour travailler. Il y a quelques autres schémas standard, mais moins utilisés. Dans le prochain article, je donnerai un exemple de design de schéma personnalisé.

 

Note: Tous les schémas décris dans cet article sont disponibles dans documents/schémas-ldap/<rfcXXXX.ldif>

Aucun commentaire pour cet article

Note: Les commentaires sont temporaiment désactivés, merci de contacter l'auteur par mail