Gruppenrichtlinie(n) werden an EINEM (!) Client/Benutzer nicht angewendet

[Blase 15]

Hallo in die Runde,

 

gegeben ist ein Server 2012 R2 als alleiniger DC (Funktionsebene noch 2008) und diverse Clients - überwiegend Windows 10.

 

Ein Windows 10 Client scheint sich keine Gruppenrichtlinien zu ziehen - nicht einmal die Default Domain Policy. Die anderen Clients haben damit keine Probleme. Ich kann an diesem speziellen so erst einmal keinen Unterschied zu den anderen Clients erkennen.

 

Ein gpresult sagt mir, dass keine Gruppenrichtlinienobjekte angewendet worden sind - aber eben auch keine abgelehnt. Das Ereignisprotokoll am Clients zeigt keine besonderen Auffälligkeiten in diese Richtung.

 

Ich stehe dann wohl auf dem Schlauch - mag mich mal bitte jemand in die richtige Richtung schubsen?!

 

Danke und viele Grüße

Björn

[blub 115]

klist tgt

bekommst du ein TGT Ticket vom DC?

Sind die Daten im oberen Teil der Ausgabe schlüssig?

[lefg 276]

Meine liebste Hauptverdächtige ist die Namensauflösung per DNS.

[Blase 15]

Hallo ihr beiden,

 

@lefg - ein "nslookup" vom Client aus wird normal mit der ip v4 Adresse des Servers zzgl. dessen FQDN beantwortet. Das sollte "reichen", oder?

 

@blub - den Befehl kenne ich überhaupt nicht. Also das sieht so bei mir aus:

Aktuelle Anmelde-ID ist 0:0x35e56

Zwischengespeichertes TGT:

ServiceName        : krbtgt
TargetName (SPN)   : krbtgt
ClientName         : Funke
DomainName         : MeineDomäne.LOCAL
TargetDomainName   : MeineDomäne.LOCAL
AltTargetDomainName: MeineDomäne.LOCAL
Ticketkennzeichen       : 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize 
Sitzungsschlssel        : KeyType 0x12 - AES-256-CTS-HMAC-SHA1-96
                   : KeyLength 32 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
StartTime          : 7/18/2016 16:00:28 (lokal)
EndTime            : 7/19/2016 2:00:28 (lokal)
RenewUntil         : 7/25/2016 16:00:28 (lokal)
TimeSkew           :  + 0:00 Minute(n)
EncodedTicket      : (GrӇe: 1136)

Anschließend kommt jede menge Hexadezimales Zeugs... "Klingt" gut, oder?!

[Sunny61 773]

Eine Variante wäre auch noch, aus der Domäne raus, Reboot, und wieder in die Domäne rein. Nach dem entfernen aber auch das Konto im Ad löschen.

[lefg 276]

 

@lefg - ein "nslookup" vom Client aus wird normal mit der ip v4 Adresse des Servers zzgl. dessen FQDN beantwortet. Das sollte "reichen", oder?

 

Mir reichte es gewiss nicht. Ich führte am Client wohl ein ipconfig /registerdns aus, schaute in die Liste im DNS, schaute, ob es eine neue Fehlermeldung im Ereignisprotokoll gibt.

 

Ereignisprotokoll, wurde dort schon reingeschaut? Es wurde noch nicht erwähnt, nicht wahr?

 

Ansonsten versuche es mit der von Sunny in #5 empfohlene Methode!

bearbeitet 18. Juli 2016 von lefg

[blub 115]

Hallo Blase,

Wenn du ein gültiges TGT-Ticket vom DC bekommst, haben du und der Client sich schonmal erfolgreich angemeldet! Das ist gut :-

d.h.

- DNS funktioniert

- du hast dich nicht mit einem lokalen User, sondern einem Domainuser angemeldet

- du hast dich nicht mit einem zwischengespeicherten Profil angemeldet. (das hatte ich vermutet, daher die Frage)

 

Wenn du jung und wissbegierig bist , kannst du noch diese Schritte untersuchen

- hängt dieser Rechner in derselben OU wie die anderen Clients?

- gpresult /H /F c:\temp\badclient.html (dauert immer einen Moment)

sind in der Ausgabe weder user noch machinepolicies zu sehen?

- kannst du von dem Client auf \\<DCName>\Sysvol zugreifen und weiter auf den GPO-Ordner?

- hast du schonmal mit enem Netzwerkmonitor (wireshark.org) gearbeitet? Der liefert dir die besten Informationen: DNS, LDAP, krbtgt und SMB sind die entscheidenden Protokolle, auf die du Filtern solltest. Gerade wenn du funktionierende und nichtfunktionierende Clients miteinander vergleichen kannst!

 

In meinem Alter würde ich wahrscheinlich den von Sunny vorgeschlagenen Weg im vorletzten Post bevorzugen

 

blub

[Blase 15]

Mahlzeit in die Runde,

 

*gg* also als jung würde ich mich nun nicht mehr bezeichnen - das wissbegierig lassen wir mal so stehen ;)

 

Vorwegnehmen kann ich, dass sich der Benutzer und auch der Computer in der selben OU befindet, wo auch die restlichen User und Computer sich jeweils befinden - und dass vom Benutzer aus Zugriff auf das Sysvol Verzeichnis inkl. GPO Ordner darunter besteht.

 

