Interop 4: Linux Benutzer per Kerberos am AD authentifizieren

In dieser Serie von Blogeinträgen möchte ich Schritt für Schritt erklären, wie man die Vorteile des AD auch für Linux nutzen kann. Ich hab mir gedacht, ist ein bisschen viel für einen Artikel, daher werde ich das jetzt abschnittweise vorstellen.

Nachdem ich im ersten Teil erklärt habe, welche Voraussetzungen erfüllt sein müssen, um LDAP-Abfragen ans AD zu senden, und wir im zweiten Teil den Nameservice von Linux so konfiguriert haben, dass es Benutzerinfos nicht nur aus seiner lokalen /etc/passwd holt, sondern auch aus dem AD, ging es im dritten Teil darum, diese LDAP-Fähigkeit zum Login zu nutzen. Die Schwachstelle hierbei ist (unter anderem), dass man sich um eine Transport-Verschlüsselung kümmern muss. Hier würde sich der Einsatz von Kerberos anbieten, das funktioniert „von Hause aus“ schon verschlüsselt.

Als erstes machen wir mal die PAM-Einstellungen vom letzten Kapitel rückgängig, also die pam_ldap-Zeile auskommentieren oder löschen. Jetzt klären wir mal ein paar Vorbedingungen, die die spätere Fehlersuche (und die wird kommen!) etwas einfacher macht:

  • Zeitunterschied: Zwischen unserem DC und dem Linux-Client muss die Zeit möglichst gleich sein, auf gar keinen Fall aber mehr als 5 Minuten voneinander abweichen.
  • DNS: Alle Clients und Server müssen korrekt im DNS aufgelöst werden können, mit vollständigem Namen (FQDN), Am besten alle Adressen von beiden Seiten prüfen, eventuell alte „Leichen“ in /etc/host“ oder so bereinigen.
  • Eine Möglichkeit schaffen, eine wichtige Datei sicher von Windows nach Linux zu kopieren (WinSCP zum Beispiel).
  • Firewalls prüfen. Zu Testzwecken am besten zwischen DC und Client alles freischalten.

Falls nachher etwas nicht funktioniert, bitte mindestens 1) und 2) erneut überprüfen.

Dann müssen wir natürlich Kerberos installieren. Das kommt in zwei Varianten daher, einmal als MIT-Kerberos und einmal als Heimdal. Welches besser ist? Keine Ahnung. Manchmal ist auch nur eine der beiden Varianten in einer Standard-Distribution dabei, dann fällt die Wahl etwas leichter 🙂

Beiden gemeinsam ist die Konfigurationsdatei, nämlich /etc/krb5.conf (verwendet wird Kerberos 5, Version 4 ist zu alt!). Die Einträge in der (mitgelieferten) Standard-Konfiguration sind fast selbsterklärend, daher nur ein paar Worte als Hinweis:

  • Grundsätzlich wird der sog. Kerberos-Realm, also sowas wie die Domäne, in GROSSBUCHSTABEN geschrieben.
  • Neuere Versionen können mit DNS-SRV-Records umgehen, eine explizite Angabe des Kerberos-Servers (also des DCs) kann dann entfallen.
  • Die Verschlüsselungstypen sind je nach Version unterschiedlich, am besten angeben, auch wenn es bei ihnen der Standard sein sollte…

Hier noch meine /etc/krb5.conf als Beispiel

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = CONTOSO.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes

