phatair

Danke Nils für die schnelle Rückmeldung, dann belassen wir es bei der Instanz und wir packen die DBs dort mit rein. Gruß, Steffen

Hallo zusammen, vorab, ich bin kein MSSQL Admin und mein Wissen darüber hält sich in Grenzen. Der DB Server hostet nur kleine DBs und hat nicht viel zu tun. Wir haben bei uns einen MSSQL 2017 Standard laufen. Aktuell gibt es eine Instanz und in dieser liegen mehrere DBs. Nun benötigen wir für einige Admin Anwendungen eigene DBs. Ich hätte jetzt, damit es übersichtlicher ist, eine eigene Instanz erstellt um die Admin DBs von den "User" DBs zu separieren. Das wäre jetzt nur eine Bauchentscheidung und daher mal die Frage in die Runde - macht sowas Sinn bzw. ist es eher kontraproduktiv mehrere SQL Instanzen (2-3) auf einem Server laufen zu lassen? Oder ist das eher Geschmacksache und ein wirkliches richtig/falsch gibt es nicht, wenn man es mit der Anzahl der Instanzen nicht übertreibt. Laut MS sind Sie ja auf 50 begrenzt. Danke euch schon mal. Gruß, Steffen

Hi Martin, danke für deine Rückmeldung. Das heißt ihr habt die GPO Einstellung gesetzt und zusätzlich noch das ms-DS-SupportedEncryptionType Attribut geleert oder gefüllt? Bei uns ist aktuell auf 99% der Computerobjekte das ms-DS-SupportedEncryptionType Attribut schon gefüllt mit dem Wert 28 was RC4, AES128, AES256 bedeutet. Ich würde es jetzt also so verstehen, wenn im EventLog nichts weiter protokolliert wird, sind wir erstmal sauber konfiguriert bzw. haben keine Geräte im Netz die eine schwache Kerberosauthentifzierung verwenden. Oder sehe ich das falsch? Gruß, Steffen

Guten Morgen zusammen, ich habe eine Frage zu der Kerberos-Protokolländerungen die mit dem KB5021130 begonnen wurde. Wir haben eine AD mit Domänenfunktionsebene und Gesamtstrukturfunktionsebene die noch 2012R2 ist. Die DCs sind 2019er. Mit dem November Update wurde ja die Initial deplyoment phase gestartet und über die EventLogs kann man prüfen welche Anmeldungen betroffen sind. Nun ist es bei uns so, dass hier das vCenter auftaucht. Event Source NETLOGON Event ID 5840 Event Text The Netlogon service created a secure channel with a client with RC4. Dazu hat auch vmware einen KB Beitrag erstellt. Weitere Einträge erscheinen im Eventlog nicht. Nun habe ich mir mal das vCenter AD Objekt angeschaut und das Attribut ms-DS-SupportedEncryptionType ist leer. Mit einem Script habe ich dann erstmal alle Computer Objekte geprüft. Hier war folgendes zu sehen Folgende Fragen stellen sich mir nun, da mit dem November Update ja mehrere Änderungen am Kerberos und Netlogon Protokoll gemacht bzw. gestartet Bedeutet das Ergebnis vom Script, dass ich die 13 Geräte die keinen ms-DS-SupportedEncryptionType Eintrag haben prüfen muss? Aktuell meldet sich ja nur das vCenter im Eventlog da es eine RC4 Verbindung nutzt, ich würde es also so verstehen, dass die anderen 12 Computer Objekte, die kein ms-DS-SupportedEncryptionType Attribut gefüllt haben, keine Probleme bekommen. Muss das ms-DS-SupportedEncryptionType Attribut im Computer Objekt gesetzt werden oder sollte das Attribut leer sein? Wenn das Attribut leer ist, wie bzw. wo wird der Standard geregelt? Wird das über die GPO Einstellung "Network security: Configure encryption types allowed for Kerberos" geregelt? Kann man davon ausgehen, wenn die genannten Eventlog IDs aus den hier verlinkten Beiträgen keine Treffer zeigen, dass man dann erstmal keine Probleme bekommt bzw. weitere Schritte durchführen muss? Für Tipps wäre ich sehr dankbar. Grüße

Alles klar. Danke für den Hinweis und den Denkanstoß. Das heißt aber, um auf die ursprüngliche Frage zurückzukommen, dass die Zertifikate standardmäßige durch die CUs aktualisiert werden oder direkt übers Internet aktualisiert werden?

das wäre natürlich auch eine Idee. Aber mal eine blöde Frage, woher bekomme ich diese bzw. gibt es da eine Übersicht? Ich kann zwar in den ZertSpeicher schauen, aber das sind ja extrem viele Zertifikate und Kategorien und das ist doch recht komplex.

