Mar 04, 2020, updated at 11:03:55 (UTC)

8574

DFS - seltsames Verhalten bei einem Benutzer

Hi,
ich bräuchte bitte mal Denkansätze zu folgendem Problem.

Wir haben einen Benutzer, welcher ein Problem beim Zugriff auf einige "tiefer gelegene" Ordner innerhalb einer DFS-Struktur hat. Das Problem äußert sich in etwa so:

Benutzer greift mit dem Explorer auf DFS-Stamm zu
Benutzer hangelt sich in tiefere Ebenen
bei einigen, willkürlichen Unterordnern in der 2., 3. oder tieferen Ebene kommt dann plötzlich "Sie haben keinen Zugriff ..."
mit der CMD kommt er dann auch nicht auf diesen Ordner

Workaround

Eigenschaften des Ordner --> DFS --> aktives Ziel bestimmen
Benutzer öffnen den UNC-Pfad des Servers, welcher als aktives Ziel genannt wurde, und kann ohne jedes Problem auf diesen Ordner zugreifen

Der Benutzer hat dieses Problem im mehreren verschiedenen DFS-Stämmen.
Es betrifft sowohl Ordner mit mehreren Zielen, welche auch mit DFS-R repliziert werden, als auch Ordner mit nur genau einem Ziel, welche nicht repliziert werden.
Er hat dieses Problem sowohl bei direktem Zugriff von seinem Notebook (Win10) als auch beim Zugriff aus seiner TS-Sitzung (Win2016).

Wir haben das Benutzertoken überprüft und da sind alle erforderlichen Gruppenmitgliedschaften drin. Der Zugriff funktioniert ja auch, wenn man direkt über den Server-UNC geht, statt über den DFS-UNC.
Der Benutzer hat sich schon mehrmals angemeldet. Ordner, wo das Problem gestern noch bestand, kann er heute ohne Probleme über DFS öffnen. Heute sind es dafür andere.

Ich habe z.Z. keine Idee mehr, was das sein könnte.

E.

Edit: Er hat auch schon mehrmals ein neues, frisches Benutzerprofil für die TS-Anmeldung bekommen.

Please also mark the comments that contributed to the solution of the article

Content-Key: 554104

Url: https://administrator.de/contentid/554104

Printed on: April 26, 2024 at 14:04 o'clock

49 Comments

Latest comment

Serverbasierte Benutzerprofile?

Die DFS Server mal neugestartet?

Zitat von @falscher-sperrstatus:
Serverbasierte Benutzerprofile?

Nein, Domäne.

Die DFS Server mal neugestartet?

Es betrifft mehrere.

Habt ihr in der letzten Zeit einen Server entfernt der noch unter DFS Management -> Namespace drinnen steht?
Vergisst man gerne mal.

Wenn das Problem nur bei diesem Benutzer auftritt, dann könntet ihr zum Testen seinen Benutzer kopieren und damit testen.

LG
VorteX

Zitat von @emeriks:

Zitat von @falscher-sperrstatus:
Serverbasierte Benutzerprofile?

Nein, Domäne.

widerspricht sich nicht.

Die DFS Server mal neugestartet?

Es betrifft mehrere.

eher die Regel, daher alle neustarten.

Zitat von @falscher-sperrstatus:

Nein, Domäne.

widerspricht sich nicht.

Äh, sorry bitte. Lesen ist nicht so meine Stärke.

Ich hatte irgendwie nur das "serverbasiert" verarbeitet und dachte da an einem serverbasierten DFS-Stamm. Und meinte: Nein, wir haben nur domänenbasierte Stämme.

eher die Regel, daher alle neustarten.

Ich meinte, wir haben unabhängige Stämme, welche jeweils andere Server verwenden. Und dieser Effekt ist bei diesem Benutzer bei verschiedenen dieser Stämme aufgetreten. Es kann doch kaum sein, dass da jetzt mehrer Server, welche außer der Domäne nichts gemein haben, da jetzt plötzlich Probleme im DFS haben.

