cj_berlin

...aber bevor die AD-Intelligenz greift, muss wenigstens ein DNS-Server erreicht werden, der die Resource Records für AD und die NS Records hostet. Und wenn sie sich alle ändern, hilft auch keine Intelligenz.

Doch, ist es. Auf diese Weise behältst Du IP-Adressen und Namen der DCs, ohne fertig hochgestufte DCs nachträglich verändern zu müssen. 99% meiner Kunden wissen nicht mit absoluter Sicherheit, wo welche Maschinen für DNS und LDAP mit Namen oder sogar IP-Adressen eingetragen sind. Doch selbst wenn man es wüßte - will man jede doofe Appliance, jeden Drucker usw. usw. anfassen und IP-Adressen ändern? Man kann natürlich, wenn man nur zwei DCs hat, zuerst einen dritten installieren und ihn zum Schluss wieder entfernen. Aber bereits wenn man drei DCs hat, verzichtet man auch bei reiner Rotation zu keinem Zeitpunkt auf Redundanz. Aber auch bei zwei DCs dauert der Verlust der Redundanz bei ordentlicher Vorbereitung 18 Minuten, 15 davon braucht der KCC, um die Replication Links neu auszuwürfeln.

Genau so macht man das. Denk daran, ihn auch aus Sites & Services zu entfernen und so lange zu warten, bis der KCC alle Replikationsverbindungen von alleine entfernt hat.

In einem größeren AD - nicht so, sondern Get-ADUser -LDAPFilter "(altsecurityidentities=*)" -Properties altsecurityidentities | Select-Object samaccountname,altsecurityidentities

Moin, wie äußert sich "funktioniert gar nicht" technisch? Was passiert, wenn Du einen User dort anmeldest, der dort noch nie ein Profil hatte?

Ja, aber es ist nichts für schwache Nerven. Und ein 3rd Party-Patchmanagement, mit Ausnahme von Adobe, ist auch eher dürftig ausgeprägt.

Ich habe einfach das umgesetzt, was der Hersteller an Verwendungszweck des Accounts dokumentiert, und als dann beim Start des Dienstes "Zugriff verweigert" kam, noch die Schreibrechte für das Verzeichnis nachgetragen.

Falls es jemanden Interessiert: Wir haben STAS nun ohne DA ans Laufen bekommen: Logon As a Service auf DCs Builtin\Event Log Readers Full Access auf das Programmverzeichnis von STAS Lokaler Admin auf Workstations (als Abkürzung für Remote WMI) Viel fehlt hier effektiv nicht zum DA, aber das ganze lief im Rahmen eines AD-Audits, und jeder DA, dessen Kennwort nicht abläuft, bringt Strafpunkte

Ja, und nicht nur bei den Öffis. Wenn alle Stricke reißen --> Kurier mit verschlüsseltem USB-Stick. Da ist der Ball dann bei denen, und sie müssen ihre IT-Security dazu bringen, dass sie den Stick einstecken dürfen.

Dafür ist es jetzt wohl zu spät, aber fürs nächste Mal: Microsoft hat einen schrittweisen Bereitstellungsassistenten in einfacher Sprache für alle möglichen Exchange-Migrationen online veröffentlicht. Warum müssen die Leute sich jedes mal einen eigenen Umzugsmechanismus ausdenken? Ist Exchange 2016 sauber deinstalliert worden? Ist evtl. der Autodiscover-SCP vom alten Server noch da? Was sagt die Autokonfigurations-Diagnose in Outlook?

Falsch. Die einzige Rolle, die mit einem DC koexistieren sollte, ist DNS. Und normale User sollten sich niemals an einem DC interaktiv anmelden dürfen - das hast Du ja bereits auf einem DC verbogen, mach es bitte nicht nochmal. Benutzerprofile kannst Du über Roaming-Profile migrieren. Muss sich halt jeder User nach dem Aktivieren 2x an- und abmelden, damit das Profil auf den Fileserver zurückgespeichert wurde. RDS-CALs kannst Du direkt von einem aktivierten Lizenzserver zum anderen umziehen, wenn beide online sind und sich sehen. Gibt einnen Punkt im RDS-Lizenzmanager.