Hallo zusammen, ich habe mal eine kurze Frage zum Windows Zertifikatsspeicher und dessen Aktualisierung. Unsere Server haben alle keinen bzw. sehr eingeschränkten Internet Zugriff. Nun ist es ja so, dass der Zertifikatsspeicher auch aktualisiert werden muss, damit Root Zertifikate usw. aktualisiert werden. Wie funktioniert dieses Update. Erfolgt das über die Kumulativen Updates die man über den WSUS freigibt oder erfolgt dies immer direkt übers Internet? Das würde dann ja bedeuten, dass man bestimmte Microsoft IPs freigeben müsste, damit der Zertifikatsspeicher aktualisiert werden kann. Oder sehe ich das falsch? Vielen Dank im Voraus.

Stimmt, dass hatte ich falsch verstanden. Ich hatte es so verstanden, dass man Domänen Admin sein muss um das Objekt zu übernehmen. Aber es ist so, dass man es übernehmen kann, wenn der Objekt Ersteller ein Domänen Admin war.

Hallo zusammen, ich habe dazu im Board noch nichts gefunden und ich hoffe der Bereich hier ist der richtige. Günther Born hatte schon vor ein paar Tagen darüber berichtet, dass mit dem CU 10/22 die Sicherheitslücke CVE-2022-38042 geschlossen wurde. Dies hat zur Folge, dass sich beim Domain Join etwas ändert. MS hat dazu auch einen KB Artikel veröffentlich, blöderweise ist der aber im KB Artikel von dem CU 10/22 nicht vermerkt. https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8 Wenn das CU 10/22 installiert ist, ändert sich folgendes. Bisher konnte ein Client auch dann in die Domäne aufgenommen werden, wenn das Computer Objekt schon bestand. Der Account der für den Domain Join genutzt wurde musste nur die passenden Rechte haben. Diese hatte man ja meisten per Delegation auf die OU gesetzt. Ab dem CU 10/22 geht das nicht mehr. Wenn das Computer Objekt schon besteht kann nur noch ein Domänen Admin oder der damalige Ersteller des Computer Objekts den Domain Join durchführen. Bei uns werden Clients beim Imaging über einen Service Account in die Domäne aufgenommen. Nur bestimmte Accounts haben überhaupt das Recht Clients in die Domäne aufzunehmen. Würde nun ein Client aus der Domäne genommen werden (z.B. troubleshooting) und ein Client Admin würde versuchen den Client wieder aufzunehmen, würde das fehlschlagen. Er müsste das als Domain Admin machen (ist ein NoGo bei uns) oder den Service Account aus dem Imaging nehmen. Letzte Lösung wäre dann, er löscht das Computer Objekt und lässt es neu erstellen. Ich hoffe, ich habe hier nichts komplett falsch verstanden. Finde die Änderung ärgerlich, aber nicht so problematisch, da dieses Vorgehen bei uns äußert selten vorkommen wird. Aber MS hätte es meiner Meinung nach besser kommunizieren müssen. Ich hätte diese Info nirgends gefunden. Was meint ihr? hab ich da einen Denkfehler und wusstet ihr von der Änderung?

Ich denke das werden wir so machen. Gefällt mir gut die Idee und wir haben das Problem mit den SID Leichen nicht mehr. Vielen Dank an alle!

Ja, es muss aktuell überall gespart werden ;) Nein, mal ernsthaft. Der UPN/SamAccountName ist bei uns immer der Nachname, wenn dieser schon belegt ist gibt es bestimmte Reihenfolge wie der Account benannt wird. Nun war mein erster Gedanke, wenn wir die Accounts deaktivieren und "archivieren" blockiere ich damit ja eben mögliche neue Accounts, die den gleichen Namen tragen würden. Beispiel von Evgenij mit Frau Müller wurde ja schon genannt. Aber ich könnte ja Accounts umbenennen, wenn die Mitarbeiter das Unternehmen verlassen. Dann wird aus Müller eben Müller220922. Wenn ich das, wie auch Martin schreibt, im UPN/SamAccountName/usw. mache, kann ich ja wieder einen Account Müller erstellen. Die SID wird dadurch ja nicht verändert, oder verstehe ich das gerade falsch?

Oh, ok :) Also wir verwenden keine generischen Anmeldenamen und alle User zu archivieren ist nicht realisierbar. Ich denke mal, wir werden das vielleicht auf Admin Accounts begrenzen und diese Accounts dann "archivieren". Vielen Dank.

