Ok seems that isn’t required
Here is a summary of the steps I took:
++ Auf dem Server (Master) ++
+ Export-Root auf dem Server anlegen +
Datei /etc/exports
"/home" -rw,root_squash,sync,no_subtree_check,sec=krb5i
FQDN="$(hostname -f)"
DOMAIN="$(dnsdomainname)"
REALM="$(ucr get kerberos/realm)"
PRINCIPAL="nfs/${FQDN}@${REALM}"
BASE="cn=kerberos,$(ucr get ldap/base)"
udm kerberos/kdcentry create --position "$BASE" --set name="$PRINCIPAL" --set generateRandomPassword=1
/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "nfs-$HOSTNAME" --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs.keytab
ktutil copy /var/lib/samba/private/nfs.keytab /etc/krb5.keytab
systemctl try-reload-or-restart nfs-server.service
samba-tool spn add nfs/tux.gehr.lan/gerh.lan tux\$
/etc/univention/templates/files/etc/default/nfs-kernel-server
NEED_SVCGSSD=yes
ucr commit /etc/default/nfs-kernel-server
/etc/univention/templates/files/etc/default/nfs-common
NEED_STATD=no
ucr commit /etc/default/nfs-common
++ Auf dem Client ++
systemctl restart rpc-gssd.service
kinit Administrator
Wenn ich nun auf dem Client versuche das Home zu mounten erhalte ich lediglich:
root@pc001:~# showmount -e tux.gehr.lan
Export list for tux.gehr.lan:
/home *
root@pc001:~# mount -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: an incorrect mount option was specified
Das ist Quatsch. Relevant wird es erst ab diesem Beitrag:
EDIT: Ich verstehe übrigens nicht, wieso es Univention immer noch nicht geschafft hat, das Join-Script 81univention-nfs-server.inst so anzupassen, daß da dieser läppische Service-Principal automatisch angelegt wird. Für DNS gehts doch auch …
ok, habe ich entfernt. Das war ja mein Frage welche Schritte aus welchem Beitrag … Aber der Rest passt?
Wenn ich wieder die “alte” Syntax in der /etc/exportfs nutze, wie sie auch im oberen Teil genannt ist:
/home gss/krb5i(rw,sync,no_subtree_check)
kommt beim mounten wieder:
mount.nfs4: access denied by server while mounting tux.gehr.lan:/home
Also gut. Das paßt:
/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "nfs-$HOSTNAME" --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs-$hostname.keytab
ktutil copy /var/lib/samba/private/nfs.keytab /etc/krb5.keytab
systemctl unmask rpc-svcgssd.service
systemctl restart rpc-svcgssd.service
Danach über die UMC an der jeweiligen Freigabe die Option sec=krb5p setzen (“Erweiterte NFS-Einstellungen”). Am Client mußt du diesbezüglich nichts machen. Das ist nur notwendig, wenn mehrere Optionen zur Auswahl stehen (z.B. sec=krb5i:krb5p).
Aber dein Problem ist wahrscheinlich, daß der Client keine Keytab hat. Das macht der Join-Assistent leider nicht. Ich habe meinen Workarround hier irgendwo publiziert …
EDIT: Da ist es:
Also für das Home nochmal zusätzlich die Freigabe im UMC erstellen. Ich würde “sec=krb5i” nutzen.
Da ist von OPSI-Paket die Rede. Da kann ich nicht ganz folgen. Wie bekomme ich den Keytab per Hand auf den Client?
Indem du es von Hand ausführst. Die Abhängigkeiten habe ich vom UCC übernommen.
Mir ist leider nicht klar wie ich das tun soll 
ich versuch’s mir mal zusammen zu reimen. Die Pakete:
python-univention-heimdal
python-support
sind ja auf dem Master installiert. Das:
hostname="$(hostname)"
kvno="$(ldapsearch -x -D "$binddn$" -w "$bindpwd$" "(&(objectClass=univentionHost)(cn=$hostname))" krb5KeyVersionNumber | sed -n 's/^krb5KeyVersionNumber: \(.*\)$/\1/p')"
schreibt ja die Versions-Nummer in die Variable “kvno”.
Das:
[ -e /etc/krb5.keytab ] && mv /etc/krb5.keytab "/etc/krb5.keytab.old_$(date +%F-%S%M%S)"
erstellt ein Backup. Kann ich diese Zeile einfach so am Master in die Shell schreiben?
Und dann rufe ich am Master:
/usr/lib/univention-heimdal/univention-create-keytab --keytab="/etc/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname$" --kvno=$kvno --password="$(cat /etc/machine.secret)"
auf um einen Dump des Keytab zu erstellen?
Und wohin wird dieser geschrieben bzw. was kopiere ich dann auch den Client?
Also ich habe am Master:
kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
[ -e /etc/krb5.keytab ] && mv /etc/krb5.keytab "/etc/krb5.keytab.old_$(date +%F-%S%M%S)"
/usr/lib/univention-heimdal/univention-create-keytab --keytab="/etc/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname$" --kvno=$kvno --password="$(cat /etc/machine.secret)"
ausgeführt. Nun müsste ich “nur noch” wissen wie ich diesen Keytab auf den Client bekomme
Kann sein, daß du die so auf dem DC Master erstellen kannst:
hostname="clienthostname"
domainname="x.y"
scp $hostname:/etc/machine.secret /tmp
kvno="$(ldapsearch -x -D "uid=Administrator,cn=users,dc=x,dc=y" -w "MeinGeheimesPasswort!11eelf" "(&(objectClass=univentionHost)(cn=$hostname))" krb5KeyVersionNumber | sed -n 's/^krb5KeyVersionNumber: \(.*\)$/\1/p')"
/usr/lib/univention-heimdal/univention-create-keytab --keytab="/tmp/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname" --kvno=$kvno --password="$(cat /tmp/machine.secret)"
scp /tmp/krb5.keytab $hostname:/etc/krb5.keytab
ssh $hostname chmod 600 /etc/krb5.keytab
rm /tmp/machine.secret
rm tmp/krb5.keytab
Da kommt:
ldap_bind: Invalid credentials (49)
Passwort für den Administrator habe ich anstelle der xxxxx korrekt eingesetzt
So:
hostname="pc001"
domainname="gehr.lan"
scp $hostname:/etc/machine.secret /tmp
kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
/usr/lib/univention-heimdal/univention-create-keytab --keytab="/tmp/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname" --kvno=$kvno --password="$(cat /tmp/machine.secret)"
scp /tmp/krb5.keytab $hostname:/etc/krb5.keytab
ssh $hostname chmod 600 /etc/krb5.keytab
rm /tmp/machine.secret
rm tmp/krb5.keytab
funktioniert zumindest der Ablauf. Ich kann jedoch nicht beurteilen ob die Variable kvno dadurch mit dem richtigen Wert gefüllt wird. Beide Systeme neu gestartet:
oot@pc001:~# mount -vvv -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: timeout set for Fri Dec 6 21:01:09 2019
mount.nfs4: trying text-based options 'sec=krb5i,vers=4.2,addr=192.168.24.5,clientaddr=192.168.24.111'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting tux.gehr.lan:/home
Ob die Keytab etwas sinnvolles enthält könntest du testen, ob du dich per Kerberos am SSH-Daemon vom Client authentifizieren kannst (muß aber manuell aktiviert werden).
Wie sieht die /etc/exports jetzt eigentlich aus?
Muss ich dazu in der /etc/ssh/sshd_config:
KerberosAuthentication yes
KerberosTicketCleanup yes
aktivieren und dann mit:
ssh -1 tux.gehr.lan
verbinden?
Die Option “-1” kenne ich nicht. Das sollte reichen sofern du ein Ticket hast:
ssh tux.gehr.lan
Läuft eigentlich der rpc-gssd.service auf dem Client:
systemctl status rpc-gssd.service
EDIT: So oder so mußt du ihn nach dem Erstellen der Keytab neustarten:
systemctl restart rpc-gssd.service
Nein, funktioniert nicht.
root@pc001:~# systemctl status rpc-gssd.service
● rpc-gssd.service - RPC security service for NFS client and server
Loaded: loaded (/lib/systemd/system/rpc-gssd.service; static; vendor preset: enabled)
Active: active (running) since Fri 2019-12-06 20:57:51 CET; 21min ago
Process: 712 ExecStart=/usr/sbin/rpc.gssd $GSSDARGS (code=exited, status=0/SUCCESS)
Main PID: 731 (rpc.gssd)
Tasks: 1 (limit: 4915)
Memory: 28.1M
CGroup: /system.slice/rpc-gssd.service
└─731 /usr/sbin/rpc.gssd
Dez 06 20:57:51 pc001 systemd[1]: Starting RPC security service for NFS client and server...
Dez 06 20:57:51 pc001 systemd[1]: Started RPC security service for NFS client and server.
Siehe EDIT
“Beitrag muss mindestens 20 Zeichen lang sein”