phatair

Hallo zusammen, danke euch. Ich hatte das nicht in einem offiziellen MS Dokument gelesen, diese Behauptung hatte jemand im MS Forum aufgestellt https://learn.microsoft.com/en-us/answers/questions/123130/advance-audit-policy-no-longer-applying-after-runn Mir ist klar, dass ich mit gpedit.msc die lokalen Richtlinien sehe und diese von den Domain Policies überschrieben werden. Ich dachte nur, dass ich die Advanced Audit Policy "Überschreibungen" in der gpedit.msc sehe (wie z.B. in den Sicherheitsoptionen ja zu sehen ist, das Icon ändert sich). Ich hätte aber zumindest erwartet, dass es im rsop.msc zu sehen ist. Aber auch dort sehe ich die Änderungen nicht. Laut dem oben verlinkten Artikel verstehe ich das auch so, oder stehe ich komplett auf dem Schlauch? Gruß

Hallo zusammen, ich habe folgendes Problem. Ich habe eine neue GPO erstellt in der ich die Advance Audit Policy konfiguriert z.b. für File Zugriff aktiviert habe. Ebenso habe ich folgende Einstellung in den Sicherheitsoptionen aktiviert -> Überwachung: Unterkategorieeinstellungen der Überwachungsrichtlinie erzwingen (Windows Vista oder höher), um Kategorieeinstellungen der Überwachungsrichtlinie außer Kraft zu setzen Wenn ich diese GPO nun auf den betroffenen Server aktiviere und mir dort per gpedit.msc die GPO Einstellungen anzeigen lasse, stehen weiterhin alle Advance Audit Policys auf nicht konfiguriert. Prüfe ich die Einstellung per auditpol /get /category:*, sehe ich das sie aber korrekt eingestellt sind. Ich habe nun gelesen, dass man die Advance Audit Policy nur in der Default Domain Policy aktivieren soll, damit es eben in der lokalen gpmc sichtbar ist. Das kann ich mir aber nicht vorstellen und hatte das auch getestet, war trotzdem nicht sichtbar. Kennt jemand das Problem und weiß wie ich es lösen kann?

Na sauber, dann hab ich ja mal schön mit Unwissenheit geglänzt Danke.

Danke - das war einfach :) Dann ist es bei uns tatsächlich über Kerberos abgesichert Dann muss ich hier mal noch etwas Suchen, damit ich das verstehe. Scheint dann ja doch "out of the Box" zu funktionieren, da ich nicht wüsste das hier bei uns etwas in der Richtung konfiguriert wurde. Dann erklärt es aber das Verhalten. Danke!

Hi Evgenij, die Frage ist vielleicht etwas peinlich, aber wie kann ich das prüfen? Bei uns ist RDP nur mit "Network Level Authentication" aktiviert, aber das hat ja erstmal nix mit Kerberos zu tun. Das was ich jetzt gefunden habe, scheint es ja nicht "out of the box" mit Kerberos abgesichert zu sein, daher würde ich jetzt bei uns mal sagen - das ist nicht der Fall.

Es wird nicht gesagt das der Name nicht stimmt, sondern das dem Zertifikat nicht vertraut wird, da die Root CA nicht in den trusted root certificates vorkommt (was ja auch korrekt ist), wenn ich mich per IP verbinde, sehe ich , dass es vom Server selber für sich ausgestellt ist. Auch der Zertifizierungspfad stimmt nicht und ist self signed. Ich könnte jetzt natürlich die Zertifikate für das RDP aktivieren und dann so prüfen ob das richtige Zertifikat gezogen wird. Aber das erklärt dann trotzdem noch nicht warum ich keine Meldung beim self signed Zertifikat per DNS Namen erhalte :( Aber wenn per IP dann das richtige Zertifikat (das von unserer PKI) gezogen wird, müsste es beim DNS Namen ja auch verwendet werden, oder?

Hi Evgenij, danke für den Tip. Das heißt also wenn der RegKey AuthenticationLevelOverride mit dem Wert 0 besteht, kommt die Meldung nicht, richtig? Aber der Key AuthenticationLevelOverride ist nicht vorhanden, somit sollte die Meldung doch erscheinen. Vor allem erscheint Sie auch, wenn ich per IP die RDP Verbindung aufrufe. Nur per DNS Name wird die Warnung nicht angezeigt. Nun kann man natürlich sagen, ist doch gut - aber ich würde gerne wissen warum Sie nicht angezeigt wird :) Wir wollen dann die Zertifikate für die RDP Verbindung verteilen und so könnte ich gar nicht sehen ob jetzt das korrekte Zertifikat genommen wird, da die Meldung ja so oder so nicht erscheint.