Moin, die Bibel: https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?msclkid=8035f7b2cf8711eca658ca2f8b3edf76&view=exchserver-2019 Exchange 2013 kann durchaus mit FFL 2016 funktionieren, nicht jedoch mit DCs auf Server 2019. Daher musst Du zuerst Exchange migrieren und dann die DCs upgraden.

Wenn der verbaute RAID-Controller auf SSD-Betrieb optimiert ist und man seine Meldungen auch wirklich auswertet, wird er normalerweise melden, wenn das auffangbare Maß des Zellensterbens bald ausgeschöpft ist. Ein 08/15-RAID-Controller hat hierfür keine eingebaute Intelligenz, da kann man gemäß dem Datenblatt des Herstellers versuchen zu schätzen, wann die Schreibgrenze erreicht ist. Dabei spielt der 24/7-Betrieb eher weniger die Rolle (meist ist von ca. 1 Million Stunden MTBF auszugehen), aber die TBW-Angaben sind da schon im Rahmen dessen, was man in ein paar Jahren ausschöpfen kann. Man muss aber messen, wieviel man *wirklich* schreibt. PerfMon hilft da.

Moin, Redundanz hilft nicht gegen Ransomware. Was hilft, ist aktive Verhinderung (Härtung der Systeme, XDR auf den Endpoints, Segmentierung im Netzwerk, rigoroses Filtern von Mail-Attachments und des Internet-Traffics, auch auf Kosten der Bequemlichkeit der Nutzer) nicht veränderliche Backups (die Platte "mitnehmen" hilft übrigens nicht gegen Ransomware, sondern eher gegen Brand oder Vandalismus - gegen Ransomware würde "herausnehmen nach Verifizierung, dass die Backups darauf nicht verschlüsselt sind" bereits genügen). Das Wissen, welche Daten ich "in Reinform" brauche (Deine SQL-Datenbank oder Röntgenbilder) und welche ich mit wenig Aufwand neu erzeugen kann (Benutzer-Accounts). Ich hätte hier auf meinen Vortrag "Wegwerf-IT" auf der CIM Lingen 2021 verwiesen, aber die CIM hat es nicht geschafft, die Videos zu veröffentlichen :-( Deine Ausführungen lesen sich so an, als wäre die Umgebung ziemlich klein. Da kommst Du schnell in die Situation, wo der Aufwand, die Infrastruktur nach Ransomware-Befall schnell und mit vertretbarem Datenverlust wieder ans Laufen zu bekommen, den Schaden wegen Arbeitsausfall und Datenverlust um einiges übersteigt. Daher solltest Du - wie immer, wenn man etwas gegen etwas absichern will - damit anfangen, den Schaden zu beziffern, den Deine Praxis erleidet, wenn Arbeitsausfall von X Tagen von einem Datenverlust von Y Wochen begleitet wird. Und da, wo der Schaden den wirtschaftlichen Tod der Praxis bedeuten würde, liegt die absolute Obergrenze für den Aufwand, den Du treiben solltest. Von da kannst Du dich dem Optimum annähern - wenn die Ausfallverkürzung um 100.000 € einen Aufwand von 250.000 € bedeuten würde, ist der Aufwand kritisch zu hinterfragen.

Dann muss der Chef einen Mail-Gateway mit Recipient Lookup vorschalten und es dort abbilden.

Das würde ich verneinen wollen. Solange ein Windows-Computer Mitglied einer Workgroup ist, hat er in den Tat diesen Server als NTP-Zeitquelle. Sobald er Domänen-Irgendwas ist, steht die Zeit auf NTDS5. Auch beim PDCe, wenn man es nicht konfiguriert. Und ja, ich habe nachgeschaut, habe genug Domänen in allen möglichen Versionen hier im Labor.

Moin, welche Zeitzone und welches Locale verteilt ihr an die Clients beim Betanken? Was passiert denn, wenn man einen Client stumpf von CD mit der richtigen Zeit- und Ländereinstellung installiert und dann in die Domäne aufnimmt? Damit wüßte man wenigstens, ob die problematische Konfiguration aus der Domäne (GPOs, Skripte usw.) kommt oder aus dem Deployment...

OK, der Sachverhalt ist folgender: 2019 und höher erlaubt kein Downgrade der Verschlüsselung für das Service-Ticket, d.h. selbst wenn Client und User nur RC4 können, der Service-Account jedoch *auch* AES, wird das Service-Ticket mit AES verschlüsselt. Das ist funktional ja auch in Ordnung, denn nur der Service muss das Ticket entschlüsseln, der Client reicht es ja nur im Auftrag des Users beim Service ein. Ich habe das gestern nachvollzogen (Server 2003 als Member in einer Server 2022-Domäne und ja, dafür musste ich SMB1 nachträglich installieren ). Prä-Auth geht mit RC4, TGT und Service-Ticket ist mit dem verschlüsselt, was KRBTGT respektive der Service-Account als höchstes können. Somit ist der Haken nicht wirkungslos, aber die Einsatzszenarien für den Haken sind etwas weniger geworden. EDIT: Vermutlich ist es deswegen auch nicht explizit irgendwo dokumentiert, denn es ist ja keine "Verhaltensänderung" im eigentlichen Sinne (sowohl das alte als auch das neue Verhalten bewegen sich innerhalb der RFCs), sondern erschwert einfach nur das Kerberoasting.

Huch? Wo steht das? 2019er und 2022er DCs speichern weiterhin RC4_HMAC_MD5-Hashes, wenn es nicht wegkonfiguriert wurde. Und der erste DC einer Domäne, egal in welcher Version, muss RC4 unterstützen, sonst kann er ja die lokalen Accounts nicht in Domain-Accounts konvertieren.

Problem ist bei MSFT bekannt, wird irgendwann demnächst wieder geheilt.

Die Bugs kommen monatlich am Patchday rein, kann also auch 2012R2 noch betreffen. So geschehen beispielsweise auch diesen Winter

...wobei natürlich nicht unerwähnt bleiben sollte, dass der Hersteller für genau diesen Use Case etwas vorgesehen hat: https://docs.microsoft.com/en-us/windows/iot/iot-enterprise/kiosk-mode/kiosk-mode

Das ist auch AES256 + future enctypes. Das löst aus, dass für das Account alles, was nicht angekreuzt ist, nicht verwendet wird. Und da offenbar sowohl die DCs als auch die Clients nur AES256 erlaubt haben, sollte da theoretisch gar nichts passieren. Lass Dir eine Audienz geben, er soll alle wichtigen Dateien schließen und alle wichtigen Programme beenden, und dann probierst Du es halt. Kannst die Session damit anfangen, dass Du in seinem Benutzer-Kontext die CMD aufmachst (was bei euch natürlich deaktiviert ist ) und klist tickets sagst. Da kannst Du dann sehen, welche Verschlüsselung die derzeit angemeldete Sitzung verwendet.

Was passiert denn, wenn Du bei einem betroffenen User das Häkchen setzt bei "Account supports AES256 encryption" bzw. msDS-SupportedEncryptionTypes auf 0x10?

Moin, ich weiß, dass sich hier einige sehr eingehend mit den SOPHOS Firewall-Produkten beschäftigen. Ich hätte hier einen Fall für Schwarmwissen, da der Hersteller es sich einfach macht. Im Dokument "Best Practices for STAS" steht Event Viewer-Abfrage kann ich mit "Event Log Readers" abfackeln. Sophos Dienst starten kann ich explizit delegieren. WMI zu Workstations kann ich durch lokale Adminrechte dort oder vielleicht sogar noch dediziertere Berechtigungen ermöglichen. Ich möchte den Service-User aus DA raus haben. Und nun die Frage: Hat das hier schon jemand getan und wäre er/sie bereit, das gewonnene Know-How zu teilen? 1000 Dank im vorab!