Discussion :

[sat_ourne]

Salut,

Cela fait 10 ans que je fais du développement et aujourd'hui, je suis tombé sur un cas de figure étrange : ils ont changé la casse d'un login windows qui permet de s'authentifier sur l'intranet de l'entreprise ...

ex: le login aaa12345 est devenu AAA12345

Cela génère des problème car ce Login est stocké dans plusieurs endroits (champs de bases de données...) de plusieurs applications ... car bien sur en langage de programmation : aaa12345 est différent de AAA12345


Je leur ai expliqué que cela ne devait pas se faire ...

Et vous, est-ce que vous rendez vos applications insensibles à la casse (login aaa12345 = AAA12345) ?

Merci.

[Richard_35]

Bonjour Sat_ourne,

Plus largement, tu évoques le sujet de modification de la clé d'une entité qui est présente en clé étrangère dans d'autres entités, que ce soit une histoire de casse ou non.

Plusieurs choses :

• en conception, une clé définie ne doit jamais pouvoir être modifiée. Un moyen d'y arriver est de générer une clé qui ne veut rien dire (donc, aucun intérêt de la modifier), par exemple en numérotation automatique. La clé devient donc un numéro et, dans ton cas, le login n'est qu'un attribut de l'entité en question ;
• à ma connaissance, tous les SGBD évolués proposent la modification "en cascade" des tables contenant la clé étrangère modifiée. Si le MCD est bien construit (si les relations sont correctes), alors la modification "en cascade" doit fonctionner.

Pour information, jettes un coup d'oeil à ce fil.

[montesq]

@Richard_35
Relisez le post de sat_ourne, vous ne répondez pas à la question posée.
De plus, a priori le "login" ne devrait pas être une clé car il peut être amené à être modifié (par exemple si l'utilisateur veut/peut changer son identifiant ou si une erreur a été commise à la saisie)

Pour répondre à la question de sat_ourne : dans l'application sur laquelle je travaille le login est insensible à la casse, tout simplement parce que dans notre cas précis le login est l'adresse email de l'utilisateur, or les adresses email ne sont pas sensibles à la casse.
Par contre, nous sommes sensibles à la casse pour le mot de passe.

En fait, si tu gardes la sensibilité à la casse sur le login, cela suppose donc que sat_ourne et Sat_ourne peuvent être 2 utilisateurs différents. Admettons que tel soit le cas sur developpez.net, alors si au cours de notre fil, un certain Sat_ourne intervient au cours de ce fil de discussion, il y a fort à parier que je ne fasse pas la distinction entre les 2 utilisateurs! Et on pourrait même penser qu'il s'agit d'une tentative d'usurpation d'identité...

[Richard_35]

Bonjour à toi aussi, Montesq,

Relisez le post de sat_ourne, vous ne répondez pas à la question posée.

==> Ah... c'est possible, après tout. Attendons l'avis de Sat_ourne.

.../... a priori le "login" ne devrait pas être une clé .../...

==> ce n'est pas ce que je comprends : c'est une sorte de clé étrangère dans d'autres tables puisqu'elle sert à retrouver une personne :

Cela génère des problème car ce Login est stocké dans plusieurs endroits (champs de bases de données...) .../...

==> je comprends que Sat_ourne est embêté car le login figure dans plusieurs tables et que s'il est modifié dans la table principale (qui pourrait être l'active directory), alors la correspondance est perdue. Le terme "la correspondance" étant, en l'occurrence, une correspondance d'un login vers un champ le comprenant donc, une sorte de clé étrangère, non ?


C'est vrai, en règle générale, le login est insensible à la casse, seul le mot de passe l'est, chez developpez.net comme partout ailleurs.

.../... login est l'adresse email de l'utilisateur .../...

==> il est possible que tes utilisateurs changent d'adresse mail (abandon du FAI, ou autre) ?
Dans ton application, quelles seraient les répercussions de ce changement de login ?

[montesq]

==> Ah... c'est possible, après tout. Attendons l'avis de Sat_ourne.

