wznutzer

Fall das auch jemand bauen will. Ich habe mich dazu entschieden, die Rechte auf den OUs nicht zu entfernen (authentifizierte Benutzer), sondern stattdessen ein explizites verweigern zu setzen. Der einfache Grund ist, dass beim scripten mit dsacls es nicht möglich ist, einzelne Rechte zu entfernen. Es funktioniert so aber auch prima.

Hoppla, dann unerwartet für mich . Aber schön, dass man immer noch dazulernen kann.

Hallo und guten Tag, ich habe mal noch ein wenig rumgespielt um zu verstehen wie das mit dem ListMode funktioniert. ohne ListMode (dsHeuristics) 1) Man kann auf die Idee kommen, einfach den OUs das Recht "Inhalt auflisten" zu entziehen. Auf den ersten Blick funktioniert das. Man sieht als "normaler" Nutzer z. B. in den RSAT-Tools dann die Benutzer unter der OU ohne "Inhalt auflisten" nicht mehr und auch keine Unter-OUs. Aber Nutzer in Unter-OUs werden in Suchen angezeigt. OU001 ("Inhalt auflisten" entfernt) OU001.01 - nicht sichbar Usr002 - z. B. in RSAT-Tools nicht sichbar, aber in Suchen schon. Usr001 - nicht sichtbar Das scheint daran zu liegen, dass das AD die Berechtigungen auf eine unerwartete Art auswertet und der Kombination mit vererbten und direkt zugewiesenen Rechten. In diesem Fall ist das Recht "Inhalt auflisten" bei der Unter-OU OU001.01 noch gesetzt und somit kann der User Usr002 gefunden werden. Die Auswertung der Rechte scheint so zu sein: 1. verweigern, direkt zugewiesenen 2. erlaubt, direkt zugewiesenen 3. verweigern, vererbt 4. erlaubt, vererbt Sobald eine Bedingung zutrifft wird nicht weiter ausgewertet. D. h. ein vererbtes verweigern ist schwächer als ein direktes erlauben. Darauf muss man auch erst mal kommen. 2) Weiterer Versuch ohne AD ListMode. Man ersetzt einfach in der entsprechenden OU "Authentifizierte Nutzer" durch eine Gruppe die alle Benutzer- und Computerobjekte der entsprechenden OU enthält. Funktioniert prima, für alle außerhalb der OU sind die Inhalte nicht sichtbar, auch nicht in Suchen. GPOs werden sauber abgearbeitet. Aber je nach Tool mit dem man das AD anschaut, sieht man die oberste OU mit dem tatsächlichen Namen als "unbekannt". mit ListMode (dsHeuristics) Hier gehen die Infos wild durcheinander und sind teilweise schlicht falsch oder vielleicht auch einfach nur veraltet. Teilweise wird behauptet, dass "Inhalt auflisten" dann nicht mehr gebraucht wird oder auch die Vererbung unterbrochen werden muss. Evtl. waren aber auch die Microsoft-Entwickler bei der Idee betrunken. 1) Ist der ListMode aktiv und es wird bei einer OU das Recht "Inhalt auflisten" entzogen, verhält es sich anders als ohne ListMode. Es werden dann trotzdem noch die Unter-OUs, aber nicht direkt zugeordnete Benutzer-/Computerobjekte angezeigt. 2) Man darf nicht den Fehler machen und den Namen der Rechte versuchen einen Sinn zu geben um das zu verstehen. "Inhalt auflisten" und "Objekt auflisten" stehen in direktem Bezug zueinander: Ein Objekt (OU, Benutzer, Computer usw.) sieht man dann, wenn das zugreifende Objekt (mein Scope) das Recht "Objekt auflisten" auf dem anzusehenden Objekt besitzt und man auf dem Elternobjekt das Recht "Inhalt auflisten" hat. Es gibt also eine strikte Beziehung zwischen Objekt (Objekt auflisten) und Elternobjekt also Parent (Inhalt auflisten). Anhand der obigen Regel lässt sich das ganze Verhalten erklären. Außer es handelt sich um Computerobjekte. Die sieht man auch dann nicht, wenn man auf dem Computerobjekt das Recht "Objekt auflisten" besitzt und man auf dem Elternobjekt das Recht "Inhalt auflisten" nicht hat. Bei Benutzerobjekten hat man das Recht nicht standardmäßig. Wenn man solche Sachen macht, sollte man sich die Verarbeitung der GPOs anschauen. Im meinem Fall funktioniert es wunderbar, wenn man pro Mandant eine Gruppe hat in der alle Benutzer- und Computerobjekte drin sind und diese die entsprechende OU lesen können. Also praktisch eine mandantenspezifische "authentifizierte Benutzer - Gruppe".

