daabm

Ja. Überschreiben.

Nein. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4670 "This event does not generate if the SACL (Auditing ACL) was changed." Edit 1: Grad noch gefunden - das ist ein anderes Audit-Setting: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4715 Edit 2: Und jetzt auch noch gelesen - hm, nein das scheint was anderes zu sein. Da wäre jetzt Recherche erforderlich...

Da fällt mir spontan immer das hier ein: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj721517(v=ws.11) Wird natürlich mehr als anstrengend in heterogenen Umgebungen - aber wenn alles unter Windows läuft und in der Domäne ist, ist das einfacher als hunderte von FW-Freigaben.

Advanced Auditung und NTFS SACL sollte helfen. Für Freigaben aber nicht, wobei deren Rechte in der Registry stehen - und Registry kann auch per SACL mit Advanced Auditing überwacht werden. So als Denkhilfe : Wobei das jetzt "global" gelten würde - das Löschen musst pro Ordner setzen, kann man aber für Unterordner durchvererben.

Um das aufzuklären - da gibt's mehrere Aspekte... DDP und DDCP haben statische GUIDs, die in jeder Domain gleich sind. Mit dcgpofix kann man den "Originalzustand" wiederherstellen. Das ist der eine Grund, daß man die nicht anfasst. Wenn was damit schiefgeht und man dcgpofix braucht, sind eigene Anpassungen natürlich weg. Und dann gibt es noch das "Phänomen" der engen Verbindung zwischen Account-/Kerberos-Settings in Domain Policies und dem PDC-Emulator. Der ist der einzige Computer in der Domäne, der Kerberos-Settings anwendet, die mit der Domäne verlinkt sind. Und er ist der einzige Domain Controller, der Account-Settings verarbeitet, die ebenfalls mit der Domäne verlinkt sein müssen (Links an Domain Controllers werden ignoriert). Die wiederum schreibt er dann in Attribute im Domain Head (des Domänen-Objekts in Active Directory). Ändert man DORT jetzt was, dann findet das seinen Rückweg - aber nicht in die eigene GPO, sondern anhand der statischen GUID in die DDP. Ein "gpupdate" behebt dann die jetzt abweichenden Einstellungen im Domain Head, weil Security Settings per Default auch dann verarbeitet werden sollten, wenn sie sich nicht geändert haben (https://admx.help/?Category=Windows_11_2022&Policy=Microsoft.Policies.GroupPolicy::CSE_Security). Und selbst wenn man das nicht aktiviert - alle 960 Minuten werden sie zwangsweise verarbeitet, was man auch nicht abschalten kann. Ok, man kann schon, aber das wollen wir jetzt nicht breit treten... Und damit stellt man am Ende sicher, daß die eigenen Account-Settings aus der eigenen GPO auch dann wirksam sind, wenn jemand im Domain Head rumfuhrwerkt... Hoffe das war jetzt nicht zu kompliziert Jein. Die Anzahl von GPOs ist irrelevant (unsere größten Domänen haben weit mehr als 10.000) - das sind ja einfach nur Container unter CN=Policies,CN=System und Ordner in Sysvol. Die Anzahl der GPO-Links pro OU ist limitiert, weil im GPLink-Attribut nur 999 GPO-CNs reinpassen. Und dann gibt es noch das Problem der Verarbeitungsgeschwindigkeit, aber das ist ein sehr weites Feld... Bissle was dazu hab ich mal runtergeschrieben: https://evilgpo.blogspot.com/search?q=performance Aber das ist bei weitem nicht erschöpfend. "Eine GPO pro Setting" ist aber definitiv der falsche Weg.

Nicht daß Du in einer User-GPO auch noch was dazu drinstehen hast? Normal gewinnt ja Computer, hier aber: User policies take precedence over computer policies. If a user policy is set, the corresponded computer policy is ignored. If a user policy isn't set, the computer policy is used Und dann finde ich in https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/multifactor-unlock?tabs=intune noch so ein "Achtung" When the DontDisplayLastUserName security policy is enabled, it is known to interfere with the ability to use multi factor unlock. Leider steht nicht dabei, was "interfere" hier genau bewirkt.

[OT] In der DDP setzt man gar nichts . Man macht sich eine eigene, die man oberhalb der DDP verlinkt. Und da kommen auch nur Settings rein, die da reingehören - Account und Kerberos, sonst nichts. [/OT]