Désolé d'avoir été très/trop direct/binaire dans ma réponse.
La question est:
"est-ce que vous rendez vos applications insensibles à la casse (login aaa12345 = AAA12345) ?"
Je considère le reste du post comme le contexte qui amène Sat_ourne à se poser cette question.
Ceci dit, étant donné le contexte, peut-être que la question était mal posée et que ta réponse a du sens si la question avait été différente.

==> ce n'est pas ce que je comprends : c'est une sorte de clé étrangère dans d'autres tables puisqu'elle sert à retrouver une personne :

Ce n'est pas parce que c'est un attribut qui doit être unique et qu'il permet de retrouver un utilisateur que cet attribut doit être la clé primaire de l'utilisateur (et dans ce cas être utilisé comme clé étrangère dans les autres tables).

==> je comprends que Sat_ourne est embêté car le login figure dans plusieurs tables et que s'il est modifié dans la table principale (qui pourrait être l'active directory), alors la correspondance est perdue.
Le terme "la correspondance" étant, en l'occurrence, une correspondance d'un login vers un champ le comprenant donc, une sorte de clé étrangère, non ?

A la relecture du post initial, je comprends d'où vient ton interprétation:
"Login est stocké dans plusieurs endroits (champs de bases de données...) de plusieurs applications"
Il me paraissait évident que ce login n'apparaissait qu'une fois (dans une colonne d'une seule table) pour chaque application et non pas en tant que clé étrangère de chaque application. En effet, utiliser le login comme clé étrangère serait une erreur grave de conception : il faut toujours utiliser des clés techniques comme clés primaires pour ces raisons, voir ma réponse ci-après.

==> il est possible que tes utilisateurs changent d'adresse mail (abandon du FAI, ou autre) ?
Dans ton application, quelles seraient les répercussions de ce changement de login ?

En général dans une table "utilisateur", tu as 3 colonnes (au minimum): ID (clé primaire), USERNAME (unique), PASSWORD
Lors de la connexion, on recherche l'enregistrement par rapport au USERNAME saisi (qui est unique dans la table)
select * from user where username = '...'
et on vérifie que le PASSWORD saisi est celui en base.

Si on a des enregistrements qui sont liés à l'utilisateur (par exemple des posts dans un forum) alors on utilise bien sûr l'ID "Technique" comme clé étrangère.
Le jour où l'utilisateur :
ID , USERNAME, PASSWORD
33 , montesq , toto
veut changer de USERNAME, il devient
ID , USERNAME, PASSWORD
33 , montesq_new , toto
et tous les enregistrements liés à cet utilisateur ne sont pas impactés puisqu'ils sont liés à l'ID technique 33 et non à son USERNAME

[Richard_35]

Bonsoir Montesq,

Il me paraissait évident que ce login n'apparaissait qu'une fois (dans une colonne d'une seule table) pour chaque application et non pas en tant que clé étrangère de chaque application. En effet, utiliser le login comme clé étrangère serait une erreur grave de conception : il faut toujours utiliser des clés techniques comme clés primaires pour ces raisons, voir ma réponse ci-après.

==> nous sommes bien d'accord, donc.


Pour reprendre ton exemple :

Le jour où l'utilisateur :
ID , USERNAME, PASSWORD
33 , montesq , toto
veut changer de USERNAME, il devient
ID , USERNAME, PASSWORD
33 , montesq_new , toto
et tous les enregistrements liés à cet utilisateur ne sont pas impactés puisqu'ils sont liés à l'ID technique 33 et non à son USERNAME

==> ce que je comprends mais, peut-être, ai-je mal compris, c'est que Sat_ourne exploite une table qui :

Le jour où l'utilisateur :
USERNAME, PASSWORD
montesq , toto
veut changer de USERNAME, il devient
USERNAME, PASSWORD
montesq_new , toto
et tous les enregistrements liés à cet utilisateur ne sont pas impactés puisqu'ils sont liés à l'ID technique 33 et non à son USERNAME.

C'est, il me semble, l'objet de sa remarque :

ex: le login aaa12345 est devenu AAA12345

Cela génère des problème car ce Login est stocké dans plusieurs endroits (champs de bases de données...)

Le conseil initial étant celui que tu as suivi dans ton application, à savoir :

en conception, une clé définie ne doit jamais pouvoir être modifiée. Un moyen d'y arriver est de générer une clé qui ne veut rien dire (donc, aucun intérêt de la modifier), par exemple en numérotation automatique. La clé devient donc un numéro et, dans ton cas, le login n'est qu'un attribut de l'entité en question

[sat_ourne]

Tout d'abord merci de votre réactivité.

J'ai bien lu vos différents arguments et je vais apporter quelques précisions :

• le login qui a changé se trouve dans l'Active Directory
• ce login peut être stocké dans plusieurs champs (login, login du signataire, modifié par...), de plusieurs bases de données sur plusieurs systèmes
• ces bases de données peuvent être de plusieurs types/modèles : SQL, SQL SERVER, MySQL, Oracle, Lotus Notes Databases, spécifiques(fichiers plats propriétaires:.csv)
• les applications peuvent utiliser plusieurs technologies ASP .net,C#,PHP,Lotus Notes ...
• il n'y a pas forcément de "tables utilisateurs" dans toutes ces applications, et si oui cela n'apporterait-il pas plus à confusion ?

A ma connaissance, l'entreprise a souhaitée utiliser une authentification au travers de l'AD pour tout les systèmes informatique; et même hors ce choix, la plupart du temps les systèmes ne sont pas sensibles à la casse dans la boîte de login. Ceci dit, lorsque l'on demande à ces système (par programmation) de renvoyer le login, ce n'est pas ce que l'utilisateur a tapé dans la boîte de login qui est renvoyé mais bien ce qui est stocké dans la base de donnée : ici il s'agit de l'annuaire LDAP/Active Directory. Par conséquence, l'AD est un référentiel et le login est une clé, ce qui nous renvoie à la définition d'une clé en informatique.

Pour toutes ces raisons, et même si j'avais pensé à cette éventualité, je ne réalise pas d'applications qui anticipe ce problème. Un login est un texte et dans ce sens hahaha est différent de HAHAHA. Je ne vous parle pas de héhéhé qui est différent de HEHEHE, et vous savez combien il est dur de mettre des accents sur les lettres majuscules
J'ajouterai que sous ubuntu, les logins ne contiennent que des minuscules, ce qui résoud le problème.

Dans mon cas, normalement le problème devrait être remonté à l'origine de ceux qui ont fait ce changement. J'ai hâte de savoir la solution qui sera prise (retour en arrière ou non) ou le silence qui en suivra, et de savoir qui paye les pots cassés (ne les laissez pas trop abuser de votre pot ...).

En attendant, n'hésitez pas à apporter votre pierre à l'édifice ou au pire comme moi : lapidez les administrateurs ...

[montesq]

Reprenons ; l'architecture type pour se genre de besoin est :
1° une application / base de données définie comme le référentiel pour les utilisateurs (ici ton AD)
Cette table doit être définie avec les 3 colonnes: ID (clé primaire), USERNAME, PASSWORD comme expliqué précédemment
2° toutes les applications qui nécessitent de lier des données aux utilisateurs doivent le faire à partir de l'ID fourni par la bdd référentiel (normal, l'ID est la clé primaire!)
3°
- Soit aucune information de type usesrname/password n'est stockée dans les applications filles (ce qui nécessite de requêter la base de données référentiel en temps réel a priori via un webservice)
- Soit on organise une réplication des données du référentiel sur les bases filles.
Dans ce cas 2 systèmes sont envisageables :
A) le batch ou ETL si on veut une réplication à intervalle régulier,
B) l'EDI si on veut tendre vers le temps réel: le référentiel publie un message lorsque un utilisateur est créé/modifié/supprimé. Les applications filles qui ont besoin des informations sur les utilisateurs sont abonnées aux messages envoyés par le référentiel et mettent à jour les données en conséquence lorsqu'il détecte un nouveau message.

