Wir haben vor kurzem eine Implementierung unseres Certificate Management System (CMS) Version 4.0 für einen Kunden durchgeführt und sind dabei auf ein bizarres Problem mit der Microsoft-Implementierung von SCEP - dem Microsoft Network Device Enrollment Service (NDES) Certificate Authority Role Service unter der Active Directory Certificate Services (AD CS) Role - auf Windows Server 2012 R2 gestoßen, das uns vorher noch nie begegnet ist. Ich dachte, ich erzähle Ihnen alles darüber, damit Sie, falls Sie auf dieses Problem stoßen, nicht so lange mit dem Kopf gegen die Wand rennen müssen wie wir, bevor Sie eine Lösung finden.
Microsofts NDES wird in Verbindung mit CMS verwendet, um die Anmeldung für Zertifikate von iOS-Geräten zu unterstützen. In dieser speziellen Kundenimplementierung wurde CMS auf demselben Server installiert, auf dem auch die Microsoft NDES-Rolle installiert war. Dies ist ein übliches Implementierungsdesign. Sowohl CMS als auch NDES laufen unter IIS, aber CMS benötigt mehr IIS-Rollendienste als NDES. Außerdem ist ASP.NET 4.5 erforderlich, das unter IIS Application Development auf Windows Server 2012 R2 sowohl ein Feature als auch ein Rollendienst ist.
Da NDES ein wenig fummelig sein kann, um es zum Laufen zu bringen, installieren wir es normalerweise zuerst und stellen sicher, dass es erfolgreich SCEP-Herausforderungen ausgibt, bevor wir CMS installieren, was wir in diesem Fall getan haben. Aber so sehr wir uns auch bemühten, wir konnten den NDES-Dienst nicht dazu bringen, SCEP-Challenges auszugeben. Wir hatten den NDES gemäß der Microsoft-Dokumentation unter Verwendung der Kerberos-Authentifizierung korrekt konfiguriert und unseren Benutzern Rechte zur Registrierung für Zertifikate unter Verwendung der für die Verwendung durch den NDES konfigurierten Vorlage erteilt. Aber jedes Mal, wenn wir eine SCEP-Herausforderung anforderten, erhielten wir die Meldung, dass wir nicht über ausreichende Berechtigungen zur Anforderung einer SCEP-Herausforderung verfügten. Die genaue Meldung im Ereignisprotokoll für jeden Fehler lautete:
Der Network Device Enrollment Service kann sein Kennwort nicht bereitstellen, weil der Benutzer nicht über Enroll-Berechtigungen für die konfigurierte Zertifikatsvorlage verfügt oder die Zertifizierungsstelle nicht in der Lage ist, Zertifikate auf der Grundlage der konfigurierten Zertifikatsvorlage auszustellen.
Die Nachricht, die der Endnutzer erhielt, lautete:
Sie haben keine ausreichende Berechtigung, sich bei SCEP anzumelden. Bitte wenden Sie sich an Ihren Systemadministrator.
Während wir weiter mit dem Kopf gegen die Wand rannten, bemerkten wir einige sehr merkwürdige Verhaltensweisen:
- Wenn wir unserem Benutzer lokale administrative Rechte auf dem NDES-Server gewährten, konnte dieser Benutzer eine SCEP-Challenge aus der Ferne abrufen (indem er von einem anderen Computer aus die vom NDES-Server bereitgestellte URL /certsrv/mscep_admin aufrief), war aber nicht in der Lage, eine SCEP-Challenge lokal abzurufen. Damit CMS korrekt funktioniert, muss dies lokal funktionieren. Außerdem ist es ein Sicherheitsrisiko, dem Benutzer (für die CMS-Funktionalität wäre dies das Dienstkonto, unter dem CMS läuft) lokale administrative Rechte auf dem Server zu gewähren, und das sollte nicht erforderlich sein.
- Der Domänenadministrationsbenutzer "Administrator" (das integrierte Konto) konnte lokal eine SCEP-Herausforderung erhalten, aber kein anderes Domänen- oder Unternehmensadministratorkonto konnte lokal eine SCEP-Herausforderung erhalten. Beachten Sie, dass dieses Verhalten nur in Umgebungen auftrat, in denen der NDES für die Kerberos-Authentifizierung konfiguriert war. Wenn der NDES korrekt funktioniert, arbeitet er erfolgreich innerhalb einer einzelnen Domäne mit NTLM-Authentifizierung.
- Die Meldung "Berechtigung verweigert" beim Versuch, eine SCEP-Herausforderung zu erhalten, trat auch dann auf, wenn wir der magischen Gruppe "Jeder" die Berechtigung zur Anmeldung bei der für NDES konfigurierten CA-Vorlage erteilt hatten.
Offensichtlich war die Meldung "Erlaubnis verweigert" eine Fälschung und etwas anderes lief schief, aber was? Sind Sie bereit für die große Enthüllung? Hier ist, was es sein sollte.
Als wir die NDES-Rollen auf dem Server installiert haben (sowohl den Network Device Enrollment Service als auch die Certificate Authority Web Enrollment-Rollen), haben wir gleichzeitig die zusätzlichen Rollen installiert, die für CMS benötigt werden - Basic Authentication for IIS und ASP.NET 4.5 (sowohl die Funktion als auch den IIS-Rollendienst). NDES auf Windows Server 2012 R2 spielt damit nicht gut zusammen. Das Gemurmel, das wir von Microsoft dazu gehört haben, war, dass die web.config-Datei, die von NDES verwendet wird, von einer dieser anderen Rollen beschädigt wird, was zu einer Situation führt, in der NDES nicht mehr funktionieren kann.
Die Lösung für dieses Problem? Deinstallieren Sie NDES (alle CA-Rollen) und alle IIS-Rollen. Installieren Sie dann nur die NDES-Rollen und alle IIS-Rollendienste neu, die installiert werden sollen. Wählen Sie bei dieser ersten Installation keine zusätzlichen Rollen oder Funktionen aus. Sobald die SCEP-Herausforderungen sowohl aus der Ferne als auch lokal funktionieren (ohne Passwortabfrage), können Sie zurückgehen und die zusätzlichen erforderlichen Rollen und Funktionen für CMS installieren und mit der CMS-Implementierung fortfahren.
WARNUNG: Deinstallieren Sie .NET Framework 4.5 nicht von Windows Server 2012 R2. Dadurch wird die grafische Benutzeroberfläche des Computers deinstalliert, so dass Sie etwas haben, das wie eine Windows Server Core-Installation aussieht. Es ist in Ordnung, ASP.NET 4.5 zu deinstallieren, aber es ist nicht erforderlich, um das Problem zu beheben.
Bei der Fehlersuche zu diesem NDES-Problem stießen wir auf ein weiteres seltsames NDES-Problem, das dieselbe falsche Fehlermeldung wie das obige verursachte, aber eine andere Ursache hatte. In diesem alternativen Fall war das Problem das Ergebnis eines IIS Handler Mapping-Fehlers. Dieser Fehler ist spezifisch für Windows Server 2012 R2 und NDES und scheint mit der Installation der ASP.NET 4.5-Rolle zusätzlich zu den NDES- und Webregistrierungsrollen auf dem NDES-Server zusammenzuhängen, obwohl wir noch auf eine Mitteilung von Microsoft über die genaue Ursache dieses Problems warten. Wenn Sie auf dieses Problem stoßen und die obige Neuinstallationsmethode das Problem nicht löst, versuchen Sie diese Lösung:
- Starten Sie den IIS-Manager mit der Option "Als Administrator ausführen".
- Gehen Sie zum virtuellen Verzeichnis mscep_admin unter certsrv für die Standard-Website.
- Doppelklicken Sie auf "Handler-Zuordnungen".
- Klicken Sie im rechten Fenster auf "Bestellte Liste anzeigen...".
- Suchen Sie "ExtensionlessURLHandler-ISAPI-4.0_64bit" und wählen Sie es aus.
- Klicken Sie im rechten Fensterbereich unter "Aktionen" auf "Nach unten", bis "ExtensionlessURLHandler-ISAPI-4.0_64bit" ganz unten in der Liste steht.
- Starten Sie den IIS im IIS-Manager oder über eine administrative Eingabeaufforderung command mit "iisreset" neu.
- Versuchen Sie erneut, die SCEP-Challenge als NDES-Dienstkonto sowohl lokal als auch remote abzurufen.