Discussion :

[Richard_35]

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

==> je ne comprends pas trop .
Loin de moi, l'idée d'une quelconque mauvaise foi. Si c'est impression donnée, alors j'en suis désolé, vraiment.
Le but est de t'aider et, éventuellement, de faire bénéficier nos forumeurs des solutions (à prendre ou à éviter).
Dans cet optique, si j'insiste, c'est que je pense que la solution que je te propose pourrait solutionner ton souci. Mais je peux me tromper et, si c'est le cas, j'en suis (encore) désolé. Mais la production d'arguments me semble riche, en tout état de cause.

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

==> c'est l'ID de l'Active Directory. Il est donc unique et non modifiable pour l'Active Directory courant. Une API doit pouvoir retrouver ces ID non-modifiables.
Je ne suis pas spécialiste mais, comme je te le disais, le forum Système/Windows, pourrait t'être d'un grand secours (à mon avis, une API pourrait retrouver ces ID non-modifiables).

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) ?

==> c'est tout à fait vrai. Et, dans ce cas, il n'y a pas de solution.
C'est comparable, par exemple, à la création d'un client qui existe déjà... malgré tous les contrôles, un doublon peut-toujours arriver.

Cet ID interne est-il propre à Windows(donc à l'OS) ?

==> je pense, oui, mais je ne suis pas un spécialiste.

ou à l'annuaire LDAP, et par conséquence n'a pas forcèment la même allure selon l'environnement ?

==> je ne peut pas répondre. Ce sont des questions à poser (ou à rechercher) aux spécialistes via le forum adéquat.

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)
-...

==> oui, si c'est respecté. Avec l'expérience, on sait bien que les directives procédurales peuvent ne pas être suivies (changement de personnel, vacances, etc...). Si le contrôle peut-être effectué par la machine, c'est plus efficace.

[sat_ourne]

==> je ne comprends pas trop .
Loin de moi, l'idée d'une quelconque mauvaise foi. Si c'est impression donnée, alors j'en suis désolé, vraiment.

C'était de l'humour, c'était pour dire que tout les points de vue sont respectables, mais que l'on trouvera toujours un argument pour ne pas céder.

A vrai dire, je ne suis pas certains que tous les logiciels commerciaux anticipent ce genre de problème de casse sur le login.

Et par ailleurs, je pense que le secteur informatique se doit d'être exigeant (linux en est un très bel exemple) et dans ce sens, que les applications soient sensibles à la casse(cela dépend du contexte), tout comme le langage de programmation est une très bonne chose, surtout en ce qui concerne un élément de sécurité.
Même si rendre accessible et facile l'informatique à tout le monde est une intention très louable.

Quand à savoir si a est identique à A, peut-être un dictionnaire nous aidrerait-il à le savoir ?

[Richard_35]

A vrai dire, je ne suis pas certains que tous les logiciels commerciaux anticipent ce genre de problème de casse sur le login .../...
Quand à savoir si a est identique à A, peut-être un dictionnaire nous aidrerait-il à le savoir ?

==> pour s'affranchir de cette problématique, il faut trouver une information non modifiable : l'ID caché généré par Windows me paraît être la solution .
Je sais, j'insiste... mais comme tu n'en parles pas dans ton dernier post...

Je crois que nous avons fait le tour de la problématique "casse", du moins en ce qui concerne mes arguments. Reste cette l'alternative "ID système"... à argumenter, me semble-t-il.

A noter que, sous Linux, je pense que c'est la même chose (mais je peux me tromper) : si le login est modifiable (changement de nom, ou autre), un ID caché généré par Linux devrait exister. C'est celui-ci que Linux devrait utiliser pour toutes les applications "système" internes.

[sat_ourne]

==> pour s'affranchir de cette problématique, il faut trouver une information non modifiable : l'ID caché généré par Windows me paraît être la solution .
Je sais, j'insiste... mais comme tu n'en parles pas dans ton dernier post...
...

• 1. Peut-être bien que oui, peut-être bien que non ...

