none
Netzwerkfreigabe ohne Passworteingabe RRS feed

  • Allgemeine Diskussion

  • Hallo,

    ich habe ein seltsames Problem: Domäne A und B sind über eine Vertrauensstellung verbunden. Auf einem Server in Domäne A befinden sich freigegebene Ordner.

    Die Benutzer von Domäne B konnten auf die Netzwerklaufwerke von Domäne A zugreifen. Das hatte bis vor kurzem gut funktioniert. Die Netzwerkfreigaben mit IP-Adressen (\\<IP-Adresse des Servers auf Domäne A>\<Freigabe>) funktionieren noch, die mit Hostnamen (\\<Name des Servers auf Domäne A>.<domaene-a>.local\<Freigabe>) nicht richtig. Dabei wurden die Benutzer plötzlich nach einem Passwort gefragt. Die Eingabe ihrer Benutzerdaten hat nicht funktioniert, nur die Eingabe von Benutzerdaten aus Domäne A. Das heißt, die Benutzer in Domäne B können nicht auf ein Netzlaufwerk von Domäne A ohne Passwortabfrage zugreifen oder nur über die IP-Adresse.

    Ping auf servername.domaene-a.local funktioniert einwandfrei. Nslookup zeigt auch die richtigen DNS-Einträge an. Die Firewall wurde testweise deaktiviert - kein Erfolg. Die Vertrauensstellung ist aktiv und funktioniert auch einwandfrei.

    Wie konnte es passieren, dass bei Netzwerkfreigaben mit Hostnamen plötzlich nach einem Passwort gefragt wurde?

    Dienstag, 21. Mai 2013 11:32