Dans tous les cas, si on modifie les attributs USERNAME et/ou PASSWORD dans une application fille, la modification des données doit avoir lieu impérativement sur le référentiel afin que toutes les applications filles puissent bénéficier à terme de ces modifications.

[sat_ourne]

Dans tous les cas, si on modifie les attributs USERNAME et/ou PASSWORD dans une application fille, la modification des données doit avoir lieu impérativement sur le référentiel afin que toutes les applications filles puissent bénéficier à terme de ces modifications.

Le problème est là : ce n'est pas dans l'application fille que l'on a changé le Login ID, c'est dans l'AD que ça a été modifié.

Le problème est donc que l'on a une relation :
1 AD --> n applications
sans qu'il y ait une quelconque synchro prévue car il y a une contrainte d'intégrité qui n'est bien sûr pas programmée dans les n applications.

d'où la question de départ : Doit-on vérifier que son application n'est pas sensible à la casse du login/identifiant ?

C'est un débat sans fin mais est-ce que les administrateurs ont l'habitude de changer la casse de leur login et pour quelle raison ?

Voici qui complète ma réponse précédente : je considère que changer la casse du login c'est changer son login, même si l'administrateur ne le voit pas sous cet angle. Ce qui au regard de l'environnement (nbre de fois où est utilisé le login dans les applications) peut avoir des conséquences catastrophiques ...

