NFSv4 mit UCS 3.0

german

#1

Hallo nochmal,

nach dem ich ja vor einigen Wochen die LDAP/Kerberos Anbindung bis zum erfolgreichen Benutzerlogin erreicht habe, wenn auch noch simpel und nicht besonderes abgesichert, habe ich nun endlich wieder Zeit gefunden weiter mit der Integration voran zu schreiten. Dabei habe ich im Thema NFSv4 und Kerberos einen nächsten Stolperstein gefunden, der aber zunächst relativ Kerberos spezifisch ist und auch eine paar grundlegende Fragen zu Kerberos auf dem UCS 3.0 aufwirft, die ich leider nirgends dokumentiert gefunden habe.

Folgt man dem Artikel [wiki]NFSv4_mit_UCS[/wiki] (welcher wohl ebenfalls für 2.4 ist) bedarf es bei der gesicherten NFSv4 Anbindung zuerst der Erstellung und Einbindung von Zertifikaten bzw. Principals für den Service. Dabei scheitert es sofort beim Einholen eines Tickets auf dem UCS (master) für den Prinzipal “kadmin/admin” (mittels kinit), da dieser zumindest nicht über das während der Installation vergebene Passwort von root/Administrator verfügt. Daher gleich die 1. Frage: Ist kadmin eine Art superuser der Kerberos-Datenbank selbst und wie sieht es mit der Authentifizierung und der Nutzung hierzu aus?

Versucht man sein Glück alternativ mittels “kinit” bzw. “kinit Administrator” bekommt man zwar ein Ticket, aber das Hinzufügen eines NFS Prinzipals für den Server mittels “kadmin add -r nfs/nfs-server.domain” scheitert nach Festlegung der weiteren Details an der zweiten Passworteingabe:

kadmin: kadm5_create_principal: Client (Administrator/admin@DOMAIN.LOCAL) unknown kadmin: adding nfs/ucs.domain.local@DOMAIN.LOCAL: Client (Administrator/admin@DOMAIN.LOCAL) unknownMit “kadmin -l” lässt sich dies dann aber vollziehen, was zur 2. Frage führt: Woher rührt das unterschiedliche Verhalten zwischen “kadmin -l” und der normalen Benutzung des Administrator Accounts?

Will man den NFS Prinzipal nun in die Keytab aufnehmen (ktutil get nfs/nfs-server.domain) scheitert das wieder an der oberigen Problematik und leider ist es meines Verständnis nach nicht möglich dies über “kadmin -l” zu erledigen. 3. Frage: Auf welchem Wege (zur Not auch per dump und einfügen mittels Editor) lässt sich der Eintrag noch in die keytab bringen?

Letztlich führen alle genannten Probleme dazu, dass der NFS-Server sich wohl erwartungsgemäß beschwert:

ucs rpc.svcgssd[4698]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure. Minor code may provide more information - Key table entry not found ucs rpc.svcgssd[4698]: unable to obtain root (machine) credentials ucs rpc.svcgssd[4698]: do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
Über weitere Erkenntnisse zum Kerberos Setup auf dem UCS 3.0 und allgemein zu NFSv4 wäre ich wie bisher sehr dankbar :slight_smile:


Debian-Fremdsysteme und UCS 3.0
#2

Hallo,

der genannte Wiki Artikel NFSv4_mit_UCS ist, wie schon von Ihnen vermutet, für UCS 2.4 erstellt worden. Ein entsprechender Wiki Artikel für UCS 3.0-x wird erstellt werden.

Auf UCS 3.0-x Systemen mit installiertem Samba4 wird nicht der Heimdal Kerberos Dienst verwendet, sondern der in Samba4 enthaltene. Daraus resultieren einige Unterschiede in der Handhabung. Z.B. ist die Verwendung des Programms “kadmin” so nicht möglich.

