Kerberos und Server

Beachten Sie auch die Informationen auf Ticketsize zu anderen Anwendungen

Kerberos ist keine Erfindung von Microsoft. Ursprünglich hat das MIT (http://de.wikipedia.org/wiki/Kerberos_(Informatik) damit angefangen und so ist es auch keine Überraschung, dass es auch andere Kerberos-Strukturen gibt, die natürlich nicht zwingend auf Windows aufsetzen. Diese Seite beschäftigt sich nicht mit diesen anderen Services, sondern zeigt auf, wie eine bestehende Windows Kerberos Struktur auch von anderen Programmen und Diensten genutzt werden kann.

Beachten Sie dazu die Seite Kerberos mit Linux und AD

Diese Seite wird nicht oft aktualisiert. Es kann daher sein, dass Informationen schon überholt sind und Einrichtungen sich stark vereinfacht haben.

Autorisierung <> Authentifizierung <> Userverwaltung
Kerberos ist ein Authentifizierungsprotokoll. für ein "Single SignOn müssen Sie aber auch die Benutzerverwaltung entsprechend konfigurieren. LDAP, NIS etc. sind Protokolle um Benutzerdaten zu erhalten und ACLs auf Dateisystemen oder .htaccess-Dateien im Webverzeichnis steuern letztlich, was ein per Kerberos authentifizierter Benutzer durchführen darf.

Kerberos und DFS

Wenn Sie ihr Dateisystem per DFS erreichbar machen, dann sollten Sie wissen, dass auch hier Kerberos zum Einsatz kommt, aber nur, wenn Sie den FQDN verwenden

Kerberos und Exchange

Für die Anmeldung an Outlook WebApp kommt heute fast nur noch die "Formularbasierte Anmeldung" zum Einsatz. Hierbei ist Kerberos kein Thema. Anders sieht es aber aus, wenn LoadBalancer ins Spiel kommen und Outlook per RPC sich mit dem Exchange CAS verbinden. Dann würde Outlook 2003 und höher schon gerne mit Kerberos arbeiten und damit auch den CAS-Server entlasten. Genau das geht aber erst mal nicht, wenn Sie mit einem Exchange 2010 CAS-Array arbeiten, da dieses keinen ServicePrincipalName anlegt und selbst mit einem SPN kein CAS mit dem Ticket etwas anfangen könnte.

Erst seit Exchange 2010 SP1 ist es überhaupt möglich, die Exchange Dienste mehrere CAS-Server mit dem gleichen Dienstkonto laufen zu lassen, und so auch mit einem virtuellen Farmnamen zu arbeiten.

Recommendation: Enabling Kerberos Authentication für MAPI Clients
http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx

Exchange 2010 SP1Cu4 enthält extra zwei Skripte zur Konfiguration großer Tokens.:
LargeToken-Kerberos.ps1 und LargeToken-IIS_EWS.ps1

Kerberos und IIS

Der Internet Information Server ist natürlich eine prädestiniert für eine automatisch Anmeldung. Als Mitglied in der Domäne kann er natürlich auf die Benutzer des Active Directory zugreifen. Umgekehrt kann man entweder dem Server oder dem Dienstkonto des Applicationpool auch einen SPN im AD verpassen, damit der KDC die Tickets ausstellen kann.

By Default bietet der IIS sogar Kerberos als Authentifizierungsverfahren an, was in Verbindung mit Kerberos Delegation sogar erforderlich ist, zumindest wenn Sie die "Integrierte Anmeldung" aktiviert haben,

Das parallele Angebot von Kerberos und NTLM erschwert natürlich die Fehlersuche, wenn eine Webseite auf die Funktion von Kerberos setzt aber der Client auf NTLM zurück fällt. Leider steht das genutzte Authentifizierungsverfahren nicht im IISLog und kann daher relativ einfach nur über das Security Eventlog nachvollzogen werden.

Daher kann es aber interessant sein, die Authentifizierung feiner einzustellen, was aber per GuI nicht mehr geht:

REM Anzeige der aktuellen Einstellung
'
cscript adsutil.vbs get w3svc/1/NTAuthenticationProviders

REM setzen für Kerberos und NTLM
cscript adsutil.vbs set w3svc/WEBID/NTAuthenticationProviders "Negotiate,NTLM"

REM setzen für Kerberos ONLY
cscript adsutil.vbs set w3svc/WEBID/NTAuthenticationProviders "Negotiate"

Die WEBID ist die Nummer, die im IIS-Manager bei der Webseite zu sehen ist:

Wenn der Zugriff auf den Webserver ohne SSL erfolgt (z.B.: weil Sie die Daten selbst nicht verschlüsseln müssen und das Kennwort durch den Einsatz von NTLM oder Kerberos schon ausreichend gesichert ist (bei einer Anmeldung per Basic Authentication oder Formular sollten Sie immer SSL erzwingen !!), dann können Sie im Netzwerk Monitor ebenfalls sehen, was zwischen CIient und Server passiert.

Im Paket 1464 möchte der Client die owa/logon.html eines OCS Communicator Web Access erhalten und fängt sich natürlich einen 401 ein, da er die Daten anonym nicht erhalten darf. Die Antwort enthält aber auch gleich die Information, welche Authentifizierungsverfahren angeboten werden:

Da der Client dann ein Ticket erhalten hat, sendet er im Paket 1466 dann die Anforderung noch einmal mit der passenden Anmeldung.

Damit das alles aber auch funktioniert, muss der Client natürlich mitspielen. Dazu gehört, dass der IE die integrierte Anmeldung aktiviert hat und die angesprochene Adresse auch als vertrauenswürdig oder lokales Intranet angesehen wird. Browser

Kerberos und Sharepont

Auch wenn Sharepoint eigentlich eine IIS-Applikation ist, sind die ein oder anderen Dinge beim Einsatz von Kerberos dabei auch zu beachten.

Kerberos mit Microsoft SQL

Auch SQL 2008 kann mit Kerberos umgehen. Wird der SQL-Server aber nicht als "LocalSystem" oder als "NetworkService" gestartet, dann kann der nicht den ServicePrincipalName nicht aktualisieren. Damit in dieser Umgebung mit Kerberos bearbeitet werden kann, haben Sie die Wahl zwischen zwei Optionen:

  • Manuelle Pflege des SPN
    Als Administrator nutzen Sie das Programm SetSPN, ADSIEDIT o.ä. Um dem Dienstkonto statisch den passenden SPN zuzuweisen.
  • Rechte dem Dienstkonto zum Lesen/Schreiben des SPN geben
    Alternativ können Sie dem Dienstkonto, mit dem die SQL-Server-Instanz läuft, das Recht zur Pflege der SPN an ihrem Dienstkonto geben.

Microsoft® Kerberos Configuration Manager für SQL Server
http://www.microsoft.com/en-us/download/details.aspx?id=39046

Weitere Informationen finden Sie auch auf:

Kerberos mit Hyper-V

Auch für Hyper-V Server kann es erforderlich sein, dass diesen zur Delegierung vertraut wird. Immer dann, wenn z.B.: ein Anwender über die Konsole ein ISO-Image auf einem anderen Server einbinden will, muss der Hyper-V-Server sich mit den Rechten des Benutzers am anderen Server authentifizieren. Damit dies funktioniert, muss auf dem Computerkonto des Hyper-V-Servers unter Delegation der CIFS-Pfad des anderen Server eingetragen werden:

Erst dann kann sich der Hyper-V Server ein Ticket im Auftrag des Benutzers holen, um auf den angegebenen Server zugreifen zu können.

Kerberos mit Unix, Apache und Samba

Kaum eine Netzwerk ist heute noch homogen und auch wenn Windows und Active Directory oftmals die zentrale Rolle für Authentifizierung und Autorisierung spielen, so gibt es in vielen Umgebungen natürlich Dateiserver auf Basis von Samba und Apache-Webserver. Da liegt es nahe, natürlich die Benutzerdaten und Anmeldeinformationen aus dem Active Directory auch hier einzusetzen. Es geht dabei aber nicht nur darum. dass Sie bei einer Anmelden an diesen Diensten ihr gewohntes Windows Kennwort eingeben können, sondern dass Sie am Besten gar keine Anmeldedaten mehr eingeben müssen. Dazu muss der Client vom Server eine Anmeldeaufforderung für  GSSPI/Negotiate erhalten und der Client vom KDC des Domain Controller ein passendes Ticket erhalten und an den Service zur Überprüfung weiter leiten. Wenn der Service dann weiß (Authentifizierung), welcher Benutzer ankommt, kann er z.B. über die Gruppenmitgliedschaften den Zugriff regeln (Autorisierung)

Der Schlüssel ist hierbei immer ein Benutzer oder Computerkonto im Active Directory, welches einen ServicePrincipalName (SPN) hat und eine KEYTAB-Datei für Apache bzw. Samba bereit gestellt wird. Die Integration hierzu erfolgt in mehreren Schritten:

  • Unix Betriebssystem mit Kerberos konfigurieren
    uNIX-System über Eintragungen in der Datei "/etc/krb5.conf" für den Einsatz von Kerberos konfigurieren
[libdefaults]
 ticket_lifetime = 24000
 default_realm = MSXFAQ.DE
 dns_lookup_realm = false
 dns_lookup_kdc = false
 
[realms]
 DOMAIN.TLD = {
  kdc = dc1.msxfaq.de:88
  kdc = dc2.msxfaq.de:88
 }
 
#[domain_realm]
# .domain.tld = DOMAIN.TLD
# domain.tld = DOMAIN.TLD

# pam einstellungen nicht fuer Apache erforderlich 
[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }
  • Prüfen der Kerberos Basiskonfiguration
    um die Konfiguration in der krb5.conf zu prüfen sollten Sie ein Ticket für einen AD-Benutzer holen und anzeigen, z.B. mit
# Ticket fuer Anwender Username anfordern. Kennwort muss eingegeben werden
" kinit Username

# Tickets auf console ausgeben
klist
  • Benutzer im Active Directory für den Dienst anlegen
    Sie sollten das Kennwort auf "nie ändern" stellen, damit die Funktion nicht nach Ablauf des Kennworts gestört wird.
  • Keytab-Datei erstellen
    Mit dem Tool "ktpass" (Windows 2003) wird nun mit dem gerade angelegten Benutzer eine MIT-kompatibles KEYTAB-Datei erzeugt.
ktpass
  -princ HTTP/myweb.msxfaq.de@MSXFQ.DE
  -mapUser svc-myweb
  -crypto RC4-HMAC-NT
  -pass password
  -ptype KRB5_NT_PRINCIPAL
  -mapop set
  -out c:\myweb_rc4.keytab
  • Kontrolle des SPN
    Das Programm KTPASS im vorigen Schritt addiert sowohl den Service Principal Name an das Konto als auch das Kennwort. Mittels ADSIEDIT können Sie gut prüfen, ob diese Änderungen erfolgt sind:
  • "httpd.keytab"-Datei auf das Zielsystem kopieren
    Übertragen Sie die Datei über einen sicheren Weg (z.B. SCP) auf das Zielsystem und ändern Sie den Besitzer und Rechte, damit der Dienst diese Datei später verwenden kann.
chown nobody:nobody myweb_rc4.keytab
chmod 400 myweb_rc4.keytab
  • Prüfen der Keytab-Datei
    Auf dem Unix-System können Sie über KINIT die Gültigkeit der Datei prüfen. Es darf kein Fehler gemeldet werden.
kinit -k -t /usr/local/apache2/conf/myweb_rc4.keytab HTTP/myweb.msxfaq.de
  • Apache: Kerberos auf dem Dienst installieren und aktivieren.
    Je nach System müssen dazu die Kerberos-module (mod_auth_kerb) erst kompiliert werden. Über eine Konfigurationsdatei wird das Modul eingebunden und konfiguriert.
# Apache Kerberos Modul einbinden (/etc/httpd/conf/httpd.conf )

LoadModule auth_kerb_module modules/mod_auth_kerb.so

<Directory "/geheim">
  Allow from all
  AuthName "Kerberos Anmeldung"
  AuthType Kerberos
  KrbAuthRealms MSXFAQ.DE
  KrbServiceName HTTP/myweb.msxfaq.de
  Krb5KeyTab /etc/httpd/conf/myweb_rc4.keytab
  KrbMethodNegotiate On
  KrbMethodK5Passwd Off
  require valid-User
</Directory>
  • Apache neu starten
    Die Konfiguration sollte nach dem Neustart des Webservers über "service httpd restart" bzw. "apachectl -restart" aktiv werden.

Ich habe schon gehört, dass es auch Wege gibt, einen Apache/Tomcat per Kerberos über ein Dienstkonto mit passendem Kennwort anzubinden. Eine Musterkonfiguration habe ich dazu aber nicht.

Wenn Sie nun auf den Webserver über http://servername/geheim zugreifen, dann sollte ihr Browser eine 401-Meldung erhalten, die ihn zwingt, ein Ticket für den gemeldeten <Servername der URL>@<KrbAuthRealms> vom KDC anzufordern, an den Apache zu liefern und dann über die Zugriffsregeln in der ".htaccess" den Inhalt auszuliefern. Ein Blick mit Kerbtray auf dem Windows PC

Für die Integration in das Betriebssystem selbst (z.B. zur Anmeldung per Telnet, SSH oder Samba sind weitere Schritte erforderlich.

  • Samba: Integration mit Kerberos
    Für die Samba-Integration ist die Konfiguration der "/etc/krb5.conf" erforderlich. Dann können Sie in der "/etc/samba/smb.conf" die Integration in die Domäne und Kerberos für Samba einzustellen. Danach müssen Sie mit einem "net ads join" den Samba in die Domäne aufnehmen. Samba legt dann alleine das Computerkonto im AD an.
workgroup = <NetBIOS der AD-Domain>
security = ads
realm = <DNS-Name der AD-Domain> use kerberos keytab = true
password server = <Liste der DCs durch Leerzeichen getrennt>

Leider unterscheiden sich die verschiedenen Unix-Distributionen in umfang und Default-Einstellungen, so dass Sie eventuell etwas basteln müssen. ein paar Tools können auf Unix aber helfen, um die Funktion von Kerberos zu prüfen:

  • Unix: KDESTROY
    Sorgt dafür. dass alle bislang erhaltenen Tickets verworfen werden. Nur dann sind Test zum Anfordern von Tickets aussagekräftig
  • Unix: GETENT password <Username>
    Dieses Tool sollte bei erfolgreicher Integration per PAM zum Benutzer z.B.: das Heimatverzeichnis, Shell, uID etc. liefern
  • Unix: KINIT User@addomain.tld
    Dieser Befehl holt für den angegebenen Benutzer ein Ticket, welches zur Anforderung weiterer Tickets erforderlich ist.
  • Unix: KLIST
    Gibt die lokal im Cache vorhandenen Tickets auf dem Bildschirm aus.
  • Windows: KerbTray
    Diese kleine Tool aus dem Ressource Kit erlaubt die Anzeige und das Löschen (Purge) der lokal vorgehaltenen Kerberos Tickets und helfen z.B. zu prüfen, welche Tickets ihr Windows Server erhalten hat.
    http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

Einige Linux Distributionen (z.B. Fedora 11) erlauben schon beim Installieren auf Festplatte die Konfiguration einer Kerberos-Authentifizierung:

Wobei klar zu unterscheiden ist, dass Kerberos nur die Anmeldung eines schon bekannten Benutzers durchführen kann. Die Benutzerdaten selbst (z.B. Heimatverzeichnis, Anmeldeskripte, uID, GID etc.) müssen z.B. NIS, LDAP o.ä. eingerichtet werden.

Weitere Links

Folgende Links führen zu weiterführenden Seiten. Das ein oder andere wird ihnen wieder bekannt vorkommen.