Hallo zusammen, irgendwie stehe ich gerade auf dem Schlauch und hoffe mir kann jemand helfen :) Wir haben zwar eine eigene interne PKI und hier auch schon ein Template für die RDP Zertifikate erstellt, aber aktuell haben wir für die RDP Zugriffe noch keine Zertifikate verteilt/konfiguriert. Es ist also nur das self signed Zertifikat auf den jeweiligen Server vorhanden. Nun würde ich erwarten, dass bei einem RDP Zugriff auf einen Server die bekannte Zertifikatsmeldung erscheint. Das tut es aber nicht. Ich kann mich einfach verbinden. Verbinde ich mich über die IP, kommt die Meldung und es wird das self signed Zertifikat erwähnt. Nun habe ich die Info gefunden, dass (falls man bei der Zertifikatsmeldung "nicht noch mal Fragen" angehakt hat) der Hash Wert vom Zertifikat dann im RegKey HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Servers gespeichert wird. Das habe ich geprüft, dort steht aber nichts drin. Mich wundert nun, warum aktuell die Meldung bei uns nicht erscheint, wenn wir per DNS Name uns auf die Server per RDP schalten. Hat jemand eine Idee woran das liegen kann? Kann man das irgendwo deaktivieren oder verstehe ich hier irgendwas falsch? ich habe auch schon das RemoteDesktop self signed Zertifikat auf einem Server gelöscht und neu erstellen lassen. Zugriff geht weiterhin ohne Zertifikatsmeldung. Vielen Dank. Grüße

Den Beitrag hatte ich doch glatt übersehen. Danke! Bezüglich der MS Sicherheits-Bulletins - das habe ich auch gelesen. Aber das scheint nur für Enterprise Kunden zu sein, da nur M365 E Lizenzen davon profitieren. Wir haben aber M365 Business Lizenzen und sind somit raus. Finde ich eine Frechheit, aber was soll man machen. Wir schauen uns halt immer verstärkt nach MS Alternativen um.

Danke euch. Ich werde das mal beobachten. Wir lassen jetzt die granulare Berechtigung. Wir monitoren die Server alle und die DCs langweiligen sich sehr. Mal schauen ob sich das ändert, wenn ja weiß ich ja wo ich hin fassen muss.

Danke Evgenij, war auch mein Bauchgefühl, aber war etwas verunsichert weil es so merkwürdig konfiguriert war. Dann habe ich jetzt noch ein bisschen was am Freitag zu tun :) Schönes WE. Jetzt habe ich doch noch eine Frage. Wenn ich die Audit Einträge so granular mache und für jede Klasse eigene Berechtigungen erstelle, komme ich auf 10 Einträge. Dann informiert mich aber Microsoft, dsas dies zu Problemen führen kann und zeigt mir diese Warnung an. Die Einträge setzen wir auf die oberste Domänenebene. Gehe ich richtig in der Annahme, dass hier 10 Einträge kein Problem sind? Ich wüsste nicht wie ich die zusammenfassen soll.

