none
Login Skript in einer trusted Domain Umgebung RRS feed

  • Frage

  • Hallo,

    ich habe zwei getrennte AD Domänen (DOM A und B). Zwischen diesen ist ein beidseitiger Trust aufgebaut.

    Der Zugriff auf Ressourcen in der jeweilig anderen Domain funktioniert wunderbar.

    Jetzt soll ein Nutzer aus der Domäne A sich an einem PC der Domäne B anmelden. Auch das funktioniert ohne Probleme.

    Allerdings führt er das Login-Skript nicht aus. Das Login-Skript ist NICHT über GPO zugewiesen, sondern ist in den Profil-Eigenschaften des Benutzers zugewiesen! Dort ist der volle Pfad gesetzt.

    \\<AD/DNS-Domainname>\netlogon\LS\LOGIN.CMD

    Ein manuelles ausführen nachdem der Nutzer angemeldet ist funktioniert ohne Probleme.

    Ich habe "mitgesnifft", ein Namensauflösungsproblem besteht nicht, unter SMB sieht man keine Anforderung, im DNS/WINS keine Namensauflösungsanforderung!

    In den Eventlogs sind keine Fehlermeldungen zu sehen.

    In der "Default Domain Policy" beider Domänen ist "allow cross-forrest user policy and roaming user profiles" "enabled".

    Normalerweise muss das Logonscript ja irgendwie vom Domaincontroller im Benutzerkontext übergeben werden, damit es aufgerufen werden kann.

    Beim "Mitsniffen" einer funktionierenden (Benutzer in DOM A und PC in DOM A) und der nichtfunktionierenden Konstellation (Benutzer in DOM A und PC in DOM B) ist die einzige Stelle wo das Loginskript mitgegeben wird im PAC_LOGON_INFO (http://msdn.microsoft.com/en-us/library/cc237917.aspx) Feld des Kerberos-Tickets.

    Allerdings ist mir dort nicht klar, wie der Client (PC/Nutzer) an den verschlüsselten Inhalt kommen soll, da dieses lt. Wireshark mit dem Master Key des Domänencontrollers verschlüsselt ist.

    (A) - Was mache ich falsch, was kann man noch konfigurieren, das das Login-Skript aus dem User-Profil ausgeführt wird?

         - Wie kann ich weiter debuggen?

    (B) Wie funktioniert das mit dem PAC-Field?

    Danke Meike

    Mittwoch, 23. Juli 2014 14:21

Antworten

  • Hi,

    Am 23.07.2014 um 16:21 schrieb "Meike Stone":

    \\<AD/DNS-Domainname>\netlogon\LS\LOGIN.CMD

    Definiere jeweilse beide <AD/DNS-Domainname> in jeder Domäne als INTRANET in den IE Eigneschaften.

    zB per GPO über die "Liste der Sites zu Zonenzuweisungen"

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    • Als Antwort markiert Meike Stone Donnerstag, 24. Juli 2014 15:09
    Mittwoch, 23. Juli 2014 17:33

Alle Antworten

  • Hi,

    Am 23.07.2014 um 16:21 schrieb "Meike Stone":

    \\<AD/DNS-Domainname>\netlogon\LS\LOGIN.CMD

    Definiere jeweilse beide <AD/DNS-Domainname> in jeder Domäne als INTRANET in den IE Eigneschaften.

    zB per GPO über die "Liste der Sites zu Zonenzuweisungen"

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    • Als Antwort markiert Meike Stone Donnerstag, 24. Juli 2014 15:09
    Mittwoch, 23. Juli 2014 17:33
  • Hallo Mark,

    Vielen Dank, das war die Ursache ... Ist mir aber unbegreiflich, dass man am IE Einstellungen ändern muss, damit das Login-Script funktioniert (kopfschüttel) ....

    Meike



    Donnerstag, 24. Juli 2014 15:09
  • > Vielen Dank, das war die Ursache ... Ist mir aber unbegreiflich, dass
    > man am IE Einstellungen ändern muss, damit das Login-Script funktioniert
     
    Ist schon immer so - der Explorer nimmt die Zonenzuordnungen des IE.
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Donnerstag, 24. Juli 2014 15:30
  • Hi

    Am 24.07.2014 um 17:09 schrieb "Meike Stone":

    Vielen Dank, das war die Ursache ... Ist mir aber unbegreiflich, dass
    man am IE Einstellungen ändern muss, damit das Login-Script
    funktioniert (kopfschüttel) ....

    Es ist nun mal ein DNS Name und Netzwerkzugriff und da hat der Explorer schon immer den IE gefragt "wo" das Ziel ist.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage: http://www.gruppenrichtlinien.de - deutsch
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 24. Juli 2014 18:35

  • Beim "Mitsniffen" einer funktionierenden (Benutzer in DOM A und PC in DOM A) und der nichtfunktionierenden Konstellation (Benutzer in DOM A und PC in DOM B) ist die einzige Stelle wo das Loginskript mitgegeben wird im PAC_LOGON_INFO (http://msdn.microsoft.com/en-us/library/cc237917.aspx) Feld des Kerberos-Tickets.

    Allerdings ist mir dort nicht klar, wie der Client (PC/Nutzer) an den verschlüsselten Inhalt kommen soll, da dieses lt. Wireshark mit dem Master Key des Domänencontrollers verschlüsselt ist.

    (B) Wie funktioniert das mit dem PAC-Field?

    Hallo,

    es wäre wunderbar, wenn mir jemand noch erklären könnte, wie das mit dem PAC-Field funktioniert.

    Für wen ist das gedacht. Wenn das stimmt, dass das Feld mit dem Master Key des DCs verschlüsselt ist, kann der Client das doch nicht lesen.

    (Das wäre dann wie beim TGT, dort wird der Sessionkey, die Zeit und die Userinfo auch mit dem Masterkey des KDC verschlüsselt - mit dem Hintergrund, das a) der KDC keine Sessiontable für die Principals benötigt und b) als Validierung, das das TGT auch wirklich vom KDC stammt ...)

    Allerdings stellt sich mir dann die Frage, woher bekommt der Client die Informationen, welches Logon-Skript er ausführen soll, wenn diese Info mit einem Ihm nicht bekannten Key verschlüsselt ist.

    Ich habe den gesamten Loginvorgang mit Wireshark mitgeschnitten (mit Client und User aus einer Domäne) und mit der keytab vom DC (Kerberos) via Wireshark decrypted. Das PAC_LOGON_INFO Feld enthielt als einziges Paket das Logonscript - kein LDAP Paket, o.ä. enthielt noch etwas brauchbares ...

    Kann mir das jemand bitte genauer erläutern (oder einen Link zum nachlesen) woher der Client die Info über das Logon-Skript bekommt? Hier war Google leider nicht wirklich mein Freund ...

    Es wird zwar erläutert, wie das PAC-Feld validiert wird (http://msdn.microsoft.com/en-us/library/cc224020.aspx, http://blogs.msdn.com/b/openspecification/archive/2009/04/24/understanding-microsoft-kerberos-pac-validation.aspx), aber nicht wie der Client an die Info für das Loginscript kommt ...

    Vielen, vielen Dank!

    Meike

    Freitag, 25. Juli 2014 09:02
  • > es wäre wunderbar, wenn mir jemand noch erklären könnte, wie das mit dem
    > PAC-Field funktioniert.
     
     
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Freitag, 25. Juli 2014 09:48