@+

[Richard_35]

Bonjour à tous,

Effectivement, si la clé de tes différentes applications est le login AD, alors cela se complique.

Dans AD, le login peut être changé. Cela signifie que cette table interne à Windows à un identifiant interne unique : une sorte de numérotation automatique, donc.

Je ne suis pas un spécialiste, mais la solution serait donc de stocker, dans tes applications filles, l'ID unique du login, et non pas le login lui-même. Voies, peut-être, dans le forum Windows s'il y a la possibilité de trouver cet ID unique généré automatiquement par Windows.

[montesq]

Le problème est donc que l'on a une relation :
1 AD --> n applications
sans qu'il y ait une quelconque synchro prévue car il y a une contrainte d'intégrité qui n'est bien sûr pas programmée dans les n applications.

Je ne comprends pas "il y a une contrainte d'intégrité qui n'est bien sûr pas programmée dans les n applications".
Ceci étant, la vraie question c'est : pourquoi il n'y a pas de synchro entre les différents systèmes!?
Si le besoin que j'imagine est que l'utilisateur doit pouvoir se connecter avec le même login/password sur toutes les applications et si il existe au moins 1 application parmi elles qui permet de changer soit le username, soit le password, alors il faut nécessairement gérer la propagation de ces changements à travers les autres applications (voir mon post précédent).

Si ce que tu appelles l'administrateur n'avait pas seulement changé la casse du login, mais s'il avait changé tout le login que se serait-il passé!?

C'est un débat sans fin mais est-ce que les administrateurs ont l'habitude de changer la casse de leur login et pour quelle raison ?