Hallo zusammen, ich bin gerade dabei das AD Audit zu überarbeiten, da wir ein Tool einführen mit dem wir die Überwachung verbessern. Nun ist es so, dass ein ehemaliger Kollege die SACL der Objekte so konfiguriert hatte, dass dort alle Klassen aktiviert sind. Das ist laut unserem Tool unnötig, da wir gezielte Klassen überwachen wollen und es gibt genaue Vorgaben welche man aktivieren soll. Ist es von Nachteil, wenn im Audit alle Klassen wie "Benutzer-Objekt erstellen", "Computer-Objekt erstellen", "msExchOmaDataSoruce-Objekt erstellen", usw. aktiviert ist? Macht das z.B. Performance Probleme oder ähnliches oder kann man sagen, macht Sinn, da man dann wenigstens alle Infos hat und abfragen könnte? Ich hätte jetzt gesagt, ich passe Sie an und wir protokollieren nur das mit, was wir auch benötigen. Danke euch. Gruß, Steffen

Das habe ich mich auch schon gefragt, aber noch nichts passendes gefunden. Ich schaue meistens bei Heise, Born und bei MS im Message Center Danke - dann werde ich mal schauen ob ich es komplett verstehe und dann aktivieren :)

Hallo zusammen, ich weiß das dieser KB schon älter ist, aber aktuell prüfen wir die Logs um zu prüfen ob wir hier Probleme haben/bekommen. Das erzwingen des Enforcement modes wurde auf Januar 2024 verschoben. Im KB Beitrag sind die EventIDs aufgeführt, die man prüfen soll. Nun ist es so, dass bei uns auf jedem der DCs beim Neustart folgende EventIDs geschrieben werden. Diese sind auch in den aufgelisteten EventIDs vorhanden Quelle: ActiveDirectory_DomainService Event-ID 3054 Die Info von MS dazu lautet "Mode Change Events – temporary removal of Implicit Owner rights" "Events that occur when bit 29 of the dSHeuristics attribute is changed, which changes the mode of the temporary removal of Implicit Owner rights portion of the update." Quelle: ActiveDirectory_DomainService Event-ID 3051 Die Info von MS dazu lautet "Mode Change Events – Additional AuthZ verification for LDAP Add operations" "Events that occur when bit 28 of the dSHeuristics attribute is changed, which changes the mode of the Additional AuthZ verifications for the LDAP Add operations portion of the update." Ich würde das jetzt aber so verstehen, dass dies nur Info sind zum einen über die neuen Berechtigungen informieren und dass man den enforcement mode aktivieren sollte um die bestmögliche Sicherheit zu erhalten. Die wirklich kritischen EventIDs wären die, die unter "Audit mode events" -> "Events that occur in Audit mode to log potential security concerns with an LDAP Add or Modify operation." gelistet werden (also 3047 - 3049 + 3056 und 3044 - 3046). Wie handhabt ihr das? Habt ihr den enforcement mode manuell aktiviert oder wartet ihr bis MS das aktiviert? Das manuelle aktivieren scheint ja nicht so einfach zu sein wie z.b. bei KB5020805, wo man einfach nur ein RegKey setzen muss. Hier muss ich ja wohl Attribute im AD anpassen. Oder verstehe ich das komplett falsch? Vielen Dank. Gruß, Steffen

Danke an alle. Vielleicht hatte ich mich mit der Aussage "In deinem verlinkten Artikel wird die Dokumentation und die Tests genannt, aber das würde ich bei unseren minimalen Berechtigungen vernachlässigen." etwas schlecht ausgedrückt. Ich wollte damit keinesfalls sagen, dass es für mich sinnlos ist, sondern bei einer Berechtigung auf 1 OU (wie in unseren aktuellen Fällen) ich es persönlich nicht so gravierend finde. Sinn macht es natürlich schon, auch diese Berechtigungen zu dokumentieren, da gebe ich euch vollkommen Recht. Grundsätzlich bin ich für die Tipps und die Hilfe hier immer sehr dankbar. Alles können wir nicht 1:1 umsetzen, aber es hilft sehr Prozesse zu optimieren. Ich werde mir die Tools anschauen und eure Ratschläge zu Herzen nehmen. Gerade der Punkt "code reuse" ist auch sinnvoll, wenn man die Berechtigungen nicht so oft macht. Dann hat man einfach etwas vorgefertigtes, spart Zeit und reduziert Fehler. Ich habe die Einwände also verstanden. Das nächste Mal versuche ich meine Nachfrage gezielter zu stellen, dann vermeiden wir hoffentlich die OT Diskussion Danke auch für die Info Links und das Tool Liza.

