Pipeline

Moin Martin, hast du dazu ("Shadow Principals" und "Break-Glass-Accounts") für mich eine gute Quelle zum nachlesen?

Oh ich danke euch für die vielen Antworten. Leider zeigt sich, dass es differenziert betrachtet und abgewogen werden sollte und nicht die eine richtige Antwort gibt. Ich bin hier gerade in einem Umfeld aktiv, wo der Fall zutrifft: ist vorgegeben, BSI und Co ... Eure weiteren Anregungen nehme ich für nachträgliche Verbesserungsideen gerne mit

Moin zusammen, wir hatten ein Sicherheitsaudit (mal wieder) inkl. PEN Test. Der Abschlussbericht enthält die Empfehlung im Active Directory den built-in Administrator zu deaktivieren. Das ist ja auch nicht gerade eine neue Idee. Wir verwenden den nicht aktiv, nur unsere personalisierten Konten, daher wäre das ohne direkte Probleme nötig. Wir wollten das schon lange machen, jedoch waren wir uns über mögliche Einschränkungen nicht sicher. Bei der Recherche gab es nur ein einziges Risiko welches wir gefunden haben und zwar der AD Restore. Dazu haben wir widersprüchliches gefunden. In einigen Artikeln hieß es der built-in Admin wird auf der Restore Konsole automatisch wieder aktiviert, mal hieß es ohne aktiven User geht es nicht. Auch dieser Artikel hatte letztes Jahr noch die Empfehlung den User zu deaktivieren, inzwischen wurde das überarbeitet Appendix D - Securing Built-In Administrator Accounts in Active Directory | Microsoft Learn Auch das forest recovery sollte zuvor das Verhalten haben, dass der User wieder aktiv wird. Nun bitte ich euch um echte, eigene Erfahrungen dazu. Hat es schon jemand durchgeführt und kann die Widersprüche aufklären? Viele Grüße, Stefan

Moin zusammen, bitte beachten, ich habe das bereits auf englisch hier gepostet (unbeliebter cross-post ich weiß): Quser hangs and how to find the citrix load index equivalent - Microsoft Community Hub Ich dachte im englischen Forum bekomme ich mehr Experten ran, ist ja nun mal die IT Sprache... Jedoch gab es null Antworten. Vielleicht könnt Ihr mir einen Tipp geben, welches Forum, welche Community auf englisch hier am aktivsten ist für Fragen zu den Themen Windows Server, Remote Desktop Services und Active Directory? Ich habe diese Seiten gefunden und bin mir nicht sicher, welches die richtige ist: https://learn.microsoft.com/en-us/answers/tags/301/remote-desktop https://learn.microsoft.com/en-us/answers/tags/220/windows-server https://techcommunity.microsoft.com/t5/windows-server/ct-p/Windows-Server https://techcommunity.microsoft.com/t5/windows-server-for-it-pro/bd-p/WindowsServer Nun endlich zu meiner aktuellen Frage zu Remote Desktop Services: Wir haben eine Farm mit über 30 RDSH. Seit einigen Wochen haben wir Probleme mit der Anmeldung. Wir sind darauf gestoßen, dass wir auch Probleme mit dem Abrufen von Sitzungsinformationen mit dem Befehl „quser“ haben. Die Eingabeaufforderung bleibt hängen und es wird keine Ausgabe gemacht. Wir haben keine Ahnung, warum das passiert. Hat das jemand schon einmal erlebt? Teilweise gibt es dort dann auch Sitzungen mit einem Idle Wert: "24692+". Kennt das jemand? Zweite Frage: Vor einigen Jahren hatten wir Citrix Terminalserver. Es gab eine Sache, die sich Lastindex nannte. Die Citrix-Terminalserver erhöhten ihre Last während des Anmeldevorgangs eines Benutzers auf den Maximalwert von 10000. Danach sinkt sie auf einen niedrigeren Wert, basierend auf einigen Regeln für Ressourcen und so weiter. Ich habe in RDS keinen Befehl gefunden, um einen ähnlichen Wert wie den Lastwert zu erhalten. Macht RDS etwas Ähnliches mit dem Lastindex wie Citrix? Wo kann ich diesen Wert erhalten? Wie verhindert eine rdsh zu viele gleichzeitige Anmeldungen? Wenn wir als Admins eine gleichzeitige Anmeldung provozieren, bekommt einer eine Meldung mit dem Text "Remotedesktopdienste ausgelastet". Und auch der quser-Befehl scheint eine „kurze Pause“ zu machen und die Ausgabe kommt einige Sekunden später. Ich bin über jedes Feedback dankbar. Gruß Stefan

