Wie habe ich diese Windows-Freigabe dazu gebracht, zur Anmeldung aufzufordern?


14

Oder: "Ist das ein Ding? Und wie würde ich prüfen, ob es eines ist?"

In einer Umgebung ohne Domänencontroller beobachte ich beim Zugriff auf eine Freigabe auf einem Windows Server 2008 R2- Computer von einem Remotecomputer ohne ein entsprechendes Benutzerkonto auf dem Server (und beim Herstellen einer Verbindung über \\SERVERNAME\ShareNamedas Startmenü) derzeit das folgende Verhalten in der Einstellung "Kennwortgeschützte Freigabe" (Erweiterte Freigabeeinstellungen):

Wenn „Kennwortgeschütztes Freigeben“ eingeschaltet ist auf alle Verbindungsversuche fehlschlagen , nachdem bis zu 30 Sekunden mit:

Anmeldefehler: Dem Benutzer wurde auf diesem Computer der angeforderte Anmeldetyp nicht gewährt.

Wenn "Kennwortgeschütztes Teilen" deaktiviert ist , sind Verbindungen zu Freigaben mit anonymem Zugriff zulässig, während Freigaben mit eingeschränkten Berechtigungen fehlschlagen mit:

Sie haben keine Berechtigung, auf \ SERVERNAME \ Freigabename zuzugreifen. Wenden Sie sich an Ihren Netzwerkadministrator, um Zugriff anzufordern.

Dies scheint erwartetes Verhalten zu sein. Ich muss bestimmte Freigaben für anonyme Anmeldungen verfügbar haben, daher musste ich diese Einstellung von der Standardeinstellung in " Aus" ändern .

Es gibt jedoch einen dritten Fall. ( Wie bitte? )

Wenn Sie versuchen , auf eine Freigabe zu verbinden , ohne diese Einstellung geändert haben (das heißt, wird es auf auf , aber sie haben es nie angeklickt), verhält sich die Verbindung ähnlich der auf Fall oben, dass es bis zu 30 Sekunden in Anspruch nimmt Show Eine Antwort, aber dann wird ein Authentifizierungsdialog angezeigt :

Dialogfeld "Authentifizierung freigeben"

Ich hatte diese Vermutung, nachdem ich ein paar Tage mit dem Kopf gegen eine Wand geklopft und dies einfach auf einem Server ohne vorhandene Freigaben repliziert hatte: Eine nicht gelesene Freigabe erstellen, versuchen, eine Verbindung herzustellen und einen Dialog zu erhalten, die Einstellung zu ändern, die Verbindung erfolgreich herzustellen, die Einstellung zu ändern zurück und erhalten eine andere Fehlermeldung. (Getestet alle diese auf frischen Client-Systemen, so gab es kein Caching-Risiko.)

Um es noch einmal zu wiederholen: Ich habe für die Client-Systeme kontrolliert. Dies scheint vollständig serverbezogen zu sein.

Mir ist also klar, dass das Ändern der Einstellung "Kennwortgeschütztes Teilen" im Hintergrund mehr als eine Änderung bewirkt (Registrierungsschlüssel? Ich bin Mac-native) und dass die Standardeinstellungen, mit denen das System geliefert wird, NICHT alle übereinstimmen mit der Einstellung im Bedienfeld (oder das Bedienfeld selbst ist kaputt und sollte mehr Dinge ändern).

