phatair

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.

Hallo zusammen, ich habe eine kurze Frage. Wenn ich ein User AD Objekt umbenenne, kann ich mich ja problemlos weiterhin an einem Windows Client mit dem neuen Usernamen anmelden. Das alte Profil wird weiterhin gefunden, da es ja über die SID aufgelöst wird und die hat sich ja nicht geändert. Nun ist das Problem, dass ja dann unter C:\Users weiterhin der alte Username im Ordnernamen verwendet wird. Das ist erstmal nicht problematisch, macht aber Probleme wenn man im Script z.b. %Username% verwendet, da dieser dann immer auf den neuen Usernamen auflöst und den gibt es ja z.B. unter c:\Users nicht. Deshalb würde ich gerne den Ordner des Users Profil anpassen unter c:\Users Nach dem umbenennen noch in der Regdit unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList den entsprechenden Eintrag anpassen und fertig. Oder macht das Probleme und man sollte lieber ein neues Profil erstellen? Das haben wir bisher immer gemacht, ist aber für den User natürlich etwas ärgerlich, da er Einstellungen usw. neu anpassen muss. Wie handhabt ihr das bei Hochzeit usw? Ich weiß, manche hier verwenden gar keine Namen, sondern IDs usw. aber wir verwenden noch Namen :) Danke euch. Gruß

Ja, stimmt. So hatte ich das vermutet, dass Windows die Root Zertifikate bei Bedarf runterlädt. Aber mir fehlt jetzt auch die Zeit das Thema im Ganzen zu recherchieren und mit der aktuellen Lösung es sauber und Risiken sehe ich dort aktuell nicht. Manuell möchte ich die Zertifikate eigentlich nicht laden, da ich dann immer aufpassen muss, dass ich diese auch erneuere. Da ich bei unserer Firewall vordefinierte und automatisch gepflegte "Internet Services" in den Regeln definieren kann, wähle ich hier einfach "Sectigo" aus. Damit erschlage ich gleich auch die CRL Urls. Nachteil ist natürlich, dass in dem "Internet Service" Sectigo nicht nur die URLs für die Zertifikate hinterlegt sind, sondern ein Großteil der Sectigo Infrastruktur. Aber das Risiko ist es mir wert und das dieser Zugriff missbraucht werden könnte halte ich für eher unwahrscheinlich. Aber da driften wir schon in den Bereich Security ab ;) Vielen Dank für eure Antworten und Hilfe!

Das dachte ich auch. Aber ist wohl nicht so. Laut unserem Dienstleister wird das online abgerufen (kann so passieren, muss aber nicht immer so sein). Das steht in unserem Zertifikat. Und hier wird auf das Zwischenzertifikat gezeigt. Dieses Zwischenzertifikat ist auch im lokalen Windows Zertifikatsspeicher gar nicht vorhanden, trotzdem ist die Zertifikatskette gültig. Das geht eben nur, wenn die FW Sectigo Services zulässt.