wir haben in den RZ jeweils die selben Netzbereiche, daher gibt es nur eine AD Site

Wir haben in beiden RZ je einen DC. Bislang wuppen die sehr gut den Workload. Trotzdem überlegen wir zusätzlich einen DC in unserem VM Cluster laufen zu lassen. Interessant, warum denn sogar fünf? Ist das nur wegen der Pferde vor der Apotheke oder hat das technisch einen konkreten Vorteil?

Moin, erneut vielen Dank für eure Gedanken, Meinungen und Erfahrungen. Auf einige Punkte möchte ich eben eingehen, da ich meine Ausgangslage scheinbar schlecht beschrieben habe. Zunächst weil ich teils andere Begriffe verwende als im HyperV, wir nutzen den XenServer (Citrix) als Hypervisor. Es sind bis auf einen Server nur noch VMs bei uns (außer die Hosts ). Wilder Mix aus insgesamt 460 VMs, Windows und Linux, sogar mehr Linux, mit dem AD verbunden davon ca. 140 Wir haben natürlich nicht nur einen DC, und die laufen entkoppelt auf separaten Hosts die nicht im Virtualisierungs-Cluster sind und nicht vom AD abhängig sind. Schöne Sichtweise und bestärkt mich diese Fragen nach dem Gedankenspiel dann auch praktisch zu erproben. Denn ja, die Frage der Dauer ist spannend, da ich aber eh nicht weiß welchen Vorfall wir erleiden immer nur ein Baustein. Wir werden im Ende dann ja auch verschiedene Restore Wege haben. Und in dem Szenario ist erstmal entscheidend, dass ein Weg überhaupt funktioniert. Der schnelle wird dann vermutlich der mit der DR Kopie sein. Unsere VM-Backups liegen neben dem aktiven Datenbestand und dann erste Kopie in einem zusätzlichen separaten Storage, dann noch in der klassischen Datensicherung die separiert ist und schlussendlich auch noch per Tape gesichert und im Bunker ausgelagert wird. Wir haben da schon eine Menge an Sicherungen. Nur der unabhängige Restore des AD wurde halt bislang dann nicht hinterfragt... Nein, nein. Das wird bei uns nicht mal als Notlösung in Betracht gezogen. Wir stellen uns da richtige Serverhardware hin. Unsere Kunden rufen per Haftbarhaltung so schnell große Summen bei Störungen auf, da ist der Preis für ein paar Server mehr in Relation komplett zu vernachlässigen. Gar nichts, siehe oben, wir haben einen zweiten ich denke hier das Szenario durch, beide DC und die Hosts sind schrott. Meine DR Kopie entspricht einem Replikat. Grüße Stefan

Vielen Dank für eure Antworten! Ihr seid super. Ja ich wollte da gar nicht den Eindruck erwecken meine Idee ist neu, nur findet man hauptsächlich Anleitungen die entsprechend etwas komplexere weil differenziertere Wiederherstellungen beschreiben. Ich habe jetzt hier nur diesen einen Fall beschrieben. Natürlich fahren wir mehrgleisig und wollen mehre Möglichkeiten zur Hand haben da ja nie vorher bekannt ist welchen Vorfall man erlebt. File- und Systemstate Backup ist vorhanden, bislang nur mit Backup Software. Ich werde das onboard Windows Backup ergänzen. Das mit dem "da gabelt sich der Weg" ist genau der Kern, ja. Der Cyber-Vorfall ist sicherlich sehr eklig, weil in der Regel (zu) lange unklar und das Vertrauen verloren ist. Die DR Kopie ist hier nur ein Mittel die komplett ohne Abhängigkeiten nutzbar ist. Danke für den Tipp, war mir noch gar nicht untergekommen. Und @NilsK ja, "einfach" endet dann bei einem echten Vorfall und dem nötigen Restore. Ich finde deine Formulierung : richtig gut, schön griffig und trifft den Punkt. Daher werde ich versuchen eine gute Testumgebung einzurichten und Restore Varianten zu testen. Jedoch kenne ich die Herausforderung zu einer guten Testumgebung, diese muss halt "mit Leben gefüllt" werden sonst hat das keine Aussagekraft. Und für umfangreiche Testumgebungen in denen auch Testbetrieb läuft sind wir mit unseren Admin-Ressourcen zu knapp. Gruß Stefan

