Content-Update simplex-messaging-service

articles/2025/05/default-domain-policy-kann-nicht-gelesen-werden.md

@@ -0,0 +1,132 @@
+<!--{"title": "Warum meldet der Client, dass die Default Domain Policy nicht gelesen werden kann?", "date": "2025-05-06", "slug": "default-domain-policy-kann-nicht-gelesen-werden", "description": "Die Ereignisse (Event ID 1058 / 1030) deuten fast immer darauf hin, dass der Client zum Zeitpunkt der Verarbeitung die Datei gpt.ini im SYSVOL‑Verzeichnis nicht erreichen kann. Im Normalfall verschwinden die Fehler nach dem nächsten Verarbeitungszyklus – ein Hinweis auf ein zeitweiliges Erreichbarkeitsproblem.", "cover": "/static/img/default-domain-policy-kann-nicht-gelesen-werden.webp"}-->
+> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [💜 <ins>Kein Einsatz von KI</ins>](/page/ai)
+
+## Problembeschreibung
+
+Leider kommt es häufiger vor, dass Administratoren vor dem Problem stehen, dass Clients die konfigurierten Gruppenrichtlinien nicht korrekt verarbeiten.
+Die konfigurierten Richtlinien werden von einem oder mehreren Clients oder Servern in unregelmäßigen Abständen nicht angewendet.
+Nach einem Neustart oder manchmal auch nach einiger Zeit hat der Client die Richtlinie auf magische Weise doch verarbeitet.
+
+Die Fehlersuche kann zeitaufwändig sein und den Administrator zur Verzweiflung bringen.
+Ich versuche hier die naheliegendsten Möglichkeiten aufzuzeigen und einen Leitfaden zur systematischen Lösung des Problems bereitzustellen.
+
+## Mögliche Ursachen
+
+* **Namens- oder Netzwerkauflösung**: Der Client kann den zuständigen Domänencontroller nicht erreichen
+* **SYSVOL-Replikation**: Die Replikation des DFS dauert lange und verzögert die Bereitstellung
+* **DFS-Client deaktiviert**: Der Dienst auf dem Client ist beendet oder deaktiviert
+* **Berechtigungen / SMB-Signatur**: Authentifizierte Benutzer haben keine Leserechte oder die SMB-Signaturpflicht wird misachtet
+* **Zeit- / Kerberos-Probleme**: Die konfigurierte Zeit von Client und Domänencontroller weicht stark ab
+
+## Warum es später trotzdem doch klappt
+
+* **Namens- oder Netzwerkauflösung**: Der Client findet einen anderen Domänencontroller oder einen anderen Server per DNS
+* **SYSVOL-Replikation**: Nach Abschluss der Replikation ist die Datei *gpt.ini* wieder vorhanden und kann gelesen werden
+* **DFS-Client deaktiviert**: Der Client meldet sich an einem Domänencontroller, an dem SMB direkt funktioniert
+* **Berechtigungen / SMB-Signatur**: Nach administrativen Korrekturen oder der Zuweisung eines anderen Domänencontrollers wird der Zugriff erlaubt
+* **Zeit- / Kerberos-Probleme**: *W32Time* synchronisiert sich und der nächste Versuch wird positiv bearbeitet
+
+## Lösungsansätze
+
+📈 Wir ordnen nun die Lösungsschritte nach Schwierigkeit und Warscheinlichkeit
+
+### 1. Systemzeit prüfen
+
+Der einfachste Schritt ist, die Systemzeit des Clients zu verifizieren.
+Weicht die Zeit des Clients um mehr als 5 Minuten vor der des Domänencontrollers ab, so werden Anfragen durch Kerberos verweigert.
+
+✅ **Lösung**: Öffnen Sie eine Konsole und geben den Befehl ```w32tm /resync``` ein. Der Client wird aufgefordert, die Zeit erneut zu synchronisieren.
+
+### 2. Prüfen der Erreichbarkeit von DNS-Servern und Domänencontroller
+
+Was Sie auch einfach mit einer Konsole vom problematischen Client aus erledigen können ist die Konnektivität in Hinsicht auf DNS und Namensauflösung zu testen.
+Kann der Client die Domänencontroller einer Domäne nicht auflösen, so schlägt die Aktualisierung der Gruppenrichlinie ebenfalls fehl.
+Beliebte Fehler sind vergessene DNS-Server im DHCP, Artefakte alter Domänencontroller im Active-Directory und DNS.
+
+✅ **Lösung**:
+
+* Prüfen sie die dem System konfigurierten DNS-Server einfach mit dem Befehl ```ipconfig /all```.
+Führen Sie für jeden der Server einen Ping-Befehl aus.
+Ist ein Server nicht erreichbar, sollten Sie hier weiter forschen und das System aus den DNS-Einstellungen des Clients entfernen.
+Werden die DNS-Server über DHCP verteilt, so müssen Sie die Zone über Ihren DHCP-Server bearbeiten.
+
+* Ausgabe der konfigurierten Domänencontroller
+Untersuchen Sie, ob es in Ihrem Active Directory verwaiste Einträge gibt.
+Öffnen Sie eine Konsole und geben folgenden Befehl ein:
+```
+nslookup -type=SRV _ldap._tcp.dc._msdcs.<IhreDomäne>
+```
+Führen Sie für jeden der Server einen Ping-Befehl aus.
+
+### 3. Prüfen des Datei-Zugriffs
+
+Jeder Benutzer- und Computeraccount einer Domäne muss lesenden Zugriff auf die Objekte der Gruppenrichtlinie haben.
+Ist dies aus einem Grund nicht zutreffend, so kann die Richlinie nicht verarbeitet werden.
+Eine einfache möglichkeit ist, die Stammdatei einfach im Explorer zu öffnen.
+Der Inhalt der Datei ist dabei erstmal unerheblich.
+
+✅ **Lösung**:
+
+Öffnen Sie ein neues Explorer-Fenster auf dem betroffenen Computer und fügen Sie den folgenden Pfad (angepasst auf Ihre Domäne) ein:
+```
+\\<Domäne>\SYSVOL\<Domäne>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini
+```
+Öffnet sich die Datei, so kann davon ausgegangen werden, das hier kein Problem vorliegt.
+
+### 4. Diagnostizieren der Gruppenrichtlinien-Verarbeitung
+
+Prüfen Sie noch einmal ganz genau, was exakt bei der Verarbeitung fehlschlägt.
+Nicht immer muss die gesamte Richlinie betroffen sein. In einigen Fällen scheitern nur Bestandteile des Richliniensatzes in der Verarbeitung.
+
+✅ **Lösung**:
+
+Öffnen Sie auf dem betroffenen Client eine neue Konsole und laden Sie die Richtlinie erneut mit dem Kommando ```gpupdate /force```.
+Danach lassen Sie sich das Ergebnis der Richtlinienverarbeitung ausgeben:
+```
+gpresult /h C:\Temp\report.html
+```
+Es wird im genannten Pfad ```C:\Temp``` eine Datei mit dem Namen ```report.html``` erzeugt, welche Sie mit einem Browser Ihrer Wahl öffnen können.
+Nicht angewendete Gruppenrichtlinien mit dem dazugehörigen Fehlercode werden hier protokolliert.
+
+### 5. Ereignisprotokoll durchsuchen
+
+Auch das Windows-Eventlog kann eine nützliche Informationsquelle sein.
+
+✅ **Lösung**: Suchen Sie im Protokoll ```System``` nach Einträgen mit den Event-IDs ```1058``` und ```1030```.
+
+### 6. Prüfungen am Domänen-Controller
+
+Auch wenn ein Problem an einem Client nicht unbedingt auf ein Problem des DCs hinweist, kann die Prüfung auch nicht schaden.
+Hierzu gibt es einige nützliche Befehle, die Sie in einer Konsole auf einem Domänencontroller ausführen können:
+
+* **dcdiag /v** gibt Auskunft über die generelle Gesundheit Ihres Active Directory
+* **repadmin /replsummary** gibt Auskunft über Rückstände in der Replikation
+* **dfsrdiag backlog /rgname:"Domain System Volume"** gibt Auskunft über Rückstände in der Replikation
+* **net share** gibt Auskunft, ob auch die Notwendigen Freigaben (SYSVOL und NETLOGON) auf dem DC vorhanden sind
+
+Zusätzlich kann ein Prüfen des Dienste-Status helfen. Folgende Dienste müssen gestartet sein:
+
+* Netlogon
+* DFS-R
+* DNS
+* RPC
+* TCP/IP NetBIOS
+
+### 7. Zusätzliche Möglichkeiten
+
+* Langsame Netzwerkverbindungen können die Ausführung der Gruppenrichtline negativ beeinflussen
+* Der Client hat ein defektes Computerkonto oder die Vertrauensstellung ist beeinträchtigt
+* Der Domänencontroller ist über Wifi nicht erreichbar
+* Firewall-Einstellungen verhindern den Zugriff auf den Domänencontroller
+
+✅ **Lösung**:
+
+* Verbinden Sie den Client mit einem Kabel direkt in das Netzwerks des Domänencontrollers
+* Deaktivieren Sie temporär die Firewall auf dem Client
+* Entfernen Sie den Client aus der Domäne und fügen Sie den Client neu hinzu
+
+## Zusammenfassung
+
+Clients, welche die Gruppenrichtlinie nicht mehr korrekt verarbeiten, stellen ein großes Maß an Aufwand dar.
+Die Fehlerursachen sind vielfältig.
+In der Regel liegen größere Probleme zu Grunde, welche evaluiert werden sollten.