Hallo, ich verstehe den List Mode (dsHeuristics) nicht. Es gibt List Content und List Object. Aber es macht nicht das was es soll bzw. wie es heißt und das noch abhängig, ob es eine Unter-OU gibt. Wenn ich z. B. bei der OU2 (siehe unten) die Berechtigung List Content entferne, wird der Content trotzdem angezeigt. Rot verhält sich irgendwie nicht wie erwartet. Evtl. kann mich jemand in die richtige Richtung schubsen.

Nachtrag: Genau das ist mir noch nicht klar, ob und was ich mit dsacls setzen muss.

Es ist eine Mischung aus beidem. Meinst Du die Berechtigungen auf AdminSDHolder oder auf einzelnen OUs? OK, das muss ich mir dann nochmals anschauen. Ich habe den Registry Key gesetzt und evtl. deswegen keinen Unterschied festgestellt. Ich bin mir nicht sicher, ob wir unter „Automatisierung“ das gleiche verstehen. Ich habe für meinen Fall ein Powershell-Script um einen User anzulegen. Beim ersten User der Gruppe wird auch die OU angelegt und die Berechtigungen mit dsacls gesetzt. Also schon „automatisch“, aber halt ohne irgendein großartiges System dahinter. Im Prinzip ist es so, dass das Script „nur“ für mich klickt. Wenn Du mir noch sagst, welches Buch, kaufe ich mir das am Ende noch :-).

Hallo und guten Tag, es ist gut möglich, dass ich da etwas nicht ganz verstanden habe. Ziel Normalen Usern soll es nicht erlaubt sein z. B. Mitgliedschaften von privilegierten Konten abzufragen oder Objekte (Benutzer, Computerobjekte) außerhalb ihrer eigenen OU sehen zu können. Was zu tun ist. Man leert die Gruppe Prä-Windows 2000. Man entfernt die Authentifizierten Benutzer vom AdminSDHolder-Objekt oder (besser) ersetzt das durch eine vorerst leere eigene Gruppe. Wenn nötig könnte diese Gruppe dann erweitert werden. Man entfernt auf den entsprechenden OUs ebenfalls die Authentifizierten Benutzer und ersetzt diese durch die Gruppe der berechtigen User. Es scheint zu funktionieren, aber ist es auch gut so? 1) Es gibt noch den Registry Key „List Object“ unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Ist das gesetzt, sollen Objekte nur noch gelistet werden, wenn das Recht vorhanden ist. Ich kann keinen Unterschied feststellen, ob dieser gesetzt ist oder nicht. Es hängt alles am expliziten Recht. Brauche ich das? 2) Muss man die Berechtigungen von OUs wirklich über ldp.exe setzen? Ich habe mal irgendwo gelesen, dass das der beste Weg sein soll. Zum Anschauen ist es jedenfalls besser. Es funktioniert, aber muss es sein? 3) Man kann ja trotzdem noch die Standardgruppen sehen. Ist das ein Problem? Ich will ja nicht verhindern das AD zu sehen, sondern nur evtl. das Auskundschaften erschweren. Grüße und ein schönes Wochenende

