Samba 3.x als Domänen-Mitglied
Beitritt zu einer Windows 2003-Domäne mit Benutzerübernahme
Möchte jetzt ein Client auf einem Dienst zugreifen so kontaktiert dieser Client als erstes den AS. Der AS erteilt dem Client ein sogenanntes »Ticket Granting wendet sich der Client mit dem TGT an den »Ticket Granting Service«. Der TGS erstellt dem Client ein sogenanntes »Service Granting Ticket«. Dieses Ticket ist nur für einen bestimmten Dienst auf einem bestimmten Server gültig. Mit dem SGT wendet sich der Client an den eigentlichen Server, auf den der gewünschte Dienst läuft. Der Server gibt dann sein Einverständnis und der Client darf auf den gewünschten Dienst zugreifen.
){kind=small}
Rainer Budde
Kerberos-Authentifizierung
Jeder KDC arbeitet innerhalb eines Verwaltungsbereichs, der auch als REALM bezeichnet wird. Es gibt niemals mehr als ein Realm für einen KDC. Der REALM ist im Normalfall die DNS-Bezeichnung des Domänencontrollers nur in Grossbuchstaben. Meine Domäne heißt prodas und der DNS Server des Domänencontrollers verwaltet den Domänennamen prodas.local. Somit ist der zuständige Realm PRODAS.LOCAL.
Die Konfigurationsdatei /etc/krb5.conf
Damit man den Linux-Server dazu bewegen kann, sich mit dem Kerberos-Server in Verbindung zu setzen, müssen einige Einträge in der Datei /etc/krb5.conf geändert werden. Wie gesagt, heißt meine Domäne prodas, der DNS-Domänenname ist prodas.local und der Realm heißt somit PRODAS.LOCAL. Der Domänencontroller heißt pds-ad.prodas.local. Somit sieht meine /etc/krb5.conf wie folgt aus:
[libdefaults]
default_realm = PRODAS.LOCAL
clockskew = 300
[realms]
PRODAS.LOCAL = {
kdc = PDS-AD.PRODAS.LOCAL
}
[domain_realm]
.prodas.local = PRODAS.LOCAL
[logging]
# default = SYSLOG:NOTICE:DAEMON
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/kdc.log
kadmind = FILE:/var/log/kadmind.log
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 0
debug = false
}
Wichtig: Ein beliebter Fehler ist hierbei die fehlende DNS-Auflösung des Linux-Servers. Es muss also einmal geprüft werden, ob der Servername pds-ad.prodas.local in eine IP aufgelöst werden kann. Das kann einfach geprüft werden, indem man ein Ping auf pds-ad.prodas.local absetzt. Sollte der Domänencontroller nicht aufgelöst werden können, muss geprüft werden, ob ein gültiger DNS-Server in der Datei /etc/resolv.conf eingetragen ist. Alternativ kann auch die fehlende Auflösung durch einen Eintrag in /etc/hosts ergänzt werden, so wie im folgenden Beispiel:
# # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 10.233.224.10 pds-ad.prodas.local pds-ad
Funktioniert die IP-Auflösung, steigt das erste Mal die Spannung an. Der Befehl kinit Administrator@PRODAS.LOCAL fordert die Eingabe des Administrator Passworts des Domänencontrollers. Sollte alles erfolgreich gelaufen sein, bekommt man eine Meldung, dass das Ticket für einen bestimmten Zeitraum gültig ist.
Hinweis: Auch hier sind beliebte Fehler die fehlende Groß- und Kleinschreibung. Es muss wirklich alles so geschrieben werden wie in dem obigen Beispiel.
Hinweis: Erscheint als Meldung so etwas wie »kinit: command not found«, so fehlt wahrscheinlich das Paket »Heimdal« und muss nachinstalliert werden.
Sollte dieser Schritt erfolgreich durchgelaufen sein, so sind wir schon ein großes Stück weiter und schließen die Geschichte mit Kerberos erst mal ab.
