Kerberos - Constraint Delegation und Double Hop

Für den Einsatz von Kerberos Delegation müssen alle Domains im Windows 2003 Mode sein und die verbundenen Dienste sich in der gleichen Domain befinden:
Siehe auch Summary (Kerberos Protocol Transition and Constrained Delegation) http://technet.microsoft.com/en-us/library/cc772683(WS.10).aspx

Single Domain Only
Nach meinen eigenen Tests scheint eine Delegierung nur innerhalb einer Domain zu funktionieren, d.h. Domain1/Server1 kann nicht berechtigt werden, auf Domain2/Server2 im Auftrag eines Anwenders zuzugreifen. Das kann ich mir so erklären, weil der Server 1 nur den Domain1/KDC ansprechen kann und der zu wenig Informationen über Domain2/Server2 hat oder Domain2/Server2 den Tickets eines KDC aus eine anderen Domäne nicht vertraut

Interessant und bekannt wurde Kerberos als Lösung eines Problems, welches durch die Verteilung von Diensten immer mehr offenbar wurde. Solange der Zugriff auf einen Server ausgereicht hat, war die Anmeldung auch per NTLM problemlos. NTLM aber zeichnet sich gerade dadurch aus, dass der Server selbst keine Anmeldedaten des Benutzers hat, sondern nur selbst prüfen kann, dass es sich um den Benutzer handelt. Läuft nun auf dem Server aber eine Anwendung, die ihrerseits auf einen anderen nachgelagerten Server zugreifen will, dann konnte Sie das bislang nicht mit den Daten des Benutzers tun, sondern musste entweder ein Dienstkonto nutzen (Sicherheitsrisiken und das nachgelagerte System kann keine Zugriffsrechtesteuerung durchführen) oder ein "unsichereres" Verfahren anbieten um das Kennwort selbst zu erhalten. Die Übertragung von Kennworten von Client zum Server ist aber ein Risiko und oft hat der Client nicht mal das Kennwort selbst bzw. sendet es nicht automatisch an andere Systeme. Mit Kerberos und "Constraint Delegation" geht das viel einfacher.

Der Client greift wie gewohnt nun per Kerberos auf den Server "web1" zu. Dieser Server ist nun im Active Directory dazu berechtigt worden, im Auftrag des Benutzers vom KDC ein Ticket für eine bestimmte Zielanwendung (hier db1) anzufordern. Der Server db1 bekommt also vom web1 ein Ticket im Auftrag des pc1 vorgelegt. Dazu muss natürlich nun db1 auch Kerberos unterstützen. Im Active Directory finden Sie die Einstellungen sowohl beim Benutzer als auch beim Computerobjekt.

Delegierung beim Computer

Auf dem Computerobjekt muss man die Erlaubnis zur Delegierung einschalten. Seit Windows 2003 kann man hier sogar sehr genau dieses Recht nur für bestimmte Server und deren Dienste zulassen.

Bei sensiblen Benutzern kann man die Delegierung unterbinden, z.B.: kein Server kann sich im Auftrag dieses Benutzers ein Ticket für einen anderen Server besorgen. Die hier gemachten Einstellungen werden durch den KDC ausgewertet, d.h. weder der Client-PC noch der vermittelnde Server noch das Zielsystem kann diese Einstellungen beeinflussen.

IIS Impersonation, Kerberos und SPN

Das sicher am häufigsten untersuchte System bei einem "Double Hop" Zugriff ist der Webserver IIS. Um einen Zugriff auf entfernte Dienste zu erreichen (zweiter Hop) muss man daher entweder die Anmeldedaten an die Anwendung übergeben (Basic Authentication) oder Kerberos einsetzen. Als Tabelle sieht das dann wie folgt aus:

Verfahren Browser Sicherheit Automatische Anmeldung Impersonation
Basic Alle Klartext ! SSL als Verschlüsselung ratsam Nein. Maximal durch Kenwortmanager oder speichern Ja, unbeschränkt
Formbased Alle Klartext ! SSL als Verschlüsselung ratsam Nein. Maximal durch Kenwortmanager oder speichern Ja, unbeschränkt
NTLM IE/Firefox Hash Ja Nur Localhost
Kerberos IE ? PKI Ja Ja, Steuerbar

Um dem "Double Hop"-Problem zu entgehen, muss man also die Anmeldung am Webserver also entweder über die "Basic Authentication" oder über ein Formular durchführen, so dass die Webanwendung die Anmeldedaten (Username/Kennwort) bekommt, wobei Sie unbedingt SSL verwenden sollten. Allerdings ist damit keine automatische "integrierte" Anmeldung möglich. Erst durch die Anmeldung mit Kerberos funktioniert auch die automatische integrierte Anmeldung und die Impersonation auf einen anderen Server.

