J'écris une application de gestion des identités et des accès en langage de programmation C. J'utilise donc openLDAP pour conserver les détails des utilisateurs et il fournit un ensemble d'API pour effectuer des opérations telles que lier, ajouter, rechercher, modifier, etc. J'ai créé une nouvelle classe d'objets pour contenir les détails de l'utilisateur de mon application comme ci-dessous,

attributetype ( 2.5.4.1 NAME 'id'
    DESC 'RFC2256: user identifier'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 2.5.4.2 NAME 'name'
    DESC 'RFC2256: user name'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 2.5.4.3 NAME 'email'
    DESC 'RFC2256: user mail address'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )


objectclass ( 2.5.4.4 NAME 'user'
    DESC 'user details'
    SUP top STRUCTURAL
    MUST id
    MAY ( name $ email ) )

Est-il possible d'ajouter un nouvel attribut 'phoneNumber' à la classe d'objets 'user' sans éditer directement le fichier de schéma mais en utilisant les API fournies par la bibliothèque openLDAP?

0
Ajith C Narayanan 23 mai 2018 à 09:46

3 réponses

Meilleure réponse

La meilleure pratique serait d'ajouter une ObjectClass auxiliaire sans attributs REQUIS et d'ajouter des attributs "MAI" si nécessaire.

Après avoir ajouté la classe AUX au schéma, vous pouvez ajouter, via une opération de modification, la classe AUX à n'importe quelle entrée de structure ObjectClass en tant que valeur ObjectClass comme vous le souhaitez.

Cela vous permet de conserver le schéma de base intact.

-jim

2
jwilleke 28 mai 2018 à 17:38

Pas ce que tu as demandé. Mais c'est important pour que les autres ne copient pas naïvement et collez ceci:

attributetype (2.5.4. *

[..]

objectclass (2.5.4.4 NOM 'utilisateur'

Vous abusez des OID déjà affectés à d'autres descriptions de schéma. C'est cassé. Vous ne pourrez pas charger de données avec cela.

Avec la configuration dynamique d'OpenLDAP, vous pouvez ajouter / modifier un schéma à la volée si vous suivez les règles de la RFC 4512 pour définir les types d'attributs et les classes d'objets.

Voir aussi: cn = schema

Notez que la suppression des descriptions de schéma au cas où des données existantes l'utilisent est un non-non.

1
Michael Ströder 31 juil. 2018 à 15:19

Les normes LDAP sont écrites pour que le schéma soit Write Once Read Many data - une fois que vous avez défini quelque chose, vous ne pouvez pas l'annuler. En conséquence, de nombreux serveurs LDAP sont très résistants à la modification de leurs éléments de schéma comme vous en parlez.

Bien sûr, pour beaucoup d’entre nous, cette attitude est un luxe académique que nous ne pouvons pas nous permettre, alors nous faisons des modifications à notre schéma, malgré l’horreur de nos fournisseurs LDAP.

Cependant, nous modifions notre schéma, pas le schéma standard. La modification des classes d'objets standard est un non-non, car les modifications que vous apportez à la norme par défaut disparaissent parfois sans avertissement lorsque vous mettez à jour votre logiciel de serveur LDAP. Et même lorsque vous vous limitez à la modification des classes d'objets que vous devez modifier, vous devrez probablement mettre à jour les fichiers de schéma directement, puis demander au serveur LDAP de charger les nouveaux fichiers, plutôt que de simplement lui demander de mettre à jour ses éléments de schéma.

Bien sûr, différents serveurs LDAP ont différents niveaux de fiabilité à ce sujet. Par exemple, lorsque nous avons utilisé iPlanet LDAP, si je me souviens bien, cela nous permettait de supprimer et d'ajouter une classe d'objets qui n'était pas utilisée, et d'y apporter des modifications comme ça. (N'utilisez pas iPlanet LDAP; c'était le produit d'une coentreprise qui s'est effondrée il y a plus de 15 ans.)

1
Ed Grimm 16 janv. 2019 à 01:12