wznutzer

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.

Ja, scheint so. Die Informationen von MS sind komplett durcheinander. Im deutschen KB-Artikel steht das Problem unter "Verbesserungen" und im englischen unter "known issues". Gleichzeitig steht im KB-Artikel vom Juli (seit da gibt es das Problem) dass es mit dem September-Patch behoben ist. Prima Informationsfluss .

Hallo und guten Tag, seit dem Patchday 07/2024 gibt es ein von Microsoft bestätigtes Problem mit dem RDP-Gateway. Wenn RPC over HTTP verwendet wird crasht der Dienst sporadisch mehrfach am Tag. Lt. den Releasenotes von Microsoft sollte das Problem mit dem September-Patch behoben sein, ist es aber nicht. Hat da evtl. jemand nähere Informationen oder kann bestätigen, dass das Problem noch vorhanden ist? https://support.microsoft.com/en-us/topic/september-10-2024-kb5042881-os-build-20348-2700-5b548143-9613-4e5a-9454-8ed9be8b2bd2 (Improvements) Was ist der schnellste Weg an Informationen von Microsoft zu kommen? Eine Anfrage über https://support.serviceshub.microsoft.com/supportforbusiness? Vielen Dank

Wie seht Ihr die Vertrauenswürdigkeit? Bei OPSI oder ähnlichen Systemen sorge ich selber dafür. Aber bei WinGet, Chocolatey usw. habe ich ja vor der Installation nicht die Chance Herkunft, Signatur, Hash oder ähnliches zu prüfen. Man vertraut einfach dem Repository. Während beim MS, Apple oder Google noch jemand die Hand drauf hat, ist das bei den genannten nicht so. Oder ist das ein Hängen an alten Zöpfen?

Damit hat es nichts zu tun. Einzig die Option (bzw. ich kenne keine andere) media.peerconnection.enabled auf false zu setzen, hält Firefox davon ab. Naja, ein richtiges Problem scheint es nicht zu sein, aber wenigstens etwas gelernt.

Das werde ich versuchen und berichten...