Alle Antworten

  • > Wie konnte es passieren, dass bei Netzwerkfreigaben mit Hostnamen plötzlich nach einem Passwort gefragt wurde?

    Es hat sich etwas geändert, wovon Du nicht direkt etwas mitbekommen hast.. ;)

    Was? Dazu erstelle sowohl auf dem betroffenen Client mit angemeldeten, betroffenen Benutzer als auch auf dem File-Server und dem File-Server zugehörige(n) Domain Controller(n) aus der Domäne A gleichzeitig einen Network-trace und verfolge, wieso die Anmeldung ursprünglich scheitert.

    Als Aktionsplan ab Windows 7/2008 R2 ist z.B. folgende Befehlsfolge ziehlführend (auszuführen auf allen beteiligten Endpunkten wie Client, File-Server und DCs - s.o.):

    klist purge
    klist –li 0x3e7 purge
    ipconfig /flushdns
    NBTStat -R
    netsh trace start capture=yes
    ping -n 1 -l 111 8.8.8.8
    <repro issue>
    ping -n 1 -l 222 8.8.8.8
    netsh trace stop

    Weitere Informationen hierzu:

    Kerberos for the Busy Admin
    http://blogs.technet.com/b/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx

    Kerberos errors in network captures
    http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx

    --

    Tobias Redelberger
    StarNET Services (HomeOffice
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Dienstag, 21. Mai 2013 12:50
  • Danke für die Antwort. Irgendwie scheint das nicht zu funktionieren. Ich kann keine Authentifizierungsfehler finden...

    Ich habe versucht, auf den drei Rechnern (DC, Fileserver, Client) gleichzeitig einen network-trace zu erstellen. Dabei habe ich gleichzeitig auf allen Rechnern diese Befehle eingegeben:

    klist purge
    klist –li 0x3e7 purge
    ipconfig /flushdns
    NBTStat -R
    netsh trace start capture=yes
    ping -n 1 -l 111 8.8.8.8

    Danach habe ich den Fehler mit dem Befehl "net use x: <Hostname\Freigabe>" produziert. Dann habe ich noch einmal die Freigabe "\\<Server auf Domäne A>.<domaene-a>.local\<Freigabe>" manuell in das Textfeld im Explorer eingegeben und bestätigt, um die Freigabe über den Explorer öffnen zu können.

    Nach dem Reproduzieren habe ich auf allen Rechnern gleichzeitig diese Befehle ausgeführt:

    ping -n 1 -l 222 8.8.8.8
    netsh trace stop
    Nun wollte ich die erstellten traces mit dem Network Monitor öffnen und habe "KerberosV5" als Filter ausgewählt. Aber es wurden keine Ergebnisse gefunden. Habe ich was falsches gemacht?

    Dienstag, 21. Mai 2013 15:02
  • Am 21.05.2013 17:02, schrieb -tux-:
    > Nun wollte ich die erstellten traces mit dem Network Monitor öffnen
    > und habe "KerberosV5" als Filter ausgewählt. Aber es wurden keine
    > Ergebnisse gefunden. Habe ich was falsches gemacht?
     
    Die vollständigen Windows-Parser hast Du in Netmon aber geladen, oder?
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 21. Mai 2013 15:10
  • So, habe die vollständigen Windows-Parser geladen. Ich kannte mich nicht so gut mit diesem Programm aus

    Aber der KerberosV5-Filter hat trotzdem nichts gefunden. Mit Wireshark habe ich versucht, was rauszufinden und bin auf diese Pakete gestoßen. Was bedeutet die Fehlermeldung "KRB_AP_ERR_BAD_INTEGRITY" und wie behebe ich diesen Fehler? (OS: Windows Server 2008 R2)


    Zusammenfassung:

    \\<IP-Adresse>\<Freigabename> = funktioniert, auch mit Benutzeranmeldeinformationen aus beiden Domänen A und B (der Zugriff auf die per GPO zugewiesenen Netzlaufwerke sollte ohne Passwortabfrage erfolgen, was auch funktioniert hat)

    \\<Hostname>\<Freigabename> = funktioniert zwar, aber nur nach Anmeldung mit Benutzerdaten aus Domäne A (es sollte eigentlich genau so gut funktionieren wie mit IP-Adresse...)


    • Bearbeitet -honeybee- Mittwoch, 22. Mai 2013 11:30
    Mittwoch, 22. Mai 2013 11:29
  •  
    > Aber der KerberosV5-Filter hat trotzdem nichts gefunden. Mit Wireshark
    > habe ich versucht, was rauszufinden und bin auf diese Pakete gestoßen.
    > Was bedeutet die Fehlermeldung "KRB_AP_ERR_BAD_INTEGRITY" und wie
    > behebe ich diesen Fehler? (OS: Windows Server 2008 R2)
     
    "Irgendwas" auf der Netzwerkstrecke zwischen Domäne A und Domäne B
    zerhackstückt Dir die Kerberos-Pakete. Ist da ein VPN-Tunnel beteiligt?
    Und auch wenn nicht: Zwinge Kerberos mal dazu, TCP statt UDP zu
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 22. Mai 2013 12:13
  • Am 22.05.2013 14:33, schrieb -tux-:
    > Es ist kein VPN-Tunnel vorhanden. Ich werde mal in nächster Zeit
    > versuchen, das Protokoll von TCP auf UDP zu ändern. Dieser Vorgang
    > muss auf dem DC von Domäne A ausgeführt werden, oder?
     
    Sicherheitshalber überall... Kannst per Group Policy Preferences
    Registrierung ganz einfach zentral machen. Reicht übrigens schon, wenn
    Router mitspielen... UDP ist verbindungslos, und wenn das Kerberos-Paket
    zwischen 1536 und 2048 Byte groß ist, braucht es 2 UDP-Pakete, die u.U.
    in der falschen Reihenfolge auf der Gegenseite ankommen -> kaputt.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 22. Mai 2013 12:53
  • Ich kann dies nur auf dem DC von Domäne A versuchen, da ich eingeschränkte Adminrechte für Domäne B habe, denn man müsste dafür den Server neu starten.

    Gibt es eine einfachere Lösung? Mir ist aufgefallen, dass das Problem weiterhin bestehen bleibt, wenn ich einen neuen Server aufsetze. Der Zugriff auf die Freigaben von Domäne B funktioniert. Es sieht so aus, dass das Problem in Domäne A liegt. Könnte das Problem in den Security Policies liegen?

    • Bearbeitet -honeybee- Mittwoch, 22. Mai 2013 13:50
    Mittwoch, 22. Mai 2013 13:46
  • Am 22.05.2013 15:46, schrieb -tux-:
    > Könnte das Problem in den Security Policies liegen?
     
    Tendenziell nein. Die Fehlermeldung im Trace war eindeutig, und es gibt
    keine Security Policies, die Kerberos Pakete kaputtmachen ;-)
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Mittwoch, 22. Mai 2013 20:00
  • Ich habe das heute versucht. Das Problem bleibt leider bestehen.

    Ich befürchte, dass es ein Problem mit der Vertrauensstellung gibt. Wenn ich mich als Benutzer von Domäne A an einen Rechner der Domäne B anmelde, funktioniert die Anmeldung. Wenn ich mich aber als Benutzer von Domäne B an einen Rechner der Domäne A anmelde, schlägt die Anmeldung fehl, weil angeblich das Kennwort falsch ist...

    Donnerstag, 23. Mai 2013 07:55
  • Dann würde jedoch nach Deiner Aussage nicht folgendes funktionieren:

    \\<IP-Adresse>\<Freigabename> = funktioniert, auch mit Benutzeranmeldeinformationen aus beiden Domänen A und B

    -> Fallback auf NTLM da für IP-Adresse kein Kerberos-Ticket (Stichwort: SPN) ausgestellt wird (s.a. http://blogs.technet.com/b/surama/archive/2009/04/06/kerberos-authentication-problem-with-active-directory.aspx und http://blogs.technet.com/b/isrpfeplat/archive/2010/11/05/optimizing-ntlm-authentication-flow-in-multi-domain-environments.aspx)

    Bevor Du deshalb etwas ohne zugehöriges Hintergrundwissen (" Ich kannte mich nicht so gut mit diesem Programm aus") mutmaßt, besteht die Möglichkeit den erstellen Trace einem Spezialisten oder uns bereit zu stellen?

    Bitte die zugehörigen Hintergrundinformationen bzgl. den beteiligten Usern (Domain,Name) und Domain-Controllern (FQDN/IP-Adresse usw.) wie auch Ausgangspunkt des jeweiligen Traces und Zeitpunkte der zugehörigen Aktionen zusätzlich beilegen.

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Donnerstag, 23. Mai 2013 10:42
  • Ich glaube, ihr habt mich falsch verstanden...

    Es geht darum, dass ich via Hostname auf keine Freigabe von Domäne A zugreifen kann. Via IP-Adresse funktioniert es. Nslookup zeigt den richtigen DNS-Namen an. Deshalb habe ich keine Erklärung, warum die Freigabe via Hostname trotzdem nicht funktioniert.

    Und zum Testen bin ich auf die Idee gekommen, mich als Benutzer von Domäne B an einen Rechner, der Mitglied in Domäne A ist, anzumelden. Dort hat es nicht funktioniert. Wenn ich mich aber als Benutzer von Domäne A an einen Rechner, der Mitglied in Domäne B ist, anmelde, funktioniert es. Das heißt, irgendwie vertraut Domäne A die Domäne B anscheinend nicht. Deshalb diese Probleme mit der Freigabe, denn wenn ich von einem Rechner aus Domäne B aus auf eine Freigabe von Domäne A via Hostname zugreife, funktioniert es. Nur umgekehrt nicht. Warum es so ist, kann ich mir nicht erklären.

    Habe bei der Anmeldung an Domäne B die Fehlermeldung "Das System hat eine mögliche Sicherheitsgefahr festgestellt" bekommen. Dieses Problem konnte ich mit dem von Martin Binder genannten Lösungsvorschlag beheben. Nur bei Domäne A bleibt das Problem bestehen. Dort ist ja auch das Hauptproblem mit den Hostnamen.

    Ich habe noch nie mit Network Monitor gearbeitet. Ich verwende ausschließlich Wireshark als Alternative.

    • Bearbeitet -honeybee- Donnerstag, 23. Mai 2013 13:31
    Donnerstag, 23. Mai 2013 13:26
  • Nochmal: wir brauchen einen aussagekräftigen Network-Trace aller Beteiligten (s.o.) während das Problem auftritt - alles andere ist nur stochern im Nebel.

    P.S.: Sind RODC und Windows Server 2003 Domain Controller im Spiel?

    --

    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Donnerstag, 23. Mai 2013 13:48
  • Wir haben schon richtig verstanden...
     
    > Es geht darum, dass ich via Hostname auf keine Freigabe von Domäne A
    > zugreifen kann. Via IP-Adresse funktioniert es. Nslookup zeigt den
    > richtigen DNS-Namen an. Deshalb habe ich keine Erklärung, warum die
    > Freigabe via Hostname trotzdem nicht funktioniert.
     
    Bei Hostnamen wird Kerberos verwendet, bei IP-Adressen NTLM. Also
    funktioniert die Kerberos-Authentifizierung nicht.
    Hier dann der Abschnitt "Simple Cross-Realm Authentication and Examples"
     
    mfg Martin
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 23. Mai 2013 14:38