Novell a commencé avec Netware avec une base de données utilisateur appelée Bindery. Le mot de passe, à l'époque comme aujourd'hui, était basé sur des paires de clés privées/publiques RSA.
Avec NDS dans Netware 4.0, ils ont conservé la même méthode de mot de passe de base, et elle est raisonnablement sûre.
Avec eDirectory (nom sous lequel NDS a été renommé, vers la version 8.x d'eDirectory, qui correspondait à l'époque de Netware 6.x), ils devaient prendre en charge les mots de passe réversibles, ce qu'une paire de clés RSA n'est absolument pas.
Ils en avaient besoin pour la prise en charge de NFS, SMB et AFP. Parce que SMB utilise le hachage MD4 ou MD5, NFS utilise MD5 ou MD4 (je n'arrive jamais à faire la part des choses entre les deux et cela n'a pas d'importance non plus). Les Mac's utilisent un nombre aléatoire à deux voies pour l'authentification, et requièrent un mot de passe en clair pour la comparaison.
La première tentative était un produit appelé Simple Password, qui était un bon premier essai, mais qui ne résolvait pas tous les problèmes.
La deuxième tentative est le mot de passe universel qui semble avoir bien fonctionné. UP est stocké dans un attribut caché (il est protégé de la même manière que la clé privée est protégée dans eDir et il est assez difficile d'y avoir accès).
Là où vous vous trompez, c'est que l'UP n'est PAS mise en œuvre via une méthode de connexion ou autre, elle est intégrée à eDirectory dans le cadre de la fonctionnalité de mot de passe de base, tout comme les paires de clés RSA ne sont pas une méthode de connexion mais sont intégrées.
Il existait une méthode de connexion par mot de passe amélioré avant l'arrivée de Simple/UP pour essayer de mettre en œuvre certaines des fonctionnalités nécessaires, mais ce n'était pas non plus la meilleure approche.
Quoi qu'il en soit, pour activer le mot de passe universel (non activé par défaut), vous devez créer une politique de mot de passe (en utilisant iManager comme TheDave1022 le note), et l'attribuer.
Il y a quelques subtilités dans la façon dont il hérite. Vous pouvez affecter une politique à l'objet Politique de connexion dans le conteneur Sécurité (à la racine de l'arbre) et cela s'applique à chaque objet avec un mot de passe dans l'arbre. C'est simple et facile.
Vous pouvez l'appliquer à la plupart des objets conteneurs (pas les objets Pays si je me souviens bien, mais je pense savoir comment contourner ce problème maintenant. O, OU, les types les plus courants fonctionnent parfaitement) et il s'appliquera à tous les enfants directs.
Pour qu'il puisse hériter de plus d'un niveau, le OU/O doit être une limite de partition eDirectory.
Le niveau d'affectation le plus bas prévaut sur toutes les affectations supérieures. Ainsi, attribuez le niveau le plus strict à l'objet Login Policy.Security pour toute l'arborescence, puis une politique plus raisonnable pour les personnes que vous aimez dans le conteneur Friends.users.acme pour leur faciliter la vie.
Ensuite, vous avez le bozo qui fait de votre vie un enfer dans la comptabilité, alors attribuez une nouvelle politique à Bozo.Accounting.people.acme et faites-lui exiger un mot de passe de 92 caractères, avec 6 caractères non-ASCII.
Ou n'importe quoi d'autre.
Une fois que vous l'avez activé, tout changement de mot de passe effectué par le biais d'un client NMAS activera UP (et Simple, et NDS, si votre politique dit de se synchroniser à tous ces mots de passe. Des options faciles à modifier selon les besoins).
Un client compatible NMAS est un utilisateur avec le client 32 avec le NMAS (Novell Modular Authentication Services, qui fait partie par défaut de l'installation du client, sauf si vous avez spécifiquement choisi de ne pas le faire), iManager, toutes les applications LDAP qui effectuent des changements de mot de passe puisque le service LDAP de Novell est compatible NMAS. Les clients CIFS/AFP contre le service CIFS/AFP d'OES (Netware ou noyau Linux). (OES 1 utilisait Samba, qui, je pense, n'était PAS compatible NMAS, mais OES2 utilise un port du service CIFS de Netware, qui est plus évolutif que Samba).
Ainsi, le seul cas d'un client non compatible NMAS est le client 32 sur lequel vous n'avez pas installé NMAS.
Il existe un autre cas d'erreur connu, qui correspond à une installation plus ancienne de ConsoleOne, où il existe un fichier NMAS.DLL dans la structure du répertoire C1. Il s'agit d'un vestige qui doit être supprimé.
Une option dans la politique de mot de passe est "Autoriser l'administrateur à récupérer les mots de passe" et ensuite spécifier un utilisateur spécifique qui est autorisé. Vous pouvez ensuite utiliser l'excellent outil de Jim Willeke, intitulé Outil de diagnostic du mot de passe universel qui vous montrera quel est le mot de passe défini (si la politique l'autorise), s'il correspond au mot de passe NDS, au mot de passe simple et à de nombreux autres éléments de diagnostic. Difficile de travailler sans lui !
