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.
Auch über Trusts ist keine Delegation möglich !

Warum "Delegation"?

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. Technisch landen die Werte im Hintergrund im Feld msDS-AllowedToDelegateTo einfach als String.

msDS-AllowedToDelegateTo: www/srv01.msxfaq.local/msxfaq.local
msDS-AllowedToDelegateTo: www/srv01.msxfaq.local
msDS-AllowedToDelegateTo: www/SRV01
msDS-AllowedToDelegateTo: www/srv01.msxfaq.local/MSXFAQW

Damit nun dieses privilegierte Computerkonto nun sich nicht als wirklich "jedermann" ausgeben kann, gibt es pro Benutzer noch mal einen Schutz, den Sie auf sensiblen Konten wieder aktivieren können:

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.

Delegation und Sicherheit

Wenn ein Dienstkonto oder ein Computerkonto das Recht hat, ein Ticket im Auftrag eines Benutzers anzufordern, dann sollten Sie diese "Impersonation" möglichst kompakt halten. Im Active Directory können Sie bei der Delegierung drei Optionen auswählen:

  • Do not trust this computer for delegation
    Dies ist die Standardeinstellung und verhindert, dass der Computer oder das Dienstkonto sich ein Ticket für einen Benutzer ausstellen lassen kann.
  • Trust this user for delegation for any Service (kerberos only)
    Auch wenn so Tickets nur für Kerberos ausgestellt werden können, ist das eine sehr unsichere Einstellung. Der Computer oder das Dienstkonto kann sich für jeden Benutzer und jedes Ziel ein Ticket ausstellen lassen, wenn der Anwender dieses System anspricht. Das machen Sie eigentlich nur, wenn es sehr viele oder veränderliche nachgeschaltete Systeme gibt. Ich würde den Computer dann aber per Netzwerk abschotten, damit er nicht andere Services erreicht. So ein Computer ist natürlich auch eine Steilvorlage für Angriffe.
    Allerdings funktioniert dies natürlich nur, wenn der Client sich per Kerberos anmeldet. Wenn der Client sich anders authentifiziert, dann bekommt der Application Server ein KERB_ERR_BADOPTION als Antwort vom KDC.
  • Trust this user for delegation to specified services only
    Besser ist es mit dieser Option nur die Ziele freizuschalten, auf die der Computer oder das Dienstkonto sich im Auftrag des Anwenders verbinden muss. Als "Geschenk" können Sie dann zwischen "User Kerberos Only" und "Use any authentication protocol" wählen. Die Delegation funktioniert im zweiten Fall auch bei einer Anmeldung des Clients per NTLM , Basic, Forms o.a.

Unabhängig davon ist natürlich "Delegation" immer genau zu bewerten, dass die eingesetzte Software oder der Computer nur vertrauenswürdigen Code einstellen.

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.

Voraussetzung ist bislang immer dass folgende Konten in der gleichen Domäne sind:

  • Benutzer
  • Dienstkonto
  • Zielserver

Update:
Seit Windows 2012 kann Kerberos Delegation auch über Forest und Domaingrenzen hinweg genutzt werden.
Siehe auch http://blog.kloud.com.au/2013/07/11/kerberos-constrained-delegation/

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--> E2003 Frontend -->Kerberos----> 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.

You can enable ADFS to accept Kerberos authentication applicable only which Kerberos constrained delegation front end and back end servers are in same domain.
http://blogs.technet.com/b/ad/archive/2007/10/24/kerberos-constrained-delegation-fe-and-be-servers-must-be-in-same-domain.aspx

Kerberos Constrained Delegation (KCD) is limited to having your front-end and back-end in the same domain
http://blogs.technet.com/b/ad/archive/2007/10/24/kerberos-constrained-delegation-fe-and-be-servers-must-be-in-same-domain.aspx

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.

Delegation mit SharePoint

Delegation mit TMG

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.