Zitat von @falscher-sperrstatus:
Serverbasierte Benutzerprofile?

Ja, auch. Aber nicht mit DFS-R repliziert.
Welche Relevanz soll das für eine laufende Benutzersitzung haben?

Was passiert denn wenn du den Domänenaccount des Betroffenen Users mal kopierst und mit dem kopierten Account versuchst den Fehler zu reproduzieren?

Du schreibst ja es tritt nur bei einem User auf, daher würde ich das Userobjekt und die Attribute mal prüfen.

Zitat von @TRDSRLZ:
Was passiert denn wenn du den Domänenaccount des Betroffenen Users mal kopierst und mit dem kopierten Account versuchst den Fehler zu reproduzieren?

Das ist unser aktueller Ansatz. Mit der Kopie oder gar einem vollkommen neuen Benutzer tritt das nicht auf.
Aber das kann doch keine Lösung sein. Was ist, wenn das ab morgen auch bei anderen Benutzern auftritt?

Ok. Und jetzt? Habt ihr mal in der erweiterten AD Ansicht die Attribute des alten Accounts mit denen des neuen verglichen? Ist der "alte" Account schon paar mal migriert worden? Stichwort Legacy-Account...

Offlinedateien auf dem Client sind deaktiviert?

Zitat von @TRDSRLZ:
Habt ihr mal in der erweiterten AD Ansicht die Attribute des alten Accounts mit denen des neuen verglichen?

Nichts auffälliges. Woran denkst Du?

Ist der "alte" Account schon paar mal migriert worden?

Dieser nicht. Warum?

Stichwort Legacy-Account...

Was soll das sein?

Ich weiss dass bei Exchangemigrationen alt Accounts nach der Migration oft mal Probleme haben sie Sicherheitseinstellungen richtig zu übernehmen. Da muss man dann die Vererbung einmal aktivieren dass der Account zum Beispiel wieder ActiveSync zulässt...

War auch nur ne Vermutung in deinem Zusammenhang, denn prinzipiell würde ich das Problem so erstmal am Account selbst vermuten und die Attribute prüfen.

Zitat von @TRDSRLZ:
Offlinedateien auf dem Client sind deaktiviert?

Ja, zumindest auf den TS.

Edit: Außerdem sind die betreffenden Freigaben (Stamm wie Blatt) nicht für Offlinefiles aktiviert.

Ok. Gut. Wäre nur ein zusätzlicher Ansatz gewesen, das zu prüfen, nicht dass er sich durch eine fehlerhafte Synchronisation die Dateien selbst sperrt.

Und mir ist klar, dass du was drauf hast, aber die Frage hätten wir viel früher stellen sollen, was sagen die Logfiles?

Zitat von @TRDSRLZ:
Und mir ist klar, dass du was drauf hast,

Oh Gott, wie kriege ich das bloß wieder ab?

aber die Frage hätten wir viel früher stellen sollen, was sagen die Logfiles?

Hätte ich erwähnen sollen: Leider gar nichts. Weder auf dem Client, noch auf dem Server mit dem DFS-Stamm, noch am Fileserver mit dem DFS-Ordner-Ziel.

Hast du mal das NTFS Auditing aktiviert und da rein geschaut?
Kommt evt. ABE in den Shares zum Einsatz?

Aber das gibts doch nicht. Wenn ein Zugriff auf den Server erfolgt wird das doch im erweiterten Log protokolliert.

Hast du das schon mal am Client versucht?

https://blog.feldmann.io/windows-server/windows-dfs-namespace-access-den ...

Zitat von @TRDSRLZ:
Aber das gibts doch nicht. Wenn ein Zugriff auf den Server erfolgt wird das doch im erweiterten Log protokolliert.

Wenn man das aktiviert, ja, na klar. Haben wir sogar aktiv. Aber außer dem fehlgeschlagenem Zugriff wird da nichts vermerkt. Kein Eintrag wie "He, ein seltsames DFS-Problem ist aufgetreten."