Um einen Kerberos Principal für einen NFS Server anzulegen, konnte ich das im Folgenden beschriebene Verfahren erfolgreich testen. Bitte beachten Sie, das dieses Vorgehen nur grob getestet wurde. Sie sollten es zunächst auf einem Testsystem nachstellen.

Gegeben ist ein UCS 3.0-1 DC Master mit dem Hostnamen “master”, der Domäne “kerb.eros” und dem Kerberos Realm “KERB.EROS” . Auf diesem wird eine Datei nfs.ldb mit dem folgenden Inhalt erstellt:

dn: samAccountName=nfs-master,CN=Principals objectClass: kerberosSecret privateKeytab: nfs.keytab realm: KERB.EROS secret: <Passwort> sAMAccountName: nfs-master servicePrincipalName: nfs/kerb.eros servicePrincipalName: nfs/master.kerb.eros name: nfs-master

Diese Informationen werden in die nfs.keytab des Samba 4 hinzugefügt.

root@master: ~ $ ldbadd -H /var/lib/samba/private/secrets.ldb nfs.ldb

Die Datei “/var/lib/samba/private/nfs.keytab” wird durch diesen Befehl erzeugt.
Daraufhin können die Informationen ausgelesen und geprüft werden.

root@master: ~ $ ktutil --keytab=/var/lib/samba/private/nfs.keytab list
 /var/lib/samba/private/nfs.keytab:
 
 Vno  Type                     Principal                       Aliases
   0  des-cbc-crc              nfs/kerb.eros@KERB.EROS         
   0  des-cbc-crc              nfs/master.kerb.eros@KERB.EROS  
   0  des-cbc-crc              nfs-master@KERB.EROS            
   0  des-cbc-md5              nfs/kerb.eros@KERB.EROS         
   0  des-cbc-md5              nfs/master.kerb.eros@KERB.EROS  
   0  des-cbc-md5              nfs-master@KERB.EROS            
   0  arcfour-hmac-md5         nfs/kerb.eros@KERB.EROS         
   0  arcfour-hmac-md5         nfs/master.kerb.eros@KERB.EROS  
   0  arcfour-hmac-md5         nfs-master@KERB.EROS            
   0  aes128-cts-hmac-sha1-96  nfs/kerb.eros@KERB.EROS         
   0  aes128-cts-hmac-sha1-96  nfs/master.kerb.eros@KERB.EROS  
   0  aes128-cts-hmac-sha1-96  nfs-master@KERB.EROS            
   0  aes256-cts-hmac-sha1-96  nfs/kerb.eros@KERB.EROS         
   0  aes256-cts-hmac-sha1-96  nfs/master.kerb.eros@KERB.EROS  
   0  aes256-cts-hmac-sha1-96  nfs-master@KERB.EROS 

Nach dem Aufruf von

ldbedit -H /var/lib/samba/private/sam.ldb

wird am Objekt

 dn: CN=MASTER,OU=Domain Controllers,DC=kerb,DC=eros

folgendes hinzugefügt.

servicePrincipalName: nfs/master.kerb.eros

Danach kann der Status wie folgt validiert werden:

[code]root@master: ~ $ kinit Administrator
Administrator@KERB.EROS’s Password:
root@master: ~ $ kgetcred nfs/master.kerb.eros@KERB.EROS
root@master: ~ $ klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: Administrator@KERB.EROS

Issued Expires Principal
Mar 2 17:09:22 2012 Mar 3 03:09:22 2012 krbtgt/KERB.EROS@KERB.EROS

Mar 2 17:09:32 2012 Mar 3 03:09:22 2012 nfs/master.kerb.eros@KERB.EROS[/code]

Mit freundlichen Grüßen
Tobias Scherer


#3

Ist eigentlich eine bessere Integration von NFSv4 schon für eine konkrete Version geplant?


#4

Hallo,

aktuell gibt es diesbezüglich keine genauen Planungen.

Mit freundlichen Grüßen
Tobias Scherer


#5

Hallo,