articles/2025/05/tls-zertifikat-mit-sha3-256-cbc-auf-windows-server-2016-einspielen.md

@@ -0,0 +1,38 @@
+<!--{"title": "TLS-Zertifikat mit SHA3 auf Windows Server 2016 einspielen", "date": "2025-05-08", "slug": "tls-zertifikat-mit-sha3-256-cbc-auf-windows-server-2016-einspielen", "description": "Wer auf einem Windows Server 2016 ein TLS-Zertifikat einspielen möchte, das mit einem privaten Schlüssel im neuen SHA3-256-CBC-Verfahren erstellt wurde, könnte auf ein frustrierendes Problem stoßen: Beim Importieren erscheint nur die lapidare Fehlermeldung Falsches Kennwort, obwohl das eingegebene Passwort korrekt ist.", "cover": "/static/img/tls-zertifikat-mit-sha3-256-cbc-auf-windows-server-2016-einspielen.webp"}-->
+> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [🌱 <ins>Rechercheunterstützung</ins>](/page/ai)
+
+Wer auf einem Windows Server 2016 ein TLS-Zertifikat einspielen möchte, das mit einem privaten Schlüssel im neuen SHA3-256-CBC-Verfahren erstellt wurde, könnte auf ein frustrierendes Problem stoßen: Beim Importieren erscheint nur die lapidare Fehlermeldung **"Falsches Kennwort"**, obwohl das eingegebene Passwort korrekt ist.
+
+Interessanterweise funktioniert der Import reibungslos, wenn der Schlüssel stattdessen mit **PBE-SHA1-3DES** erstellt wurde. Warum ist das so, und wie kann man das Problem lösen?
+
+### Ursache
+
+Windows Server 2016 (und auch ältere Windows-Versionen) unterstützen bestimmte moderne kryptografische Verfahren nicht nativ. Konkret bedeutet das: Das Betriebssystem kann mit PKCS#12-Dateien (`.pfx`), die mit modernen Verschlüsselungsmethoden wie SHA3-256-CBC verschlüsselt wurden, nicht umgehen. Es erkennt das Format bzw. die Verschlüsselung nicht und interpretiert das als falsches Passwort — daher die irreführende Fehlermeldung.
+
+### Lösungsmöglichkeiten
+
+1. **Schlüssel mit kompatibler Verschlüsselung exportieren**  
+   Der einfachste Weg besteht darin, das Zertifikat und den privaten Schlüssel erneut zu exportieren, aber diesmal mit einer älteren und kompatiblen Verschlüsselung. Verwende dafür **PBE-SHA1-3DES**, da dies von Windows Server 2016 problemlos verarbeitet werden kann.
+
+   Beispiel mit OpenSSL:
+
+   ```
+   openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.pfx -certfile chain.pem -keypbe PBE-SHA1-3DES
+   ```
+
+2. **Server auf neuere Windows-Version upgraden**  
+   Wenn möglich, könnte auch ein Upgrade auf eine neuere Windows-Version (z.B. Windows Server 2022) helfen, da dort modernere Algorithmen unterstützt werden. Das ist jedoch oft mit Aufwand verbunden und sollte gut geplant werden.
+
+3. **Manuelle Entschlüsselung und Neuverpackung**  
+   Falls nur die `.pfx`-Datei vorliegt, könnte man diese zunächst auf einem System entpacken, das SHA3-256-CBC versteht, und dann neu im kompatiblen Format zusammenpacken.
+
+   Beispiel:
+
+   ```
+   openssl pkcs12 -in cert_sha3.pfx -out cert.pem -nodes
+   openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert_compatible.pfx -keypbe PBE-SHA1-3DES
+   ```
+
+### Fazit
+
+Die Fehlermeldung "Falsches Kennwort" beim Einspielen eines TLS-Zertifikats mit einem modernen Schlüssel auf Windows Server 2016 ist irreführend, hat aber eine klare Ursache: fehlende Unterstützung für neuere Verschlüsselungsmethoden. Mit einem Re-Export des Zertifikats im älteren, kompatiblen Format lässt sich das Problem meist schnell beheben.