Das wäre doch viel zu einfach.

Zitat von @TRDSRLZ:
Hast du das schon mal am Client versucht?
https://blog.feldmann.io/windows-server/windows-dfs-namespace-access-den ...

Dieser Artikel ist etwas wirr. Einerseits wird von DFS-Cache gesprochen und andererseits ein Registry-Schlüssel für den Offlinefile-Cache genannt.
Das einzige, was mir bei DFS und Cache einfällt, ist dass der Client sich die einmal ermittelten DFS-Ziele in einem Cache merkt. Das wir aber nicht pro Unterordner gespeichert sondern bloß pro Stamm und DFS-Ordner.

Zitat von @143127:

Hast du mal das NTFS Auditing aktiviert und da rein geschaut?

s.o.

* Kommt evt. ABE in den Shares zum Einsatz?

Ja, auch.
Wenn es aber ABE wäre, dann würde der betreffende Ordner doch gar nicht angezeigt werden trotz Berechtigung, oder eben doch, obwohl keine Berechtigung.
Der Ordner wird angezeigt, der Benutzer hat effektive Lese- oder gar Schreibberechtigungen, aber er kann diesen Ordner nicht über DFS öffnen, sehr wohl aber über den Server.

Hallo,

Er hat dieses Problem sowohl bei direktem Zugriff von seinem Notebook (Win10) als auch beim Zugriff aus seiner TS-Sitzung (Win2016)

Die TS Sitzung startet er aber auch von seinem Laptop aus?

Wenn er das parallel mal von einem anderen Gerät mit seinem Account testet?
Nicht das auf dem Laptop eine Lokale Konfiguration greift.

brammer

Zitat von @brammer:
Die TS Sitzung startet er aber auch von seinem Laptop aus?

Ja.

Wenn er das parallel mal von einem anderen Gerät mit seinem Account testet?

Muss ich fragen, ob er das auch schon getan hat. Ich meine aber, dass er auch über das Web Gateway arbeitet, z.B. von zuhause.

Nicht das auf dem Laptop eine Lokale Konfiguration greift.

Wie soll eine lokale Konfiguration das Verhalten in einer TS-Sitzung beeinflussen?
Falls Du daran denken solltest: Er greift direkt per UNC zu, also nicht über durchgereichten Laufwerke oder sowas.

Edit:
Und

Wenn er das parallel mal von einem anderen Gerät mit seinem Account testet?

Hat er doch schon. Parallel vom Notebook und vom Server.

Zitat von @emeriks:

* Kommt evt. ABE in den Shares zum Einsatz?

Wir hatten das halt mal das ABE nur im Explorer ähnliche Probleme bereitet hat, deswegen die Frage.

Unter "lokal" auf dem Notebook würde auch die Anmeldeinformationsverwaltung fallen. Schon mal geprüft ob er da alten Quark drin stehen hat?

Ich war mal bei nem Kunden, da hat der ehemalige Admin, die Domainadminzugangsdaten eingetragen um in Outlook andere Postfächer anzubinden...

Also unmöglich ist nix...

Hallo schon spät heute Abend.
Habt ihr mal die Tokensize geprüft?
Viele Gruppenmitgliedschaften? Verschachtelte Gruppen?
Da könntest du mal schauen nach der max Token Size.
VG

Guten Morgen.

Für mich hört sich das nach Backlog Problemen an. Vielleicht einmal Backlog überprüfen und ggf. Staging Size an passen.

Viele Grüße

Hallo,

Es wurde ja bereits ABE angesprochen, aber
nur in Bezug auf den darunter liegenden Fileserver, wenn ich es richtig verstanden habe.
Mit DFS im 2008er Modus ist es möglich ABE auf Ebene von DFS zu nutzen bzw. Berechtigungen auf Verweise/Ordner einzutragen. Das könnte noch geprüft werden.