Hi, es ist "nur" eine Übergangslösung für ca. 2 Jahre. Bis der Softwareanbieter eine Webapplikation gebaut hat. Mehrere Forests, Domänen oder Vertrauensstellungen wird es nicht geben. Danke für den Hinweis.

Guten Abend und ein frohes Neujahr, in einem komplett neu aufgesetzten AD sollen sich die User mir "ihrer" Email-Adresse anmelden können. D.h. die Email-Adresse ist eindeutig, hat aber natürlich gar nichts mit meiner Domain zu tun. Hat man selber mehrere Domains kann man das mit einem Suffix machen. Das ist aber für diesen Fall unpraktikabel. Den UPN kann ich sowohl im Attribut selber oder auch per Powershell auf einen beliebigen Wert ändern. Es scheint da keine Plausibilitätsprüfungen auf ein Format (name@domain.de) zu geben. Ebenso funktioniert die Anmeldung, Gruppenauflösung, Replikation usw. völlig problemlos. Exchange, Hybrid oder ähnliches wird es da nie geben. Also in der Domäne firma.de kann es einen User mit dem UPN franz.muster@web.de geben und dieser kann sich problemlos anmelden. Soweit ich weiß wird beim Anmeldeprozess mit einem UPN die lokale Domäne und dann der globale Katalog durchsucht. Der Anmeldeversuch schlägt fehl, wenn dieser nicht gefunden wird. Also es funktioniert, aber ist das eine dumme Idee, es so zu machen? Ich rechne im Lauf der Zeit mit ca. 800 - 1.000 User. Grüße und einen schönen Abend

Das liegt an meiner Unwissenheit. Ich dachte die Vertrauensstellung geht nur verloren, wenn die Kennwörter des Computerkontos nicht übereinstimmen. Nein, leider nicht. Test-ComputerSecureChannel hat nach mehreren Neustarts (nachdem die Kommunikation wieder uneingeschränkt möglich war) noch immer FALSE gemeldet und auch die Anmeldung mit einem Domänenkonto war weiterhin nicht möglich. Test-ComputerSecureChannel mit Repair oder auch Reset-ComputerMachinePassword habe ich nicht probiert, sondern das Computerkonto gelöscht und den Client neu hinzugefügt.

Guten Tag, es gibt kein konkretes Problem zu lösen, aber verstehen würde ich es gerne. Windows 11 Enterprise mit Credential Guard, alles Updates, Domänenmitglied. Im Zuge von Tests habe ich eine Lokale Sicherheitsrichtlinie erstellt (Firewall-Richtlinie) um Verbindungen zu einem bestimmten PC zu verbieten. Durch den unten beschriebenen Sachverhalt wurde dadurch der komplette ausgehende TCP-Traffic verboten (UDP war noch erlaubt). Nach dem erstellen dieser Regel wurde der PC gesperrt, nach ca. 1 Stunde war keine Anmeldung mehr möglich, weil die Vertrauensstellung verloren war. Lt. Eventlog wurde das Event 3210 wenige Sekunden nach dem Erstellen der Regel und ziemlich zeitgleich mit dem Sperren des PCs protokolliert. Wie kann ein PC die Vertrauensstellung verlieren, wenn keine ausgehenden Verbindungen möglich sind? Lt. AD wurde das Computerpasswort vor ca. 1 Woche geändert. Besonderheit in diesem Fall wohl, dass TCP blockiert war, nicht aber alles andere. Erklärung warum der ausgehende Traffic komplett gesperrt war Wenn man in den Lokalen Sicherheitsrichtlinien eine Richtlinie erfasst (Block ausgehend) kann man z. B. keine Remote-IPs angeben. Nach dem Speichern geht man dann in die Regel und trägt die IPs ein. Beim Anlegen der Regel erscheint die Regel sofort in der Windows-Firewall (ohne Beschränkung auf IPs). Aber das nachfolgende Update aktualisiert die Regel in der Firewall *nicht*. Das wird erst beim nächsten Neustart aktualisiert. So lange gilt die ursprüngliche Regel, die dann alles blockt. Das geht sogar so weit, dass wenn man so eine Regel in den Lokalen Sicherheitsrichtlinien anlegt, ändert und dann ohne Neustart sofort wieder löscht, sieht man in den Lokalen Sicherheitsrichtlinien keine Regel, aber die Firewall-Regel der ersten Speicherung bleibt erhalten, ist voll funktionsfähig und kann nur noch über die Registry gelöscht werden. Da gehe ich mal von einem Fehler aus.

