cj_berlin

Nö, das geht in Richtung OSI-Modell und auf welcher Schicht eine Verbindung besteht.

OK, von WLAN hast Du nichts erwähnt. Bei einem Switch mit drahtgebundenem Ethernet wäre der Router egal, denn da spielen IP-Adressen keine Rolle. Mit WLAN könnte es aber im Bridged Mode eigentlich auch funktionieren.

Kannst ihnen ja IP-Adressen geben, die nicht um Subnet Deines Routers liegen

Innerhalb eines Forests ist UPN ein frei beschreibbares Feld (nur nicht mit ADUC/ADAC). Nur wenn Suffix Routing ein Thema wird, muss es in die Konfig. Natürlich packen wir es immer in die Konfig, wenn möglich, aber Kerberos innerhalb des Forests funktioniert auch ohne.

Moin, ketzerische Frage: braucht ihr die UPN-Suffixe der Kunden wirklich in der Forest-Konfiguration? So lange keine Cross-Forest-Authentifizierung im Spiel ist, kannst Du den userPrincipalName frei setzen, und innerhalb des eigenen Forests wird die Authentifizierung damit auch funktionieren.

Du meinst, Putzfrau stöpselt Server aus und Staubsauger ein?

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.