Benutzer mit den meisten Antworten
Login Skript in einer trusted Domain Umgebung

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
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
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
-
> Vielen Dank, das war die Ursache ... Ist mir aber unbegreiflich, dass> man am IE Einstellungen ändern muss, damit das Login-Script funktioniertIst 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 :)) -
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 -
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
-
> es wäre wunderbar, wenn mir jemand noch erklären könnte, wie das mit dem> PAC-Field funktioniert.Erst mal lesen: http://technet.microsoft.com/library/cc772815.aspx
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 :))