Ich glaube ich habe es verstanden. Ich frage mich aber immer, wie kommt man an solche Informationen ? Ich kann da zwei Nullen wegmachen und habe noch immer weniger . ==> andere Welten

Ich musste erstmal den Begriff googeln . Den Vorschlag von @daabm verwende ich derzeit nicht. Ich habe zwar immer die Registerkarten gesehen, aber nie verwendet. Weiß zufällig jemand, ob das auf die Performance geht (die Authentifizierung ohne Verschlüsselung). Ich das einigermaßen gängig oder baue ich da was, was kaum jemand kennt und/oder nutzt?

Ach jetzt wirds Tag, oberhalb meint die Verknüpfung an von der Zahl her niedrigerer Stelle . Aber die GPOs der OUs können dann ja noch immer das "überschreiben". Organisatorische oder technische Besonderheiten. Ist die DDP nicht den anderen gleichgestellt? Passwortrichtlinie ist separat und steht an Stelle 1 .

Extensiv, ausgedehnt / umfassend, ob ich es auch exzessiv (maßlos) mache, weiß ich nicht. Aber lt. @testperson ist es noch ausbaubar .

Guten Tag, evtl. habe ich den Begriff falsch gewählt. Während es üblich ist ganze Netzwerke voneinander zu treffen (VLANs), lese ich kaum etwas darüber die Windows-Firewall zu nutzen. Macht Ihr das auch? Ich mache das ziemlich extensiv mit RDP, WinRM, sogar die VeeamDienste schränke ich auf die nötigen Endpunkte ein. Ist das über das Ziel hinaus? Ich meine, man versucht sich ja so vor jemandem zu schützen der ohnehin schon im Netzwerk ist, andererseits gibt es ja die Sache mit lateral movement. Der kürzlich veröffentlichte Fall, bei dem über die Veeam-Dienste ein Konto angelegt worden war, wäre ja dadurch verhindert worden. Oder ist das in großen Netzwerken einfach nicht zu handeln? Grüße und einen schönen Tag

Zufällig habe ich das sogar gemacht. Die Stufe 3 aus der DDP raus und 5 in eine eigene GPO. Die spezielle GPO für DCs die ich hatte, ist dann auch überflüssig. Allerdings verstehe ich die Aussage nicht komplett. Warum oberhalb und warum meinst du Settings zu Accounts und Kerberos kommen in die DDP oder gerade nicht? Ich habe tatsächlich mal angefangen alles in eigene GPOs zu packen mit eindeutiger Benennung. Aber, wie gesagt, das war Zufall, das hätte ich auch ohne Bedenken in die DDP gemacht, Stufe 3 war ja auch drin. 1) Warum sollte man nichts in die DDP packen? Organisatorisch verstehe ich das, wenn man einen Fehler sucht und GPOs in Verdacht hat, ist es ja b***d in einer Richtlinie, die man deaktivieren will, ganz viele Sachen zu haben. Gibt es auch technische Gründe? 2) Gibt es ein Limit oder "best practice", dass man nicht mehr als X GPOs haben sollte? 3) Was für Settings zu Accounts und Kerberos meinst Du? Danke und Grüße Scheint tatsächlich kein Problem zu sein :-).