Qu'appelles-tu administrateur?
- l'administrateur au sens fonctionnel de l'applicatif (qui a donc les droits que les concepteurs de l'application ont bien voulu donner à ce profil. Donc s'ils ont prévu que l'administrateur puisse changer le login et qu'il a effectivement "usé" de ce droit, alors il faut se plaindre au concepteur de cette application qui n'ont pas respecté les contraintes fonctionnelles externes)
- Ou le DBA (administrateur de la base de données), qui a tous les droits sur la base de données MAIS qui ne devrait en AUCUN cas toucher les informations stockés dans ces bases de données

[montesq]

je considère que changer la casse du login c'est changer son login

C'est un point de vue ... d'informaticien! En effet dans la réalité tu as tout à fait raison : aaa12345!=AAA2345.
Je me répète, mais si le login est sensible à la casse, cela signifie que potentiellement les utilisateurs Paul.Durant et paul.durant sont 2 utilisateurs différents. Est-ce vraiment cela qui est souhaité?
De plus, si l'utilisateur n'arrive pas à se connecter, il doit appeler le support. En tant que DSI serais-tu satisfait que ton support passe même un temps infime à répondre à des utilisateurs qui se sont trompés de casse sur leur login? (ils ont déjà à mon avis fort à faire avec les passwords oubliés pour ne pas en rajouter une couche)

Ce qui au regard de l'environnement (nbre de fois où est utilisé le login dans les applications) peut avoir des conséquences catastrophiques ...

L'administrateur a peut-être outre-passé ses prérogatives , mais in fine cet épisode met surtout en exergue que l'architecture de votre SI n'a pas été conçue suivant les bonnes pratiques qui permettent de gérer sans problème le changement de login d'un utilisateur.

[Richard_35]

J'ai trouvé un fil sur GNT, par hasard.

Bon, c'est vrai, la solution n'y est pas... mais, avec un peu de recherche, je pense qu'elle est "trouvable".

Donc, comme dit précédemment, la solution serait de stocker l'ID Windows, et non le login. L'ID ne peut pas être modifié, c'est un ID interne généré par Windows : il existe, c'est sûr, sinon, la modification d'un login ne serait pas si aisée (cet ID doit être stocké pour la gestion des groupes, de la sécurité des dossiers, etc...).

D'ailleurs, il me semble qu'on le voit apparaître subrepticement, quand les temps de réponse sont longs... du style {1245-1264-OIOI-545}...

Le forum Système/Windows, pourrait t'être d'un grand secours.

[sat_ourne]

Je ne comprends pas "il y a une contrainte d'intégrité qui n'est bien sûr pas programmée dans les n applications".
Ceci étant, la vraie question c'est : pourquoi il n'y a pas de synchro entre les différents systèmes!?

La réponse est simple : un login ne doit pas changer, il est associé à une personne unique et est désactivé si celle-ci quitte l'entreprise. Le login n'est jamais supprimé et est réactivé si la personne revient.

Si le besoin que j'imagine est que l'utilisateur doit pouvoir se connecter avec le même login/password sur toutes les applications et si il existe au moins 1 application parmi elles qui permet de changer soit le username, soit le password, alors il faut nécessairement gérer la propagation de ces changements à travers les autres applications (voir mon post précédent).

Cette affirmation paraît extrêmement subjective : en gros si quelqu'un change la casse (je parle du changement de casse) dans l'annuaire, il embête toutes les applications de l'entreprise qui utilise la valeur du login ...

Si ce que tu appelles l'administrateur n'avait pas seulement changé la casse du login, mais s'il avait changé tout le login que se serait-il passé!?

Alors justement je ne dirais rien, et je changerai le login dans les applications filles ce qui paraît logique. Il faut comprendre que cela n'arrive que lorsqu'une personne change d'entité ou de filiales, et que par conséquent il n'est plus important qu'elle accède aux données qu'elle pouvait lire précédemment (vérifié dans plusieurs entreprises).

Qu'appelles-tu administrateur?

C'est un abus de langage, disons la personne qui a pris la décision (s'en en informer personne) de changer la casse du login(je ne parle que de changement de casse du login) dans l'annuaire/Active Directory ...

- l'administrateur au sens fonctionnel de l'applicatif (qui a donc les droits que les concepteurs de l'application ont bien voulu donner à ce profil. Donc s'ils ont prévu que l'administrateur puisse changer le login et qu'il a effectivement "usé" de ce droit, alors il faut se plaindre au concepteur de cette application qui n'ont pas respecté les contraintes fonctionnelles externes)
- Ou le DBA (administrateur de la base de données), qui a tous les droits sur la base de données MAIS qui ne devrait en AUCUN cas toucher les informations stockés dans ces bases de données

[/quote]
On parle de l'active directory = l'annuaire de l'entreprise qui gère la sécurité de Windows. On ne parle pas d'une "application".

Ce qui m'a amené à créer ce sujet c'est le commentaire d'une personne(qui n'est pas forcément celle qui a fait la modification) coté "administration & support technique des postes windows" : pour elle, à partir du moment ou windows n'est pas sensible à la casse, alors il n'y a pas de raisons qui empêcherait de modifier la casse du login à tout môment ...

La raison, je ne la connais pas mais quand on prend un recul sur l'architecture mise en place on se rend bien compte qu'une modification qui paraît minime (a --> A) impacte un grand nombre de sous-systèmes.

Je ne crois pas que si j'étais administrateur windows, je m'amuserai à changer ce genre de données sans en informer tout le monde. Sinon tout est possible: je mets les noms de famille en majuscule, je change l'extension de l'adresse e-mail, etc ... et dans ce cas, devrait-on rendre insensible ses applications à l'ensemble des changements imaginables ?