Danke Dir Evgenij. Da hatte ich einen Denkfehler und beim nochmaligen lesen ist es mir jetzt auch klar Das sagt es ja eben aus, dass die Security configuration dann erlaubt das LAPS Attribut zu lesen und nicht das Attribut msDS-CreatorSid. Es ist dann tatsächlich so, dass der entsprechende User dann als Owner eingetragen ist und auch direkt im Computerobjekt Berechtigungen hat. Eine Frage hätte ich jetzt aber doch noch - wenn die Admin Accounts dann im Server Objekt stehen, sollte man dann den Domain Join von Servern über einen dedizierten Service Account durchführen? Wenn der Admin jetzt das Unternehmen verlässt, würde der User ja irgendwann gelöscht und damit würden im Server Computerobjekt SID Leichen entstehen. Oder löscht ihr Admin Accounts gar nicht, sondern deaktiviert diese nur, wenn die nicht mehr benötigt werden?

Also wenn ich es jetzt nicht komplett falsch verstehe, kann der User der im msDS-CreatorSid steht das laps Kennwort auslesen. Deshalb prüfen wir das. Da jetzt nur admins enthalten sind und diese das laps Kennwort sowieso auslesen dürfen, halte ich es auch nicht für kritisch. Würde hier aber ein normaler User enthalten sein, da dieser z.b. einen computer in die Domäne aufnehmen durfte (da ms-DS-MachineAccountQuota nicht 0) könnte dieser user das laps Kennwort auslesen. So verstehe ich das zumindest. Auszug aus dem offiziellen laps Operation guide:

Hallo zusammen, Bei uns in der Domäne steht der Wert ms-DS-MachineAccountQuota auf 0, so dass kein User ohne explizite Delegation ein Gerät in die Domäne aufnehmen kann. Es gibt eine extra AD Sicherheitsgruppe in der die User enthalten sind, die Geräte in die Domäne aufnehmen können und diese AD Gruppe ist in dann in der AD berechtigt. Eine Frage hätte ich jetzt zum msDS-CreatorSid Attribut. Dieses wird ja erstellt, wenn ein User ohne Delegation ein Gerät aufnimmt. Das ist nur dann möglich, wenn ms-DS-MachineAccountQuota nicht auf 0 steht. Oder sehe ich das falsch? Ich habe nun bei uns nach Computerobjekten in der AD gesucht, die das Attribut msDS-CreatorSid besitzen. Mir werden hier fast alle Server aufgelistet. Diese wurden dann wohl vor der Anpassung des ms-DS-MachineAccountQuota Wertes in die Domäne aufgenommen und es wurde ein Account verwendet, der dafür nicht in der AD berechtigt war. Ich habe die SIDs geprüft, die bei den Servern im msDS-CreatorSid stehen, dass sind die Server Admin Accounts die auch jetzt das Recht haben Server in die Domäne aufzunehmen. Soweit ist das also OK. Meine Frage ist jetzt, kann ich diesen msDS-CreatorSid Eintrag irgendwie löschen oder muss ich dazu das Gerät aus der Domäne nehmen und wieder aufnehmen? Seht ihr es als kritisch an, wenn das msDS-CreatorSid Attribut bei den Server gefüllt ist, auch wenn es sich dabei um SIDs der aktuellen Server Admins handelt? In Bezug auf LAPS sollte das ja kein Sicherheitsrisiko darstellen, da diese Accounts das LAPS Passwort sowieso lesen dürfen und wenn einer der Admins nicht mehr im Unternehmen ist, wird der Account sowieso deaktiviert. Für Meinungen/Infos wäre ich sehr dankbar. Grüße

So machen wir es :) Bei der Planung und der Umsetzung für ein PAW bzw. auch Server Tier Konzept würden wir noch Externe Unterstützung benötigen. Falls uns hier jemand als externer Dienstleister unterstützten könnte, kann er sich gerne per PN an mich wenden. Vielen Dank schon mal. Grüße

Hallo zusammen, vielen Dank für eure Rückmeldungen. Ich gebe euch Recht, dass das Thema wahrscheinlich zu vielschichtig ist, um es hier im Forum zu diskutieren bzw. eine Lösung für uns zu finden. Ich werde mal schauen, ob und wie wir das über unseren bestehenden Dienstleister angehen können. Darf ich in diesem Zuge auch Fragen, wer von euch so eine Dienstleistung in Bezug auf PAW/Server Tiering anbietet oder ist das nicht gestattet?

