Die Active Directory Certificate Services bieten eine Reihe von webbassierten Zusatz-Schnittstellen (Registrierungsdienst für Netzwerkgeräte (NDES), Zertifikatregistrierungs-Richtliniendienst (CEP), Zertifikatregistrierungs-Webdienst (CES), Zertifizierungsstellen-Webregistrierung (CAWE).
Die Microsoft Internet Information Services (IIS) sind also für eine Microsoft-PKI nahezu unentbehrlich. Jede der webbasierten Schnittstellen (und auch Eigenentwicklungen) bringen ihre ganz eigenen Herausforderungen in Hinsicht auf Authentisierungsverfahren und deren Implementierung.
Nachfolgender Beitrag soll ein wenig Klarheit in das Thema bringen.
Authentisierung vs. Impersonierung vs. Delegierung vs. Protokollübergang
Als Authentisierung (engl. Authentication) wird (in Hinsicht auf IIS) bezeichnet, wenn sich der Benutzer als solcher gegenüber dem Webserver ausweisen kann, also beweisen kann, dass er wirklich ist, der er vorgibt, zu sein.
Als Impersonierung (engl. Impersonation) wird bezeichnet, wenn sich der Benutzer mit einem beliebigen Authentisierungsverfahren angemeldet hat und der Server-Prozess (z.B. die Webanwendung) anschließend eine Aktion im Sicherheitskontext des Benutzers auf dem gleichen System ausführt (z.B. den Zugriff auf ein lokales Verzeichnis, auf dem entsprechende Berechtigungen konfiguriert sind).
Als Delegierung (engl. Delegation) wird bezeichnet, wenn der Benutzer sich mit einem (als delegierbar erlaubten) Kerberos-Ticket authentisiert hat und der Server-Prozess (z.B. die Webanwendung) dieses Ticket in Namen des Benutzers auf eine nachgeschaltete Ressource (z.B. eine Datenbank, oder eine Zertifizierungsstelle) weiterleitet. In Kerberos-Termini wird dieser Vorgang auch S4U2Proxy genannt.
Als Protokollübergang (engl. Protocol Transition) wird bezeichnet, wenn der Benutzer sich mit einem Verfahren abseits Kerberos authentisiert hat, und der Server-Prozess im Namen des Benutzers ein Kerberos-Ticket in dessen Namen anfordert, um es an eine nachgeschaltete Ressource (z.B. eine Datenbank) weiterzuleiten. In Kerberos-Termini wird dieser Prozess auch als S4U bezeichnet. Hierbei handelt es sich um ein extrem mächtiges Recht, denn es ist damit verbunden, dass der Server-Dienst das Recht erhält, für jeden beliebigen Benutzer ein solches TIcket zu beantragen, sprich der Server-Prozess kann jede beliebige Identität annehmen.
Oftmals ist man vom sogenannten Double-Hop Problem betroffen, d.h. man möchte erreichen, dass der Serverprozess im Sicherheitskontext des angemeldeten Benutzers auf eine nachgelagerte Ressource zugreifen soll.
Was haben wir eigentlich vor?
Bei der Auswahl des korrekten Authentisierungsverfahrens müssen wir uns überlegen, was wir erreichen möchten:
- Reicht uns die Authentisierung? (haben wir kein kein Double-Hop Szenario)
- Welche Art Client soll sich authentisieren können? (Nur von Dmmänen-Computern aus, nur Windows, welche Authentisierungsverfahren werden von den Anwendungen unterstützt? Möchten oder brauchen wir Benutzername/Kennwort, Kerberos-Ticket, oder Clientzertifikat?)
- Möchten wir gar eine reine Kerberos-Anmeldung erreichen, also NTLM deaktivieren?
IIS Application Pool Identity
Bitte beachten dass die Application Pool Identity zwar Impersonation aber nicht Delegation kann. Hierfür wäre "Network Service" (vermutlich nicht empfohlen, aber warum?) oder ein Domänenkonto/gMSA notwendig.
Authentisierungsverfahren
In allen Fällen sollte die Verbindung unbedingt mit SSL geschützt sein, sprich die Option "Require SSL" sollte aktiviert sein.
HTTP Basic Authentication
Bei der Basic Authentication übermittelt der anmeldende Benutzer über einen HTTP-Header im Klartext. Dem Server liegt somit das Klartext-Passwort des angemeldeten Benutzers vor, sodass er in dessen Namen ein Kerberos-Ticket beantragen kann. Diese Methode benötigt keine Delegierung für einen Zugriff im Sicherheitskontext des Benutzers auf weitere Hosts.
Immerhin kann der Serverprozess dies nur für diejenigen Konten vornehmen, die sich an ihm anmelden.
Damit die Basic Authentication funktioniert, muss folgendes in die Web.config der Anwendung eingetragen werden.
{system.web}
{authentication mode="Windows"/}
{/system.web}
ASP.NET Impersonation
Wenn die ASP.NET Impersonation aktiviert wird, wird der gesamte serverseitige Code im Sicherheitskontext des angemeldeten Benutzers ausgeführt.
Das Aktivieren der ASP.NET Impersonation setzt folgendes in die Web.config der Anwendung.
{identity impersonate="true" /}
Außerdem erfordert die den "Classic" Managed Pipeline Modus für den IIS-Anwendngspool. In der Regel ist diese Option nicht notwendig, da Anwendungsbezogen impersoniert werden kann. Siehe hierzu die Windows Authentication.
Windows (integrierte, oder Kerberos-) Authentication
Bei der Windows Authentication authentisiert sich der Benutzer per Kerberos, oder falls dies fehlschlägt, mit dem NTLM Verfahren (welches eine Prüfsumme des Benutzerpasswortes übermittelt).
Ist der Hop auf einen weiteren Server notwendig, muss für das Dienstkonto des Webservers mindestens eine "Kerberos only" Delegierung erfolgen.
Dieses Verfahren funktioniert mit Kerberos nur dann, wenn alle Komponenten (Client-Computer, Benutzerkonto, Serverdienst und eventuelle nachgeschaltete Ressourcen) Mitglieder der gleichen Active Directory Domäne oder Gesamtstruktur sind, oder wen eine Vertragensstellung zwischen den beteiligten Domänen eingerichtet ist.
Das wichtigste zur Einrichtung in IIS:
- Auf Anwendungs-Ebene muss die "Anonymous Authentication" deaktiviert sein.
- Auf Anwendungs-Ebene muss "Windows Authentication" aktiviert sein.
- Wenn man den "Negotiate:Kerberos" (also nur Kerberos ohne NTLM) Provider konfiguriert, muss die Kernel Mode Authentication deaktiviert werden.
Die Webseite muss im Browser des anmeldenden Benutzers in die Zone "lokales Intranet" aufgenommen werden, damit die automatische Anmeldung erfolgt.
Mapping von Clientzertifikaten (IIS)
Im IIS gibt es zwei Formen der Authentisierung mit Clientzertifikaten. "IIS Client Certificate Mapping" mappt gegen im IIS definierte Konten. Sie eignet sich also effektiv nur zur Authentisierung, aber nicht für Impersonation, Delegation oder Protokollübergang. Sie wird daher hier nicht weiter behandelt.
Mapping von Clientzertifikaten (Active Directory)
Das IIS Feature "Client Certificate Mapping" mappt Zertifikate gegen Konten im Active Directory. Damit dies funktioniert, muss der Webserver-Prozess, nachdem er die Authentisierung empfangen hat, ein Kerberos Ticket im Namen des anmeldenden Benutzers anfordern (daher ist Protokollübergang erforderlich). Schließlich gibt es bei diesem Verfahren keine Übertragung eines Passworts, Hashwertes oder eines weiterleitbaren Kerberos-Tickets. Dieser vermeintliche Vorteil ist auch ein sehr großer Nachteil, da dem Webserver-Konten hiermit weitreichende Rechte gewährt werden.
Das wichtigste zur Einrichtung in IIS:
- Das Dienstkonto benötigt Kerberos Delegierung mit "Use any Authentication protocol" (Protokollübergang).
- Die Zertifizierungsstelle, welche die Zertifikate der anmeldenen Benutzer ausstellet, muss Mitglied von NTAuthCertificates sein. Auch dies kann ein sehr großes Sicherheitsrisiko bedeuten.
- Auf wem SSL Bindung muss der "DS Mapper" muss auf dem SSL Binding aktiviert sein (ansonsten bricht die Anmeldung mit HTTP Fehlercode 403.2.5) ab.
- Das Senden der Trust List sollte auf dem SSL Binding aktiviert sein.
- Das Authentisierungsverfahren für "Active Directory Client Certificate Authentication" muss auf Server-Ebene aktiviert werden. Nur dort ist die Option im IIS Manager vorhanden.
- Auf Webseiten-Ebene muss "Client Certificate Mapping" (die Option clientCertificateMappingAuthentication) ebenfalls aktiviert sein.
- Auf Webseiten-Ebene müssen Clientzertifikate auf "Accept" stehen, wenn es Unterordner gibt, die selektiv dieses Authentisierungsverfahren nutzen (ansonsten "require").
- Auf Anwendungs- bzw. Unterordner-Ebene müssen Clientzertifikate auf "Required" stehen, wenn es diese gibt.
- Auf Webseiten-Ebene (wenn es keine Unterordner gibt) bzw. Anwendungs-Ebene müssen alle Authentifizierungsprotokolle deaktiviert werden.
Ein Beispiel zum Aktivieren der Authentisierung mit Clientzertifikaten auf Webseiten-Ebene.
%WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/clientCertificateMappingAuthentication /enabled:"True" /commit:apphost %WINDIR%\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/security/access /sslFlags:"Ssl, SslNegotiateCert" /commit:apphost
Ein Beispiel zum Konfigurieren der SSL-Bindung mit DS-Mapper und Verwendung des ClientAuthIssuer Zertifikatspeichers, um die für die Anmeldung erlaubten Zertifizierungsstellen zu identifizieren.
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certstorename=MY certhash=71cc1fed1c7ef6cec45de66c288447a4ad464c20 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlstorename=ClientAuthIssuer dsmapperusage=enable
Der gesamte Mechanismus ist generell eher nicht empfehlenswert, da zwei potentiell hochgefährliche Einstellungen (Mitgliedschaft in NTAuthCertificates sowie Kerberos-Delegierung mit Protokollübergang) verwendet werden müssen.
Weiterführende Links:
Externe Quellen
- NDES: include username and password for http://myNDES/certsrv/mscep_admin/ (Microsoft TechNet Foren)
- Configure Windows Authentication (IIS 7) (Microsoft Corporation)
- Impersonation Levels (Microsoft Corporation)
- How To: Use Impersonation and Delegation in ASP.NET 2.0 (Microsoft Corporation, Archivlink)
- How to configure Kerberos Constrained Delegation for Web Enrollment proxy pages (Microsoft Corporation)
- Things to check when Kerberos authentication fails using IIS/IE (Microsoft Corporation)
- The Kerberos Double Hop Problem (Michael Lowery)
- Client Certificate Mapping Authentication (Microsoft Corporation)
Deutsch 
English