none
DFS-Stamm unter 2003 und Windows 7 RRS feed

  • Frage

  • Hallo zusammen,

    das Problem ist etwas tricky, deshalb meine Frage recht ausführlich mit ein paar schon erledigten ToDo's. Falls die Frage jemandem bekannt vorkommt - sorry, das Problem ist etwas dringlich und daher habe ich auch an anderer Stelle um Hilfe gebeten - bisher leider noch ohne Erfolg.

    Es existiert eine Windows 2008-Domäne A mit einigen Windows XP-Clients. In einer weiteren Domäne B existiert ein DFS-Stamm, auf den User regelmäßig zugreifen sollen. Die User haben sowohl in Domäne A und in Domäne B je einen Account, der den gleichen Anmeldenamen und das gleiche Kennwort hat. Die Domänen haben eine NT4-kompatible Vertrauensstellung, wobei Domäne A der Domäne B vertraut. Die Vertrauensstellung ist (leider) einseitig.

    Bei den Windows XP-Anmeldeskripten ist ein Batch hinterlegt, dass den Nutzer der Domäne A beim Arbeiten auf einem Computer der Domäne A mit seinem Anmeldenamen der Domäne B in der Domäne B am DFS-Stamm voranmeldet. Da die Kennworte in beiden Domänen identisch sind, braucht der Nutzer für den Zugriff in Domäne B kein Kennwort angeben.

    Die Voranmeldung sieht so aus:

    net use \\domainB.de\dfsbasis\dfsshare /user:domainB\Logonname

    Nach dieser "Voranmeldung" ist es mit dem Explorer möglich, einfach das Share \\domainB.de\dfsbasis\dfsshare oder Unterverzeichnisse aufzurufen und zuzugreifen. Ein Kennwort wird vorsätzlich nicht übergeben, da dies bei der Voranmeldung nicht bekannt ist.


    Jetzt steht eine Migration nach Windows 7 an und dieser hier beschriebene Mechanismus funktioniert mit Windows 7 nicht. Nach dem Versuch des Öffnens des Shares dauert es einen kurzen Moment bis ein Fenster angezeigt wird, das mitteilt, dass der Benutzername oder das Kennwort falsch sind.

    Durch Hinweise im Internet habe ich bereits mit secpol.msc die Anmeldetypen so umgestellt, dass NTLM und LM wieder möglich sind - trotzdem funktioniert es nicht. Ein Sniff mit Whireshark zeigt, dass sich Windows 7 versucht an dem DFS anzumelden und dabei quasi den falschen Domänennamen mitgibt. Statt DomainB\Logonname wird DomainA\Logonname an den Server übertragen, was dann natürlich schief geht, da ja die Vertrauensstellung in die falsche Richtung zeigt.

    Es scheint fast so als wenn Windows 7 zwar über net use bestätigt, dass alles ok ist, aber keine Session aufgebaut wird, die beim Zugriff Verwendung findet. Das Problem tritt auch bei abgeschalteter UAC auf und mit dem Registry-Key der sagt, dass administrativ eingerichtete Shares an den User durchgereicht werden dürfen.

    Hülfe zusammen, das Problem ist wirklich vertrakt und alle Hinweise sind willkommen. Nicht nur Hinweise, wie das Problem zu lösen ist, auch Workarounds, die dem Nutzer das manuelle Anmelden an den DFS-Laufwerken ermöglichen, sind gern willkommen. Ausgeschlossen ist, dass die Vertrauensstellung beidseitig wird oder eine Datenmigration stattfindet - aber sonst sind viele Wege offen.

    Danke schön schon jetzt für eure Hilfe.
    Sonntag, 22. August 2010 21:33