Evtl. wurde nicht
durchgängig nur mit Gruppen berechtigt?
Es klingt nach einem Berechtigungs-Problem direkt von diesem Benutzer. Eine Kopie vom Profil und neuer Benutzer (gleiche Gruppen) hat dieses Problem nicht.

Gruß

Zitat von @mastadook:
Habt ihr mal die Tokensize geprüft?

Ja, schrieb ich bereits. Alle Gruppen drin.

Zitat von @reAsti:
Für mich hört sich das nach Backlog Problemen an. Vielleicht einmal Backlog überprüfen und ggf. Staging Size an passen.

Staging Size ist für DFS-R. Es fehlen keine Elemente oder sind nicht aktuell. Da wird aus heiterem Himmel so plötzlich mal der Zugriff auf ein beliebiges Verzeichnis nicht gewährt.

Zitat von @Rasalghul:
Es wurde ja bereits ABE angesprochen, aber
nur in Bezug auf den darunter liegenden Fileserver, wenn ich es richtig verstanden habe.
Mit DFS im 2008er Modus ist es möglich ABE auf Ebene von DFS zu nutzen bzw. Berechtigungen auf Verweise/Ordner einzutragen. Das könnte noch geprüft werden.

Zu ABE habe ich doch schon geschrieben. ABE verweigert nicht den Zugriff. ABE ist rein Anzeige, blendet nur aus. Wenn da etwas falsch ausgeblendet würde, dann könnte man es doch trotzdem direkt adressieren.

Evtl. wurde nicht
durchgängig nur mit Gruppen berechtigt?
Es klingt nach einem Berechtigungs-Problem direkt von diesem Benutzer. Eine Kopie vom Profil und neuer Benutzer (gleiche Gruppen) hat dieses Problem nicht.

Das ist es ja. Das können wir ausschließen, weil der Zugriff auf diese Ordner dann zeitgleich direkt über den Server UNC eben funktioniert.

Da ist korrekt. Habe das in Größeren Strukturen ganz oft gehabt, das genau das Problem eingetreten ist und der Backlog das Problem war. Staging Size angepasst. 1 h später alles super. Ich weiss nicht genau warum aber die NTFS Berechtigungen wurden nicht richtig mit repliziert und konnte das im Vorfeld auch sehen wenn ich zwischen den beiden DFS-R Zielen gewechselt hätte und mir die Berechtigungen im einzelnen angesehen hatte.

Gruß

Zitat von @reAsti:

Magst Du mich nicht verstehen?
Der Zugriff auf den Ordner funktioniert! Also sind auch die NFTS-Berechtigungen in Ordnung.
Und es betrifft auch Ordner ohne jede Replikation.

Zitat von @emeriks:

Zu ABE habe ich doch schon geschrieben. ABE verweigert nicht den Zugriff. ABE ist rein Anzeige, blendet nur aus. Wenn da etwas falsch ausgeblendet würde, dann könnte man es doch trotzdem direkt adressieren.

Ich meinte das möglicherweise eine Berechtigung direkt auf dem DFS-Verweis bzw. Ordner für den Benutzer eingestellt ist. Das geht, meine ich, erst mit DFS im 2008 Modus (egal ob DFS-ABE aktiviert ist oder nicht). Diese Berechtigung greift unabhängig davon was am darunter liegenden Fileserver/Share berechtigt wurde.

Es muss ja irgendwie eine Kombination von DFS (Berechtigung?) und dem Benutzer sein. Ohne Umweg über DFS funktioniert der Zugriff ja.

Eine andere (verzweifelte) Idee: den DFS Verweis löschen und neu erstellen.

Gruß

Hi,
hast du mal die Namenslänge UNC Pfad überprüft?
Du sagst, wenn du über den Server zugreifst kannst du die Dateien öffnen.?
Über den DFS Pfad nicht mehr weil dann der NameSpace in der Pfadlänge dazukommt.
MAX_PATH ist 255 Zeichen.
Manche Anwender geben ihren Dateien merkwürdige Namen

Zitat von @Rasalghul:

