SharePointCommunity
Die deutschsprachige Community für SharePoint, Office 365 und mit Azure
Kerberos in einer SharePoint Farm einrichten

Blogs

Fabian´s Blog [SharePoint MVP]

Syndication

„Kerberos“ – ein Thema, wovor einige auf den ersten Blick zurückschrecken, weil sie denken, dass diese Technologie etwas sehr komplexes und auch nur schwer zu implementieren ist. Heute möchte ich versuchen, ein wenig die Angst zu nehmen und zeigen, wie Kerberos in einer SharePoint Farm aktiviert werden kann.

Warum eigentlich Kerberos?

Kerberos als primäres Authentifizierungsprotokoll einzusetzen kann viele Gründe haben. Dazu gehören zum Beispiel bessere Performance gegenüber NTLM oder auch automatisiertes Anmelden. Der aus meiner Sicht wichtigste Grund ist Delegation! Spätestens dann wenn eine mehr-schichtige Farm aufgebaut wird und man über Webparts mit den Credentials des Clients auf Backend-Systeme zugreifen möchte, wird man um die Verwendung von Kerberos nicht mehr herum kommen. Kerberos ist ein delegierungsfähiges Protokoll. Das heißt, dass die Anmeldeinformationen des Benutzers über mehrere Stationen an Backend-Systeme weitergereicht werden können. Bekannte Beispiele sind Zugriffe auf Datenbanken oder das Active Directory über SharePoint Webparts. Ich möchte hierbei nicht verschweigen, dass auch Basic eine delegierungsfähiges Protokoll ist aber Credentials unverschlüsselt durch das Netzwerk zu schicken, möchte nicht wirklich jeder.

Kerberos zur Datenbank aktivieren

Bevor Kerberos auf den Web Applikationen der Frontend Server aktiviert wird, sollte es auch auf Ebene der Datenbank eingerichtet werden. Beim SQL Server 2005 ist das nicht all zu kompliziert. Die Voraussetzung für die Verwendung von Kerberos ist, dass der Datenbankdienst über einen Active Directory Account ausgeführt wird. Ist das der Fall, kann für diesen Service Account ein Service Principal Name (SPN) registriert werden. Die Erstellung des SPNs wird über das Kommandozeilenwerkzeug SETSPN unterstützt. SETSPN ist Bestandteil der Windows Server Ressouce Kit Tools und kann von der Installations-CD oder dieser Website bezogen werden.

Über folgenden Befehl kann der Service Principal Name für den Service Account des SQL Servers registriert werden.

setspn -A MSSQLSvc/sql01.devdemo.de:1433 devdemo\_svc_sql

Nachdem der Befehl ausgeführt wurden, muss der SQL Server Dienst neu gestartet werden. Danach kann über das SQL Server Management Studio von einem externen Client geprüft werden, ob die Aktivierung von Kerberos erfolgreich war. Über folgenden Befehl können sich die Verbindungen und dazugehörigen Authentifizierungsarten aufgelistet werden.

select auth_scheme, * from sys.dm_exec_connections

Wenn in der Liste das auth_scheme KERBEROS erscheint, war die Aktivierung erfolgreich.

 

Sollte die Abfrage nicht das gewünschte Ergebnis liefern, kann es teilweise sinnvoll sein, den ganzen Server noch einmal neu zu starten. Besonders bei Cluster-Umgebungen wird dieser Fall auftreten. Außerdem muss die Client-Software nach Aktivierung von Kerberos noch einmal neugestartet werden.

Kerberos für die SharePoint Applikationen aktivieren

Um auf einer SharePoint Web Applikation Kerberos zu aktiviern, müssen die identischen Voraussetzungen wie beim SQL Server gegeben sein. Dass heißt, der Application Pool muss über die Identität eines Domain Service Accounts ausgeführt werden. Ist das der Fall, kann über das SETSPN-Kommanzoweilenwerkzeug ein Service Principal Name für diesen Account registriert werden.

setspn -A HTTP/intranet.devdemo.de devdemo\_svc_app_intranet
setspn -A HTTP/intranet devdemo\_svc_app_intranet

Damit die Benutzer sowol über die FQDN als auch über den Hostname auf die Website über Kerberos zugreifen können, habe ich den SPN für beide URLs registriert. Über folgenden Befehl kann geprüft werden, ob die SPNs für den Account erfolgreich gegistriert wurden.

setspn -L devdemo\_svc_sp_app_intranet

Nachdem der SPN erfolgreich gesetzt wurde, kann das Authentifizierungsprotokoll nun auf der Web Applikation geändert werden. Diese Einstellung kann in der Zentraladministration über Application Management > Authentication Providers geändert werden.

Standardmäßig ist für eine Web Applikation NTLM als Authentifizierungsprotokoll eingestellt. Dieser Wert muss auf Negotiate (Kerberos) geändert werden. Negotiate bedeutet, dass der Client bei der Anmeldung zunächst versucht, sich über Kerberos zu authentifizieren und danach über NTLM. Die Einstellung der Zentraladministration werden dann in den Metabase des IIS automatisch aktualisiert. Diese Anpassung musste in der SharePoint-Vorversion noch manuell durchgeführt werden. Im Anschluss muss der Worker Process der Web Applikation neu gestartet werden.

Authentifizierung prüfen

Jetzt stellt sich der Eine oder Andere sicherlich die Frage, wie ich denn sicher testen kann, ob der Benutzer sich tatsächlich über Kerberos an der Web Applikation authentifizieren kann. Eine sehr gute Möglichkeit liefert das IIS Ressouce Kit Tool WFETCH, dass kostenlosten heruntergeladen werden kann.