Je ne cherche pas un coupable , la question que je me posais était : est-ce qu'il faut systématiquement anticiper et traiter ce genre de problème à la conception ?

Je ne le pense pas mais pour vous confirmer l'ampleur du problème dans ce cas : cela ne concerne pas qu'une seule personne

Rien n'est impossible mais voici une décision qui peut coûter cher et qui aurait mérité que l'on se pose la question.

[montesq]

La réponse est simple : un login ne doit pas changer, il est associé à une personne unique et est désactivé si celle-ci quitte l'entreprise. Le login n'est jamais supprimé et est réactivé si la personne revient.

Quand le compte est désactivé dans l'AD, les applications "filles" doivent bien à un moment ou à un autre se synchroniser pour savoir que le compte ne peut plus accéder à l'application? Comment cela se passe-t'il?

Cette affirmation paraît extrêmement subjective : en gros si quelqu'un change la casse (je parle du changement de casse) dans l'annuaire, il embête toutes les applications de l'entreprise qui utilise la valeur du login ...

Depuis le début de ce fil nous t'expliquons qu'utiliser le login comme clé étrangère dans les applications filles est une énorme erreur de conception dans la mesure où ce login est modifiable dans l'AD. Alors soit tu empêches quiconque de modifier le login dans l'AD (je ne suis pas sûr que ça soit possible) ou soit tu changes la conception des applications filles pour utiliser une clé technique non modifiable. Tant que tu n'auras pas fait l'un ou l'autre tu seras toujours potentiellement victime d'une erreur d'inattention ou d'un boulet qui veut faire *** son monde.

On parle de l'active directory = l'annuaire de l'entreprise qui gère la sécurité de Windows. On ne parle pas d'une "application".

Ah bon? Pourquoi cela ne peut-il pas être considéré comme une application? Pour moi, c'est une application qui permet de stocker les informations sur les employés de l'entreprise...
Ce que je veux dire encore une fois, c'est que tant que l'IHM laisse le droit à l'utilisateur de faire cette modification, il y aura toujours quelqu'un pour faire cette modification de son plein gré ou par erreur! De plus, en toute honnêteté si je travaillais dans ta boîte, avec les informations que tu as donné, j'aurais pensé qu'un changement au niveau du login AD se serait propagé aux applications filles!

Rien n'est impossible mais voici une décision qui peut coûter cher et qui aurait mérité que l'on se pose la question.

Effectivement, tu peux voir qu'une petite faute de conception peut mener à de gros problèmes d'exploitation... Et c'est là où l'expérience de l'architecte prend tout son sens car tant qu'on n'a pas a minima réfléchi, voire rencontré ce genre de problème, il y a peu de chance qu'on pense à ce genre de subtilité.

[sat_ourne]

Effectivement, tu peux voir qu'une petite faute de conception peut mener à de gros problèmes d'exploitation... Et c'est là où l'expérience de l'architecte prend tout son sens car tant qu'on n'a pas a minima réfléchi, voire rencontré ce genre de problème, il y a peu de chance qu'on pense à ce genre de subtilité.

Vous faites quoi comme métier pour donner de telles leçons ?

Je ne pense pas que vous connaissiez beaucoup de développeurs car je ne pense pas qu'il y ait beaucoup de développeurs qui gèrent ce genre de cas à la conception (que il y a un petit génie qui change la casse du login utilisateur pour faire plus "joli-joli"), d'ailleurs c'était le sujet de la discussion...

Pour ma part, le débat est clos, j'attends la réponse d'autres développeurs et je vous souhaite bon courage avec vos changements d'attributs tous les jours ...

[montesq]

Je ne pense pas que vous connaissiez beaucoup de développeurs car je ne pense pas qu'il y ait beaucoup de développeurs qui gèrent ce genre de cas à la conception (que il y a un petit génie qui change la casse du login utilisateur pour faire plus "joli-joli"), d'ailleurs c'était le sujet de la discussion...