Die Frage ist also: Ist das beabsichtigt oder ist es ein Fehler? Und in jedem Fall, was ist die "versteckte Einstellung", die geändert oder unverändert gelassen wird? Wie würde man das aufspüren? Mir gehen die neuen Server aus, auf denen ich testen kann. :-(


Wie lautet die Zugriffssteuerungsliste für den Ordner und wie lautet die Berechtigung für die Freigabe?
AWippler

Sie können ein Projekt mit dem Namen regshot verwenden , um zwei Momentaufnahmen der Registrierung zu vergleichen (eine beim Initialisieren des Systems, eine nach dem Festlegen der Einstellung und eine dritte nach dem Deaktivieren der Einstellung). Sehen Sie sich auch die Einstellungen für "Lokale Domäne / Sicherheitsrichtlinie" an und aktivieren Sie die Einstellung "Auf diesen Computer über das Netzwerk zugreifen " (auch bekannt als " SeNetworkLogonRight" ). Hier einige Informationen zu Änderungen und hier einige Informationen zu Einstellungen .
mbrownnyc

@NReilingh: Du hast das Kopfgeld gepostet, konntest du es jemals herausfinden?
charleswj81

@ charleswj81 Deine Antwort war genau das, wonach ich gesucht habe! Musste nur die Zeit finden, mich damit zu setzen. Was ich jetzt bemerke, ist, dass die Gastkontenauflistungen in der Systemsteuerung Computerkonten verwalten und im Server-Manager hinsichtlich der Aktivierung oder Nichtaktivierung nicht immer synchron zu sein scheinen. Daher muss ich jetzt drei Variablen auf anonyme und kennwortgeschützte Verbindungen testen: "Kennwortgeschützte Freigabe" aktivieren oder deaktivieren, das Gastkonto im Server-Manager aktivieren oder deaktivieren und das Gastkonto in den Kontrollfeldern aktivieren oder deaktivieren.
NReilingh

Antworten:


11

Das hat mein Interesse geweckt. Ich konnte Ihre Ergebnisse in meinem Labor mit demselben Ergebnismuster wiederholen, das Sie beschrieben haben. Ich habe Procmon verwendet, um zu versuchen, festzustellen, welche Änderungen vorgenommen wurden, und hätte beinahe aufgegeben, bis ich Folgendes sah:

procmon guest account geändert

Das zeigt, wie lsass.exe (Local Security Authority) in das lokale SAM schreibt und Änderungen am integrierten Gastkonto (bekanntes RID 501) vornimmt. Wenn ich Ihr Szenario erneut getestet habe, während ich den Status des Gastkontos betrachte, sehe ich, dass es aktiviert ist, wenn "Kennwortgeschütztes Teilen" deaktiviert ist. Wenn jedoch "Kennwortgeschütztes Teilen" wieder aktiviert wird, wird das Gastkonto nicht wieder deaktiviert. Durch manuelles Deaktivieren des Gastkontos wird die ursprüngliche Funktionalität wiederhergestellt: Ich werde zur Eingabe von Anmeldeinformationen aufgefordert (dh Ihr dritter Fall).

Ich bin mir nicht sicher, warum sich das so verhält. Um ehrlich zu sein, habe ich die Einstellung "Passwortgeschütztes Teilen" noch nie zuvor umgeschaltet (oder es überhaupt bemerkt). Ich hoffe das hilft bei deinem Projekt. Wenn jemand anderes weiter graben möchte, wäre es interessant zu wissen, ob dieses Verhalten auf Server 2012/2012 R2 noch vorhanden ist ...

Oh und zu deinen ursprünglichen Fragen (Ist das beabsichtigt oder ist es ein Fehler?), Ich habe nicht die geringste Ahnung ...


Ich kann bestätigen, dass dies korrekt ist. Ich musste heute einen neuen W2K8-Server installieren und konnte diesen replizieren, bevor ich ihn der Domäne hinzufügte. Das Gastkonto muss manuell deaktiviert werden. Wenn dies getan wird, ist das Verhalten das, was ich für normal halte: Nach einer Zeitüberschreitung wird der Benutzer aufgefordert, die korrekten Anmeldeinformationen (aus der Sicht des Servers) einzugeben. (PS: Ich habe nie verstanden, warum dieses verdammte Timeout so lang ist. Es ist nicht so, dass die ursprünglichen Anmeldeinformationen während der Timeout-Zeit auf magische Weise gültig werden. Warum also warten?)
Tonny

2

Wenn ich Ihre Frage richtig verstanden habe, werden die Anmeldeinformationen der Freigaben im Anmeldeinformations-Manager in der Systemsteuerung gespeichert.

Um das Authentifizierungsdialogfeld aufzurufen, löschen Sie einfach den Berechtigungsnachweis für diese Freigabe im Berechtigungsnachweis-Manager.

Wenn Sie das Kontrollkästchen "Anmeldeinformationen speichern" aktivieren, wird dies normalerweise im Anmeldeinformations-Manager gespeichert. Wenn dieses Kennwort falsch ist, wird der Anmeldefehler angezeigt.


Nein so; Ich habe alle drei Fälle auf einem neuen Client-System ohne zwischengespeicherte Anmeldeinformationen getestet. (In diesem Fall hätte jeder von mir eingegebene Berechtigungsnachweis Zugriff gewährt.) Das einzige Mal, dass ich dieses Authentifizierungsdialogfeld jemals gesehen habe , war , dass die "kennwortgeschützte Freigabe" nicht berührt wurde.
NReilingh

Hatte das gegenteilige Problem (hier: serverfault.com/q/619027/175650 ), bei dem ich die Aufforderung erhielt, sie aber nicht wollte. Es stellte sich heraus, dass ich einen schlechten Berechtigungsnachweis gespeichert hatte, und Ihr Beitrag hat mich in die richtige Richtung gelenkt, um ihn zu löschen und mein Problem zu lösen. Vielen Dank!
SenorAmor

0

Könnte Ihnen nicht helfen, aber falls doch - Ich habe oft Anrufe, bei denen meine Benutzer nicht auf eine Freigabe zugreifen können (ihr altes Kennwort wird von Windows zwischengespeichert), und ich lasse sie dies tun:

Nettonutzung * / D


Wie ich in der Frage sagte, kontrollierte ich für den Kunden. Ich habe für jeden Test ein neues System verwendet, sodass keine Gefahr besteht, Anmeldeinformationen zwischenzuspeichern.
NReilingh
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.