leider funktioniert das so nicht bei mir:

Nach Anlegen der nfs.keytab bekomme ich beim ktutil list Aufruf folgende Fehlermeldung:

ktutil --keytab=/var/lib/samba/private/nfs.keytab list
ktutil: krb5_kt_start_seq_get /var/lib/samba/private/nfs.keytab: Unsupported key table format version number

Any hints ?

Gruß Markus


#6

Vielen Dank Herr Scherer für Ihre Antwort, da ich vergessen hatte die E-Mail Benachrichtigungen auch für den neuen Thread einzustellen hatte antworte ich nun leider “etwas” verspätet. Ihre Anleitung habe ich so eben unter 3.0-1 errata42 getestet, allerdings ist es keine frische Installation und beinhaltet bisherige Änderungen zu Heimdal und NFS. Allerdings scheitere ich genau wie “mvatuv” bereits am “kutil list” Aufruf.

Haben Sie dazu weitere Erklärungen oder können Sie uns weitere Informationsquellen zur NFS & Kerberos Integration in 3.0 nennen?

Besten Dank!


#7

Hallo,

es hatte sich hier ein kleiner Tippfehler eingeschlichen, den ich entsprechend editiert habe.
Der Aufruf:

root@master: ~ $ ldbadd -H /var/lib/samba/private/nfs.keytab nfs.ld

müsste wie folgt lauten:

root@master: ~ $ ldbadd -H /var/lib/samba/private/secrets.ldb nfs.ldb

Bei einem erneuten Test sollte die zuvor fehlerhaft erzeugte Datei “/var/lib/samba/private/nfs.keytab” entfernt werden.

Mit freundlichen Grüßen,
Tim Petersen


#8

Danke für diesen Thread!

Ich habe ein ganz ähnliches Problem, für das dies aber leider noch nicht die Lösung darzustellen scheint.

Der KDC läuft auf einem UCS-Server, der NFS-Server ist aber ein existierendes anderes Gerät.
Die Problematik läuft ansonsten analog: es wird kerberos-typisch “kadmin/admin” erwartet, was aber nicht vorhanden ist. Da der NFS-Server nicht zugleich der KDC (Kerberos-Server) ist, fällt die Verwendung von “kadmin -l” aus.
Wie bereits in der ursprünglichen Anfrage beschrieben, ist das Aufnehmen des NFS-Prinzipals (ktutil get nfs/nfs-server.domain) in die Keytab nicht auf regulärem Wege möglich.
Ich habe den beschriebenen Workaround zwar nachvollzogen, es funktioniert aber nicht, da dabei davon ausgegangen wird, daß der UCS-basierende KDC zugleich der NFS-Master (und nicht der Client) sei.

Frage:
Wie kann man einen NFS4-Server mit UCS3.0 verbinden?

Maschine A ist ein Domaincontroller mit UCS3.1-1, hier als KDC tätig
Maschine B ist der NFS4-Server
Der NFS-Client soll in meinem Fall A sein, für eine allgemeinere Lösung (angekündigter Wiki-Artikel?) wäre ggf. eine separate Maschine C anzunehmen.

Welche Schritte muß man nun jeweils vornehmen, damit der NFS4-Client sich unter Verwendung der Kerberos-Authentisierung (und daraus folgend des User/Group-Mappings) mit einem Export des NFS4-Servers verbinden kann?


#9

[quote=“jwilkes”]
Frage:
Wie kann man einen NFS4-Server mit UCS3.0 verbinden?

Maschine A ist ein Domaincontroller mit UCS3.1-1, hier als KDC tätig
Maschine B ist der NFS4-Server
Der NFS-Client soll in meinem Fall A sein, für eine allgemeinere Lösung (angekündigter Wiki-Artikel?) wäre ggf. eine separate Maschine C anzunehmen.