1° Ta question initiale, j'y ai répondu dans mon premier post. Qu'est-ce qui ne te satisfait pas dans cette réponse? Comme tes collègues l'ont fait remarquer, Windows est insensible à la casse sur le login, les applications google aussi (gmail...). Je n'ai pas fait le tour des forums sur lesquels j'ai un compte, mais ceux que j'ai testés sont insensibles à la casse. Qu'attends-tu d'autre?

2° D'autre part tu t'entêtes à ne pas écouter ce que l'on te dit. Tu te bornes à ton problème de casse alors que Richard_35 et moi-même nous t'expliquons que le problème est plus général et vient de votre stratégie d'intégration des applications "filles" avec le AD qui utilisent le login comme clé étrangère alors qu'il aurait fallu utiliser un identifiant technique non modifiable comme clé.

En attendant la réponse d'autres intervenants, n'hésite pas à relire ce fil.
Concernant ta dernière question, je ne sais pas ce que cette remarque sous-entend, mais si ça peut t'aider j'ai fait du développement et je travaille aujourd'hui en tant que chef de projet avec une équipe de dév sur des applications qui justement s'intègrent avec d'autres systèmes dont un LDAP... Inutile donc de préciser que ce genre de questions nous nous les posons pour chaque projet.

[sat_ourne]

1° Ta question initiale, j'y ai répondu dans mon premier post.

Soit et donc merci de votre point de vue.

[Richard_35]

Bonjour Sat_ourne et Montesq,

Je sais, j'insiste un peu... et, peut-être est-ce une mauvaise idée.

En tout état de cause, tes recherches et réponses pourraient, sans doute, servir à d'autres forumeurs.

Donc, comme dit précédemment, la solution serait de stocker, dans les applications filles, l'ID Windows (valeur système qui est cachée), et non le login. L'ID ne peut pas être modifié, c'est un ID interne généré par Windows : il existe, c'est sûr, sinon, la modification d'un login ne serait pas si aisée (cet ID doit être stocké pour la gestion des groupes, de la sécurité des dossiers, etc...).

Le forum Système/Windows, pourrait t'être d'un grand secours. A mon avis, une API pourrait retrouver ces ID non-modifiables.

[sat_ourne]

Je sais, j'insiste un peu... et, peut-être est-ce une mauvaise idée.

En tout état de cause, tes recherches et réponses pourraient, sans doute, servir à d'autres forumeurs.

Soit, allons tous au bout de notre mauvaise foi, que le meilleur en ressorte

Donc, comme dit précédemment, la solution serait de stocker, dans les applications filles, l'ID Windows (valeur système qui est cachée), et non le login. L'ID ne peut pas être modifié, c'est un ID interne généré par Windows : il existe, c'est sûr, sinon, la modification d'un login ne serait pas si aisée (cet ID doit être stocké pour la gestion des groupes, de la sécurité des dossiers, etc...).

Est-ce que cet ID persiste lorsque l'on change le domaine par exemple ?

Cela n'empêchera jamais mon Génie (d'aministrateur Windows) de supprimer mon Login pour le recréer car il a de mauvaise méthodes de travail (je pense que c'est un point clé de ce genre d'affaire) ?

Le forum Système/Windows, pourrait t'être d'un grand secours. A mon avis, une API pourrait retrouver ces ID non-modifiables.

je suis le super architecte(ou urbaniste) de montesq et j'ai décidé que mes serveurs passaient de Windows à Unix tout en gardant les mêmes logins(j'avais bien pris soin de spécifier à mes administrateurs de saisir tout les logins en minuscules) car je ne veux pas embêter mes utilisateurs ?
Cet ID interne est-il propre à Windows(donc à l'OS) ?
ou à l'annuaire LDAP, et par conséquence n'a pas forcèment la même allure selon l'environnement ?



Au final, on voit bien que le plus simple c'est de dire aux administrateurs de suivre des régles spécifiées:
-mon id est constitué comme ceci : ID pays (3 caractères)+N° incrémenté d'employé dans le service sur 6 chiffres... ex: fra000720
-mon id respecte la casse, tout en minuscule (car je sais que c'est le cas sous Unix donc je préserve un maximum de compatibilités possibles)
-...