La classe d’objet « InetOrgPerson » est la classe standard utilisée par les services d’annuaire LDAP, selon la norme X.500. Pour davantage de détails, vous pouvez consulter le RFC 2798.
La classe d’objets « User » est donc une classe d’objets spécifique, propre à Microsoft Windows Active Directory.
C’est ainsi une implémentation particulière au sein de l’annuaire Microsoft, Active Directory.
Sans grande surprise, la plupart des entreprises adosse son infrastructure sur Microsoft Windows Active Directory, bien que ce ne soit pas franchement le standard X.500.
Classe stratégique d’objets
C’est là où la firme Microsoft est forte et astucieuse en termes de stratégie :
– Création d’un annuaire spécifique, avec une gestion presque intuitive pour le commun des mortels,
– Ajout d’une compatibilité lié à la standardisation (Novell, OpenLDAP et cætera),
– Absorption des autres annuaires dans la mesure du possible.
Dans le cadre de la cohabitation de plusieurs annuaires, une problématique se posait autrefois lorsqu’il s’agissait d’interopérabilité avec l’annuaire Active Directory.
En soulignant ses différences et subtilités, nous voudrions vous sensibiliser sur l’importance de la création des objets utilisateurs autrefois au sein de votre environnement.
D’une façon générale, la phase d’étude qui permet d’avoir logiquement une vision architecturale simple et efficace doit pouvoir permettre de bien déterminer quelle serait la nature de l’objet utilisateur (au sens classe d’objet LDAP du terme) devant être synchronisé entre différents annuaires de son infrastructure, InetOrgPerson versus user. Ce n’était pas toujours chose simple.
Depuis la version de Windows 2003, Microsoft s’est assuré que ces deux classes d’objets soient prises en compte par Active Directory directement, c’est pour ainsi dire faciliter la migration des autres annuaires vers Windows Active Directory.
Sur le plan technique, l’objet InetOrgPerson est clairement un dérivé de l’objet user.
La légende raconte que la conversion de la classe d’objet n’est pas possible. Cela reste une légende si votre niveau fonctionnel de la forêt est inférieur à 2003.
Admettons-le, c’est un non-sujet de nos jours, et nous osons l’espérer sans prendre beaucoup de risques en tous cas.
Concept de conversion en InetOrgPerson
Le concept de conversion consiste à ajouter à l’attribut ObjectClass la valeur InetorgPerson.
La conversion et le retour arrière sont possibles à l’aide de PowerShell.
Conversion : Set-ADUser %useraccount% -Add @{objectClass=’InetorgPerson’}
Retour arrière (roll back) : Set-ADUser %useraccount% -Remove @{objectClass=’InetorgPerson’}
Le sujet que nous soulevons ici n’engendrera évidemment aucun questionnement dans un environnement totalement bâti avec des solutions purement Microsoft. Dans une pareille situation, il n’y a pas débat.
Ce qu’il faut retenir
- Le compte InetOrgPerson peut remplacer un compte d’utilisateur dans un environnement Active Directory. Le plus grand avantage d’utiliser un compte InetOrgPerson plutôt qu’un compte d’utilisateur est que InetOrgPerson vous offre une interopérabilité avec d’autres services d’annuaire ; Novell eDirectory par exemple. Ce dernier inclut distinctement le type de classe d’objet InetOrgPerson dès sa première version,
- A chaque fois que vous avez besoin d’un compte qui interopère facilement avec d’autres services d’annuaire basés sur LDAP, vous devriez envisager de créer le compte de l’utilisateur en utilisant le type de compte InetOrgPerson,
- Les attributs entre les objets de type InerOrgperson et user sont similaires, le respect de la norme n’engendre aucune régression fonctionnelle.