Hallo zusammen, ich würde bei uns gerne mal ein dringendes Thema angehen. Das Thema wurden ja schon öfter mal diskutiert und ich wollte nicht einfach ein anderen Thema übernehmen. Aktuell nutzen bei uns die Admins ihre normalen Notebooks auch für jegliche administrative Tätigkeiten, d.h. auf diesen werden Management Konsolen gestartet, Admin Web GUIs aufgerufen und RDP Sessions zu Servern gestartet. Ein kurzer Überblick über die bestehenden Security Vorgaben VLAN Segmentierung für Server, RDMS, Management, IT, Clients, DMZ, usw vorhanden Routing über die zentrale Firewall inkl. granularer FW Regeln und Security Profiles für jedes VLAN und WAN Verbindung personalisierte Server Admin Accounts die nur auf zugewiesenen Servern genutzt werden können. personalisierte Client Admin Accounts die nur auf zugewiesenen Servern genutzt werden können. personalisierte Domain Admin Accounts die nur auf den DCs genutzt werden können. Spezielle "Fine grained password policies" für die Admin Accounts dedizierte Service Accounts die jeweils nur für einen Dienst/Aufgabe genutzt werden Kein "normaler" User hat Adminrechte bzw. einen Admin Account Standard Admin ist auf allen Servern deaktiviert. Unterschiedliche Passwörter für die lokalen Server Admins LAPS befindet sich aktuell in der Implementierung Kein Internet Zugriff für Server. Wenn benötigt, werden diese URLs/Ports explizit für diesen Server in der Edge Firewall geöffnet es werden noch keine Admin Tiers verwendet Nun nutzen wir, wie schon oben beschrieben, unsere Notebooks zum einen für die tägliche "non Admin Arbeit" wie Mails schreiben oder Recherche im Internet. Zugleich haben wir auf diesen Geräten auch unsere administrativen Tools installiert. Das ist natürlich alles andere als optimal und soll geändert werden. Die erste Idee war, für jeden Admin eine VM bereitzustellen und dort die notwendigen Tools zu installieren. Über das Notebook wird dann nur noch die normale Standard Tätigkeit durchgeführt. Credential Guard nutzen um die Anmeldedaten vor "Pass-the-Hash" Attacken zu schützen. -> Bei weiterer Recherche stellte sich dann aber raus, dass dies wohl nicht so einfach ist. Ein PAW sollte wohl eher anders rum genutzt werden. Also das NB als Admin Workstation und z.b. eine VMware als normale Arbeitsstation. Da die Admin Station aber nicht in der Domäne sein soll und besonders gehärtet sein muss, stellt sich das bei uns aktuell etwas schwierig da. Das Thema ist recht komplex, gerade wenn man auch die Admin Tiers mit einbezieht. Daher mal meine Frage in die Runde, was gibt es für Möglichkeiten um die aktuelle Situation mit den Admin Notebooks bei uns zu verbessern, aber ohne gleich die volle Ausbaustufe zu implementieren? Das würden wir aktuell absolut nicht schaffen. Auf der VMware Seite hätten wir noch genug Ressourcen um jedem Admin eine eigen VM bereitzustellen. Lässt sich da schon etwas bauen, damit wir etwas besser aufgestellt sind als jetzt? Ziel wäre es also: - Notebook für die tägliche User Arbeit - VM als Admin PC/"PAW" der z.B. nicht in der Domäne und gehärtet (Security Baselines ...) ist Vorgehen wäre dann so, dass man per RDP auf den "Admin PC" geht um dann dort die installierten Admin Tools zu nutzen oder sich von dort per RDP auf einen bestimmten Server einwählt. Damit hätte ich zumindest schon mal die Admin Tätigkeit von der täglichen Arbeit getrennt. Ein erster Schritt, dem noch weitere folgen müssen, aber besser so als es einfach so zu belassen wie es ist. Bin gespannt und dankbar für eure Antworten. Grüße

ich mosere ja nicht, sondern Suche jetzt nach Erfahrungen andere Aber wie gesagt, ich werde die beim nächsten Wartungsfenster aktualisieren und dann berichte, ob es problemlos abgelaufen ist.

Hi Norbert, den Link im Health Checker Report hatte ich ja geprüft. https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/VisualCRedistributableVersionCheck/ Ich habe aber weder bei dem Link noch bei den verlinkten Artikeln eine Info dazu gefunden, ob ich die einfach aktualisieren kann. Vor allem hatte mich im Health Checker die Info " This is not a requirement to upgrade, only a notification to bring to your attention." verunsichert und sagt eben nicht aus, dass es "problemlos" gemacht werden kann/soll. Wäre ja nicht die erste Abhängigkeit die man anfasst und auf einmal geht nix mehr. Ich werde das nun aber einfach mal machen. Denke auch, dass es kein Problem geben sollte. Ich werde berichten :)

