You are not logged in.
Bonjour,
Quand on a un GLPI connecté à un serveur LDAP comme active directory par exemple, les comptes utilisateurs de GLPI se synchronisent au LDAP grâce au chemin DN que l'on peut voir d'ailleurs quand on clique sur un utilisateur (onglet habilitation)
exemple :
CN=ADON Eric,OU=equipement1,OU=Utilisateurs_societe,DC=domaine,DC=lan
Hors si on déplace l'utilisateur dans l'active directory (en le déplaçant d'OU par exemple) le chemin DN change et est erroné dans GLPI. Donc l'utilisateur GLPI ne peut plus se connecter à l'interface web. Et GLPI est incapable de mettre a jour cette information...
Il serait bon que dans GLPI, sur l'utilisateur, que l'on puisse modifier le chemin DN, que cela ne soit plus juste une information affichée mais un champ modifiable qui permettrait à l'administrateur GLPI de corriger le chemin DN.
J'ai actuellement le cas pour plusieurs utilisateurs. La seule solution est de les supprimer l'utilisateur et de réimporter. Mais cette solution a le désavantage qu'il n'y a plus de laison avec les anciens tickets de l'utilisateur.
L'autre solution est de modifier en SQL avec les risques de mauvaises manipulation.
Merci
Last edited by eric.le-corre (2013-12-06 11:08:28)
Offline
Bonjour
Je soutiens la demande, car c'est une situation qui peut arriver dans le fonctionnement normal du système d'information sur lequel je travaille.
Ce détail est bon à savoir.
Utiliser l'identifiant de l'utilisateur seul (sAMAccountName) serait peut être plus approprié ?
Offline
Bonsoir,
C'est une demande qui me semble également intéressante. A mon sens, le problème est qu'Active Directory et les autres annuaires ldap (Openldap entre autre) n'utilisent pas le même attribut pour stocker l'identifiant unique d'un objet.
AD utilise l'attribut objectsid, tandis que openldap et consorts utilisent entryuuid (de mémoire). Si seul Active Directory n'utilise pas le même attribut que les autres annuaires, il pourrait être envisageable d'étendre la fonction de pré-configuration active directory pour dissocier les deux types d'annuaires sur ce point...
Qu'en pensez-vous ?
Last edited by @meurou (2013-12-11 22:57:33)
Prod : Windows Server 2012R2 - IIS - PHP 7.1.6 - MySQL 5.6 - GLPI 9.1.4 - OCS server 2.3.1 - Ocsinventoryng 1.3.3
Offline
Bonjour
C'est exactement ce que je pense : une préconfiguration pour Active Directory étant déjà implémentée, il suffit de la compléter.
Offline
Bonjour
C'est exactement ce que je pense : une préconfiguration pour Active Directory étant déjà implémentée, il suffit de la compléter.
c'est à dire ?
une configuration particulière permettrait de corriger ce problème ?
Offline
Une configuration je ne pense pas, il faudra une évolution de code.
Actuellement, GLPI utilise un critère d'unicité commun à tout moteur ldap, le dn du compte utilisateur. Avec ce que l'on souhaite, ce critère change en fonction de l'annuaire ldap utilisé :
L'idée serait de transformer le champs dn en champs informatif, et d'ajouter un champs uuid comme critère d'unicité. Celui-ci prendrait comme valeur selon l'annuaire le sid (AD) ou le uuid (openldap et consorts).
Donc on touche au code dans ce cas...
Prod : Windows Server 2012R2 - IIS - PHP 7.1.6 - MySQL 5.6 - GLPI 9.1.4 - OCS server 2.3.1 - Ocsinventoryng 1.3.3
Offline
Dans un cas de multi-ldap utiliser le sid ou uuid risque de poser des problèmes de collision non ?
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Bonjour
En ce qui concerne un AD
le SID est divisé en plusieurs parties. Une de ces parties est généré à l'installation de windows pour être le Domain SID, et est calculé de manière à être unique. Les SID des utilisateurs et des groupes contiennent le domain SID, plus une partie qui s'incrémente à chaque création.
Je pense qu'il est possible d'avoir un domain SID identique entre deux domaines. Cela doit arriver quand il y a collision dans l'algorithme (ce qui devrait être relativement rare), et aussi quand des systèmes d'exploitation windows sont clonés sans utiliser sysprep (le clonage reproduit le domain SID)
une petite doc récupérée rapidement est disponible ici : http://www.windowsecurity.com/articles- … ctory.html
Voici l'extrait qui nous intéresse ici :
What is a SID?
A SID is a security identifier. Although we know users, groups, and computers as Derek, Domain Admins, and Server1, the operating system knows these accounts as 1000, 512, and 1500 (along with some other numbers and few letters!). It is like the Internet Web sites that you visit. Do you know the IP address for google.com? Neither do I! However, the Internet does not really either! The Internet knows it as 74.125.91.106. It is DNS that helps with resolution, so you don’t need to know what the IP address is.
An example of a Windows SID would be S-1-5-21-549688327-91903405-2500298261-1000. The S-1-5-21 is used for most user and group accounts, where the 549688327-91903405-2500298261 is the domain SID.
Note:
I have been asked if two domains can be installed and have the same domain SID? Yes is the answer, however, based on my knowledge of statistics, I find it VERY HARD to imagine that two domains in the world would generate the same domain SID and then be associated to the same physical network. I think getting hit by lightning on a sunny day would be a greater risk.
Maintenant, pour linux, je ne sais pas, mais je pense que c'est TRES probable car il n'y a pas de notion similaire au domain SID. C'est à l'administrateur de faire attention à la construction de ses annuaires.
Une astuce que je sors de ma mémoire embrumée (nous ne sommes que mardi) donc à vérifier : LDAP connait un numéro qui est l'object ID, ou numéro de série d'objet. Si je ne dis pas de bêtise, et si un algorithme visant l'unicité le génère, cela pourrait être un bon candidat, tout en étant commun à tous les annuaires LDAP. (note : je ne lira pas la RFC concernée aujourd'hui par manque de temps)
Offline
+1 avec la réponse de dethegeek concernant Active Directory.
Par contre, je ne connais pas non plus le comportement côté openldap.
Pour info, la rfc sur le UUID http://tools.ietf.org/html/rfc4530
Prod : Windows Server 2012R2 - IIS - PHP 7.1.6 - MySQL 5.6 - GLPI 9.1.4 - OCS server 2.3.1 - Ocsinventoryng 1.3.3
Offline