In der heutigen vernetzten Arbeitswelt ist ein zuverlässiger Zugriff auf Unternehmensressourcen von überall unerlässlich. Microsofts Always On VPN (AOVPN) bietet hierfür eine robuste Lösung, die eine nahtlose und persistente Verbindung zum Firmennetzwerk ermöglicht. Doch selbst die beste Technologie ist nicht immun gegen Probleme. Eine besonders frustrierende Fehlermeldung, die IT-Administratoren und Anwender gleichermaßen verzweifeln lässt, lautet: „Ike credentials are unacceptable”.
Wenn diese Meldung auf dem Bildschirm erscheint, bedeutet das oft eine Blockade bei der Arbeit und einen erhöhten Fehlersuchaufwand. Keine Sorge, Sie sind nicht allein mit diesem Problem, und in den meisten Fällen lässt es sich mit einer systematischen Herangehensweise beheben. Dieser Artikel taucht tief in die Ursachen dieses spezifischen AOVPN-Fehlers ein und bietet Ihnen eine detaillierte, Schritt-für-Schritt-Anleitung zur Fehlerbehebung, um Ihre Always On VPN-Verbindung schnell wiederherzustellen.
Always On VPN (AOVPN) kurz erklärt
Bevor wir uns den Fehlern widmen, lassen Sie uns kurz rekapitulieren, was Always On VPN so besonders macht. Im Gegensatz zu traditionellen VPNs, die manuell verbunden werden müssen, stellt AOVPN automatisch eine Verbindung her, sobald ein Gerät mit dem Internet verbunden ist – und hält diese auch aufrecht. Es ermöglicht sowohl die Geräte-Tunnel-VPN-Verbindung (Machine Tunnel), die bereits vor der Benutzeranmeldung aktiv ist, als auch die Benutzer-Tunnel-VPN-Verbindung (User Tunnel), die nach der Anmeldung des Benutzers aufgebaut wird.
Diese Funktionalität basiert auf einer komplexen Infrastruktur, die typischerweise folgende Komponenten umfasst:
- Routing and Remote Access Service (RRAS) Server: Der VPN-Server, der die eingehenden VPN-Verbindungen annimmt.
- Network Policy Server (NPS): Ein RADIUS-Server, der für die Authentifizierung und Autorisierung der VPN-Clients zuständig ist.
- Public Key Infrastructure (PKI): Eine Zertifizierungsstelle (CA), die die erforderlichen X.509-Zertifikate für Client und Server ausstellt.
- Gruppenrichtlinien (GPOs) oder Microsoft Intune: Zur automatisierten Bereitstellung der AOVPN-Profile und Zertifikate an die Clients.
Die Sicherheit dieser Verbindungen wird maßgeblich durch IPsec (Internet Protocol Security) gewährleistet, das auf dem IKEv2 (Internet Key Exchange Version 2)-Protokoll basiert. Und genau hier liegt der Kern unseres Problems.
Verständnis von IKE und Anmeldeinformationen im VPN-Kontext
Der Fehler „Ike credentials are unacceptable” weist direkt auf ein Problem im Initialisierungsprozess der IPsec-Sicherheitsassoziation hin, der als IKE-Phase bekannt ist. IKEv2 ist das Protokoll, das für die Einrichtung eines sicheren Kanals zwischen dem VPN-Client und dem VPN-Server verantwortlich ist. Es kümmert sich um zwei Hauptaufgaben:
- Authentifizierung: Client und Server müssen sich gegenseitig identifizieren und ihre Legitimität nachweisen.
- Schlüsselaustausch: Sichere Vereinbarung von Verschlüsselungsschlüsseln für die nachfolgende Datenkommunikation.
Die „Anmeldeinformationen” (Credentials) im Kontext von AOVPN und IKEv2 sind in den meisten Fällen digitale Zertifikate. Für eine erfolgreiche Verbindung müssen sowohl der Client als auch der Server die jeweils vom Gegenüber präsentierten Zertifikate validieren können. Wenn diese Validierung fehlschlägt, weil ein Zertifikat ungültig, abgelaufen, widerrufen ist oder die ausstellende Stelle nicht vertrauenswürdig ist, wird der IKE-Verbindungsversuch mit dem besagten Fehler abgebrochen.
Häufige Ursachen für den Fehler „Ike credentials are unacceptable”
Der Fehler ist generisch und kann auf verschiedene spezifische Probleme hindeuten. Die häufigsten Ursachen lassen sich in folgende Kategorien einteilen:
1. Zertifikatsprobleme (Die häufigste Ursache!)
Dies ist mit Abstand der Hauptgrund für „Ike credentials are unacceptable”. Sowohl der Client als auch der Server müssen über gültige und korrekt konfigurierte Zertifikate verfügen.
- Ablaufende Zertifikate: Ein Client- oder Serverzertifikat ist abgelaufen. Der VPN-Server kann das Client-Zertifikat nicht validieren, oder der Client kann das Server-Zertifikat nicht validieren.
- Fehlende oder ungültige Zertifikate:
- Der Client besitzt kein gültiges Maschinenzertifikat (für den Gerätetunnel) oder Benutzerzertifikat (für den Benutzertunnel).
- Dem VPN-Server fehlt ein gültiges Serverauthentifizierungszertifikat oder es ist nicht korrekt im RRAS konfiguriert.
- Einer der Kommunikationspartner (Client oder Server) vertraut der Zertifizierungsstelle (CA) nicht, die das Zertifikat des Gegenübers ausgestellt hat. Dies geschieht, wenn die Stammzertifikate der CA nicht in den jeweiligen „Vertrauenswürdige Stammzertifizierungsstellen”-Speichern vorhanden sind.
- Das Zertifikat hat die falsche Erweiterte Schlüsselverwendung (EKU). Z.B. fehlt die Clientauthentifizierung für Client-Zertifikate oder die Serverauthentifizierung für Server-Zertifikate.
- Zertifikatswiderruf: Das Zertifikat wurde widerrufen und steht auf einer Certificate Revocation List (CRL) oder ist über Online Certificate Status Protocol (OCSP) als ungültig markiert, und die CRL/OCSP-Server sind erreichbar.
- Privater Schlüssel fehlt oder ist unzugänglich: Obwohl das Zertifikat sichtbar ist, ist der dazugehörige private Schlüssel entweder nicht vorhanden oder der Prozess, der ihn verwenden möchte (z.B. der IKEv2-Dienst), hat keine Berechtigung darauf zuzugreifen.
2. NPS-Server (RADIUS) Konfigurationsfehler
Der NPS-Server ist für die Autorisierung zuständig. Wenn die Richtlinien hier nicht stimmen, schlägt die Authentifizierung fehl.
- Falsche Netzwerkrichtlinien: Die auf dem NPS konfigurierten Netzwerkrichtlinien (Connection Request Policies und Network Policies) stimmen nicht mit den vom Client erwarteten Authentifizierungsmethoden überein (z.B. EAP-TLS oder PEAP-MSCHAPv2).
- Falsche Bedingungen oder Einschränkungen: Die Bedingungen der NPS-Richtlinie (z.B. bestimmte AD-Benutzer-/Computergruppen) passen nicht zu den anfragenden Clients. Oder die Einschränkungen (z.B. NAS Port Type) sind falsch gesetzt.
- VPN-Server nicht als RADIUS-Client im NPS registriert: Der RRAS-Server muss im NPS als RADIUS-Client eingetragen sein, und das gemeinsame Geheimnis (Shared Secret) muss auf beiden Seiten exakt übereinstimmen.
3. VPN-Server (RRAS) Konfigurationsfehler
Probleme mit der Konfiguration des RRAS-Servers selbst können ebenfalls den Fehler verursachen.
- Falsche Authentifizierungsmethode konfiguriert: Der RRAS-Server ist so konfiguriert, dass er eine andere Authentifizierungsmethode erwartet, als die, die der NPS-Server oder der Client bereitstellt.
- Falsches Serverauthentifizierungszertifikat gebunden: Obwohl ein gültiges Zertifikat vorhanden ist, ist es im RRAS nicht korrekt an die IKEv2-Schnittstelle gebunden.
- NPS-Weiterleitungsprobleme: Der RRAS-Server ist nicht korrekt konfiguriert, um Authentifizierungsanfragen an den NPS-Server weiterzuleiten.
4. Netzwerk- und Firewall-Probleme
Obwohl seltener bei diesem spezifischen Fehler, können Netzwerkprobleme die Kommunikation stören.
- Firewall blockiert Ports: Firewalls auf Client, VPN-Server oder im Netzwerk blockieren die für IKE/IPsec erforderlichen UDP-Ports 500 (IKE) und 4500 (IPsec NAT-T).
- NAT-Traversal (NAT-T) Probleme: Wenn Clients hinter NAT-Geräten sitzen, kann es zu Problemen mit der NAT-T-Implementierung kommen.
5. Client-seitige Konfigurationsfehler
Fehler im AOVPN-Clientprofil oder in der Bereitstellung.
- Falsches VPN-Profil: Das AOVPN-Profil auf dem Client enthält fehlerhafte Informationen, z.B. einen falschen FQDN des VPN-Servers.
- Probleme bei der GPO-Bereitstellung: Zertifikate oder VPN-Profil wurden nicht korrekt über Gruppenrichtlinien auf den Client übertragen.
Schritt-für-Schritt-Fehlerbehebung: So lösen Sie das Problem
Gehen Sie die folgenden Schritte systematisch durch, um die Ursache des Fehlers „Ike credentials are unacceptable” zu identifizieren und zu beheben.
Schritt 1: Überprüfen der Ereignisanzeige auf dem NPS-Server (Priorität 1!)
Beginnen Sie hier, da der NPS-Server oft die präzisesten Fehlermeldungen liefert, warum eine Authentifizierung fehlschlägt.
- Öffnen Sie die Ereignisanzeige (Event Viewer) auf Ihrem NPS-Server.
- Navigieren Sie zu
Anwendungs- und Dienstprotokolle->Microsoft->Windows->NetworkPolicyServer. - Suchen Sie nach Ereignissen mit den IDs 6273, 6274, 6278, 6276, 6275. Diese IDs geben Auskunft über Authentifizierungsversuche und deren Ergebnisse.
- ID 6273 „Der Netzwerkrichtlinienserver hat den Zugriff für einen Benutzer verweigert.”: Dies ist der häufigste Fehler. Die Beschreibung enthält detaillierte Informationen darüber, warum der Zugriff verweigert wurde, z.B. „Die vom Benutzer präsentierten Anmeldeinformationen sind möglicherweise nicht vertrauenswürdig.”, „Der Client hat kein gültiges Clientauthentifizierungszertifikat.”, „Die EAP-Authentifizierung schlug fehl”.
- ID 6274: Beschreibt den Grund für den fehlgeschlagenen Authentifizierungsversuch genauer.
- ID 6276: Zeigt an, dass die Verbindung vom Benutzer oder Computer beendet wurde (oft nach einem Authentifizierungsfehler).
- Die Fehlermeldung im Ereignisprotokoll des NPS-Servers ist oft sehr präzise und führt Sie direkt zur Wurzel des Problems (z.B. „Ungültiges Client-Zertifikat”, „Falsche EAP-Methode”).
Schritt 2: Überprüfen der Zertifikate auf Client und Server
Basierend auf den Erkenntnissen aus Schritt 1 oder als genereller erster Schritt, wenn der NPS-Server keine klare Meldung liefert.
Auf dem VPN-Client:
- Öffnen Sie
certmgr.msc(für Benutzerzertifikate) undcertlm.msc(für Maschinenzertifikate). - Navigieren Sie zu
Eigene Zertifikate->Zertifikate.- Gerätetunnel: Überprüfen Sie das Maschinenzertifikat des Computers. Es sollte eine „Clientauthentifizierung” EKU haben.
- Benutzertunnel: Überprüfen Sie das Benutzerzertifikat des angemeldeten Benutzers. Es sollte ebenfalls eine „Clientauthentifizierung” EKU haben.
- Für jedes Zertifikat:
- Gültigkeitsdatum prüfen: Ist es abgelaufen?
- Zertifizierungspfad prüfen: Ist der gesamte Pfad zur Stamm-CA gültig und vertrauenswürdig? Befindet sich die Stamm-CA in
Vertrauenswürdige Stammzertifizierungsstellen? - Privaten Schlüssel prüfen: Das Zertifikat muss einen dazugehörigen privaten Schlüssel haben, der nicht als exportierbar gekennzeichnet sein muss, aber für den Zugriff verfügbar sein muss.
- Erweiterte Schlüsselverwendung (EKU): Stellen Sie sicher, dass „Clientauthentifizierung” für die Client-Zertifikate aufgeführt ist.
- Überprüfen Sie auch
Nicht vertrauenswürdige Zertifikate, ob das Client- oder Serverzertifikat dort gelandet ist.
Auf dem VPN-Server (RRAS):
- Öffnen Sie
certlm.msc. - Navigieren Sie zu
Eigene Zertifikate->Zertifikate. - Suchen Sie das Serverauthentifizierungszertifikat, das für RRAS verwendet wird.
- Gültigkeitsdatum und Zertifizierungspfad prüfen (analog zum Client). Die Stamm-CA des Client-Zertifikats muss dem Server vertrauen und umgekehrt.
- Erweiterte Schlüsselverwendung (EKU): Stellen Sie sicher, dass „Serverauthentifizierung” aufgeführt ist.
- Öffnen Sie die Routing und RAS-Dienst-Konsole. Rechtsklick auf den Server ->
Eigenschaften->Sicherheit. - Im Abschnitt „IPsec” (IKEv2) stellen Sie sicher, dass das korrekte Zertifikat aus dem Dropdown-Menü ausgewählt ist und noch gültig ist.
Schritt 3: Überprüfen der NPS-Server-Konfiguration
Wenn die Zertifikate in Ordnung zu sein scheinen, könnte die NPS-Konfiguration der Übeltäter sein.
- Öffnen Sie die NPS-Konsole.
- Navigieren Sie zu
RADIUS-Clients und Server für den Remotezugriff->RADIUS-Clients.- Stellen Sie sicher, dass der RRAS-Server als RADIUS-Client mit seiner korrekten IP-Adresse und dem exakt passenden gemeinsamen Geheimnis (Shared Secret) eingetragen ist.
- Navigieren Sie zu
Richtlinien->Netzwerkrichtlinien.- Identifizieren Sie die für AOVPN relevanten Richtlinien (oft „Always On VPN – Device Tunnel” und „Always On VPN – User Tunnel”).
- Verarbeitungsreihenfolge: Stellen Sie sicher, dass die spezifischsten Richtlinien zuerst verarbeitet werden.
- Bedingungen: Prüfen Sie, ob die Bedingungen (z.B. Mitgliedschaft in einer bestimmten AD-Sicherheitsgruppe für Benutzer oder Computer) korrekt konfiguriert sind und der Client diesen Bedingungen entspricht.
- Einschränkungen: Überprüfen Sie unter
Einschränkungen->NAS Port Type, obVirtual (VPN)erlaubt ist. - Konfigurierte Authentifizierungsmethode: Dies ist entscheidend. Klicken Sie auf
Bearbeitender Richtlinie und gehen Sie zum ReiterEinschränkungen. UnterAuthentifizierungsmethodenmüssen die korrekten EAP-Typen ausgewählt sein (z.B. „Microsoft: Smartcard oder anderes Zertifikat” für EAP-TLS oder „Microsoft: Geschütztes EAP (PEAP)” für PEAP-MSCHAPv2, falls verwendet). Stellen Sie sicher, dass diese mit der auf dem Client und RRAS erwarteten Methode übereinstimmen.
Schritt 4: Überprüfen der VPN-Server (RRAS) Konfiguration
- Öffnen Sie die Routing und RAS-Dienst-Konsole.
- Rechtsklick auf den Server ->
Eigenschaften->Sicherheit.- Unter
Authentifizierungsmethoden: Stellen Sie sicher, dassRADIUS-AuthentifizierungundRADIUS-Abrechnungausgewählt sind (wenn NPS verwendet wird). - Wenn Sie lokal authentifizieren (was bei AOVPN unüblich und unsicher ist), stellen Sie sicher, dass die lokalen Methoden korrekt sind.
- Unter
- Navigieren Sie zu
IPv4->RADIUS-Authentifizierung. Stellen Sie sicher, dass der NPS-Server hier korrekt eingetragen ist, inklusive dem gemeinsamen Geheimnis. - Überprüfen Sie die Ereignisanzeige auf dem RRAS-Server (System- und Anwendungsprotokolle) auf IKEv2-spezifische Fehler (z.B. Event IDs 20227, 20272, 20257 für IPsec- oder IKE-Fehler).
Schritt 5: Überprüfung der Netzwerk- und Firewall-Einstellungen
- Stellen Sie sicher, dass Firewalls auf dem Client, dem VPN-Server und allen Netzwerkgeräten (Router, Hardware-Firewalls) die erforderlichen Ports zulassen:
- UDP-Port 500 (für IKE).
- UDP-Port 4500 (für IPsec NAT-T, falls der Client hinter einem NAT-Gerät ist).
- Zwischen RRAS- und NPS-Server: UDP-Ports 1812/1813 (oder die älteren 1645/1646) für RADIUS-Kommunikation.
- Verwenden Sie
Test-NetConnection(PowerShell) odertelnet(falls installiert) vom Client zum VPN-Server (Port 500/4500) und vom RRAS-Server zum NPS-Server (Port 1812/1813), um die Konnektivität zu prüfen.
Schritt 6: Client-seitige Überprüfung und erweiterte Diagnose
- AOVPN-Profil: Stellen Sie sicher, dass das VPN-Profil auf dem Client korrekt installiert ist und der FQDN des VPN-Servers stimmt. Sie können dies mit
Get-VpnConnection -AllUserConnectionin PowerShell überprüfen. - Neustart des Dienstes: Manchmal hilft ein Neustart des „IKE and AuthIP IPsec Keying Modules”-Dienstes auf dem Client oder des „Routing and Remote Access”-Dienstes auf dem Server.
- Netzwerkmonitor / Wireshark: Für fortgeschrittene Fehlersuche kann eine Netzwerkanalyse auf Client und Server (insbesondere während des Verbindungsversuchs) sehr aufschlussreich sein. Suchen Sie nach IKE_SA_INIT-Paketen und deren Antworten, um zu sehen, wo der Handshake abbricht.
- IKEv2 Diagnostics PowerShell Module: Es gibt spezielle PowerShell-Module, die bei der Diagnose von IKEv2-Verbindungsproblemen helfen können.
Präventive Maßnahmen und Best Practices
Um zukünftige Verbindungsfehler zu vermeiden, sollten Sie folgende Best Practices implementieren:
- Zertifikatslebenszyklus-Management: Implementieren Sie eine robuste PKI und automatisieren Sie die Erneuerung von Client- und Serverzertifikaten, um Abläufe zu vermeiden. Überwachen Sie Zertifikatsablaufdaten aktiv.
- Regelmäßige Überprüfung der NPS-Richtlinien: Stellen Sie sicher, dass Ihre Netzwerkrichtlinien auf dem NPS-Server aktuell sind und den aktuellen Anforderungen entsprechen.
- Dokumentation: Führen Sie eine detaillierte Dokumentation Ihrer AOVPN-Infrastruktur, einschließlich Zertifikatdetails, NPS-Richtlinien und RRAS-Konfigurationen.
- Monitoring: Überwachen Sie die Ereignisanzeigen auf Ihren RRAS- und NPS-Servern auf Warnungen oder Fehler im Zusammenhang mit AOVPN und IKE.
- Testen: Führen Sie nach jeder Änderung an der AOVPN-Konfiguration gründliche Tests durch.
Fazit
Der Verbindungsfehler „Ike credentials are unacceptable” bei Always On VPN kann anfänglich entmutigend wirken, ist jedoch in den meisten Fällen auf Probleme mit Zertifikaten oder der NPS-Konfiguration zurückzuführen. Durch eine systematische Fehlersuche, beginnend mit den detaillierten Fehlermeldungen in der Ereignisanzeige des NPS-Servers und der sorgfältigen Überprüfung aller beteiligten Zertifikate und Konfigurationen, können Sie die Ursache des Problems effektiv eingrenzen und beheben.
Eine gut geplante und gewartete AOVPN-Infrastruktur, unterstützt durch proaktives Zertifikatsmanagement und regelmäßige Überprüfung der Konfigurationen, ist der Schlüssel zu einer stabilen und sicheren Konnektivität für Ihre Benutzer.