articles/2025/05/warum-personenbezogene-daten-nie-in-die-betreffzeile-einer-e‑mail-gehoeren.md

@@ -0,0 +1,137 @@
+<!--{"title": "Warum personenbezogene Daten nie in die Betreffzeile einer E‑Mail gehören", "date": "2025-05-07", "slug": "warum-personenbezogene-daten-nie-in-die-betreffzeile-einer-e-mail-gehoeren", "description": "Die Betreffzeile wandert vom Postfach‑Vorschaubereich über Spam‑Gateways bis in Mail‑Archive – fast immer im Klartext.", "cover": "/static/img/warum-personenbezogene-daten-nie-in-die-betreffzeile-einer-e-mail-gehoeren.webp"}-->
+> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [🌱 <ins>Rechercheunterstützung</ins>](/page/ai)
+
+**Warum personenbezogene Daten nie in die Betreffzeile einer E‑Mail gehören**
+
+
+## Kurzer Überblick
+
+Die Betreffzeile wandert vom Postfach‑Vorschaubereich über Spam‑Gateways bis in Mail‑Archive – fast immer im Klartext!
+Selbst wenn Transport Layer Security (TLS) oder Ende‑zu‑Ende‑Verschlüsselung eingesetzt werden,
+bleiben Header‑Daten (Absender, Empfänger, Datum … und eben der Betreff) außen vor – sie sind also für jeden involvierten Mailserver sowie für Administrator‑ oder Gateway‑Logs einsehbar.
+
+## Was gilt als „personenbezogen“?
+Die DSGVO definiert personenbezogene Daten in Art. 4 Nr. 1 als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen – von Namen, 
+Kundennummern oder Personal-ID bis hin zu Gesundheits‑ oder Gehaltsangaben. Schon eine Kombination aus Name + Projektcode kann eine Person eindeutig zuordnen lassen.
+
+> „personenbezogene Daten“ alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person\
+> (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt\
+> oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu\
+> Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck der\
+> physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser\
+> natürlichen Person sind, identifiziert werden kann
+
+## Rechtlicher Rahmen
+
+Es gibt viele Punkte in der DSGVO, auf die sich ein Verstoß herleiten lässt, wenn Sie personenbezogene Daten im Betreff einer E-Mail verwenden.
+
+### Artikel 5 Abs.1 (c + f)
+
+Demnach dürfen Daten nur in dem Umfang erhoben und verarbeitet werden, wie es unbedingt erforderlich ist. Zudem müssen die Daten angemessen geschützt sein.
+Ein Klartext im Betreff verletzt somit beide Grundsätze.
+
+> Personenbezogene Daten müssen\
+> c: dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein („Datenminimierung“);\
+> f: in einer Weise verarbeitet werden, die eine angemessene Sicherheit der personenbezogenen Daten gewährleistet,\
+> einschließlich Schutz vor unbefugter oder unrechtmäßiger Verarbeitung und vor unbeabsichtigtem Verlust,\
+> unbeabsichtigter Zerstörung oder unbeabsichtigter Schädigung durch geeignete **technische und organisatorische Maßnahmen**;
+
+Hier finden wir schon den nächsten Hinweis, **technische und organisatorische Maßnahmen**.
+
+### Artikel 32 - Sicherheit der Verarbeitung
+
+In Absatz 1 findet sich die relevante Definition:
+
+> _Auszug:_\
+> Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der\
+> Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des\
+> Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter\
+> **geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu\
+> gewährleisten**; diese Maßnahmen schließen unter anderem Folgendes ein:
+
+Hier ist insbesondere der Buchstabe A zu nennen:
+
+> die Pseudonymisierung und Verschlüsselung personenbezogener Daten;
+
+Ein offener Betreff der durch keine technische Maßnahme geschützt ist, stellt kein "angemessenes Schutzniveau" dar.
+
+### Artikel 33 & 34 - Melde‑ & Benachrichtigungspflicht
+
+Ist es aber doch passiert, kann das versehentliche Offenlegen sensibler Daten eine meldepflichtige Datenschutzverletzung auslösen.
+
+In Artikel 33 heißt es dazu:
+
+> Im Falle einer Verletzung des Schutzes personenbezogener Daten meldet der Verantwortliche unverzüglich und\
+> möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde, diese der gemäß Artikel 51 zuständigen\
+> Aufsichtsbehörde, es sei denn, dass die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem\
+> Risiko für die Rechte und Freiheiten natürlicher Personen führt. Erfolgt die Meldung an die Aufsichtsbehörde nicht\
+> binnen 72 Stunden, so ist ihr eine Begründung für die Verzögerung beizufügen.
+
+Weiter zu beachten sind ebenfalls:
+
+* Artikel 33 Absatz 3 (Mindestangaben)
+* Artikel 33 Absatz 4 + 5 (Lieferung der Informationen, welche zum Zeitpunkt des Bekanntwerdens nicht geliefert werden können)
+Dies kann insbesondere bei E-Mails der Fall sein. Es ist zumeist nicht eindeutig feststellbar, welche E-Mail-Server in den Verstoß involviert waren.
+
+In Artikel 34 ist geregelt, wann und in welchem Umfang die betroffene Person durch den Verursacher informiert werden muss.
+Hier gibt es keinen Spielraum. Ausnahmebestände nach Absatz 3 kommen in diesem Fall nicht in Frage.
+
+### Bußgelder
+
+Verstöße gegen die Einzelnormen können mit empfindlichen Bußgeldern belegt werden.
+Hier ist Vorsicht geboten.
+
+## Risiken und Folgeabschätzung
+
+Was sind zu erwartende Folgen, welche Sie im Fall des Falles einplanen sollten:
+
+* Reputations- und Vertrauensverlust
+* Finanzielle Schäden
+* Störungen im Geschäftsablauf
+
+Kunden oder auch Mitarbeitende verlieren das Vertrauen, wenn Daten von Ihnen ungewollt veröffentlicht werden.
+Bußgelder, Schadensersatz-Ansprüche, sowie Kosten für Forensik, Anwalts- und Gerichtskosten, sowie steigende Öffentlichkeitsarbeit können die Finanzplanung negativ beeinflussen.
+Die zu erfüllenden Pflichten zur Meldung innerhalb von 72 Stunden, das Beschaffen der Informationen und die Unterbrechung des Betriebsablaufs für Forensik oder Aufsichtsverfahren sind einige mögliche Einschränkungen.
+
+## Typische Fälle, welche bereits zu den Verstößen von Personenbezogenen Daten gehören
+
+* HR-E-Mails: "Bewerbung Max Mustermann - Gehaltsvorstellungen zu hoch"
+* Akten-E-Mail: "Kunde #4711 - Erforderliche Unterlagen nicht vor Fristablauf eingereicht - Abgelehnt"
+
+Jeder dieser Fälle kann sensible Kategorien nach Artikel 9 DSGVO berühren.
+In Unternehmen kann dies auch die Verwendung der Personalnummer im Betreff sein!
+
+## Technische Hintergründe
+
+Warum ist es aber so kritisch, diese Art der Informationen im Betreff zu verwenden?
+Schließlich geben Unternehmen und Provider Unsummen für Verschlüsselungen und die Einhaltung moderner Kryptografie aus.
+
+Der primäre Grund liegt am technischen Design des Mail-Transports. Auch E-Mails, welche mit TLS verschlüsselt übermittelt werden, werden nicht an sich verschlüsselt.
+Es wird lediglich der Kommunikationskanal zwischen den zwei beteiligten Servern verschlüsselt.
+Die zwischengespeicherten E-Mails liegen jedoch (auch wenn nur kurz) unverschlüsselt auf den Systemen.
+Das an sich ist nicht maximal kritisch. Problematisch ist, das jeder E-Mail-Server sogenannte Meta-Daten protokolliert.
+Die Meta-Daten werden für die Protokollierung verwendet, oder für maschinelles Lernen für Spam-Bewertungen.
+Somit findet eine automatische Datenverarbeitung statt, der nicht zugestimmt wurde.
+Passiert das auf einem Server, der nicht Ihnen als Unternehmen gehört, ist das nochmals schlimmer.
+Nun handelt es sich bereits um eine Datenverarbeitung durch Dritte.
+
+Weitere Gründe, die negative Bewertung von Personenbezogenen Daten im Betreff sind:
+
+* Client Geräte zeigen oftmals den Betreff unmittelbar an. Dies ist z.B. bei Smartphones mit Push-Nachrichten der Fall. In bestimmten Fällen werden durch angeschlossenen Systeme (z.B. Car-Play) diese Art der Informatioen sogar laut vorgelesen.
+* Backup und Archive nutzen in der Regel den Betreff als markanten Index. Hier können auch externe Dienstleister ungewollt Zugriff auf sensible Informationen erhalten.
+
+Selbst E‑Mail‑Dienste, die die Nachricht intern verschlüsseln (z. B. ProtonMail), lassen den Betreff aus Gründen der Kompatibilität unverschlüsselt. 
+
+## Technische & organisatorische Schutzmaßnahmen
+
+* Betreff‑Policies: Interne Richtlinie, die personenbezogene Details im Betreff verbietet; statt Namen Ticket‑ oder Referenznummern verwenden
+* E‑Mail‑Verschlüsselungsportale: Nachricht wird in einem Web‑Portal abgelegt, Betreff enthält nur einen neutralen Hinweis („Neue gesicherte Nachricht“)
+* DLP‑Regeln & Content‑Filter: Prüfen Betrefffelder auf Begriffe wie „Geburtsdatum“, „IBAN“, „Mitarbeiter‑ID“ etc. und stoppen den Versand
+* Header‑Verschlüsselung via PGP/MIME (RFC 7435) oder S/MIME „message/rfc822“ Wrapping – setzt jedoch beidseitige Unterstützung voraus
+* Schulungen: Regelmäßiges Training, denn menschliche Fehler verursachen den Großteil der Vorfälle
+* Logging & Review: Betreff‑Zeilen in Archiven regelmäßig stichprobenartig prüfen; Verstöße als KPI im ISMS messen
+
+## Fazit
+
+Die Betreffzeile ist kein geeigneter Ort für personenbezogene Informationen – technisch gesehen bleibt sie fast immer ungeschützt, rechtlich drohen empfindliche Sanktionen, und organisatorisch lassen sich Missgriffe kaum zurückholen, weil Kopien in Backups, Logs und Posteingängen liegen. Wer Datenschutz ernst nimmt, minimiert den Betreff zu einem rein funktionalen Hinweis und verschiebt alles Identifizierbare in den verschlüsselten Teil der Nachricht.
+So schützen Sie nicht nur Betroffene, sondern auch Ihr eigenes Unternehmen vor Bußgeldern, Reputationsschäden und unnötigem Aufwand.

articles/2025/05/windows-server-2025-adds-netzwerk-profil-public-nicht-domainauthentifiziert.md

@@ -0,0 +1,104 @@
+<!--{"title": "Windows Server 2025 Domänen-Controller legt Netzwerkprofil auf Öffentlich fest", "date": "2025-05-09", "slug": "windows-server-2025-adds-netzwerk-profil-public-nicht-domainauthentifiziert", "description": "Wer sich dazu entschließt seine Domänen-Controller auf Windows Server 2025 zu aktualisieren erlebt nicht selten eine böse Überraschung. Nach jedem Neustart wird das Netzwerk-Profil auf Öffentlich gestellt. Das ist besonders für einen Domänencontroller schlecht.", "cover": "/static/img/windows-server-2025-adds-netzwerk-profil-public-nicht-domainauthentifiziert.webp"}-->
+> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [💜 <ins>Kein Einsatz von KI</ins>](/page/ai)
+
+**Windows Server 2025 Domänen-Controller legen nach einem Neustart das Netzwerkprofil auf Öffentlich fest.**
+
+## Problembeschreibung
+
+Der neu aufgesetzte Windows Server 2025 welcher zum Domänen-Controller heraufgestuft wurde, wollte sein Profil des Netzwerk-Adapters nicht mehr konstant behalten.
+Normalerweise muss das Domänen-Profil zugeordnet sein. Statt dessen steht nach jedem Neustart des Systems der Netzwerk-Adapter wieder auf Öffenliches-Netzwerk.
+Dieses Verhalten ist für eine konsistente Konfiguration der Firewall nicht hinnehmbar. Also was tun?
+
+Dieser Bug ist nach meinen Recherchen mindestens seit November 2024 bekannt.
+Da ich in meinem Unternehmen vor der gleichen Problematik stand, musste ich mich zwangsläufig mit der Systematik auseinandersetzen.
+Die Lösungssuche gestalltete sich sehr schwierig, da es auch von Seiten Microsoft keine erkennbare Stellungnahme dazu gibt.
+
+## Lösungsversuche und Recherche
+
+In mehreren Blogs und in der Tech-Community von Microsoft konnte ich eine Reihe von Ansätzen erkennen, die das Problem zwar lösen, für eine reale Lösung jedoch für mich nicht zufriedenstellen genug waren.
+Das Zurücksetzen der Netzwerkkarte nach Neustart in der Aufgabenplanung oder Start-Skript ist ein wirklich guter Work-Around, aber mehr auch nicht.
+Niemand kann damit sicher sein, das ein zufälliges Ereignis der Netzwerkkarte nicht wieder zu einer Änderung des Profils führt.
+
+Nach vielen Recherchen in diverser Fachlektüre bin ich zu dem Schluss gekommen, dass es etwas mit dem NLA-Dienst zu tun haben muss.
+In früheren Erklärungen von Microsoft, welche bis zum Jahr 2016 zurück reichen, wurden die immer größere Relevanz von IPv6 für Systemdienste erwähnt.
+Im Hintergrund funktionieren viele Dinge ungeachtet der Konfiguration, bereits seit einigen Jahren über IPv6.
+
+## Fehlendes IPv6 als mögliche Ursache
+
+### Warum kommt IPv6 als Ursache in Frage
+
+Microsoft behandelt bereits seit Jahren IPv6 höher priorisiert als IPv4.
+Das kann man schon daran erkennen, dass sobald der Client eine IPv6-Adresse bezogen hat, quasi ausschließlich IPv6 gesprochen wird.
+Angefangen von DNS über sonstige Dienste, welche über IPv6 erreichbar sind.
+Die vollständige Deaktivierung von IPv6 über Windows gestaltet sich schwierig. Verwendet man den "Slider" im neuen Einstellungs-Menü, so ist IPv6 nicht "wirklich" deaktiviert.
+Möchte man dies tun, so geht dies nach wie vor nur über die alte Systemsteuerung via Netzwerk -> Adapter und den Haken bei IPv6 herauszunehmen.
+Dies kann man auch gut anhand von ipconfig /all verifizieren.
+
+Mit dem Wissen ist es naheliegend, das Windows zur Zuweisung des Profils IPv6 verwendet. Nach meinen Recherchen wird beim Start des Servers / Clients versucht einen Domänencontroller zu identifizieren.
+Auf einem Domänencontroller konfiguriert man normalerweise immer 127.0.0.1 als primären DNS-Eintrag. Wenn der Server kein IPv6 Profil hat, so ist dort auch kein IPv6 DNS-Eintrag vorhanden (::1).
+
+### Warum wird IPv6 in Unternehmen trotzdem nicht verwendet
+
+Viele Administratoren, wie auch ich, empfinden die Nutzung von IPv6 im Unternehmen als nicht zielführend.
+Die Gründe dafür sind vielfältig:
+
+* Ausreichende Kapazitäten in IPv4-Netzen
+* Komplexe Konfiguration von IPv6
+* Schlechte Möglichkeiten für das Ausrollen automatischer Installationen durch Softwareverteilungen
+* Komplexe Einrichtungen von DHCP-Reservierungen
+* Aufwändige Notation
+* Fehlendes Wissen des komplexen Protokolls
+
+Somit haben viele Administratoren bislang einen großen Bogen um die Konfiguration und den großen Stack an Aufgaben, die im Netzwerkbereich daraus resultieren gemacht.
+Doch das wird nun zunehmend zum Problem.
+
+## Lösung
+
+Wie Sie sich bereits gedacht haben, ist die Lösung tatsächlich die Zuweisung eines IPv6-Profils.
+Zudem habe ich bei uns noch einen Registry-Schlüssel auf unseren Domänen-Controllern angelegt. Das löst die Probleme.
+
+Der Eintrag in der Registrierung ist ein DWORD-Wert (32-Bit) im Schlüsselpfad
+```
+HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
+```
+mit der Bezeichnung ``` AlwaysExpectDomainController ``` und dem Wert ``` 1 ```.
+
+Ich habe für mein Unternehmen eine Möglichkeit die IPv6 bietet verwendet, die relativ unbekannt ist.
+Es ist bei IPv6 vorgesehen, Teile von IPv4 zu integrieren. So kann man einen Präfix wählen, der immer (/96) ist.
+Die letzten Werte sind die IPv4-Adresse des Clients.
+
+Mit diesem Rpäfix ist es möglich nun die IPv4-Adressen der Clients, auch in der Notation, zu integrieren:
+
+```
+fd12:3456:789A:BCDE:: /96
+```
+
+Angenommen Ihr Domänen-Controller hat die IPv4 (172.16.0.10) dann wäre seine IPv6-Adresse nach dem Beispiel:
+
+```
+fd12:3456:789A:BCDE::172.16.0.10 /96
+```
+
+oder umgerechnet:
+
+```
+fd12:3456:789A:BCDE::ac10:a /96
+```
+
+Das ist eine wirklich simple Möglichkeit IPv6 schnell zu Migrieren.
+Sie können diese Adresse in beiden Notationen im Windows-Interface eingeben.
+Windows rechnet die Adresse dann in das rein Hex-Basierte Format um.
+
+In meinem Fall, habe ich die Option Gateway bei IPv6 aktuell nicht konfiguriert.
+
+> Welche IPv6 Adresse Sie verwenden ist jedoch vollkommen unerheblich. Wichtig ist lediglich, das der Domänen-Controller eine IPv6 Adresse hat.
+> Ebenfalls macht es keinen Unterschied, ob die IP fest oder von einem DHCP6-Server vergeben wurde.
+
+Trotzdem erscheint es als Zukunftssicher, sich mit der Thematik auseinanderzusetzen und den Schritt hin zu einem fläschendeckenden Ausrollen von IPv6 in Betracht zu ziehen.
+
+## Fazit
+
+Ich persönlich empfinde es als unzumutbar, das Administratoren für eine eigentlich gut funktionierende "Out-of-the-Box" Installation der ADDS schlecht Dokumentierte Zusatzschritte unternehmen muss, um seine Domäne lauffähig zu halten.
+Der immense Zeitaufwand zur Lösungsfindung war aus meiner Sicht vollkommen vermeidbar.
+
+Ich hoffe dieser Artikel hat Ihnen weiterhelfen können!