Die Verwendung von Kerberos in Windows-Anwendungenm ist nicht so komplex, wie man das vielleicht vermuten würde. Das Microsoft .NET Framework, die aktuelle Basis für die Entwicklung von Windows-Anwendungen, stellt wichtige Funktionen für die Nutzung auch der Kerberos-Funktionalität bereit, wobei sich der Entwickler nicht mit den Details von Kerberos direkt auseinander setzen muss.
Das wird bei einem Blick in die MSDN-Library (http://msdn.microsoft.com/library) deutlich. Dort gibt es eine Klasse WindowsIdentity. Sie stellt verschiedene Methoden und Eigenschaften bereit, zu denen unter anderem auch Impersonate gehört. Wenn die Voraussetzungen geschaffen wurden, kann damit im Kontext eines anderen Benutzers gearbeitet werden.
Die Protocol Transition wird dagegen mit Lsa-LogonUser() durchgeführt. Damit kann eine Authentifizierung eines Benutzers an Windows über Kerberos durchgeführt werden, dessen Anmeldung zunächst über einen anderen Ansatz erfolgt ist.
Eine relativ ausführliche Beschreibung des Themas mit Codebeispielen und Hinweisen auf weitere Informationen bietet www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx.
Die Kerberos-Tickets
Für weitergehende Funktionen kann auf Informationen in den Kerberos-Tickets zugegriffen werden. Ein Überblick dazu findet sich in http://msdn.microsoft.com/library/en-us/dnkerb/html/msdn_pac.asp. Das Dokument analysiert die Voraussetzungen, um die Informationen, die mit einem Kerberos-Ticket in einem speziellen Feld für die Autorisierungsdaten geliefert werden, auszulesen und zu verarbeiten. Zu diesen Daten gehören unter anderem die SID-Informationen für den Benutzer und die Gruppen, zu denen er gehört. Diese Informationen werden in vielen Fällen für die Autorisierung von Zugriffen benötigt, weil sie entweder in ACLs (Access Control Lists) direkt genutzt werden oder weil sie für die eindeutige Identifikation des Benutzers im Active Directory erforderlich sind.
S4U Kerberos Extensions
Wenn man sich mit der Nutzung von Kerberos innerhalb von Anwendungen beschäftigt, stößt man schnell auch auf die S4U Kerberos Extensions. S4U steht für Service-for-User. Dabei geht es um Funktionen, mit denen Dienste für Benutzer bereitgestellt werden – also um die Delegation und die Protocol Transition. Es handelt sich also nicht um grundlegend neue Ansätze.
Auch hier stellt Microsoft ein recht interessantes Dokument bereit. Das Konzept wird unter http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs umfassend erläutert. Hier finden sich auch etliche weiterführende Informationen rund um die bedingte Delegation und die Protokollumsetzung.
Weitere Informationen
Eine weitere Serie interessanter Artikel mit Hintergründen zur Nutzung von Kerberos in verteilten Umgebungen – auch über die Grenzen von Windows hinweg – stellt http://msdn.microsoft.com/library/en-us/dnsecure/html/http-sso-1.asp mit den dort enthaltenen Links zu den weiteren Teilen der Serie zur Verfügung. Die Serie nennt sich “HTTP-Based Cross-Platform Authentication via the Negotiate Protocol“.
Die administrativen Schritte
Abgesehen von den grundlegenden Ansätzen für die Nutzung von Kerberos in Anwendungen können noch administrative Schritte erforderlich sein, um überhaupt die Arbeit damit zu ermöglichen. Die Schritte unterscheiden sich je nach Modus des Active Directory. Nachfolgend wird zunächst die Situation bei allen Modi außer dem Windows Server 2003-Modus besprochen.
Die Konfiguration erfolgt hier an zwei Stellen. Zum einen finden sich Einstellungen zur Delegation bei den Eigenschaften von Benutzern (Bild 1). Die Option Konto wird für Delegierungszwecke vertraut ist bei Dienstkonten erforderlich, die für Anwendungen verwendet werden. Bei einem Benutzerkonto, in dessen Kontext ein Dienst ausgeführt wird, muss die Option aktiviert werden, wenn der Dienst mit der Delegation von Kerberos arbeitet.
Die zweite Option Konto ist vertraulich und kann nicht delegiert werden sollte bei allen Konten aktiviert werden, bei denen die Delegation nicht zugelassen ist. Das gilt beispielsweise für Gastkonten. Für solche Benutzerkonten kann keine Impersonisation erfolgen. Falls es Probleme mit der Delegation für einzelne Benutzer gibt, sollte der Status dieser Option überprüft werden.Wird ein Dienst unter dem lokalen Systemkonto oder als Netzwerkdienst ausgeführt, muss die Konfiguration über die Option Computer für Delegierungszwecke verrtrauen beim Computerkonto erfolgen (Bild 2).
Falls der Windows Server 2003 zum Einsatz kommt und damit die neuen Funktionen wie die bedingte Delegation unterstützt werden, wird über die Schaltfläche Delegierung gearbeitet. Sie ist bei Computerkonten immer sichtbar. Bei Benutzerkonten ist sie nur sichtbar, wenn mit dem Werkzeug setspn aus den Windows Support-Tools ein so genannter Service Principal Name (SPN) für dieses Konto definiert wurde. Damit wird das Konto bei der Nutzung im Zusammenspiel mit Diensten identifiziert. Die Erstellung von SPNs ist nur erforderlich, wenn weder das lokale Dienstkonto noch ein Netzwerkdienst verwendet wird.
Bei den Einstellungen im Register Delegierung können Sie auswählen, ob dem System nie, generell oder nur eingeschränkt vertraut werden soll. Im letztgenannten Fall können auch andere Authentifizierungsprotokolle genutzt und Dienste eingetragen werden, auf die zugegriffen werden darf.
Damit lässt sich die Delegation deutlich differenzierter steuern als bisher. An den Konfigurationsschritten wird auch deutlich, dass ein enges Zusammenspiel zwischen Entwicklern und Administratoren erforderlich ist – spätestens wenn es um das Deployment von Anwendungen geht, die mit der Delegation arbeiten.
Das Whitepaper
Das Whitepaper „Planning and Implementing Multitier Applications Using Microsoft Windows Server 2003 Security Services“ geht darauf ein, wie sich mehrschichtige Anwendungen unter Nutzung der Sicherheitsdienste des Windows Server 2003 realisieren lassen – also auch und insbesondere unter Nutzung von Kerberos. Es ist eine gute Lektüre, wenn das Thema Nutzung von Kerberos in Anwendungen vertieft werden soll.