Danke für Deine Mühe. Aber ich kann Dir nicht folgen.

Diese Berechtigung greift unabhängig davon was am darunter liegenden Fileserver/Share berechtigt wurde.

Sehr unwahrscheinlich. Habe ich so auch noch nie gehört.
Unabhängig davon: Wie soll das ein sporadisches Verhalten erklären? Zumal in Ebenen weiter unten?

Zitat von @MaBA77:
hast du mal die Namenslänge UNC Pfad überprüft?

Guter Ansatz. Aber dann würde es ja nicht nur einen Benutzer dieses TS betreffen.
Nebenbei: Der Pfad über den Server ist sogar länger.

War nur so ne Idee, und hatte ich schon

Wenn andere User auf das gleiche Ziel zugreifen können
liegts daran natürlich nicht...

Zitat von @emeriks:

Zitat von @Rasalghul:

Danke für Deine Mühe. Aber ich kann Dir nicht folgen.

Diese Berechtigung greift unabhängig davon was am darunter liegenden Fileserver/Share berechtigt wurde.

Sehr unwahrscheinlich. Habe ich so auch noch nie gehört.
Unabhängig davon: Wie soll das ein sporadisches Verhalten erklären? Zumal in Ebenen weiter unten?

Das ist nicht unwahrscheinlich, sondern eine Funktion/Berechtigung auf DFS Ebene. Hier ist das erklärt:
https://docs.microsoft.com/de-de/windows-server/storage/dfs-namespaces/e ...
Wenn das nicht bekannt ist, dann ist es aber unwahrscheinlich daß es verwendet wird.

Das Verhalten ist ja nicht sporadisch, sondern immer reproduzierbar auf (bisher) einen Benutzer bezogen, oder? Daher die Vermutung einer gesetzten Berechtigung für diesen Benutzer im DFS.

Wenn es in Ebenen unterhalb/nach dem DFS Verweis auftritt, also man sich bereits auf dem Fileserver bewegt, dann hilft meine Vermutung nicht weiter.

Ich würde dann testweise einen neuen Verweis, mit dem gleichen UNC-Pfad hinten dran, erstellen und den Benutzer da mal drauf schicken.

Gruß

Hab grad gesehen das es mit einem neuen Konto funktioniert.
Dann hast du doch den Fehler, Konto zerschossen...

Zitat von @Rasalghul:
Wenn das nicht bekannt ist, dann ist es aber unwahrscheinlich daß es verwendet wird.

Natürlich ist uns das bekannt. Aber ich fürchte, Du verwechselst da etwas oder hast die Problemstellung noch immer nicht verstanden.

Aktiviertes ABE in der Namespace-Root beeinflusst ausschließlich in der ersten Ebene die Anzeige der DFS-Ordner. Nicht in den DFS-Ordnerzielen.
Weiterhin ist das keine Berechtigung. Das ist nur eine die Anzeige von Ordnern betreffende Einstellung.

Das Verhalten ist ja nicht sporadisch, sondern immer reproduzierbar auf (bisher) einen Benutzer bezogen, oder?

Nein.
Es kommt bisher bei diesem einen Benutzer gehäuft vor. Fälle anderer Benutzer sind mir persönlich nicht bekannt, kann ich aber nicht ausschließen.
Und bei diesem bekannten Benutzer sind es jeden Tag andere Ordner. Also nicht reproduzierbar.

Zitat von @emeriks:

Weiterhin ist das keine Berechtigung. Das ist nur eine die Anzeige von Ordnern betreffende Einstellung.

Naja, doch. Es ist eindeutig eine Berechtigung: https://docs.microsoft.com/de-de/windows-server/storage/dfs-namespaces/e .... Und die greift unabhängig ob ABE aktiviert ist oder nicht. (Ordner ein-/ausblenden und/oder Zugriff gewähren/blockieren). Aber: tut nichts mehr zu Sache.