http://www.microsoft.com/downloads/details.aspx?FamilyID=56FC92EE-A71A-4C73-B628-ADE629C89499

WFETCH gibt mir die Möglichkeit, am Client die gewünscht Authentifizierung und die Client-Credentials einzustellen. Nachdem die Anfrage an den Server gesendet wurde, kann man anhand des HTTP Header identifizieren, über welches Protokoll die Authentifizierung realisiert wurde. Ist der AUTHORIZATION-String länger als 1000 Zeichen, kann man sicher gehen, dass die Authentifizierung über Kerberos durchgeührt wurde. Der NTLM Authorization-String ist in der Regel kürzer als 300 Zeichen.

 

Delegation einrichten

Um das von mir in der Einleitung beschriebene Delegierungsszenrio zu implementieren, muss der Service Account der Web Applikation noch für die Delegierung berechtigt werden. Auch das ist recht einfach. In den Konteneinstellungen des Service Accounts kann dem Benutzer das Recht „Account ist trusted for delegation“ gegeben werden.

Wird das Active Directory im Windows Server 2003 Native Mode betrieben, stellt die Benutzeroberfläche für die Delegierungseinstellungen ein eigenes Register mit zusätzlichen Optionen bereit.

Fazit

Kerberos ist eine Technologie, vor der einige Anwender erst einmal Respekt haben, weil sie einige Arbeitsschritte für die Aktivierung bedingt. Allerdings liefern der SQL Server 2005, die Windows Support Tools und die Windows SharePoint Services sehr nützliche Werkzeuge und Benutzeroberflächen, die es Administratoren erleichtern, Kerberos in einer SharePoint Farm bereitzustellen. In einfachen Single Farmen wird es sicherlich nicht dringend erforderlich sein, dieses Authentifizierungsprotokoll zu verwenden aber spätenstens, wenn die Farm mehrstüfig aufgebaut wird oder auf Backend-Daten zugegriffen werden soll, wird man nicht mehr darum kommen, Kerberos zu aktivieren. Ich hoffe mit diesem Artikel dem Einen oder Anderen ein bisschen die Angst vor Kerberos genommen zu haben.


Bereitgestellt 28 Okt 2007 14:27 von Fabian Moritz
Gespeichert unter: ,

Kommentare

TrackBack geschrieben SharePoint Kaffeetasse 27
on 29 Okt 2007 16:23

SharePoint Kaffeetasse 27

Frank Hornscheidt geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 15 Nov 2007 15:00

Hallo!

ich habe Kerberos aktiviert. Theoretisch sollte auch alles funktionieren - das Sicherheitsprotokoll meldet bei Clientverbindungen jedenfalls "Erfolgreich". Leider aber kann man sich nur von Clients anmelden, die NICHT in der Domäne sind. Die Domänenmitglieder kriegen ein Benutzerlogin, in dem man aber keine einzige Anmeldung hinkriegt -> Error HTTP 401.1

http:// geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 10 Jan 2008 2:12

Hallo!

ich hab heute Nacht mit der Anleitung Kerberos aktiviert. Die Anmeldung direkt funktioniert einwandfrei. Trotzdem bekomme ich mit dem WFETCH – Programme immer nur zwei Zeichenreihen. Daher glaube ich, dass ich immer noch die NTLM Authentifizierung statt Kerberos nutze. Die Domänenmitglieder kriegen keine

Benutzerloginabfrage und sind sofort am SharePoint angemeldet.

Im Sicherheitslog steht auch die ID 540 und Authentifizierungspaket: NTLM… Was hab ich hier Flasch gemacht....

TrackBack geschrieben Gastbeitrag: Reporting Services 2008 im SharePoint integrierten Modus
on 20 Feb 2009 13:02

Gastbeitrag: Reporting Services 2008 im SharePoint integrierten Modus

Christoph Distefano geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 22 Jan 2010 14:25

Hallo,

danke für die Anleitung. Bekomm leider beim SQL SELECT immer nur NTLM zurück. Muss ich zusätzlich noch die User, die auf die DB zugreifen (SPSearch, SPSystem, SPAdmin) einen Service Principal Name geben, oder reicht es vorerst nur dem SQL User einen zu verpassen?

Ich denke, dass ich gar nicht zum Umstellen der SharePoint Farm gehen muss, wenn ich bei 'select auth_scheme, * from sys.dm_exec_connections ' kein Kerberos sehe!?

Danke für den Artikel,

Christoph

Christoph Distefano geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 22 Jan 2010 14:27

Sorry, geht leider nicht. Kann es sein, dass ich allen Benutzern, die sich auf die DB verbinden (also auch SPSearch, ...) einen SPN zuweisen muss, bevor ich mit 'select auth_scheme, * from sys.dm_exec_connections' dann Kerberos Authentifizierungen sehe?

Was machen wir falsch?

Igor Schulz geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 1 Feb 2010 21:43

Hallo Leute,

obwohl ich den Beitrag vom Fabian, wie immer, gut finde.

Lässt er bei der Beschreibung ein Paar wichtige Details die ihm evtl. selbst verständlich vorkommen.

Zu den Fragen welche Accounts berechtigt werden sollen gibt es ein, aus meiner Sicht sehr sinvollen Beitrag:

vspug.com/.../configuring-kerberos-autentication-on-moss-2007

Hoffe es hilft.

Gruß

Igor

Fabian Moritz geschrieben re: Kerberos in einer SharePoint Farm einrichten
on 12 Feb 2010 8:06

Hallo Igor!

Danke für den Input!

Fabian