Effectivement, l'ID caché généré par Windows est une solution à envisager sous Windows mais encore faudrait-il être sûr de la manière dont-il fonctionne (AD Windows expert needed).
Après validation, cela ne s'appliquerait que pour les nouvelles applications et sur le système concerné ...
Il est possible que dans certaines entreprises, le même login ID soit utilisé sous plusieurs environnements :
windows, linux, authentifications propriétaires (Oracle, Lotus Notes ...), champs de bases de données, applications propriétaires ... et dans ce cas qu'en est-il de la transmission de la valeur "ID caché généré par Windows" (API disponibles en VB, en java ...)?

• 2. Agence tout rique

Reste à gérer le problème du cas où l'on ne sait pas quels sont les impacts sur les applications existantes et qui stockent le Login ID... Dans ce cas est-il utile de rappeler de faire preuve de la plus grande prudence, d'un point de vue utilisation des outils et non pas conception cette fois-ci ? Ce qui mériterait de faire passer ce sujet dans la rubrique : conduite du changement.

• 3. Si j'avais su ...

Quand à l'argument : si il est possible de le faire alors on doit anticiper dans notre conception toutes les conséquences possibles ... ? Je préfère en rire.
Savez-vous que j'ai un lien vers un répertoire partagé, et que si je supprime ses fichiers je ne peux pas les retrouver dans la corbeille ? Une erreur que l'on ne peut faire qu'une fois.


On en revient à ma conclusion: il n'est pas utile de concevoir son programme avec ce genre de considération car les implications du changement de casse du login(je rappelle que aaa12345 est différent de AAA12345) peuvent-être conséquentes ... A moins que cela soit une norme spécifiée dans la charte de développement de l'entreprise ou des applications Windows(dans mon cas, c'est web) et en espérant que celle-ci existe ?


Enfin, j'aimerai que d'autres contributeurs nous donnent leurs vécus sur le problème de la casse du login(cela laisse un large choix de systèmes et langages) et si cela a été pris en compte à la conception.

Merci.

PS: ne vous faîtes aucunes illusions, ils finiront bien par nous faire changer nos applications au lieu de changer leurs méthodes de travail ...

[Richard_35]

.../... AD Windows expert needed .../...

==> nous sommes d'accord (documentations, Google, FAQ, forum, etc...). Et j'ajouterais Linux et autres.

Quand à l'argument : si il est possible de le faire alors on doit anticiper dans notre conception toutes les conséquences possibles ... ? Je préfère en rire.
Savez-vous que j'ai un lien vers un répertoire partagé, et que si je supprime ses fichiers je ne peux pas les retrouver dans la corbeille ? Une erreur que l'on ne peut faire qu'une fois.

==> ce n'est pas parce que ce cas est défaillant qu'il faut propager la défaillance sur d'autre système. Attention, je ne dis pas que c'est le cas, en l’occurrence.


Pour ma part, compte tenu de mes connaissances, je considère avoir fait le tour de la solution "ID système caché".

J'espère que tu trouveras une solution satisfaisante.
Bonne continuation.

[sat_ourne]

Pour ma part, compte tenu de mes connaissances, je considère avoir fait le tour de la solution "ID système caché".

J'espère que tu trouveras une solution satisfaisante.

Bjr Richard,

Pour information, dans mon cas, il s'est avéré que les personnes avaient non seulement changées de casse, mais que de plus elles avaient changé de domaine. A cette occasion, les comptes auraient été détruits puis recréés.

Je n'ai pas vérifié si l'ID système avait changé, car je n'en avait pas le besoin.

Si quelqu'un peut répondre à cette question :
"ID système caché" de windows(SID "Security Identifier") change-t-il lors d'une destruction/recréation de compte ?

Merci.

[Richard_35]

Bonjour Sat_ourne,

"ID système caché" de windows(SID "Security Identifier") change-t-il lors d'une destruction/recréation de compte ?

==> j'en suis, à 99%, persuadé : il s'agit d'une suppression... puis (peut-être, 15 jours après), d'une création. De ce fait, Windows devrait prendre le prochain SID disponible (une sorte de numéro automatique dans les tables internes de Windows).

D'autre part, quels seraient les éléments de comparaison que posséderait Windows pour décider qu'une création de compte est afférente à telle ou telle suppression précédente d'un compte ?...

Mais bon, je ne suis pas un spécialiste : le forum Windows et ses sous-forums seraient plus adéquat pour poser ta question.