GPO - User verbieten sich über das Netzwerk anzumelden

[wznutzer 32]

Guten Abend,

 

ich verbiete lokalen User oder auch bestimmten Domänenuser den Login über das Netzwerk. Das funktioniert an sich auch, will aber sicher sein, dass ich keinen Denkfehler habe.

 

DenyNetworkLogonRight - In der GptTmpl.inf heißt es SeDenyNetworkLogonRight, warum auch immer.

 

Gast-Nutzer

Klar, sind standardmäßig deaktiviert, aber da die GPO diese Einstellung nicht kumulativ setzt, sondern anstelle der Standardpolicy, hätte ich gerne die Gäste wieder drin.

 

Standardmäßig steht da der User Gast drin, der ebenso standardmäßig deaktiviert ist. Diesen User Gast kann ich nicht in die GPO aufnehmen, weil dieser eine lokale SID hat (S-1-5-21-irgendwas-501). Weil ich auch Clients habe, an denen sich lokale Konten anmelden müssen, gibt es eine GPO für Gäste + andere Konten, aber ohne pauschal alle lokalen Konten.

Um alle Gastkonten abzudecken füge ich folgendes hinzu: BuiltIn-Gäste (S-1-5-32-546), Domänengäste (S-1-5-21-domäne-514), Domänen-Gast (S-1-5-21-domäne-501). Der Domänen-Gast ist ebenfalls deaktiviert.

 

Ist das korrekt, vergesse ich was?

 

Vielen Dank und Grüße

 

 

 

 

[daabm 1.185]

https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

 

Wir haben ne Master-GPO, die für 46 Security Privileges lokale Gruppen definiert. Die können dann komfortabel über GPP Local Users and Groups verwaltet werden. Und da wiederum kann man mit WMI-Filtern ebenso komfortabel SID-basiert Gruppen/User auslesen, falls erforderlich. In den eigentlichen Security Privileges stehen nur die zwangsweise erforderlichen Einträge (manchmal muß SERVICE drinstehen, manchmal Administrators) sowie diese jeweiligen lokalen Gruppen.

 

Funktioniert prima

[wznutzer 32]

vor 14 Stunden schrieb daabm:

Wir haben ne Master-GPO, die für 46 Security Privileges lokale Gruppen definiert. Die können dann komfortabel über GPP Local Users and Groups verwaltet werden. Und da wiederum kann man mit WMI-Filtern ebenso komfortabel SID-basiert Gruppen/User auslesen, falls erforderlich. In den eigentlichen Security Privileges stehen nur die zwangsweise erforderlichen Einträge (manchmal muß SERVICE drinstehen, manchmal Administrators) sowie diese jeweiligen lokalen Gruppen.

Vielen Dank. Ich bin mir noch nicht sicher, ob ich das richtig verstanden habe. Ich muss das mal in Ruhe durchdenken und evtl. dann nochmals mit einer Frage zurückkommen.

 

Das hier verstehe ich nicht (aus dem Link)

• Der Server-Admin kann auf den Server auch remote zugreifen. Damit landet sein Passwort-Hash aber im Hauptspeicher des verwendeten Clients – und das will ich nicht. Also werden auf Clients die Server-Admins in CORP-LogonLocallyDeny aufgenommen – das geht per Zielgruppenadressierung auf Win32_OperatingSystem.ProductType=1.

Landet der Hash des Server-Admin, wenn er sich remote von einem Client anmeldet tatsächlich im Hauptspeicher des Clients? Ist der Hash nicht im RAM des Servers? Und wenn ich dem Server-Admin das Recht entziehe sich auf dem Client anzumelden, kann er sich doch noch immer vom Client auf dem Server anmelden.

 

[Client] ->> [Server] = Hash im RAM des Servers

[Server] ->> [Client] = Hash im RAM des Clients

 

Bin ich da irgendwo gedanklich falsch abgebogen?

[daabm 1.185]

"Remote" war hier das Szenario "Net use" mit anderen Credentials. Aber ich bin da auch nicht mehr ganz auf dem aktuellen Stand, wann welche Hashes nun wo rumliegen...

[wznutzer 32]

Das hier finde ich interessant. Network-Logons, also ein simpler Zugriff auf eine Freigabe, scheint in Ordnung, da muss man sich keine Sorgen machen. Konnte ich bestätigen, aber ich bin da überhaupt kein Experte.

 

https://www.ired.team/offensive-security/credential-access-and-credential-dumping/network-vs-interactive-logons

[daabm 1.185]

Ja, stimmt. Hab mich diese Woche mal wieder damit auseinander gesetzt, ein SMB-Zugriff hinterläßt in keinem Fall Credentials oder Hashes auf dem Remotesystem. Schwieriger wirds bei WSMAN/Powershell-Remoting.