Ich habe ab hier dennoch den vorgeschlagenen Weg gewählt und die Maschine einmal komplett aus der Domäne herausgenommen und wieder eingefügt (Computer Konto nach Herausnahme im AD gelöscht). Habe das (zu diesem Zeitpunkt ohnehin "jungfräuliche") AD User Profil vom Client gelöscht. Ein gpresult zeigt nun, dass zumindest die Default Domain Policy angewendet wird - immerhin. Nicht aber meine zusätzliche Richtlinie, wie sie scheinbar von allen anderen Clients aber genutzt wird. U.a. geht es da um eine Ordnerumleitung der eigenen Dateien auf einen Serverpfad. Sie taucht auch nicht unter den "Abgelehnten Gruppenrichtlinienobjekten" auf.

 

Die Richtlinie ist direkt unterhalb der Domäne.local Struktur erstellt und verknüpft (inzwischen auch "Erzwungen") - gleich unterhalb der Default Domain Policy. In der Sicherheitsfilterung ist eine AD Benutzer Gruppe eingetragen, in welcher alle relevanten Benutzer enthalten sind - so natürlich auch der betroffene Benutzer, um den es hier geht.

 

Was auch immer das "allgemeine Problem" vorab war (er hatte sich ja nicht einmal die Default Domain Policy gezogen), das scheint behoben. Nun bin ich allerdings mit meiner eigenen Richtlinie immer noch nicht weiter.

 

Ideen?

 

Gruß

Björn

[duerener 12]

Hallo,

 

die authentifizierten Benutzer dürfen lesen? Hierzu gab es ja letzten Monat einiges...

bearbeitet 19. Juli 2016 von duerener

[Sunny61 773]

Ergänzend zu duerener hier noch zwei Artikel zu dem Thema:

http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

http://www.gruppenrichtlinien.de/artikel/statt-loopback-benutzer-richtlinien-auf-eine-gruppe-von-computern-filtern/

[NorbertFe 1.809]

Weißt du, wozu "erzwungen" genutzt wird? Ich vermute nicht, sonst würdest du es in diesem Fall nicht nutzen.

[blub 115]

- hat die Usergruppe "Read" + "Apply" in der GPO-Filterung der GPO?

- ebenso "domain computers", falls "authenticated users" gelöscht wurde

- Wenn es an dem von Duerener beschriebenen Patch liegt, wird die GPO auf keinem Client angewendet. Aber das definitiv nicht der Fall?

[Blase 15]

Hallo,

 

die authentifizierten Benutzer dürfen lesen? Hierzu gab es ja letzten Monat einiges...

 

Danke!!!! :jau:

 

Ja, das war es wohl. Nachdem ich im Reiter Delegierung die Authentifizierten Benutzer rein gemacht habe (waren sie nicht) mit "Lesen" Berechtigung und anschließendem gpupdate /force wurde mir beim Client schon angezeigt, dass für die "Folder Redirection" (zentraler Bestandteil der besagten Richtlinie) einmal ab- und wieder anmelden nötig sei. Nachdem auch das vollzogen war, sah man direkt die eigenen Dateien auf dem passenden Server liegen (aus Sicht des Clients). Super!

 

Bleibt jetzt aber grade die Frage, warum das von Anfang an und immer noch bei den ganzen anderen Clients problemlos funktioniert hat...?! Die haben auf jeden Fall - durch diese Gruppenrichtlinie - ihre "Eigenen Dateien" und Co auf dem Server liegen. Nun ja, ich schaue mir das noch mal genauer bei den anderen an, wobei ja spätestens jetzt ohnehin nicht mehr nachzuvollziehen wäre, wenn die auch Probleme mit dieser Gruppenrichtlinie hätten - ich habe es ja nun umgestellt...

 

@NorbertFe - jetzt weiß ich es ;)  Hast Recht - hätte ich mir sparen können. In meinem konkreten Fall hat das aber keine Auswirkungen in irgend einer Form.

 

@blub - In der Sicherheitsfilterung der Richtlinie steht eine bestimmte Benutzergruppe (alle "aktiven" AD User in dieser Gruppe) drin - in der Delegierung taucht die Gruppe auf mit "Lesen (durch Sicherheitsfilterung)". Im Bereich der Delegierung sind auch andere (eher "administrative") Gruppen drin - zzgl. der Authentifizierten Benutzer, die ich dank der Frage von duerener nun auch drin habe...

 

Gruß

Björn

[NorbertFe 1.809]

Es hat in den meisten Fällen keine Auswirkungen, weil es fast immer falsch verwendet wird. Genau wie gpupdate /Force ;)

[daabm 1.186]

Bei den anderen Clients hat es vmtl. auch nicht mehr funktioniert, nur merkt es da keiner, da ja alles schon so ist, wie es sein soll. Die DDP wird normalerweise von Clients nicht angewendet, weil Clients keine Account-Settings auf Domänenebene verarbeiten, das macht nur der PDCe. Gilt aber nur, wenn man da keine weiteren Einstellungen gemacht hat :)

PS: Danke an MS für MS16-072 - mehr "Vergnügen" hat uns schon lange kein "Hotfix" mehr beschert :) :) :)