Welche Schritte muß man nun jeweils vornehmen, damit der NFS4-Client sich unter Verwendung der Kerberos-Authentisierung (und daraus folgend des User/Group-Mappings) mit einem Export des NFS4-Servers verbinden kann?[/quote]
Hallo,

ich habe zunächst versucht, mich Ihrem Problem theoretisch zu nähern.
Der Wiki-Artikel NFSv4 with UCS ist ja im März 2013 aktualisiert worden. Der letzte Post in diesem Thread stammte vom Mai 2012.
Vlelleicht verstehe ich das ja nicht ganz, aber laut Wiki-Artikel wäre bei einer Samba 4-Domain gar kein “ktutil get nfs/nfs-server.domain” nötig. Oder verwenden Sie Samba 3?

Viele Grüße,
Dirk Ahrnke


#10

Herzlichen Dank für die Antwort!

Nein, UCS3.1 mit Samba4 AD ist im Gebrauch. Allerdings stimmt eine Annahme des http://wiki.univention.de/index.php?title=NFSv4_mit_UCSArtikels hier nicht: der UCS-Server ist nicht zugleich NFS-Server.

Ich bin nicht sicher, was da aktualisiert wurde; die hier im Thread angesprochenen Probleme bestehen auch m.E. bei aktueller UCS-Version. Insbesondere ist kadmin/admin weiterhin nicht erreichbar/vorhanden.

Mittlerweile habe ich einen ersten Workaround beisammen; allerdings mußte ich dabei u.a. die Mountoption “-o sec=krb5” weglassen. Durch “gss/krb5” in den exports wird aber offenbar doch GSS+Kerberos ausgelöst, wie die Logs zeigen.

Das ist für mich schon mal ein Fortschritt, auch wenn die Zugriffsrechte noch fehlerhaft sind, wird doch das User-Mapping ausgelöst (und das Group-Mapping geht fehl). Ich bin für weitere Hinweise aber empfänglich.

Viele Grüße
J. Wilkes


#11

Hallo,

die Beschreibung in NFSv4 with UCS geht erstmal davon aus, das der Dienst auf einem UCS-Server läuft und somit der Heimdal-Kerberos Client installiert ist. Wenn das nicht der Fall ist, müssen wir uns einen anderen Weg suchen.
Klammern wir erstmal die Kerberos-Konfiguration auf dem NFS-Server selbst aus. Das ist zu speziell, muss aber trotzdem als erstes erledigt sein.
Der Ansatz wäre jetzt, den Service-Principal und die Keytab mit samba-tool auf dem DC zu erzeugen. In Samba 4 - Linux Integration ist das Verfahren erwähnt. Leider habe ich es aus Zeitgründen noch nicht ganz zum Erfolg geschafft, aber ich denke, es sollte so funktionieren.

Punkt 1 steht schon im Univention Wiki

samba-tool spn add nfs/<nfs-server or client host>.$(hostname -d)/$(hostname -d) <nfs-server or client host>\$

Anmerkung: m.E. müsste der Principal eher “nfs/.$(hostname -d)” sein.

Punkt 2 wäre dann der Export der Keytab(s) mittels “samba-tool domain exportkeytab …” wie im zuletzt verlinkten Dokument beschrieben. Das wäre dann das Pendant für “kutil get” und “ktutil add”.

samba-tool domain exportkeytab /path/to/keytab1 --principal=nfs/nfsserver.domain.tld
samba-tool domain exportkeytab /path/to/keytab2 --principal=nfsserver$

Wie man die erzeugten Keytabs dann auf dem NFS-Server einbindet, hängt natürlich wieder davon ab, welcher Kerberos-Client dort läuft.
Bei Heimdal z.B.

root@host:/etc# ktutil copy /path/to/keytab /etc/krb5.keytab

Anmerkung: Auch hier bin ich nicht sicher, ob wir die Keytab für den Maschinen-Identifier wirklich benötigen.

Wie gesagt, auch noch nicht komplett, aber vielleicht hilft es.

Viele Grüße,
Dirk Ahrnke