Hi Norbert, hast du einen schlechten Tag gehabt oder warum reagierst du so negativ und sarkastisch? Nein, es ist mir nicht egal und ich frage nicht nach, um zu hören, dass ich die gui nutzen soll. Verstehe überhaupt nicht wie du darauf kommst. Dann würde ich es einfach machen und nicht nach dem Grund fragen. Ich brauche doch nicht das ok von jemanden. Ich habe erklärt, dass meine Berechtigungen minimal sind und es könnte ja sein, dass eure Meinung zu der Berechtigung vor allem auf große Änderungen in komplexen Umgebungen beruht. Aber gut. Lassen wir das Thema einfach. Ich habe manchmal echt das Gefühl, wenn man hier etwas nachfragt, dass sich einige Personen hier immer angegriffen fühlen und man Sie und ihre Antwort in Frage stellt. Das habe ich in keiner Weise getan und wollte einfach nur wissen warum eine Aussage so drastisch formuliert wurde (NIE die gui verwenden). Habe es soweit verstanden. Danke. Gruß, Steffen

Danke Nils. Was genau ist der Grund, dass man die gui/ Assistent nicht verwenden soll? Ich möchte nur eine Gruppe mit einem Service Account für die ou berechtigen, da dieser beim onboarding Prozess die computer Objekte dorthin verschieben können muss. Ich habe auch schon mit dem Assistenten Berechtigungen vergebe und danach geprüft. Die Berechtigungen waren korrekt gesetzt. In deinem verlinkten Artikel wird die Dokumentation und die Tests genannt, aber das würde ich bei unseren minimalen Berechtigungen vernachlässigen. Klar kann man jetzt sagen, was spricht dagegen sich in die cli einzuarbeiten, ein Grund ist hier die fehlende Zeit und die Notwendigkeit, wenn es schon Möglichkeiten gibt die genau das tun was man möchte. Daher würde mich der Grund interessieren

Hallo zusammen, ich habe mal wieder eine kurze Frage, da mir ein Punkte in der Delegierung von Berechtigungen in der AD nicht ganz klar ist. Wenn ich einer Gruppe unter "Benutzerdefinierte Aufgaben" den Bereich "Computer Objekte zuweise und die Haken setze bei "Gewählte Objekte in diesem Ordner erstellen / löschen" und unter Berechtigungen "Lesen" auswähle, hat die Gruppe anschließend auf alle Computer Objekte in der OU und den untergeordneten OUs die entsprechenden Rechte (es kann Lesen und Computer Objekte löschen und erstellen) Wozu gibt es dann aber im Bereich "Berechtigungen" die Werte "Alle untergeordneten Objekte erstellen bzw. löschen". Mache ich die Schritte wie folgt -> unter "Benutzerdefinierte Aufgaben" den Bereich "Computer Objekte zuweise und die Haken bei "Gewählte Objekte in diesem Ordner erstellen / löschen" nicht setzen und dann unter Berechtigungen "Lesen" + "Alle untergeordneten Objekte erstellen bzw. löschen" auswähle, hat die Gruppe anschließend auf alle Computer Objekte in der OU und den untergeordneten OUs die entsprechenden Rechte (es kann Lesen und Computer Objekte löschen und erstellen). Der "Bereich" ist doch der Wert für den die Berechtigungen dann gelten? Also Bereich Computer gilt dann für alle Computer Objekte und mit den Berechtigungen sage ich dann, was genau mit diesen Computer Objekten gemacht werden darf. Oder übersehe ich hier etwas? Was ist der Unterschied der beiden Optionen? Vielen Dank.

Jetzt hab ich doch noch ein Hinweis für diese Thematik. Laut diesem MS Beitrag sollte man das umbenennen und Profil Pfad anpassen bei Windows 10 oder neuer unterlassen, da damit möglicherweise Winget nicht mehr funktioniert. Habe ich noch nicht getestet, da wir winget bei uns auch nicht verwenden. Nur der Vollständigkeit halber, falls jemand auf diese Thema hier stößt