Hallo zusammen, eine kurze Frage zum Exchange 2016. Der Health Checker sagt bei uns schon länger, dass die folgenden Redis nicht mehr aktuell sind Visual C++ 2012: Redistributable is outdate Visual C++ 2013: Redistributable is outdate Kann ich mir für die 2012 und 2013 Version von hier einfach die aktuellen Versionen runterladen und auf dem Exchange installieren oder sollte man das tunlichst vermeiden? Könnte ja auch sein, dass die (wenn benötigt) bei einem CU mit aktualisiert werden. Wir sind auf dem CU23 und SU 08/22, die Redis aber weiterhin von 2020 und daher gehe ich davon aus, dass die nicht aktualisiert werden. Auf Grund von Sicherheitslücken oder Bugfixes würde ich schon gerne die aktuelle Version nutzen. Für einen Tipp wäre ich sehr dankbar. Grüße

Die Grund war eher Zufall. Wir haben bei der LAPS Implementierung nach dem Attribut msDS-CreatorSid gesucht. 3 Rechner hatten dieses Attribut tatsächlich und wir haben diese Geräte eben aus der Domäne entfernt und wieder neu aufgenommen, um zu prüfen ob das Attribut leer bleibt, wenn wir die korrekten User verwenden. Dabei ist aufgefallen, dass die Geräte eben nicht deaktiviert werden. Ist jetzt nicht weiter tragisch, da bei uns die User keine lokalen Adminrechte haben und somit selber den Domänen austritt nicht durchführen können und damit auch keine "Leichen" im AD entstehen können. Komisch finde ich es trotzdem. An den Replikations-Effekt hatte ich auch gedacht, habe aber extra mal ein paar Stunden gewartet und zusätzlich auf allen DCs geprüft. Das Gerät wurde nicht deaktiviert.

An einem Test PC war das Verhalten wie folgt. Versuch 1 Mit einem lokaler Admin den PC in eine Workgroup gepackt. Bei der Anfrage für die Domäne einen User angegeben der definitiv Computer deaktivieren/löschen darf. Trotzdem war der PC danach nicht deaktiviert in der AD. Versuch 2 Den PC noch mal in die Domäne aufgenommen und mit dem Remove-Computer PS Command die Deregistrierung durchgeführt. Im Remove-Computer Command wurde der AD User mitgegeben. Als lokaler User wurde "current user" verwendet, dieser war lokaler Admin. Hier wurde das Computer Objekt in der AD deaktiviert. Jetzt habe ich diesen PC wieder in die Domäne aufgenommen und habe 1:1 noch mal das Prozedere aus Versuch1 durchgeführt. Jetzt wird das Computer Objekt in der AD auch deaktiviert. Ich verstehe es nicht, aber gut, wir werden es beobachten.

Ah ok, dann müsste ich es verstanden haben. Das heißt, dass aufkündigen erfolgt in 2 Schritten. Da ich als lokaler Admin die Workgroup auswähle, wird der Member (Client) auch aus der Domäne genommen und in die Workgroup gesteckt. Das passiert erstmal lokal. Danach authentifiziere ich mich noch gegen das AD und da der User nicht genügend Rechte hat bleibt das AD Computer Objekt aktiv, dass hat aber erstmal nichts mit den lokalen "Einstellungen" auf dem Member zu tun. Ich hätte jetzt trotzdem eine Fehlermeldung in Bezug auf das AD Objekt am Member erwartet, aber dann ist das wohl so nicht.

Danke Dir, Das mit dem aufnehmen weiß ich und ist bei uns auch auf 0 gesetzt und für den Domain Join ist eine AD Gruppe mit delegierten Rechten gesetzt. Das mit dem entfernen ist mir dann trotzdem ein Rätsel, das mit den lokalen Rechten hatte ich mir auch gedacht. Ich kann das aber auch mit einem User machen, der keine lokalen Adminrechte hat. Ich kann den Client mit einem normalen Standard AD User aus der Domäne nehmen. Das AD Objekt bleibt dann weiterhin aktiv im AD und der Client ist dann in der Workgroup. EDIT: Um es etwas genauer zu sagen - um von Domäne auf Workgroup umzustellen benötige ich natürlich administrative Rechte. Danach erscheint ja aber noch mal eine Authentifizierung gegenüber der Domäne und dort habe ich dann einfach einen normalen AD User eingetragen der keinerlei Rechte im AD oder auf dem Client hat.