Nach einigen nervigen Stunden/Tagen des rumprobierens und lesens diverser Artikel die man als Dokumentation betrachten könnte, haben der Niels und ich es nun doch geschafft einen NFS4-Server und Client unter Linux im Microsoft Active Directory zu authentifizieren.
Wenn man sich mal durch das Internet wühlt und liest wie das funktionieren soll, wird man an einigen Stellen enttäuscht feststellen das es eben genau so nicht in der Realität funktioniert. Vielleicht liegt das auch an unserer AD-Struktur die etwas größer und untypischer ist, als die in den HowTo’s und Tutorials erwähnten. Entsprechend hatten wir bei der ein oder anderen Fehlermeldung auch mal eine Mandantentrennung in Verdacht, insbesondere als ich verzweifelt versucht hab mich mit dem Likewise-Paket der Domäne anzuschliessen.
Inzwischen ist das ganze im Clientsystem auch weitestgehend automatisiert, praktischerweise erfolgen LDAP-Anfragen an das AD nun auch über SASL. Wenn das Kerberos schon funktioniert kann man es schliesslich auch gleich für jeden Mist nutzen.
Im Prinzip ist die Einrichtung auch super simpel und selbsterklärend und ich hatte mir fest vorgenommen mein gesamtes Wissen einfach mit ins Grab zu nehmen. Aber da ich mich selbst kenne und weiß das ich in spätestens 6 Monaten nicht mehr nachvollziehen kann wie und warum das funktioniert, schreib ich hier mal kurz die wenigen Einrichtungsschritte auf um das AD dafür zu Nutzen zwei Unix/Linuxmaschinen NFSv4 mit sec=krb5[ip] nutzen zu können:
Zunächst legt man ein Computerkonto im AD an, wir haben das auf einem Windows 2008 gemacht, weil man dort wenigstens im Log sehen konnte wenn etwas schief läuft, authentifizieren tun wir allerdings gegen einen 2003 DC. In den ganzen Sambahowtos steht immer man soll ein Benutzerkonto anlegen, kann man machen, muß man aber nicht.
In unserem AD werden leider die ServicePrincipalNames nicht richtig angelegt, das kann man mit setspn.exe -r Kontenname “reparieren”, oder man schreibt das wie ich einfach mit ADSIEdit da rein … letzlich wird das wohl ein Powershell oder Perlscript erledigen.
Als SPN sollte der FQDN z.b. “lilith.meine.domain.de” und host/FQDN “host/lilith.meine.domain.de” vorhanden sein, da wir NFS auch nutzen wollen fügen wir noch “nfs/lilith.meine.domain.de” hinzu.
An dieser Stelle sei angemerkt, dass die SPNs nicht richtig verarbeitet werden um nicht zu sagen der 2003DC interessiert sich nicht recht dafür und der 2008 bekommt das Lookup der Attribute nicht geregelt …
Damit das ganze ordentlich ist, setzten wir noch den DNS-Namen im AD, das dient in unserem Fall allerdings auch nur der Optik, weil wir dafür ein gesondertes IPAM-System benutzen. Und ganz wichtig, wir setzen den UPN auf “host/fqdn” also z.b. “host/lilith.meine.domain.de”. Der Grund ist einfach weil das mit den SPNs nicht funktioniert, davon ab wird wohl das ganze ServicePrincipalgeraffel ignoriert sobald ein Wert irgendwo im AD doppelt auftaucht. In der Theorie sollte es reichen die SPNs zu setzen so wie es z.B. in der MIT-Kerberos Doku auch beschrieben wird, in der Praxis setzen wir halt den UPN auf den ServiceNamen den wir benutzen in unserem Fall also host ..
Normalerweise sollte man sich nun von der Linuxmaschine mit “kinit host/fqdn@REALM” anmelden können und ein TGT bekommen, falls nicht, tja Pech ..
Für den NFS-Server setzt man den UPN aber besser direkt auf nfs/fqdn, mit host/.. ist irgendwie der gssvcd das ein oder andere mal nicht richtig gestartet. In der Doku dazu steht übrigens das in den Keytabs die Einträge in der Reihenfolge “root/fqdn”, “nfs/fqdn” und “host/fqdn” und zuletzt “nfs/*@REALM” als Credentials probiert werden. Zumindest als Client funktioniert das auch und es hat den Vorteil das man über den host-Principal noch andere Dinge laufen lassen kann, das dient aber auch nur als Übergangslösung bis das mit den SPNs klappt…
Damit das nun alles automatisch klappt, wir nutzen den Kernel-Automounter um Homedirectories zu mounten, muß man es nur noch schaffen eine Keytab zu erzeugen und das ist wieder ein sehr spannendens Kapitel.
Im Internet steht dazu: führen sie “ktpass.exe -princ host/lilith.meine.domain.de@REALM -mapuser DOMAINlilith -pass +rndpass -DES-DBC-CRC +DesOnly KRB5_NT_PRINCIPAL -out bla.keytab” aus oder so ähnlich das ist aus dem Gedächtnis zitiert. Dieses Kommando mapped ein Nutzerkonto auf einen ServicePrincipal, zu deutsch schreibt den UPN um. Da wir kein Nutzerkonto haben und den UPN schon manuell geändert haben, weil wir wissen das die SPNs nicht gehen können wir uns das sparen.
Interessant ist eigentlich nur der Hinweis auf +DesOnly, unser AD ist leider nicht in der Lage AES zu benutzen, warum weiß ich nicht ist mir auch egal. Bleiben als mögliche Chiffren also des-cbc-crc, des-cbc-md5 und rc4-hmac, letzteres will unser AD gern haben und macht die wenigsten Probleme ist dafür halt nicht mehr State-Of-The-Art.
Was man nun wissen muß, weil das in der Knowledgebase widersprüchlich steht: ktpass verhält sich je nach Windowsversion etwas anders und bekommt es nicht hin die aktuelle KVNO aus der Kerberosdatenbank zu lesen sondern legt die Keytabs immer mit Version 1 an außer man setzt das manuell via -kvno auf einen anderen Wert, den man aber nicht so trivial unter Windows heraus bekommt …
Sollte man das doch irgendwie schaffen muß man die Keytab natürlich noch auf den Client kopieren, um sich den ganzen Scheiß zu sparen kann man die Keytab auch gleich mit den MIT-KRB-Tools auf dem Linuxclient erstellen.
Als erstes finden wir die KVNO raus, dafür gibt es den Befehl kvno, Parameter ist der Kontenname, hat man noch das gültige TGT vom kinit-Test wirft einem das direkt eine Zahl entgegen, anderfalls will es ein Passwort oder mault das es keine Credentials hat -> kinit machen, glücklich sein.
Dann startet man ktutil und erstellt sich die Keytab mit folgender Zeile:
addent -princ -p host/lilith.meine.domain.de@REALM -k [hier die kvno] -e [eine vom AD unterstützte Chiffre]
wkt /etc/krb5.keytab
Und schon sind wir fertig. Die Chiffren heißen übrigens “des-cbc-crc”, “des-cbc-md5”, “rc4-hmac”, “aes256-cts-hmac-sha1-96” und “aes128-cts-hmac-sha1-96”, bei uns halt rc4, weil Baum …
Ob das klappt testet man einfach mal mit “kinit -k -c /tmp/testcc”, dann sollte man mit “klist -c /tmp/testcc” die laufenden Tickets sehen.
Herzlichen Glückwunsch, sie haben nun einen Linuxclient ohne Sambageraffel an einem Windows 2003R2 angebunden und können ihre Dienste dagegen authentifzieren.
Wenn man den rpc.gssvcd mit -vvv startet sieht man die ganzen Debugmeldungen im Log und etwaige Fehler die auftreten, die es an dieser Stelle aber nicht mehr geben dürfte.
Bei aktuelleren Linuxdistributionen muß man allerdings in der krb5.conf bei den libdefaults noch “allow-weak-crypte = true” hinzufügen, da rc4-hmac nicht mehr standardmässig akzeptiert wird, da das AD eigentlich auch Aes256 kann sollte man das zumindest ausprobieren und nehmen sofern es denn funktioniert.
Und wenn wir schon eine funktionierende Keytab haben können wir auch gleich noch die LDAP-Anfragen damit aufrufen, dazu schreibt man in die nss-ldap.conf:
use_sasl on
rootuse_sasl yes
krb5_ccname /var/tmp/nssldap.cred
Den Credentialcache lassen wir per Cron erzeugen mit einem “kinit -k -t /etc/krb5.keytab -c /var/tmp/nssldap.cred 2>&1 > /dev/null” zu Zeiten die unter der Defaultleasetime liegen, bei uns hab ich das auf alle 6 Stunden eingestellt, die Tickets sind 10 Stunden gültig.
Und alles was jetzt noch fehlt um unser cooles BlueArc in Betrieb zu nehmen ist nicht mehr direkt mein Problem, bzw. sind das nur noch Kleinigkeiten 🙂