Hi Nils, danke für deine Antwort. Der Zugriff auf http://ctldl.windowsupdate.com funktioniert nun auf den Servern, ohne diesen kompletten Internet Zugriff oder Zugriff auf die Windows Updates Services zu geben. Bezüglich der "manuellen Verteilung" der CTLs - das wäre eine Lösung, ist mir aber zu fehleranfällig und wenn ich den Zugriff über die Firewall so granular steuern kann, würde ich es gerne direkt durchführen. Nur verstehe ich den Update Prozess der Root Zertifikate noch nicht wirklich. Ich habe ein Sectigo Zertifikat, welches ein Zwischenzertifikat und ein Root Zertifikat von Sectigo benötigt. Das Zwischen- und das Root Zertifikat fehlt im Windows Cert Store. Wenn ich die oben genannte URL freigebe kann ich die Cab bzw. SST Datei von der URL runterladen. Der Zugriff funktioniert also. Rufe ich die Webseite mit dem gebundenen SSL Zertifikat auf, erhalte ich die Meldung, dass die Zertifikatskette nicht geprüft werden konnte. Das ist auch korrekt, da eben die beiden Zertifikate fehlen. Nur werden diese nicht automatisch von MS runtergeladen. Das hätte ich jetzt erwartet - zumindest das root Zertifikat. Auch verstehe ich nicht, welche Zertifikate in "vertrauenswürdige Stammzertifizierungstellen" automatisch geladen werden. Aktuell sind dort 22 Zertifikate vorhanden, führe ich ein manuelles certutil -verifyCTL -f AuthRootWU aus, werden über 300 Zertifikte für vertrauenswürdige Stammzertifizierungstellen geladen. Im Zertifikat sehe ich, dass bei "Zugriff auf Stelleninformationen" die URL für die Zwischenzertifikate und das Root Zertifikat hinterlegt ist. Das heißt der Browser prüft direkt online die Zertifikate ab. Dazu musste ich in der Firewall den Service "Sectigo" freigeben. Damit wird dann das Zwischenzertifikat online geprüft (erscheint nie automatisch im Windows Zertifikatsspeicher) und das Root Zertifikat wird dann automatisch runtergeladen und landet im Windows Zertifikatsspeicher unter "vertrauenswürdige Stammzertifizierungstellen". Somit wird das Root Zertifikat nicht von http://ctldl.windowsupdate.com geladen, sondern von einer Sectigo Seite. Das Thema ist wahrscheinlich zu komplex um es hier im Forum zu besprechen. Wollte die Infos nur noch mal teilen Wir geben jetzt am Ende die http://ctldl.windowsupdate.com frei, damit im Falle Windows die Zertifikate laden kann und geben in der Firewall die Sectigo Internet Services frei, damit dort auch die notwendigen Zertifikate geladen/geprüft werden können. Da wir nur öffentliche Zertifikate von Sectigo verwenden, sollten andere CAs auch nicht benötigt werden. Die meisten Dienste/Anwendungen sind sowieso von der internen PKI ausgestellt und da stellt sich die Frage mit dem Root und Zwischenzertifikat nicht, da diese sowieso automatisch verteilt werden.

Hallo zusammen, Ich hole nochmal den alten Beitrag hoch. Das Thema wird jetzt wieder aktuell bei uns, da es in den letzten Wochen etwas vernachlässigt wurde. Es wurde jetzt ein neuer 2019er Server installiert und dieser hat kein WAN Zugriff. Aus diesem Grund sind auch die root Zertifikate nicht auf dem aktuellen Stand. Nun haben wir eine Software, welche sich mit einem Dienst von uns verbindet der über https kommuniziert und ein öffentliches Zertifikat verwendet (also nicht von unserer internen pki ausgestellt wurde). Der Dienst verbindet sich nicht, da die zertifikstskette nicht vollständig ist. Schaue ich mir das Zertifikat an, sehe ich das eben das root und Zwischenzertifikat fehlt. Die Zertifikate werden doch nur dafür benötigt, dass ich öffentliche Zertifikate problemlos auf dem Server nutzen kann und Browser usw diesen auch vertrauen, oder werden diese auch für interne windows Dienste, Funktionen usw. verwendet und abgelaufene root Zertifikate könnten somit irgendwann zu Windows Problemen führen? Eine manuelle Pflege der Zertifikate ist aktuell etwas schwierig, daher sehe ich aktuell 2 Möglichkeiten. 1. Download direkt über http://ctldl.windowsupdate.com Diese URL habe ich in der Firewall schon freigegeben inkl wildcard. Aber wie kann ich den automatischen download von Microsoft anstoßen? Normalerweise passiert das wohl 1x in der Woche. Aber auch nach einem Neustart scheinen sich die Zertifikate noch nicht erneuert zu haben. Kann ich das irgendwie manuell anstoßen? 2. Ich lade die CTLs usw per Certutil.exe in einen freigegeben Ordner und Verweis per gpo auf diesen. Damit müsste ich die Server nicht zu den MS Servern lassen. Wie handhabt ihr das bei euch und gibt es gravierende Nachteile bei einer der beiden Lösungen? Vielen Dank euch.