Exploiter au mieux les champs de la fiche utilisateur d’Active Directory
Nous voilà donc face à « l’objet » utilisateur Active Directory et tous ses champs standards, que nous allons utiliser pour décrire les différents aspects de la position dans l’organisation.
Commençons donc par le plus simple : géographie.
>> Retour en première partie – Construire son annuaire d’entreprise
Les champs existants pour décrire la localisation géographique
Active Directory offre au moins 7 champs pour décrire la localisation, certains sont calqués sur la structuration X400, « c » et « co » pour le pays, « st » pour la région/département, « l » pour la ville, « PostalCode » pour le code postal, « StreetAddress » pour la rue et son numéro, « PostOfficeBox » pour le code cedex ou boite aux lettres et « PhysicalDeliveryOfficeName » pour le bureau.
De quoi faire certes, mais il est à noter que seul le pays fait l’objet d’un contrôle de cohérence en proposant les codes ISO des pays.
Quant aux bureaux peu adaptés aux structures à cloisons légères et aux open-spaces, il est souvent utilisé sous la forme de zone de travail ou de point d’accès, ou poteau de prises informatiques, ou encore de fenêtres.
>> Retour en deuxième partie – Construire son annuaire d’entreprise (partie 2)
Les relations hiérarchiques
Elles partent du principe que chaque personne dispose d’un seul manager et éventuellement d’un seul assistant. C’est vrai dans 99.9 % des cas, reste quelques cas de personnes disposant de plusieurs assistants ou managers qui ne pourront pas être décrits correctement.
Le champ contient la chaine du « DN » (Distinguished Name ou Nom Complet sous sa forme LDAP) du manager, mais bénéficie toutefois d’un contrôle d’intégrité : si le compte du manager est détruit, le champ est vidé.
À noter toutefois que deux écoles s’affrontent pour le plus haut niveau : « il est son propre manager » versus « il n’a pas de manager ». Personnellement je préfère la seconde qui décrit la réalité et permet de ne pas faire un traitement spécial dans le cas des recherches récursives (qui sinon risquent de boucler à l’infini). Active Directory accepte les deux cas.
La structure organique
C’est le dernier point et souvent le plus délicat, si l’on part du principe que la profondeur de la structure est sans limite, Active Directory n’est pas la réponse idéale, seules les Organizational Units permettraient ce genre de construction, et elles ne doivent, ni ne sont utilisées comme on l’a vu précédemment.
Alors au final, seuls restent les champs « Company » pour Société, « Division » pour Direction (mais qui n’est pas disponible dans l’interface standard et est apparu seulement depuis Active Directory 2008), « Department » pour Service.
Au sens strict du terme, un, au mieux deux champs ! Alors il faut tricher.
La société est le nom de l’Active Directory ou l’Organizational Unit racine, donc le champ « Company » est disponible, le titre de la personne n’est pas capital donc le champ « Title » peut aussi être détourné.
On aura donc company / division / department / title pour respectivement direction / division / département / service, c’est n’est pas forcément idéal mais suffisant en général.
Reste un dernier point
Qui va se charger de saisir ces informations ? À la base l’information est en général détenue par les Ressources Humaines, mais l’outil de gestion des comptes Active Directory est à la fois complexe à utiliser, peu ergonomique et hautement sensible en matière de sécurité. On va donc souvent déléguer par défaut cette saisie à la DSI, et sans moyen de s’assurer de la cohérence des données.
Et bon courage !
Cette série d’articles ne sort pas de mon chapeau, nous sommes très souvent confrontés à ce type de problème chez les clients d’Apsynet et les solutions explorées sont celles mises en œuvre chez eux. De plus, nos produits se fondent sur Active Directory pour exploiter les informations, mais ils peuvent aussi être utilisés pour contrôler la saisie ou bien comme outil de mise à jour contrôlée de l’AD.
Olivier Piochaud, Président Directeur Général d‘Apsynet
