accolon 10 Geschrieben 18. November 2005 Melden Teilen Geschrieben 18. November 2005 Ich stehe vor der Aufgabe, ein bisher nur aus Linuxrechnern bestehendes Netzwerk um einige XP-Clients zu erweitern. An den Rechnern sollen verschiedene Arten von Benutzern arbeiten, für die ich daher auf meinem 2k3-Server unterschiedliche Richtlinien festgelegt habe. Die Benutzer sollen sich über den vorhandenen Linux-Kerberos-Server authentifizieren. Dazu habe ich einen Trust hergestellt, auf den XP-Clients den Kerberos-Server bekanntgemacht und den Benutzern im Active Directory über "Namenszuordnungen" die korrekten Prinzipalnamen zugeordnet. Die Benutzer können sich nun erfolgreich direkt an der Windows-Domäne anmelden, oder aber bei der Anmeldung den Kerberosbereich auswählen und sich auch dort problemlos authentifizieren. Das Problem besteht nun darin, dass die den einzelnen Benutzergruppen zugeordneten GPOs nur greifen, wenn sich ein User direkt an der Windows-Domäne anmeldet. Bei einer Anmeldung via Kerberos werden sämtliche Richtlinien einfach vollständig ignoriert -- ganz so, als ob sie gar nicht da wären. Hat vielleicht jemand eine Idee, was ich übersehen haben könnte? Ich konnte dazu nirgendwo etwas finden. Soweit ich weiß, sollte der Client doch auch nach einer Kerberos-Authentifizierung trotzdem die passenden Gruppenrichtlinien vom DC holen und anwenden, bei der "normalen" Anmeldung funktioniert das ja auch. Muss ich dazu vielleicht noch zusätzliche Einstellungen machen? Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 19. November 2005 Melden Teilen Geschrieben 19. November 2005 Ich denke, da liegt ein Missverständnis über den Zweck einer Kerberos/MIT-Vertrauensstellung vor. Der Zweck dieser VS ist, dass eine übergreifende Authentifizierung und damit die Anmeldung an Rechnern der anderen Domäne möglich ist, und Berechtigungen auch für Member der Trusted Domains vergeben werden können. ABER: Gruppenrichtlinen im AD wirken für vorhandene Security Principals des jeweiligen AD-Bereiches (Standort/Domäne/OU) und nicht für Mitglieder von trusted realms! grizzly999 Zitieren Link zu diesem Kommentar
Velius 10 Geschrieben 19. November 2005 Melden Teilen Geschrieben 19. November 2005 Jo, Grizzly hat recht. GPO's werden unter anderem über RPC-Calls ermittelt und angewandt. Kerberos hat damit so gut wie gar nichts zu tun, ausser das ein nicht authentifizierter Computer/Benutzer möglicherweise, kann ich aber nicht bestätigen, gar nicht erst soweit kommt. Die Schnittstelle ist aber definitv eine andere. :wink2: Zitieren Link zu diesem Kommentar
accolon 10 Geschrieben 20. November 2005 Autor Melden Teilen Geschrieben 20. November 2005 Ich muss leider zugeben, noch nicht so tief in der Materie drinzustecken... Mein Wissen habe ich mir in den letzten paar Tagen aus verschiedenen Quellen angelesen und war zunächst auch ganz zuversichtlich, was aber wohl etwas voreilig war. Von Linux-Seite werden einige Dienste zur Verfügung gestellt, die ein gültiges Kerberos-Ticket benötigen; dieses Problem habe ich eben dadurch gelöst, dass ich den einzelnen Nutzern meiner Domäne "win.meine.domain.de" eine Namenszuordung vom Format "user@MEINE.DOMAIN.DE" verpasst habe. Wie schon beschrieben, klappt das ja auch alles wunderbar. Wenn ich euch richtig verstehe, meldet sich der Benutzer dann also bei der Kerberos-Atuhentifizierung sozusagen nur an der Linux-Domäne an, mein Domain Controller hat dabei lediglich die Funktion, die Namenszuordnungen zu liefern? Dann scheint es ein grundlegenderes Problem zu sein. Wie kann ich es trotzdem schaffen, meine Benutzer über die jew. Gruppenrichtlinien einzuschränken und ihnen gleichzeitig die benötigten Kerberos-Tickets zu geben? Vielleicht kennt auch jemand eine gute Dokumentation für solche Fälle? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.