Interessant wird das natürlich wenn man nun eine Webserverfarm (z.B.: Exchange Frontend Server oder Provisioning Server) betreibt, die mittels "Network Load Balancing" zusammen schaltet.

IIS 7.5 und Kernel Authentication

Eine neue Hürde gibt es mit dem Einsatz von Contraint Delegation mit dem IIS 7.5. Damit die Authentifizierung "schneller" erfolgt, hat Microsoft diese in den Kernel verlagert. Damit kann der Server per Default aber erst mal nicht mehr das Dienstkonto verwenden und damit das Ticket decodieren.

Der IIS 7.5 weist bei der Konfiguration sogar darauf hin, dass bei der Aktivierung von "Negotiate:Kerberos" die Kernel Mode Authentication nicht möglich ist.

Die saubere Lösung ist daher, in diesem Fall die Kernel Mode Authentication abzuschalten, damit das Dienstkonto des Applicationpools genutzt werden kann. Es gibt aber auch hinweise, dass Sie über einen Eintrag in der Datei C:\Windows\inetsrv\config\application.config mit der Kernel Mode Authentifizierung arbeiten können. Der Eintrag "useAppPoolCredentials="true"" soll das bewirken.

    <location path="Default Web Site/Test">
        <system.webServer>
            <security>
                <authentication>
                    <windowsAuthentication enabled="false" useKernelMode="true" useAppPoolCredentials="true" />
            </security>
        </system.webServer>
    </location>

Die XML-Dateien können Sie seit IIS 7.5 auch über den "Configuration Editor" in der GUI anpassen.

Beachten Sie, dass in den DropDown-Feldern linke "system.webServer/Security/authentication/WindowsAuthentication" stehen muss und rechts dann zwischen der globalen Application.config, der web.config der Webseite und der web.config des virtuellen Verzeichnisses gewechselt werden kann und einige Einstellungen "vererbt" werden und gelockt sind.

Letztlich führen Beschreibungen in der OCS 2007 R2 und AD RMS-Dokumentation weiter. In der offiziellen IIS-Dokumentation habe ich noch nichts dazu gefunden.

Kerberos über mehrere Domains

Nach meinen eigenen Tests scheint eine Delegierung nur innerhalb einer Domain zu funktionieren, d.h. Domain1/Server1 kann nicht berechtigt werden, auf Domain2/Server2 im Auftrag eines Anwenders zuzugreifen. Das kann ich mir so erklären, weil der Server 1 nur den Domain1/KDC ansprechen kann und der zu wenig Informationen über Domain2/Server2 hat oder Domain2/Server2 den Tickets eines KDC aus eine anderen Domäne nicht vertraut.

Das ist in einer Exchange Umgebung natürlich ungeschickt, wenn ein Exchange 2003 Frontend Server per Kerberos auf einen Exchange 2003 Backend Server in einer anderen (Sub-)Domain zugreifen will. Einen solchen Fall hatte ich bei einem Kunden, welcher mobile Clients auf dem ISA-Server schon mit Zertifikaten authentifiziert hat und der ISA dann auf den Frontend per Kerberos gibt, der seinerseits per Kerberos auf Backends gehen muss

WinMobile--Zertifikat-> ISA --Kerberos--> E 2003 Frontend -->Kernberos----> Exchange 2003 Backend
Zertifikat        (authentifiziert      (authentifiziert                    (authentifiziert)
                Holt sich KRB-Ticket    Holt sich KRB-Ticket                liefert Daten

Das mag auch ein Grund gewesen sein, warum Exchange 2007 dieses Verfahren anders löst, Hier meldet sich der Client nur noch am ersten CAS-Server an und für die Kommunikation der CAS-Server untereinander (CAS Intern/Extern und CASProxy 2010) und zu den Mailbox-Servern wird die Serverauthentifizierung genutzt. Alle Exchange Server untereinander "vertrauen" sich demnach.

Debugging

Für die Fehlersuche hat sich natürlich das IISLog bewährt, wobei hier natürlich bei Anmeldefehlern keine Benutzernamen zu finden Sind. Diese kann man dann im  Security Eventlog finden, wenn die Anmeldeüberwachung aktiviert ist. Ansonsten gibt es auch eine ASPX-Testseite, die hilfreich sein kann.

Keywords:Kerberos