cj_berlin

Und bei LDAPS must Du prüfen, welche Systeme, die nicht Mitglied im AD sind, auf LDAP(S) zugreifen. Falls keine, kann die CA weg *und* Du brauchst gar kein Zertifikat auf dem DC, denn Domänenmitglieder brauchen kein LDAPS, siehe meinen Blog-Beitrag, der im zweiten Link oben verlinkt ist.

So hieß vermutlich die Syno des Entwicklers, der das SMB-Protokoll für die Syno-OS geschrieben hat.

Wieso? Du kannst alle FSMO-Rollen mit (drei verschiedenen) MMCs übertragen. Nur sollte man das nach Möglichkeit nicht tun.

Bei HOME_DS klingelt beim ganz ganz leise was... aber ich komme nicht drauf, in welchem Log oder Trace ich das schon mal gesehen habe. Ist es möglich, dass auf dem Gerät, das die Abfrage macht, irgendwelche Apps installiert sind, die nix mit Arbeit zu tun haben? Waschmaschinen-Steuerung, Luftqualität, sowas? LLMNR, falls nicht totgetreten, wird versucht, nachdem DNS fehlgeschlagen ist. Bedeutet vermutlich, dass der Versuch, HOME_DS per DNS aufzulösen, nicht in einem autoritativen NXDOMAIN gipfelte, sondern ergebnislos verhallte.

Ich habe keine Ahnung, aber bei APress glaube ich das eher nicht.

Jetzt könnte ich lässig auf mein Buch verweisen

Stop right there. So funktioniert AD nicht.

Moin, hast Du es denn versucht? Wenn Du einen 2022 promoten konntest, hat das ADPREP ja zumindest geklappt. Und die Kompatibilitätstabelle in Deinem Link ist ja unvollständig - die ist bei 2012R2 einfach abgeschnitten. So sah es in 2022 aus:

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.

Moin, der Titel passt vermutlich nicht zum Sachverhalt, denn das Ändern des Kennworts scheint ja nicht das Problem zu sein. Was das Problem mit dem Secure Channel und dem Event 3210 vermutlich wirklich verursacht hat ist, dass 389/udp zu diesem DC immer noch möglich ist, während alle anderen, auf TCP basierenden Protokolle blockiert sind. Ich trau mich das gar nicht zu fragen: Hat sich der Secure Channel repariert, nachdem die Regel entfernt und der betroffene PC neugestartet wurde? Seit Windows 7 SP1 wird Netlogon das lokale Kennwort erst ändern, wenn bestätigt ist, dass es auch im AD gesetzt wurde.

Nein, aber Du kannst eine Translationstabelle verwenden.