Danke! Ganz so jung bin ich dann doch nicht mehr , aber wusste ich tatsächlich nicht, dass dies nur temporär mal für Windows 95 und ein paar Programme implementiert wurde. Das gebe ich mal an den Hersteller von unserem ERP System weiter. Die Helden prüfen dort den appdata Pfad ab.... Sonst wäre ich gar nicht auf diesen regkey gekommen. Bitte keine Rückfragen zu diesem System. Wenn ich könnte, wäre das System schon lange auf dem Müll gelandet

Wollte nur noch mal explizit drauf hinweise. Das man den Prozess anpassen kann, steht ja außer Frage :)

Wichtig ist noch, dass es Probleme gibt, wenn das Windows LAPS per April 2023 Update installiert wird und danach das Legacy LAPS zusätzlich installiert wird (oder eine legacy Policy aktiviert wird, dass weiß ich nicht genau). Ist ja oft beim onboarding der Fall, dass Clients erst die aktuellen Patches bekommen und dann mit Software bespielt werden. Note: We have verified a reported legacy LAPS interop bug in the above April 11, 2023 update. If you install the legacy LAPS GPO CSE on a machine patched with the April 11, 2023 security update and an applied legacy LAPS policy, both Windows LAPS and legacy LAPS will break. Symptoms include Windows LAPS event log IDs 10031 and 10032, as well as legacy LAPS event ID 6. Microsoft is working on a fix for this issue. You can work around this issue by either: a) uninstalling legacy LAPS, or b) deleting all registry values under the HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\State registry key.

Hallo zusammen, wir haben das Userprofile nun umbenannt und den Profilpfad in der Registry anpgeasst. Ebenso haben nach einer Anmeldung auch die Environment / Volatile Environment Einträge gepasst. Allerdings ist nun aufgefallen, dass in \HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders noch die alten Pfade eingetragen waren. So zum Beispiel AppData -> C:\Users\<alterUsername\AppData\Roaming Hätte ich die Environment Einträge in der Registry vor dem anmelden ändern müssen (in dem ich die ntuser.dat lade)? Oder ist es einfach so, dass man diese Einträge auch noch manuell anpassen muss. Unsere umgeleiteten Ordner haben natürlich gepasst, aber die lokalen Verzeichnisse haben alle noch auf den alten Usernamen gezeigt.

Hi Nils, das sieht interessant aus. Wenn ich das auf die Schnelle richtig gesehen habe, ist das ein alternative zu USMT (was wir zum Teil jetzt noch verwendet haben). Das werde ich mir auf jeden Fall mal zeitnah anschauen. Vielen Dank. Gruß, Steffen

Hi Jan, danke dir. Ich wollte jetzt eigentlich nicht alles neu Konzipieren :) Scripte ist vielleicht das falsche Wort. Wir haben in unserem unser Client Management Tool oft Variablen verwendet um Jobs zu bauen. Das möchte ich ungern alles anfassen. Hier wird halt oft C:\Users\%username\Appdata\local usw. verwendet (ja hier hätte man auch %LOCALAPPDATA% verwenden können ) Auch nutzen wir auf den RDP Server FSLogix. Aber darum sollte es hier erstmal nicht gehen. Mich würde nur interessieren, ob es Probleme gibt wenn man das User Verzeichnis unter C:\Users umbenennt und in der Regedit den entsprechenen Eintrag unter ProfilList anpasst. Bei MS habe ich auch einen entsprechenden Beitrag gefunden -> https://learn.microsoft.com/en-US/troubleshoot/windows-client/user-profiles-and-logon/renaming-user-account-not-change-profile-path Da wird das Vorgehen genau so beschrieben, nur reden die (so verstehe ich das) von lokalen Windows Accounts. Das ist bei uns ja nicht der Fall. Aber ich denke ich werde es bei dem aktuellen Fall einfach mal so probieren. Wenn es größere Probleme gibt, erstellen wir das Profil dann doch neu. Langfristig sollte man die Variable anpassen oder über ein anderes Konzept für Profile nachdenken.