Quelle dazu gibt es keine, das ist "Windows internals". Aber "Security" paßt - man muß berücksichtigen, daß das aus der NT-Entwicklung stammt, also so Anfang der 90er designt wurde.

"Unter dem normalen User" - hat der Admin-Rechte? Sonst fehlen Computereinstellungen...

Wenn die GPO nicht angezeigt wird, stimmt was mit der Verlinkung nicht.

Wenns per IP geht und per Hostname nicht - UND der Hostname auf die korrekte IP auflöst - hast Du ein Problem mit Kerberos. Und das solltest Du im einen oder anderen Security Event finden. Hintergrund: "Name" macht per Default Kerberos, nur wenn kein SPN gefunden wird kommt NTLM Fallback. IP macht immer NTLM.

Hat doch bei Dir nichts mit der Uhrzeit zu tun... Nennt sich "Zustand" oder "Wesensart". SCNR 😂

Das dürfte nichts helfen - ich tippe eher auf "normale" Anmeldeprobleme, z.B. die TS Credential Delegation oder Probleme bei NLA oder was weiß ich. Das ist etwas diffus so "remote" RDS-Host ist hier erst mal noch nicht beteiligt IMHO.

Macht dein RDS-Host DHCP und hat ne neue IP bekommen? Stimmen alle Namen und IP-Adressen im DNS? Was sagt bei dem fehlgeschlagenen Anmeldeversuch das Security-Eventlog des RDS-Hosts und des/der Domain Controller? Fragen über Fragen

Aus 18.0 wurde ja schon 18.0.1, d.h. ganz grobe Bugs sollten schon weg sein

Du bist beim falschen RZ. Komm zu uns, wir haben Kekse 🍪 SCNR... 😂

Ich schmunzle da nicht mehr 😒 Wir arbeiten seit 3 Jahren daran, und es ist - hm - "zäh" wäre ein Euphemismus... Mit Kerberos only fängt man sich gleich noch ganz viel DNS ein (Disjoint Namespaces, Hostnamen in "irgendwelchen" DNS-Zonen etc.). Meist ist das der Zeitpunkt, wo man merkt, daß das DNS-Design zwar "schön" aussieht, technisch aber eigentlich unbrauchbar ist. Jaja, Limits im Code. Heute über eins gestolpert... Wollte per Skript Domain_Realms konfigurieren, gibt ein Policy Setting dafür: https://gpsearch.azurewebsites.net/#1823 Ok, REG_SZ kann ich auch per Skript schreiben, gesagt getan - tut aber nicht. WTF? Ok, es waren 100 DNS-Zonen für ein Realm. Eigentlich weit von der Grenze von 64 kB (?) entfernt, die ein Reg-Wert groß werden darf. Aber haste nicht gesehen, da gibt's doch tatsächlich findige MS-Programmierer, die vor vielen Jahren mal "irgendwas" gedacht haben: Mit Zone #82 haben wir diese Grenze überschritten...

Hätte ich vorher noch mal genauer recherchieren sollen, wo da die Limits sind 🙈 mea culpa Wobei ich zu den 5 Tagen nichts finde. https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/ADSchema/a-msds-logontimesyncinterval.md

LastLogon geht, aber nur wenn der "most recent DC" nicht ausgetauscht wurde. Dann wäre es weg TGT/TGS hilft nur, wenn Du NTLM deaktiviert hast - viel Spaß dabei... Einfacher ist es, das Replikationsintervall von LastLogonTimestamp runterzusetzen. In halbwegs modernen Infrastrukturen sollten auch 30 Minuten kein Problem darstellen. Die Infrastruktur-Annahmen beim Design von AD berücksichtigten noch analoge Wählleitungen 🙈

Mount Points sollten gehen.

[OT] Wireshark kann die netsh-Traces auch lesen, wenn man sie vorher konvertiert. Ein paar Meta-Informationen gehen dabei verloren, aber nichts wesentliches. [/OT]

Du hast irgendwelche Grundlagenprobleme - das lässt sich per Forum nicht lösen, wenn Du nicht deine komplette Infrastruktur offenlegen willst Bisher hab ich ja nicht mal nen GPResult von "funktioniert wie erwartet" und "funktioniert nicht" gesehen.

Ja. Alles irrelevant.

Was genau wird da aufgerufen? Kann der User das auch interaktiv aufrufen, wenn er in der fraglichen Gruppe ist?

Dann ist GPResult Dein Freund. Gern mit /h report.html, ist einfacher zu lesen. Welche GPOs werden angewendet, welche nicht und warum nicht?