Guten Morgen, NTLMv1 sollte man idealerweise deaktiviert haben. Nun ist es so, dass es wahrscheinlich hier und da (wie bei mir) noch Überbleibsel aus vergangenen Zeiten gibt, in denen man die Clients per GPO auf 3 gesetzt hat. Bei allen Windows-Systemen die Support haben ist das der Defaultwert. Könnte ich nicht einfach in der "Default Domain Policy" das auf 5 setzen und die alte Client-GPO löschen? Bei den DCs sollte das sowieso gemacht werden und bei den Clients schadet es nicht. Irre ich mich? Danke und Grüße https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

Der User in der Firewall der verwendet wird um die Passwörter zu checken (LDAP Bind wie ich gelernt habe) und mit dem auch die Gruppen ausgelesen werden (z. B. darf VPN). Vermutlich wurde doch mal ein Recht vergeben und leider vergessen / nicht dokumentiert. Verstehe ich das richtig? Nicht zu müssen heißt aber zu können. Aber dann geht das Passwort beim LDAP Bind unverschlüsselt über die Leitung und das will man nicht. Richtig?

In meinen Fall ist der User nicht Mitglied, geht aber trotzdem. Das meinte ich damit.

Nein, die Erkenntnis hatte ich schon vor längerer Zeit. Deswegen ist das Computerkonto des RD-Gateway auch da drin. Jetzt muss ich aber noch rausfinden, warum die Abfrage der Gruppenmitgliedschaften geht, obwohl ich mich an keine spezielle Rechtevergabe erinnern kann. Danke für den Hinweis mit LDAP Bind. Das die Mitglieschaft der Authentifizierten User in der Prä-Windows 2000 Gruppe ein größeres Sicherheitsproblem ist, war mir tatsächlich nicht bewusst, war eher „braucht man nicht mehr“.

Ich kann z. B. schon jetzt aus Deiner Antwort „ableiten“, dass es eher schlecht ist, die Authenifizierten User in der Prä-Windows 2000 Gruppe zu haben . So hatte ich das auch mit dem Passwort im Sinn. Wie findet die Firewall heraus, ob das Passwort stimmt oder nicht?

Guten Morgen, es gibt kein Problem, aber verstehen würde ich es trotzdem gerne. Wenn man z. B. die User eines VPN der Firewall gegen das AD authentifizieren will, macht man z. B. im Fall einer Sophos einen Domainjoin in das AD und hinterlegt in der Sophos einen User in dessen Kontext Abfragen (Gruppenmitgliedschaften, Kennwort korrekt usw.) an das AD gestellt werden. Dieser User benötigt aber keinerlei besondere Rechte. Gruppenmitgliedschaften auslesen gehört zu den Standardberechtigungen, die man ja auch einschränken kann. Aber wie funktioniert das mit den Passwörter? Klar kann jeder User versuchen sich irgendwo mit einem fremden Account anzumelden und Passwörter erraten, aber wie macht das z. B. regulär eine Firewall? Auch mit einem Loginversuch, wo? Die Firewall braucht kein Passwort aus dem AD auslesen, es reicht ja die Info richtig oder falsch? Wenn man weiß wie das funktioniert, könnte man da evtl. ableiten, dass irgendwas besser verboten gehört, was bisher erlaubt ist? Danke und Grüße

Neuentwicklung: Der Fix wird lt. Support nicht in den Updates vom Oktober enthalten sein, sondern separat am 15. Oktober veröffentlicht werden. Insofern hat sich der Case dann doch gelohnt.

Für alle die das gleiche Problem haben. Und das hat man ja, wenn man nicht auf "RPC over HTTP" verzichten kann, was z. B. der Azure Anwendungsproxy nutzt. Ich habe einen Case bei Microsoft um herauszufinden, wann das Problem gefixt wird. Das weiß der Support auch nicht, aber ich soll einfach regelmäßig den Gateway-Dienst neu starten oder einfach die Updates seit Juli (insgesamt ca. 250 CVEs) deinstallieren und darauf achten, dass die Sicherheit trotzdem gewährleistet ist. Clown-Support.