Alle Antworten

  • Hi,

    Am 22.08.2010 23:33, schrieb Nailara:

    Es scheint fast so als wenn Windows 7 zwar über net use bestätigt,
    dass alles ok ist, aber keine Session aufgebaut wird, die beim
    Zugriff Verwendung findet.

    2 Dinge, die mir spontan einfallen:
    - bidirektionale Vertauensstellung
    Wenn das die Lösung ist, hast du jetzt das Argument.
    Dann hört das auch endlich mit der extra-Anmeldung auf.
    Es ist nicht "unsicherer". Es ist nur dann "unsicherer", wenn der
    Admin nicht mit ordentlichen Berechtigungen und eigene Sigruppen
    gearbeitet hat, sondern mit Wellknown SIDs.
    Der Rest lässt sich über Universelle Gruppen oder auch Globale steuern.

    - integriere das PW in die CMD

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Montag, 23. August 2010 18:06
  • Hi,

    Am 22.08.2010 23:33, schrieb Nailara:

    Es scheint fast so als wenn Windows 7 zwar über net use bestätigt,
    dass alles ok ist, aber keine Session aufgebaut wird, die beim
    Zugriff Verwendung findet.

    2 Dinge, die mir spontan einfallen:
    - bidirektionale Vertauensstellung
    Wenn das die Lösung ist, hast du jetzt das Argument.
    Dann hört das auch endlich mit der extra-Anmeldung auf.
    Es ist nicht "unsicherer". Es ist nur dann "unsicherer", wenn der
    Admin nicht mit ordentlichen Berechtigungen und eigene Sigruppen
    gearbeitet hat, sondern mit Wellknown SIDs.
    Der Rest lässt sich über Universelle Gruppen oder auch Globale steuern.

    - integriere das PW in die CMD

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Montag, 23. August 2010 18:07
  • Hi Nailara,

    Alternativen die mir nach Marks Posting noch einfallen:
    run as mitgeben und .vbs statt .bat testen

    Viele Grüße
    Christian

    Dienstag, 24. August 2010 04:49
  • Hi,

    bidirektionale Vertrauensstellung scheidet leider aus - "die andere Seite" zeigt sich hier leider wenig kooperationsbereit und die Argumente ziehen nicht wirklich. Beide Betreiber der Domänen arbeiten quasi in begrenzter Konkurrenz zu einander, meine Seite ist offener, die andere Seite stellt sich quer.

     

    Das Passwort in der CMD ist auch (fast) nicht möglich, da das Passwort nicht bekannt ist und ja jeder Nutzer sein eigenes Kennwort hat und das auch alle Nase wechseln muss. Damit hauen uns früher oder später die User wegen des Anpassungsaufwands.

    Ich wollte mal schauen, ob man mit .NET den Passworthash irgendwie auslesen kann und den statt des Klartextpassworts versendet, aber es wäre albern wenn das gehen würde. Bliebe nur, den Passwortwechseldialog abzufangen und das ist sicher auch nicht einfach.

    Die Frage für mich: warum geht es unter XP und nicht unter Windows 7?

    Danke schön :-)

    Mittwoch, 25. August 2010 21:38
  • Hallo zusammen,

    gibt es hierzu schon eine Lösung. Wir haben exakt das gleiche Problem. auf Windows 2008 Terminalservern lässt sich das Laufwerk mittels CMD verbinden, kann aber nicht genutzt werden. Selbe Problematik wie oben beschrieben.

    net use \\domainA.de\dfsbasis\dfsshare /user:domainB\Logonname    / die Server sind in der DomäneB

    Es scheint fast so als wenn Windows 2008 zwar über net use bestätigt,
    dass alles ok ist, aber keine Session aufgebaut wird, die beim
    Zugriff Verwendung findet.

    Danke und Gruß Mark

    Mittwoch, 18. Dezember 2013 10:06
  • Das Passwort in der CMD ist auch (fast) nicht möglich, da das Passwort nicht bekannt ist und ja jeder Nutzer sein eigenes Kennwort hat und das auch alle Nase wechseln muss. Damit hauen uns früher oder später die User wegen des Anpassungsaufwands.

    Die Frage für mich: warum geht es unter XP und nicht unter Windows 7?

    Moin,

    XP war noch nicht so ein Sensibelchen, da durfte die Kommunikation zwischen zwei Systemen auch ruhig noch ein wenig unsicherer sein als heutzutage.

    Klappt es vielleicht, die DFS-Freigabe einmalig per Anwender per Start/Ausführen öffnen und die Anmeldedaten dann zu speichern (den Haken dazu sollte es ja geben)?

    Die können dann in der Systemsteuerung in der Anmeldeinformationsverwaltung verhackstückt werden (sprich Kennwörter angepasst - und auch Anwender sind durchaus lernfähig und prügeln nicht immer nur auf die IT ein - man braucht sich ja gegenseitig).

    Sonst noch die Standardfragen: Stimmen Datum, Zeitzone und Uhrzeit zwischen dem Client und dem die Anmeldung beglaubigendem Domänencontroller überein?

    Wie siehts mit der DNS-Namensauflösung aus, weiss der Client überhaupt, bei welchen DC die Anmeldeinformationen hinterlegt werden müssen? (Bei XP wurde da vieles noch auf dem kurzen Dienstweg über NetBIOS erledigt.)

    Viele Grüße
    Olaf

    Mittwoch, 18. Dezember 2013 12:37