Aktiviertes ABE in der Namespace-Root beeinflusst ausschließlich in der ersten Ebene die Anzeige der DFS-Ordner. Nicht in den DFS-Ordnerzielen.

Das euer Problem unterhalb der DFS-Verweise auftritt habe ich nun verstanden. Daher ist mein Hinweis nicht weiter hilfreich.

Es kommt bisher bei diesem einen Benutzer gehäuft vor. Fälle anderer Benutzer sind mir persönlich nicht bekannt, kann ich aber nicht ausschließen.
Und bei diesem bekannten Benutzer sind es jeden Tag andere Ordner. Also nicht reproduzierbar.

Wirklich merkwürdig. Da das Problem nicht einfach nur gelöst werden soll (neuen Benutzer anlegen) sondern die Ursache gefunden und behoben werden soll, fallen mir zur weiteren Fehlersuche keine Ideen mehr ein.

Viel Erfolg!

Gruß

Zitat von @mastadook:

Hallo schon spät heute Abend.
Habt ihr mal die Tokensize geprüft?
Viele Gruppenmitgliedschaften? Verschachtelte Gruppen?
Da könntest du mal schauen nach der max Token Size.
VG

Hier hat niemand was dazu gesagt.
Eventuell tritt es halt nur manchmal auf, weil es so an der Grenze ist,
das es bei Zugriff über den einen Weg geht und bei dem anderen nicht und dann wieder anders.
Ab soundsoviel Gruppen und Verschachtelungen kann es komische Effekte haben...

Zitat von @Rasalghul:
Naja, doch. Es ist eindeutig eine Berechtigung: https://docs.microsoft.com/de-de/windows-server/storage/dfs-namespaces/e ....

Bitte hilf mir:
Wo, zum Geier, im von Dir verlinkten Artikel, steht etwas von Berechtigungen? Ich finde oder sehe es nicht.

Zitat von @emeriks:

Zitat von @Rasalghul:
Naja, doch. Es ist eindeutig eine Berechtigung: https://docs.microsoft.com/de-de/windows-server/storage/dfs-namespaces/e ....

Bitte hilf mir:
Wo, zum Geier, im von Dir verlinkten Artikel, steht etwas von Berechtigungen? Ich finde oder sehe es nicht.

Der verlinkte Artikel sollte direkt zum Kapitel "Steuern Sie die Sichtbarkeit der Ordner mit der Windows-Benutzeroberfläche" springen. Hier ist im 3. Punkt die Einstellungen für die "explizite Berechtigung" beschrieben.

Wie gesagt, das spielt in eurem Fall an dieser Stelle keine Rolle.

Gestern wurde ja mal der Client angesprochen. Das könnt ihr auch ausschließen?

Denn die RDP-Verbindung baut er ja auch mit dem Notebook auf hast du gesagt.

Zitat von @Rasalghul:
Der verlinkte Artikel sollte direkt zum Kapitel "Steuern Sie die Sichtbarkeit der Ordner mit der Windows-Benutzeroberfläche" springen. Hier ist im 3. Punkt die Einstellungen für die "explizite Berechtigung" beschrieben.

Danke.
Das habe ich sicher schon irgendwann mal gesehen, aber das setzten wir so nicht ein. Das habe ich soeben explizit überprüft.

Tritt das Problem auch auf, wenn er sich an einem anderen Rechner, an dem er im LAN noch nie angemeldet war, anmeldet?
Wenn dem so ist, und es ja auch auf dem TS per RDP das Problem gibt, ist definitiv das Profil "zerschossen". Da bleibt Dir wohl nichts anderes übrig, als ein neues Profil zu erstellen. Ist ja nun auch kein Hexenwerk, das Stunden dauert. Scheint mir aber am zielführendsten.

Das gleiche Poblem hatte ich auch schon. Ich hatte aber keine Lust das genauer zu untersuchen. Daher habe gleich ein neues Profil erstellt und 15min Konfigurationsarbeit reingesteckt und es funktioniert.

Gruß
Stephan

German Question Windows Server Microsoft