Microsoft, offene Standards und die Kunst des Inkompatibel-Seins
Oder: Warum ein eigentlich simples VPN-Setup einen ganzen Tag in Anspruch nimmt — und wer daran schuld ist.
Die Idee war einfach
Szenario: Eine Organisation betreibt ihre Benutzer-Verwaltung mit FreeIPA — einer modernen, offenen Identity-Management-Lösung. Mitarbeiter sollen von außen per VPN sicher ins interne Netzwerk kommen. Windows-Laptops, iPhones, Macs — das übliche.
Klingt nach einem Nachmittagsprojekt. Ist es nicht. Der Grund hat einen Namen: MSCHAPv2.
Was ist FreeIPA?
Wer mit Windows-Unternehmensumgebungen vertraut ist, kennt Active Directory — Microsofts Lösung zur zentralen Verwaltung von Benutzern, Computern und Berechtigungen in einem Netzwerk. FreeIPA ist das Open-Source-Äquivalent für Linux-Umgebungen.
FreeIPA kombiniert bewährte offene Standards:
- LDAP (Lightweight Directory Access Protocol) — der offene Standard für Verzeichnisdienste
- Kerberos — ein Authentifizierungsprotokoll das ursprünglich am MIT entwickelt wurde
- DNS und NTP für Netzwerkinfrastruktur
- Eine integrierte Zertifizierungsstelle (CA)
Alles basiert auf offenen, dokumentierten Standards. Kein Vendor Lock-in, keine proprietären Protokolle. FreeIPA ist in Rechenzentren, Hochschulen und bei Internetprovidern weltweit im Einsatz — überall dort, wo man nicht von Microsoft abhängig sein möchte.
Was ist IKEv2?
IKEv2 (Internet Key Exchange Version 2) ist ein offenes Protokoll für den Aufbau von VPN-Verbindungen. Es wurde gemeinsam von Microsoft und Cisco entwickelt und 2005 als RFC 4306 standardisiert — also ein echter offener Standard, der von allen Betriebssystemen nativ unterstützt wird:
- Windows (seit Version 7)
- macOS und iOS (seit Jahren eingebaut)
- Android (seit Version 11)
- Linux (über strongSwan oder systemd-networkd)
IKEv2 ist modern, schnell, sicher und unterstützt MOBIKE — das bedeutet, eine VPN-Verbindung bleibt bestehen wenn man zwischen WLAN und Mobilfunk wechselt. Ideal für mobile Mitarbeiter.
Das Protokoll selbst ist offen und gut dokumentiert. Das Problem liegt nicht bei IKEv2.
MSCHAPv2 — wo Microsoft den offenen Weg verlässt
Für die Benutzerauthentifizierung im VPN braucht man ein Verfahren, mit dem ein Benutzer seinen Username und sein Passwort sicher übermitteln kann. Hier gibt es offene Standards — und dann gibt es MSCHAPv2.
MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol Version 2) ist ein proprietäres Microsoft-Protokoll aus dem Jahr 1999. Es ist tief im Windows-Netzwerkstack verankert und wird vom nativen Windows VPN-Client als Standard-Authentifizierungsverfahren für IKEv2 verwendet.
Wie funktioniert MSCHAPv2?
Das Protokoll funktioniert so:
- Der VPN-Server schickt dem Client eine zufällige Zahl — den Challenge
- Der Client berechnet daraus eine Response — unter Verwendung eines speziellen Hashwerts des Benutzerpassworts
- Der Server prüft die Response
Klingt vernünftig. Das Problem steckt in Schritt 2: Der verwendete Hashwert ist der sogenannte NT-Hash — das Ergebnis der veralteten MD4-Hashfunktion über das Passwort:
NT-Hash = MD4(Passwort)
MD4 gilt seit den 1990er Jahren als unsicher und wird von keinem modernen Sicherheitsstandard mehr empfohlen. Trotzdem ist es bis heute die kryptografische Grundlage von MSCHAPv2 — und damit des Standard-VPN-Authentifizierungsverfahrens von Windows.
Das eigentliche Problem
Damit der VPN-Server eine MSCHAPv2-Anfrage verifizieren kann, muss er den NT-Hash des Benutzerpassworts kennen und gespeichert haben. Nicht das Passwort selbst — aber diesen spezifischen, auf MD4 basierenden Hashwert.
Das ist der Moment, wo Microsoft und die offene Welt auseinanderfallen.
Was FreeIPA stattdessen macht — und warum das besser ist
FreeIPA speichert Passwörter als Kerberos-Keys — verschlüsselt mit modernen Algorithmen wie AES-256. Diese Keys können nicht in einen NT-Hash umgerechnet werden. Das ist kein Bug — das ist eine bewusste Sicherheitsentscheidung.
Warum das sinnvoll ist: Wer keinen NT-Hash speichert, kann auch keinen NT-Hash verlieren. Ein kompromittierter LDAP-Server gibt Angreifern keine NT-Hashes, mit denen sie sich in Windows-Systeme einloggen könnten. FreeIPA folgt dem Prinzip der minimalen Angriffsfläche.
| FreeIPA | MSCHAPv2 erwartet | |
|---|---|---|
| Passwort gespeichert als | Kerberos AES-256 Keys | NT-Hash (MD4) |
| Umrechenbar? |  Nein |
— |
| Sicherheitsniveau | Modern | 1990er Jahre |
Das Ergebnis: FreeIPA und MSCHAPv2 sind fundamental inkompatibel — nicht wegen schlechter Konfiguration, sondern wegen unterschiedlicher Sicherheitsphilosophien.
Alle Umgehungsversuche scheitern am gleichen Punkt
In der Praxis führt das zu einer frustrierenden Debugging-Session. Man versucht alles:
RADIUS als Vermittler? FreeRADIUS mit dem mschap-Modul kann MSCHAPv2 verarbeiten — aber nur wenn irgendwo ein NT-Hash verfügbar ist. FreeIPA liefert keinen.
Samba Winbind gegen FreeIPA? Funktioniert im interaktiven Modus (Passwort eintippen) — weil dabei das Passwort als Klartext übergeben und lokal in einen NT-Hash umgerechnet wird. Im Challenge/Response-Modus (wie VPN ihn braucht) schlägt es fehl — der NT-Hash muss im Backend verfügbar sein.
Forest Trust zu einem Samba Domain Controller? Samba speichert NT-Hashes für seine eigenen User — aber Forest Trusts replizieren diese Hashes aus Sicherheitsgründen nicht domain-übergreifend. Wieder eine Sackgasse.
Jeder Versuch scheitert am gleichen fundamentalen Problem: MSCHAPv2 erzwingt die Speicherung von MD4-Hashes. Kein modernes, sicherheitsbewusstes Identitätssystem tut das.
Mit offenen Protokollen wäre das alles kein Problem
Hätte Microsoft statt MSCHAPv2 auf offene Standards gesetzt, würde diese Geschichte anders enden.
EAP-TTLS/PAP zum Beispiel: Ein offenes Verfahren, bei dem das Passwort in einem verschlüsselten TLS-Tunnel übertragen wird. Der Server kann es dann mit einem einfachen LDAP-Bind gegen FreeIPA verifizieren — ohne NT-Hash, ohne MD4, ohne proprietäre Abhängigkeiten. FreeRADIUS unterstützt das. strongSwan unterstützt das. Aber der native Windows IKEv2 Client? Unterstützt es nicht.
PEAP (Protected EAP) wäre eine weitere Option — ebenfalls ein offener Standard, der Passwörter in einem TLS-Tunnel schützt. Aber auch hier: Windows IKEv2 setzt auf MSCHAPv2 als inneres Authentifizierungsverfahren.
Die Ironie: IKEv2 selbst ist ein offener Standard. Das Zertifikat, das der VPN-Server vorzeigt, kann von Let’s Encrypt kommen — kostenlos, offen, vertrauenswürdig. Aber beim letzten Schritt, der Benutzerauthentifizierung, zwingt Windows in ein proprietäres Protokoll aus dem letzten Jahrtausend.
Die Lösung: Weg von MSCHAPv2
Der pragmatischste Ausweg ist ein anderes VPN-Protokoll. OpenVPN zum Beispiel ist vollständig open source, hat Clients für alle Plattformen, und authentifiziert Benutzer über RADIUS mit PAP — einem simplen, offenen Verfahren, das wunderbar mit FreeIPA zusammenarbeitet:
OpenVPN Client
→ TLS-verschlüsselter Tunnel
→ PAP (Username/Passwort)
→ FreeRADIUS
→ FreeIPA LDAP
→ Kerberos-Verifikation ✅
Kein NT-Hash. Kein MD4. Kein MSCHAPv2. Es funktioniert einfach.
Alternativ funktioniert IKEv2 mit Zertifikat-basierter Authentifizierung (EAP-TLS) — FreeIPA stellt User-Zertifikate aus, Windows vertraut ihnen. Modernes Protokoll, moderne Kryptografie. Aber das erfordert Zertifikat-Management auf jedem Gerät.
Das eigentliche Problem
MSCHAPv2 ist nicht das einzige Beispiel dafür, dass Microsoft proprietäre Protokolle tief in seine Betriebssysteme einbaut und damit Interoperabilität mit offenen Systemen erschwert. Es ist ein Muster.
Das frustrierende daran: Technisch wäre alles lösbar. Die offenen Standards existieren. FreeIPA, FreeRADIUS, strongSwan, OpenVPN — alle unterstützen moderne, sichere Authentifizierungsverfahren. Nur der Windows-Client weigert sich, sie für IKEv2 zu verwenden.
Am Ende des Tages steht die Wahl: Entweder man passt die Infrastruktur an Microsofts veraltete Protokolle an — inklusive der damit verbundenen Sicherheitskompromisse — oder man wählt ein VPN-Protokoll, das mit offenen Standards arbeitet.
Wir haben uns für OpenVPN entschieden. Der Nachmittag wurde ein langer Tag. Das Eis danach war gut verdient. 
Digitale Souveränität endet nicht bei der Wahl des Betriebssystems. Sie endet auch nicht bei der Wahl des Servers. Sie endet dort, wo ein unsicheres proprietäres Protokoll aus den 1990ern die letzte Meile kontrolliert. Jetzt tut es das nicht mehr.
Tags: FreeIPA, IKEv2, MSCHAPv2, OpenVPN, strongSwan, Open Source, Windows, Interoperabilität, VPN, Sicherheit