Login in Domäne trotz Zeitunterschied möglich

[z3r0privacy 0]

Hallo zusammen,

 

Ich habe in einer Testumgebung eine Domäne aufgesetzt, mit einem Windows Server 2012R2 als DC und mit einem Win7 als Client.

 

Standardmässig liegt die "Maximum tolerance for computer clock synchronisation" bei 5 Minuten. Für mich bedeuted das, dass wenn der Client mehr als 5 Minuten vor oder hinter dem DC ist, dass das Login fehlschlagen sollte. 

 

Allerdings funktioniert das nicht, resp. das Login funktioniert problemlos. Sogar wenn der Client über ein Jahr in der Zukunft liegt. Woran kann das liegen? Muss ich noch etwas zusätzliches konfigurieren damit das funktioniert oder wie kann ich erwingen, dass das Login verhindert wird?

 

Functional level der Domain und Forest sind beide 2012R2

 

Danke und freundliche Grüsse,

Michi

[DocData 85]

Stichwort: Cached Credentials.

[z3r0privacy 0]

Stichwort: Cached Credentials.

 

Ich kann mich auch einloggen, wenn ich einen neuen User anlege, welcher sich noch nie angemeldet hat...

[blub 115]

sieh dir doch mal mit "klist tgt" das Kerberos Anmelde-Ticket an.

- Hast du überhaupt eines?

- relativ weit oben in der Ausgabe siehst du die Anmeldezeit und den Timeskew

- auch in den Security-Eventlogs siehst du, wie sich der Client tatsächlich anmeldet

 

blub

[z3r0privacy 0]

Ja, ich habe ein Ticket bekommen. Der Timeskew ist -180 Minuten (also ist der Client 3 Stunden voraus), was mit den aktuellen Einstellungen auch überreinstimmt.

 

Im Eventlog vom Domain Controller habe ich zu dieser Zeit meherere Audit Success von Kerberos, einige den User, andere den Client betreffend. Soll ich diese auch noch posten? Und wenn ja welche davon?

 

Ausserdem habe ich gesehen, dass die Maximum tolerance ...." Policy nur in der Default Domain Policy auf 5 Minuten gesetzt ist, in der Default Domain Controllers Policy ist diese Richtlinie nicht definiert, könnte es das sein?

 

[blub 115]

Da ist glaube ich ein Verständnisproblem:

- Du (=dein Useraccount) meldest dich nicht am Client, sondern am DC an. Daher hat dein TGT-Ticket auch die Zeit des AnmdeldeDCs.

- Dein Client versucht sich mit seinem Computerkonto und seiner (verdrehten) Zeit am DC anzumelden und bekommt bei TimeSkew > 5 Minuten eine auf die Finger.

 

führ doch mal beispielsweise "gpupdate" aus (bitte ohne -force, sonst werden wir geschimpft   ).

Die Userpolicy dürfte in jedem Fall gezogen werden.

Die Clientpolicy nur, wenn die Clientzeit soweit im Rahmen liegt. Ohne ClientTicket gibt's kein Sessionticket für den Client

 

Große Probleme gibt es, wenn mehrere DCs einer Domäne nicht ausreichend synchron laufen.

 

Ich hoffe, dass stimmt so einigermaßen.

blub

[NorbertFe 1.812]

Ich beschimpfe doch niemanden :p

[z3r0privacy 0]

Ok danke, ich werde das mal versuchen.

 

Das kann aber leider ein wenig dauern, bin die nächsten Tage abwesend. 

[z3r0privacy 0]

Ich konnte gpupdate (mit und ohne force) testen.

 

In beiden Fällen erhielt ich das von dir prophezeite Ergebnis: 

- die Userpolicy wurde gezogen,

- die Clientpolicy schlug wegen der zu grossen Zeitdifferenz fehl.

 

Soweit ich das verstanden habe, hat der DC meinem Client "auf die Finger gehauen", jedoch dürfen sich User trotzdem von diesem Client aus an der Domäne authentifizieren. Dies weil sie sich nicht am Computer sondern an der Domäne (=DC) einloggen. Der Client jedoch mit seiner falschen Zeit konnte sich nicht an der Domäne mit seinem Computerkonto anmelden. Deshalb schlug die Clientpolicy beim gpupdate fehl.

 

Habe ich das soweit richtig verstanden? 

[zahni 521]

Schau Dir  mal https://technet.microsoft.com/en-us/library/jj852241(v=ws.11).aspx . Vielleicht  hilft das bei Deinem Problem...

[blub 115]

Habe ich das soweit richtig verstanden? 

Ich denke schon. User- und Clientzeit getrennt für die User- und Client Kerberostickets zu betrachten, ist ja sinnvoll.

[zahni 521]

Ich meinte: Vielleicht passiert irgendetwas über NTLM...

[z3r0privacy 0]

Ich meinte: Vielleicht passiert irgendetwas über NTLM...

 

Die Richtlinie "Network Security: Restrict NTLM: NTLM authentication in this domain" steht auf "Deny All"...