[realms]
CONTOSO.COM = {
kdc = dc1.contoso.com:88
admin_server = dc1.contoso.com:749
default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

Jetzt kommen wir zum etwas kniffligeren Teil, nämlich der Keytab. In dieser Datei (standardmäßig /etc/krb5.keytab) wird ein Key gespeichert, der für die Kommunikation zwischen Server und Client verwendet wird und die Identität überprüft. Wenn er das will. Leider klappt das nicht immer, was manchmal an der Zwischenstufe PAM liegt, manchmal aber auch an fehlerhaften Implementierungen in der Applikation (und manchmal auch in einer fehlerhaften Anleitung :-). Die gute Nachricht: Man braucht die Keytab für ein reines Login nicht unbedingt. Erst wenn es darum geht, sich mit einem schon vorhandenen Kerberos-Ticket anzumelden, ist die richtige Keytab zwingend. Zurück zur Keytab, das heißt, vorher können wir schon mal ohne Keytab probieren:

kinit harryp@CONTOSO.COM

Jetzt können mehrere Dinge passiert sein:

  • Passwort-Abfrage und keine anschließende Fehlermeldung: Glückwunsch! Geschafft! Weiter geht’s unten.
  • Clock skew too great: Die maximal Abweichung der Uhrzeiten auf Client und Server ist 5 Minuten, am besten den DC als Zeitserver konfigurieren (ntpdate).
  • Benutzer nicht gefunden: LDAP Namensauflösung geht nicht mehr! Was haben Sie getan? Probieren sie, ob sie mit getent noch Infos bekommen, ansonsten zurück zu Kapitel 2
  • Server nicht gefunden: Na, Tippfehler in der krb5.conf? Oder DNS-SRV-Records verwendet? Dann bitte mal mit statischem Eintrag versuchen.

Ich hoffe, sie haben den Fehler gefunden. Prima. Dann zeigt ihnen

klist

ihre Tickets, das sind die Dinger, mit denen Kerberos sie zukünftig an anderen Servern und Diensten ausweist (sie kennen sowas übrigens schon ewig: Ihren Personalausweis! Den hat auch einmal einer gemacht, und alle anderen vertrauen darauf, auch ohne dass sie ihre Geburtsurkunde mitschleppen müssen). Genauer gesagt haben sie ein Ticket, ein sogenanntes Ticket Granting Ticket, kurz TGT. Und mit diesem können sie jederzeit neue Tickets anfordern (wenn sie zum Fußballspiel gehen, zeigen sie vorher ihren Ausweis vor und kaufen ein Ticket, mit dem sie dann ins Stadion kommen). Schauen sie in der Ausgabe man nach krbtgt.

Wir generieren jetzt aber doch noch eine Keytab, erstens weil es schöner ist, und zweitens, weil es dann doch Applikationen gibt, die sie verwenden. Wenn sie einen Windows-Client in die Domäne aufnehmen, dann passiert (unter anderem) übrigens genau das: ein Computerkonto wird erzeugt, eine Keytab wird erstellt und auf den Client kopiert (okay, und noch etwas mehr…). Unter Linux müssen wir das von Hand machen. Wir könnten auch Samba nutzen (net ads join), aber das wäre uncool. Außerdem müsste ich da jetzt noch Samba erklären, und wenn Samba grad mal wieder ein Problem mit Windows-Servern hat und das Samba standardmäßig eine eigene keytab verwendet und und und, aber wir wollen ja irgendwann fertig werden, also alles von Hand. Ist nicht so schlimm, man kann das prima scripten.

Auf dem DC bitte ein Computerkonto erstellen mit dem Namen des Computers (es kann auch ein Benutzerkonto sein, dann meckert Windows später nicht so viel, aber ich denke, Computer sind Computer, auch wenn ein Linux drauf läuft :-). Dann bitte eingeben in einer Zeile:

ktpass -princ HOST/client1.contoso.com@CONTOSO.COM -mapuser contoso\client1$ -pass geheim -ptype KRB5_NT_PRINCIPAL -out client1.keytab

Bitte beachten: Großschreibung beim Realm und das Dollarzeichen nicht vergessen. Nach etwas Meckerei (bestätigen!) findet sich eine Datei namens client1.keytab, und die muss auf den Client kopiert werden (wer hätte das gedacht?). WinSCP ist zum Beispiel eine gute (und kostenlose) Möglichkeit. Wenn sie noch keine /etc/krb5.keytab haben, dann reicht es, die Datei entsprechend umzubenennen. Falls sie schon eine haben und behalten wollen, dann über ktutil beide Dateien einlesen und unter /etc/krb5.keytab abspeichern. kutil kommt ebenfalls in verschiedenen Gewändern daher, die man-Page oder die Hilfe gibt vielleicht was her.

So. Fertig! Ach halt, noch die PAM-Konfig ändern. Auch hier wieder der Hinweis, eine Shell offen zu lassen, falls etwas schiefgeht.

Da wo vorhin die pam_ldap.so stand, da muss jetzt die pam_krb5.so rein. Jetzt sollte ein Login mit Authentifizierung am DC möglich sein. Als Login-Name sollte der Kurzname reichen, eventuell mal mit vollständigem Namen anmelden (also Name@REALM, snape@CONTOSO.COM zum Beispiel).

Nach erfolgreichem Login mal mit klist die Ticket-Liste anschauen, ob auch wirklich alles geklappt hat. Für Debug-Zwecke kann man in der PAM-Konfig hinter das pam_krb5.so auch noch Parameter (debug oder so) angeben. Näheres dazu in der Man-Page.

So. War das so schwer? Eigentlich doch nicht, und ich wette, Sie haben die Zusammenhänge jetzt auch soweit verstanden, dass Sie das auf die spezifischen Eigenheiten ihrer Distribution anpassen können. Wenn sie sich übrigens nicht sicher sind, welche Konfig-Datei welches Programm nutzt, dann ist strace ihr Freund..

Im nächsten Kapitel möchte ich eine ganz einfache Art beschreiben, Samba zu konfigurieren.

Advertisements

Über Ralf Wigand

...arbeitet für Microsoft und war von 2008-2015 MVP für Directory Services.
Dieser Beitrag wurde unter Active Directory, Kerberos, LDAP, Linux, Windows Server veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s