cj_berlin

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.

Moin, die Essentials von 2016 war eine separate Edition mit zusätzlicher Software und besonderen Merkmalen. Die Essentials von 2022 ist einfach nur eine Standard mit besonderer Lizensierung, die aber nicht technisch erzwungen ist. Somit gilt: https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-conversion-options#windows-server-essentials

Denk an Log4j - mit Bugs ist immer alles möglich. Ich würde Syno vorsichtig zutrauen, das soweit ordentlich gebaut zu haben, dass selektiver schreibender/löschender Zugriff auf WORM nicht möglich ist. Bei Ransomware spielt der gezielte Zugriff aber keine Rolle, und hier denke ich, dass es durchaus möglich ist, sämtliche Daten auf wiederbeschreibbaren Medien unbenutzbar zu machen. Platte mit ein bisschen Verschlüsselung und Software-Überbau ist eben kein WORM

Das ist der Sound, den der DNS-Cache beim Leeren macht

Moin, "realistischer abbilden" = "Windows RRAS als interner Router wird vermutlich nicht zur Anwendung kommen" pfSense kann ich wärmstens empfehlen. Grundlegendes Routing ist in 5 Minuten eingerichtet, und dann kann man sich austoben. Nutze ich seit Jahren, in allen meinen Laboren, von ganz klein bis ganz ordentlich. Mein derzeit größtes pfSense hat 14 Beine.

...doch wie immer man es drehen und wenden will, braucht es einen User *mit* Admin-Berechtigung, um einen Prozess mit erhöhten Rechten zu starten, sonst wäre das ganze UAC-Thema ja komplett für die Füße Du kannst einen geplanten Task mit dem gewünschten Sicherheitskontext erstellen und den "Normal-User" zum Starten dieses Tasks berechtigen.

Moin, welches Betriebssystem hat denn "der" Hyper-V Host? Lizenzierung von virtualisierten Client-OS ist generell nicht einfach.

Moin, das kann keine Absicht sein, da gibt es nichts dahin zu stellen. Wenn es sich reproduzieren lässt, ist es ein Bug, denn idealerweise sollte kein Zertifikat jemals dieses Merkmal haben.

Moin, schau mal, ob sich in die "Trusted Roots" am betroffenen Client ein Zertifikat eingeschlichen hat, das nicht von sich selbst signiert ist, und falls ja, verschiebe es entsprechend dem Nutzungszweck - Endpunktzertifikate nach "eigene" ("my"), Zertifizierungsstellen nach "Zwischenzertifizierungsstellen".

Moin, habt ihr bei der Portierung auch *wirklich* alle Spuren der physikalischen Netzwerkkarten bereinigt? Ich habe Ähnliches mal gesehen nach einem, sagen wir mal, blauäugigen P2V...

Das dachte ich mir auch 😎 https://link.springer.com/book/9798868809408

Oder, je nachdem, was der Kunde *wirklich* braucht, einfach keinen Exchange einsetzen, sondern MDaemon, SmarterMail, Kerio Connect oder sowas. Cloud ist NICHT die Antwort auf alles - das ist immer noch 42.