cj_berlin

Ich glaube langsam, dass ALLES, was CISA, NIST und BSI verabschieden, auf der Vorstellung beruht, dass ein Hacker vor einer Anmeldemaske sitzt und Namen und Passwörter tippt...

Moin, deaktivieren, das DSRM-Kennwort kennen, beim Recovery zuerst im DSRM den RID-500 wieder aktivieren und dann im Recovery-Prozess damit arbeiten, falls und wo notwendig. Das ganze Thema akribisch dokumentieren, üben und die Dokumentation an einem Ort aufbewahren, den man ohne AD erreicht.

Wenn KEIN eigenes Zertifikat mit Private Key vorhanden ist, wird das Empfänger-Zertifikat verwendet. Die Mails wirst Du nie wieder entschlüsseln können.

Moin, die gesendeten Mails werden mit dem eigenen Zertifikat des Absenders verschlüsselt. Ich würde jetzt mutmaßen, dass aus welchen Gründen auch immer dieses verschütt gegangen ist. Für den Versand ist es irrelevant, da die Instanz der Mail, welche rausgeht, mit dem Zertifikat des Empfängers verschlüsselt ist. EDIT: Wenn das alte Gerät noch da ist, einfach inkl. Private Key exportieren und auf dem neuen importieren.

Moin, webservices ist HTTP/, SMB ist CIFS/. SetSPN führt in der Tat einen zusätzlichen Schritt durch, nämlich die Prüfung, ob der SPN nicht schon vergeben ist. Bei @daabm würde ich mich darauf verlassen, dass man weiß, wo was vergeben ist. Wenn man es nicht 100% weiß --> SetSPN, oder vorher eine Abfrage machen.

Moin, +1 zu was Norbert gesagt hat. Schalte auf beiden DCs den NTP-Server ein und die anderen Geräte sollen es von dort abholen. Stichwort Kirche im Dorf lassen. Dagegen könnten zwei Argumente sprechen: 1. Segal's Law, da Du nur zwei DCs hast - hier kommt es darauf an, was Du für Geräte hast und wie sie damit umgehen. Allerdings hat Du, wenn Deine DCs unterschiedliche Zeit haben, eh ein Problem. 2. Firewall-Policy a la "Nur Domain Member sprechen mit DCs" - siehe Kirche im Dorf lassen, 123/UDP könnte man durchaus als ungefährlich einstufen...

Das mit synchron ist ein Argument. Immer kopieren ist das einzige, was halbwegs ruhigen Schlaf verspricht. Insofern, selbst wenn man im geplanten Task selbst kopiert, würde ich es jedesmal machen. So groß sind die Skripte meistens nicht.

Aber: Da Du das Skript per Aufgabenplanung ausführen willst, kannst Du es mit einem GPP-Eintrag lokal kopieren und mit einem zweiten den Schtask erzeugen, ohne die IE Config zu verbiegen.

Wieso 2? Ich dachte, 1 wäre Local Intranet?

Like I said, für bereits verbundene Geräte. Darüber, ob es eine gute Idee ist und auch zu SBS2003-Zeiten war, müssen wir ja zum Glück nicht diskutieren

Aber: Da Du den Artikel ja jetzt gelesen hast, weißt Du: es hält nur max. eine Stunde Gut, für ein bereits eingebundenes Gerät hält es dann länger.

Versuch's nur mit dem Domänen-FQDN, ohne Protokoll. So hat's hier auf Anhieb funktioniert.

Moin, nein, LocalMachine überschreibt MachinePolicy, somit ist Deine resultierende Policy RemoteSigned, was Du auch lt. PowerShell-Ausgabe erlebst. Und hier beißt Dich etwas, was tatsächlich kontraintuitiv ist: Wenn Execution Policy über GPO gesetzt ist, kann sie nicht an der Kommandozeile übersteuert werden, auch wenn die GPO eine schwächere Einstellung hat als die resultierende Policy. Check mal, warum etwas, was aus einem UNC-Pfad aufgerufen wird, als "Remote" angesehen wird - by default sind UNC-Pfade Teil der Zone "Lokales Intranet". Vielleicht wurde das Skript bereits bei der Übertragung NACH NETLOGON als "Remote" markiert... vergiss es, habe es jetzt gelesen. Alternative wäre, das signierende Skript zu "Trusted Publishers" hinzuzufügen. EDIT: Das hinzufügen von "meine_domäne.de" zu der LocalIntranet-Zone scheint zu helfen.

Die sind vermutlich eh nicht in Gefahr, denn in meiner bisherigen Erfahrung war der Inplace-Upgrader von Server 2025 recht ordentlich, was das Auffinden der Sachverhalte angeht, die ein erfolgreiches Upgrade verhindern würden. Ist der Server ein Domain Controller, dann scheitert das Inplace Upgrade bereits am fehlenden ADPREP. Bei einigen meiner Server wurden Festplatten mit nicht kompatiblen Firmware-Ständen entdeckt, und auch andere Sachverhalte.

Moin, je nachdem, wofür der Alias benötigt wird, gibt es sehr wohl einen Unterschied - insbesondere, wenn Zertifikate im Spiel sind. Ich rufe app.myapps.domain.de, welche auf server.domain.de läuft. wenn das ganze als A record namens app in der Zone myapps.domain.de abgebildet ist, ruft der Client app.myapps.domain.de auf wenn das ganze als CNAME record abgebildet ist, der auf server.domain.de zeigt, wird server.domain.de aufgerufen (nicht immer - aber bspw. Outlook, auch die meisten Browser) Wenn also auf dem Server ein Zertifikat präsentiert wird, das nur app.myapps.domain.de im SAN hat, wird CNAME möglicherweise nicht funktionieren und vice versa.