Sysvol asking for credentials at a sudden

[reinht 2]

I set-up a new physical DC with Windows Server 2022. The workstations are using Win10.

Domain login worked fine for over one month.

I'm using a vbscript in NETLOGON to map drives.

And suddenly from one day to the next it's not possible to run the vbscript because there is no longer access to NETLOGON (SYSVOL).

All customer specific shares work fine.

I didn't make any changes in configuration and it looks like even updates were not applied.

If I try to access SYSVOL by Windows Explorer a window turns up and asking for network credentials. Even if I type-in the right login data it turns up again and again with no access.

The strange thing is that sometimes access to SYSVOL is possible, mostly when I played around with Windows Explorer on the DC without any configuration changes.

Unfortunately, I can't replicate this.

Any ideas?

 

Thx,

  Reinhard

[NilsK 2.785]

Moin,

 

wir sind ein deutschsprachiges Forum. Lass uns dabei bleiben, das macht es für alle einfacher.

 

Um einzusteigen:

• was hat sich zwischen vorher und jetzt an dem System geändert?
• was sagen die Eventlogs auf dem DC und den beteiligten Clients?
• nur vorsichtshalber: schon neu gestartet?
• und mal ins Blaue: die Systemzeiten laufen synchron?

 

Gruß, Nils

 

bearbeitet 5. Juni 2023 von NilsK

[daabm 1.185]

UNC-Hardening aktiv und Kerberos kaputt?

"net share netlogon" - und die Netlogon-Freigabe ist NICHT das gleiche wie die Sysvol-Freigabe, auch wenn erstere ein Unterordner von zweiterer ist.

Um Nils noch zu ergänzen: Die Eventlogs werden in dem Fall nur was Sinnvolles hergeben, wenn das Auditing entsprechend aktiviert wurde. "By default" kommt da nix bei raus.

[NorbertFe 1.800]

Hatte neulich erst einen Kunden mit ähnlichem Fehlerbild:

https://administrator.de/forum/win10-unc-hardening-und-sicherheit-375758.html

 

Zitat

Interessante Sache, aber habe die Ursache gefunden, es ist eine Nebenwirkung einer anderen GPO:
Administrative Vorlagen \ Systemsteuerung/Anpassung \ Ein bestimmtes Standardbild für den Sperr- und Anmeldebildschirm erzwingen
und das lustige bildchen lag auf \\domain.local\NETLOGON\W10\sperrbildschirm.jpg

 

 

[reinht 2]

Danke für die Unterstützung.

 

Es ist schon seltsam, jetzt tut wieder alles wie es soll.

Der Zugriff auf NETLOGON is möglich und somit auch das Mapping. Ich habe an der Konfiguration nichts geändert!

 

Zuvor, wie aus heiterem Himmel, ging es für einige Zeit nicht mehr. UNC-Hardening hatte ich bereits enabled, mit den empfohlenen Einstellungen. Dies hatte leider keine Änderung gebracht. Ich habe es dann wieder disabled. Kerberos kaputt, eher nicht, dann hätte es nicht dann und wann wieder funktioniert.

 

• was hat sich zwischen vorher und jetzt an dem System geändert?

nein, selbst Updates wurden in diesem Zeitraum nicht eingespielt

• was sagen die Eventlogs auf dem DC und den beteiligten Clients?

im Eventlog kann ich leider hierzu nichts finden (vielleicht suche ich auch nicht an der richtigen Stelle)

• nur vorsichtshalber: schon neu gestartet?

unzählige Male.

• und mal ins Blaue: die Systemzeiten laufen synchron?

ja, die Zeit hole ich mir immer vom Server

 

Jedenfalls schon ein seltsames Phänomen. Mal schaun wie lange es funktioniert. Schon dumm, wenn man die Ursache nicht kennt:-(

 

Danke,

  Reinhard

 

 

[NilsK 2.785]

Moin,

 

Da es genau solche Effekte erzeugen kann: hast du das mit der Zeit geprüft? "Vom Server" ist immer so eine Sache, das kommt gleich nach "ich hab nichts gemacht". 

 

Gruß, Nils

[reinht 2]

Ja, dass mit der Zeit habe ich schon überprüft

WshShell.Run "Net Time \\SRV11 /Set /Yes", 0, True meinte ich mit vom Server holen.

Aber das tut ja auch nur, wenn der Zugriff auf NETLOGON möglich ist.

Nichtdestotrotz stimmen die Zeiten überein

 

Danke,

  Reinhard

[NorbertFe 1.800]

vor 10 Stunden schrieb reinht:

Net Time \\SRV11 /Set /Yes", 0, True meinte ich mit vom Server holen.

Das ist nicht dein Ernst. :/ net Time im Jahr 2023. konfiguriere w32time korrekt, denn net Time kann sowieso nur ein lokaler Admin (oder jemand mit der entsprechenden Berechtigung) ausführen.

https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo

[reinht 2]

Ja, "Net Time..." ist von gestern, habe das Script vom Server 2012 übernommen. Service w32time macht das Ganze besser und sogar automatisch.

Zurück zu meinem Problem.

Folgendes konnte ich feststellen: Wenn beim Start von Win10 gleich nach dem Erscheinen vom Login Bildschirm das Login erfolgt, dann kommt es zu dem Problem mit SYSVOL. Wird jedoch noch etwas gewartet bevor das Login erfolgt, dann funktioniert es auch mit SYSVOL. Da scheint ein Service noch nicht bereit zu sein.

 

Danke für die Unterstützung,

  Reinhard

[Nobbyaushb 1.359]

vor 11 Minuten schrieb reinht:

Folgendes konnte ich feststellen: Wenn beim Start von Win10 gleich nach dem Erscheinen vom Login Bildschirm das Login erfolgt, dann kommt es zu dem Problem mit SYSVOL. Wird jedoch noch etwas gewartet bevor das Login erfolgt, dann funktioniert es auch mit SYSVOL. Da scheint ein Service noch nicht bereit zu sein.

Dazu setzt man eine GPO "auf Netzwerk warten"
Können bestimmt @Sunny61 oder einer der anderen den Artikel verlinken...

[Sunny61 773]

vor einer Stunde schrieb reinht:

Wenn beim Start von Win10 gleich nach dem Erscheinen vom Login Bildschirm das Login erfolgt, dann kommt es zu dem Problem mit SYSVOL. Wird jedoch noch etwas gewartet bevor das Login erfolgt, dann funktioniert es auch mit SYSVOL. Da scheint ein Service noch nicht bereit zu sein.

Ein Problem ist sicherlich der sog. Schnellstart, gibt es seit W8. Ist bei uns und vielen anderen sicherlich abgeschaltet, negative Auswirkungen konnte ich noch keine feststellen. Wenn das nicht reicht, geht es hier weiter: https://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36

Die beiden Einstellungen in einem GPO setzen und auf die Clients passend verlinken. Ein Neustart kann an der Stelle nicht schaden.

 

Falls auch das keine Lösung bringt, dann kannst Du dir diesen Artikel ansehen und an ausgesuchten Testclients ausprobieren: https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich

[reinht 2]

Vielen Dank für eure Unterstützung.

So tuts: https://www.gruppenrichtlinien.de/artikel/fast-logon-schnelles-anmelden-asynchrones-startverhalten-ehemals-faq-36

Grüße,

  Reinhard

[NilsK 2.785]

Moin,

 

Prima, danke für die Rückmeldung.

 

Gruß, Nils