Moin zusammen, ich weiß, AD bzw. DC Restore ist ein oft diskutiertes Thema. Ich habe dazu auch eine Menge gelesen. Doch ich möchte hier einmal kurz unser Gedankenspiel (Szenario) für einen Notfall beschreiben und eine ganz provokant simple Lösung von euch bewerten lassen. Denn alles was ich gelesen habe ist aufwändig und bringt diverse Voraussetzungen mit. Ich vermute, da sich nur Admins mit großen komplexen ADs diese Gedanken machen gibt es auch nur entsprechende Anleitungen. Szenario: Vorab: nur zwei DCs und diese sind virtuell Kein MS Exchange AD ist recht klein und simpel: nur eine Domain nur ein Forest, ca. 300 User, 60 Server, 350 Client PCs, 30 GPOs, sehr seltene Änderungen (höchstens mal neue User) alle FSMO Rollen auf einem DC, beide DC sind auch GC DNS ist AD integiert und beide DC sind als DNS auf den Servern und Clients hinterlegt Notfall tritt ein: DCs schrott (warum auch immer, nur mal angenommen, komplett schrott und nicht startfähig) Hypervisor Pool/Cluster Umgebung auch komplett schrott Idee für schnellen, simplen Restore: Auf einem gesonderten (eigenständigen) Hypervisor Server im Backup RZ gibt es aus der Virtualisierung Disaster Recovery Kopie des ersten DC Diese Kopie wird wöchentlich neu erstellt Es bleiben z.B. sechs Kopien als Historie liegen (um auch weiter zurück zu kommen, falls etwa ein Ransomware Angriff erst nach einigen Wochen entdeckt wird) Im Disasterfall wird eine der Kopie Versionen auf dem extra Server gestartet Der ältere Stand wird aufgrund der geringen Änderungsrate in Kauf genommen Einige Computerkonten und Userkonten werden abgelaufene Passwörter haben, wird dann halt individuell behandelt RID Konflikte erwarte ich nicht, da nur ein DC im Restore, der zweite wird anschließend im AD bereinigt und ein neuer zweiter DC aufgesetzt und hochgestuft Was meint ihr dazu? Übersehe ich was? Denke ich mir das zu einfach? Bin gespannt auf eure Hinweise und Gedanken. Viele Grüße

Okay super, danke für die Rückmeldung. Das heißt, das eigentliche Inplace Upgrade auf 2019 hat sauber funktioniert? Wir stehen auch davor...

Und? Ging das Heraufstufen dann noch? Wie ist die Situation ausgegangen?

ja, aber genau das habe ich ja gemacht und dann entdeckt, dass die Einträge in der cache.dns und im AD, wie in dem von dir verlinkten Artikel, noch aufgeführt sind und daher der BPA meckert

Hm, ja habe ich so. Warum dann der BPA eine Warnung für jeden der im AD als Internet DNS Root hinterlegten Server wirft ist mir dann unklar.

ja, etwa per WMI Filter: select * from Win32_OperatingSystem where Version like "10.%" and (ProductType="1") Das sind dann nur Windows 10 Clients, keine Server. Hier geht es jetzt nur im den Filter, die entsprechende Einstellung in der Richtilinie für Autoplay musst du dann entsprechend setzen

Ja ich kann mich hier nur anschließen, die Latenz ist da besonders wichtig. 19 ms Latenz ist super, bis 50 ist alles gut zwischen 50 und 100 ist okay, ab 120 wird es in der Bedienung nervig für die User