Ou: "Est-ce une chose? Et comment pourrais-je vérifier si c'était le cas?"

Dans un environnement sans contrôleur de domaine , lorsque j'accède à un partage sur une boîte Windows Server 2008 R2, à partir d'un ordinateur distant sans compte d'utilisateur correspondant sur le serveur (et en \\SERVERNAME\ShareNameme connectant en tapant dans le menu Démarrer), j'observe actuellement le comportement suivant en fonction sur le paramètre "Partage protégé par mot de passe" (Paramètres de partage avancés):

Lorsque « Mot de passe partage protégé » est activée sur , toutes les tentatives de connexion échouent après 30 secondes avec:

Échec de la connexion: l'utilisateur n'a pas obtenu le type de connexion demandé sur cet ordinateur.

Lorsque le «partage protégé par mot de passe» est désactivé , les connexions aux partages accessibles de manière anonyme sont autorisées, tandis que les partages à autorisation restreinte échouent avec:

Vous n'êtes pas autorisé à accéder à \ SERVERNAME \ ShareName. Contactez votre administrateur réseau pour demander l'accès.

Cela semble être un comportement attendu. Je dois avoir certains partages accessibles par des connexions anonymes, j'ai donc dû changer ce paramètre de la valeur par défaut à off .

CEPENDANT, il y a un troisième cas ici. ( whaaaaat? )

Si vous essayez de vous connecter à un partage sans avoir modifié ce paramètre (qui est, il est réglé sur le mais vous n'avez jamais cliqué dessus), la connexion se comporte comme l' au cas ci - dessus en ce qu'elle peut prendre jusqu'à 30 secondes pour signaler une réponse, mais ensuite il affiche une boîte de dialogue d'authentification :

J'ai eu cette intuition après m'avoir frappé la tête contre un mur pendant quelques jours, et je l'ai simplement répliqué sur un serveur sans partage existant: créez un partage non lu, essayez de vous connecter et d'obtenir une boîte de dialogue, modifiez le paramètre, connectez-vous avec succès, changez le paramètre retour , et obtenez un message d'erreur différent. (Testé tout cela sur de nouveaux systèmes clients, il n'y avait donc aucun risque de mise en cache.)

Pour réitérer: j'ai contrôlé pour les systèmes clients. Cela semble être entièrement lié au serveur.

Donc, il est clair pour moi que changer le paramètre "Partage protégé par mot de passe" change plus d'une chose (clé de registre? Je suis natif de Mac) dans les coulisses, et que les paramètres par défaut fournis avec le système ne correspondent pas tous avec le paramètre reflété dans le panneau de contrôle (ou le panneau de contrôle lui-même est cassé et devrait changer plus de choses).

La question est donc: est-ce par conception, ou est-ce un bug? Et dans les deux cas, quel est le «paramètre caché» qui est modifié ou laissé inchangé? Comment pourrait-on retrouver cela? Je manque de nouveaux serveurs pour tester. :-(

Cela a vraiment piqué mon intérêt. J'ai pu reproduire vos résultats dans mon laboratoire avec le même schéma de résultats que vous décrivez. J'ai utilisé Procmon pour essayer de voir quelles modifications sont apportées et j'ai presque abandonné jusqu'à ce que je vois ce qui suit:

Cela montre que lsass.exe (Local Security Authority) écrit dans le SAM local et apporte une ou des modifications au compte invité intégré (RID 501 bien connu). Effectivement, lorsque j'ai retesté votre scénario en regardant l'état du compte Invité, je le vois activé lorsque le "Partage protégé par mot de passe" est désactivé. Cependant, lorsque le «partage protégé par mot de passe» est réactivé, le compte invité n'est pas désactivé à nouveau. Désactiver manuellement le compte invité restaure la fonctionnalité d'origine: je suis invité à fournir des informations d'identification (c'est-à-dire votre troisième cas).

Je ne sais pas pourquoi cela se comporte comme ça. Pour être honnête, je n'avais jamais basculé le paramètre "Partage protégé par mot de passe" avant aujourd'hui (ni même remarqué d'ailleurs). J'espère que cela vous aidera dans votre projet. Si quelqu'un d'autre est intéressé à creuser davantage, il serait intéressant de savoir si ce comportement est toujours présent sur Server 2012/2012 R2 ...

Oh et à vos questions originales (est-ce par conception ou est-ce un bug?), Je n'ai pas la moindre idée ...

Si j'ai bien compris votre question, les informations d'identification des partages sont enregistrées dans le gestionnaire d'informations d'identification sous le panneau de configuration.

Afin d'inviter la boîte de dialogue d'authentification, supprimez simplement les informations d'identification relatives à ce partage sous le gestionnaire d'informations d'identification.

Lorsque vous cochez la case «Se souvenir de mes informations d'identification», cela est généralement enregistré sous le gestionnaire d'informations d'identification et si ce mot de passe était incorrect, vous verrez l'erreur d'échec de connexion.

Cela pourrait ne pas vous aider, mais au cas où cela arriverait - j'ai souvent des appels que mes utilisateurs ne peuvent pas accéder à un partage (leur ancien mot de passe est mis en cache par Windows) et je leur demande de faire ceci:

utilisation nette * / D