Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Stefan Mieth
ist Senior Consultant und Projektleiter bei der AIT und unterstützt Unternehmen bei der Einführung und Optimierung des Visual Studio Team Foundation Server. Er hat sich unter anderem der Definition und Verbesserung von ALM Prozessen verschrieben und hilft Unternehmen bei der Etablierung agiler Software Entwicklungs-Methoden und dem lösungsorientierten Anpassen der Werkzeugkette. +Stefan Mieth

Stefan Mieth

TFS Security: NTLM Vs. Kerberos?

Freitag, 12. Dezember 2014

Im ersten Artikel unserer Artikelserie „Sicherheit und TFS“ haben wir die Unterscheidung in Authentifizierung und Autorisierung getroffen. In der Windows-Welt ist die Authentifizierung eines Nutzers über verschiedene Verfahren geregelt, dominierend sind hierbei die Verfahren NTLM und Kerberos.

Lernen Sie im nachfolgenden Beitrag die Unterschiede der beiden Authentifizierungsmechanismen Kerberos und NTLM beim Team Foundation Server genauer kennen.

NTLM (NT LAN Manager) ist eine Sammlung von Sicherheitsprotokollen von Microsoft zur Sicherstellung von Integrität und Authentifizierung. Die Ursprünge reichen zurück bis vor die Windows NT  Ära, in der NTLM als proprietäres Protokoll von Microsoft eingeführt wurde. Bereits mit dem Betriebssystem Windows Server 2000 wurde vor rund 14 Jahren NTLM durch das neuere und sichere Kerberos als das bevorzugte Authentifizierungsprotokoll abgelöst. Primär wird heute NTLM noch aus Kompatibilitätsgründen von neueren Systemen unterstützt.

Was sind die Hintergründe der Ablösung von NTLM ([1]) durch Kerberos ([2])? NTLM nutzt zur Authentifizierung im wesentlichen Hashwerte um sich gegenüber einem Dienst zu authentifizieren. Ein solcher Hashwert stellt am Ende wiederum eine Art Passwort dar. Je nach Situation ist dabei der Hashwert auf dem Server oder dem Domain-Controller hinterlegt. Fängt ein „böser“ Anwender den Hashwert ab, so ist mit einem Passwort-Diebstahl gleichzusetzen. Mit der Unterstützung von Kerberos im Windows Umfeld wurden diese Design-Schwächen adressiert. Kerberos nutzt dabei zur Übermittlung der Authentifizierungsdaten anstatt Hash-Werten temporäre Tickets. Diese Tickets werden dabei von einer zentralen vertrauenswürdigen Instanz ausgestellt und verwaltet. Alle beteiligten Systeme prüfen vereinfacht erklärt, die Gültigkeit der Ticketinformationen mit dieser Instanz. In Windows Netzwerken ist diese zentrale Instanz die Active Directory Infrastruktur mit seinen Domain-Controllern.

Bei den ganzen Vorteilen stellt man sich am Ende die Frage: Warum überhaupt noch auf NTLM setzen? Wenn möglich sollte bei der Wahl des Verfahrens auf das moderne Kerberos gesetzt werden. Kerberos vereint die Vorteile von Performance und erweiterten Mechanismen gegen Manipulation. Mit den Vorteilen geht allerdings eine etwas höhere Komplexität bei der Einrichtung einher. Trotz allem Optimismus kann leider nicht in jeder Situation auf Kerberos gesetzt werden. Unterstützt eines der integrierten Systeme kein Kerberos wird automatisch wieder NTLM verwendet. Wenn das System nicht Mitglied einer Active Directory Domäne ist kann ebenfalls kein Kerberos verwendet werden. In Evaluierungs- und Studien-Umgebungen oder gemischten Netzwerken kann es schnell zu diesem Szenario kommen. Weitere Gründe die wieder zu NTLM führen können ist eine fehlerhafte Kerberos-Konfiguration oder ein fehlender Kerberos-Support in der angesprochenen Anwendung.

Und jetzt die gute Nachricht: Auf den Team Foundation Server selbst trifft keine der Eigenschaften zu, und es spricht nichts gegen die Verwendung von Kerberos. Die schlechte Nachricht: Wir müssen für die korrekte Einrichtung entsprechend Zeit einplanen. Geht es jetzt an die Konfiguration der Kerberos Authentifizierung im TFS Umfeld, so sind primär drei Dienste sehr wichtig: TFS, SharePoint und SQL Server Reporting Services (SSRS).

Jeder der drei beteiligten Systeme ist dabei unabhängig voneinander zu konfigurieren. Die Konfiguration pro System erfolgt aber stets in vier grundlegenden Schritten:

  1. Einrichten eines DNS Alias Namen für jeden Dienst (Bsp.: tfsservice.firmenname.de für TFS, tfsportal.firmenname.de für SharePoint und tfsreports.firmenname.de für Reporting Services)
  2. Aktivieren von Kerberos in jedem Dienst ( während der Installation oder durch nachträgliche Konfiguration möglich) ( [3], [4], [5])
  3. Setzen der Service Principal Names (SPN) (siehe [6]).
  4. Überprüfen der Konfiguration.

Fazit

Es gibt kaum einen Grund Kerberos nicht zu verwenden. Der etwas höhere, dafür aber nur einmalige Einrichtungsaufwand lohnt sich auf jeden Fall. Mehr Sicherheit, schnellere Authentifizierung und nicht zuletzt ein offener Standard machen ihre Infrastruktur dank Kerberos fit für die Zukunft.

Sie möchten Kerberos in Ihrer TFS Landschaft aktivieren? Sprechen Sie uns an!

Weiterführende Informationen

[1] https://en.wikipedia.org/wiki/NT_LAN_Manager

[2] https://en.wikipedia.org/wiki/Kerberos_(protocol)

[3] http://technet.microsoft.com/en-us/library/ee806870(v=office.15).aspx

[4] http://msdn.microsoft.com/en-us/library/dd631919.aspx

[5] http://blogs.technet.com/b/rob/archive/2011/11/23/enabling-kerberos-authentication-for-reporting-services.aspx

[6] http://technet.microsoft.com/en-us/library/cc731241.aspx

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , , , , ,

Hinterlasse eine Antwort