NFS (v3) & Kerberos + Fileaccess = Permission denied

dhaag · 25 April 2013

Hallo zusammen,

ich sitze aktuell vor dem Problem NFS mit Kerberos abzusichern und die
Freigabe (/home, FreeBSD 9.1) in einem Ubuntu (12.04) Client einzubinden.

Kerberos mit NFSv3 (Server & Client) funktionieren im Grunde bereits.

Ich exportiere mit folgender /etc/exports die Freigabe vom Server:

Code:

root@kerberos:/root # cat /etc/exports
/ -alldirs -sec=krb5:krb5i:krb5p

Seltsam ist auch wenn ich zwei Zeilen mit im NFSv3 Format eintrage, wird nur die erste beachtet.

Code:

root@kerberos:/root # cat /etc/exports
/tmp/from -sec=krb5:krb5i:krb5p
/home/dhaag -sec=krb5:krb5i:krb5p

Im FreeBSD Client:

Code:

[root@dhaag ~]# mount -t nfs -o nfsv3,sec=krb5 kerberos:/home/dhaag /mnt/from/
[tcp] kerberos:/home/dhaag: Permission denied

Hier bleibt der Befehl auch hängen, bis er mit Ctrl-C abgebrochen wird. Keine Meldung in /var/log/messages.

Mit folgendem Befehl mounte ich das ganze unter FreeBSD als Client (andere Machine != Server):

Code:

mount -t nfs -o nfsv3,sec=krb5 kerberos:/home/dhaag /mnt/from/

und unter Ubuntu:

Code:

mount.nfs kerberos:/home/dhaag /mnt/ -v -o sec=krb5p,vers=3

Ich komme dann auch wunderbar in den Mountpunkt rein (ls oder cd), sprich ich bekomme auch beide Tickets (Kerberos + NFS):
Die Domain habe ich wegen Datenschutz angepasst!

Code:

[dhaag@dhaag ~]$ kinit
dhaag@EXAMPLE.COM's Password: 
[dhaag@dhaag ~]$ klist
Credentials cache: FILE:/tmp/krb5cc_1002
        Principal: dhaag@EXAMPLE.COM

  Issued           Expires          Principal
Apr 25 08:48:36  Apr 25 18:47:27  krbtgt/EXAMPLE.COM@EXAMPLE.COM
Apr 25 08:49:10  Apr 25 18:47:27  nfs/kerberos.example.com@EXAMPLE.COM

Die uid und gid (identisch mit Server uid,gid), sowie alle Rechte sehen super aus:

Code:

[dhaag@dhaag ~]$ ls -lh /mnt/from/
total 8
drwxr-xr-x  2 dhaag  verlag   512B Apr 25 08:42 test
[dhaag@dhaag ~]$ cd /mnt/from/ 
[dhaag@dhaag /mnt/from]$

Das Problem tritt dann beim Schreibzugriff auf (FreeBSD Client):

Code:

[dhaag@dhaag /mnt/from]$ mv test test2
mv: rename test to test2: Permission denied
[dhaag@dhaag /mnt/from]$ touch foo
touch: foo: Permission denied
[dhaag@dhaag /mnt/from]$ rmdir test
rmdir: test: Permission denied
[dhaag@dhaag /mnt/from]$

Ubuntu 12.04 Client:

Code:

dhaag@dhaag2:/mnt$ mv test test2
mv: das Verschieben von »test“ nach »test2“ ist nicht möglich: Keine Berechtigung
dhaag@dhaag2:/mnt$ rmdir test
rmdir: konnte »test“ nicht entfernen: Keine Berechtigung
dhaag@dhaag2:/mnt$ touch foo
touch: »foo“ kann nicht berührt werden: Keine Berechtigung
dhaag@dhaag2:/mnt$

In den /var/log/messages vom Server und Client (beide FreeBSD) ist nichts zu sehen.
Auch auf dem Ubuntu Client kommen keine Meldungen in /var/log/syslog.

Ich bin mittlerweile etwas ratlos wo ich noch ansetzen könnte.

Wenn einer von euch den passenden Tipp hätte wäre das super.

Danke für eure Mühe/Hilfe.

dhaag

hessijens · 26 April 2013

Anmerkung: Ich habe noch kein nfsv3 mit Kerberos realisiert, nachlolgende Forschläge beziehen sich auf meine Erfahrung mit nfsv4 und Kerberos.

Was steht in /var/log/kdc.log? Hier solltest Du einen Fehler finden.

Apr 25 08:48:36 Apr 25 18:47:27 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Apr 25 08:49:10 Apr 25 18:47:27 nfs/kerberos.example.com@EXAMPLE.COM

Besagt nur, das ein ServiceTicket für den Server kerberos.example.com beim Kerberos Server angefordert und übermittelt wurde, das besagt aber noch nicht, der NFS Server auch dieses Ticket akzeptiert. Einige Unixe verwenden stattdessen auch host/kerberos.example.com, was meines Wissen für Ubuntu und FreeBSD aber nicht zutrifft.

Ist der Schüssel nfs/kerberos.example.com in der Keytab (/etc/krb5.keytab) des NFS Servers?

Ist die Zeit syncron?

Ist der GSS (gssd) Daemon gestartet?

[root@dhaag ~]# mount -t nfs -o nfsv3,sec=krb5 kerberos:/home/dhaag /mnt/from/
[tcp] kerberos:/home/dhaag: Permission denied

Versuche mal:

Code:

mount -t nfs -o nfsv3,sec=krb5 kerberos.example.com:/home/dhaag /mnt/from/

O.T.: Wenn Du lediglich "/usr/home" per nfs exportieren willst, was spricht gegen nfsv4?

EDIT: Nachtrag,völlig vergessen:
Haben die Clients einen ebenfalls einen Eintrag nfs/client.example.com@EXAMPLE.COM in Ihrer Keytab?

dhaag · 26 April 2013

Hallo, danke für deine Antwort.

hessijens schrieb:
Anmerkung: Ich habe noch kein nfsv3 mit Kerberos realisiert, nachlolgende Forschläge beziehen sich auf meine Erfahrung mit nfsv4 und Kerberos.

Was steht in /var/log/kdc.log? Hier solltest Du einen Fehler finden.

Code:

Apr 25 08:48:36 Apr 25 18:47:27 krbtgt/EXAMPLE.COM@EXAMPLE.COM Apr 25 08:49:10 Apr 25 18:47:27 nfs/kerberos.example.com@EXAMPLE.COM

Besagt nur, das ein ServiceTicket für den Server kerberos.example.com beim Kerberos Server angefordert und übermittelt wurde, das besagt aber noch nicht, der NFS Server auch dieses Ticket akzeptiert. Einige Unixe verwenden stattdessen auch host/kerberos.example.com, was meines Wissen für Ubuntu und FreeBSD aber nicht zutrifft.

Diese Datei gibt es bei mir nicht, muss ich irgendwo evtl. Logging einschalten?

hessijens schrieb:
Ist der Schüssel nfs/kerberos.example.com in der Keytab (/etc/krb5.keytab) des NFS Servers?

Kann ich das irgendwie ersehen außer mit kadmin -l ? Die Datei selbst ist ja binär.

Code:

root@kerberos:/root # kadmin -l
kadmin> list *
dhaag
default
default@example.com
kadmin/admin
kadmin/admin@example.com
kadmin/hprop
kadmin/hprop@example.com
kadmin/changepw
kadmin/changepw@example.com
changepw/kerberos
changepw/kerberos@example.com
krbtgt/EXAMPLE.COM
krbtgt/example.com@example.com
nfs/dhaag.example.com
host/dhaag.example.com
nfs/kerberos.example.com
host/kerberos.example.com

Die /etc/krb5.keytab habe ich mit folgendem Befehl exportiert und zusammen mit der /etc/krb5.conf auch auf den Client kopiert.

Code:

ext_keytab -k /etc/krb5.keytab *

hessijens schrieb:
Ist die Zeit syncron?

Auf die Problematik bin ich auch schon gestoßen, das Datum und die Uhrzeit sind gleich.

Auch der DNS Forward- und Reverse-Eintrag sind korrekt.

hessijens schrieb:
Ist der GSS (gssd) Daemon gestartet?

Der scheint auch zu laufen (Server und Client):

Code:

root@kerberos:/root # ps ax|grep gss
 609 ??  Ss     0:00.06 /usr/sbin/gssd
1046  0  R+     0:00.00 grep gss

Code:

[root@dhaag ~]# ps ax|grep gss
 1535 ??  Ss       0:00.06 /usr/sbin/gssd
78235  2  S+       0:00.00 grep gss

hessijens schrieb:
Versuche mal:

Code:

mount -t nfs -o nfsv3,sec=krb5 kerberos.example.com:/home/dhaag /mnt/from/

Gleiches Ergebnis.

hessijens schrieb:
EDIT: Nachtrag,völlig vergessen:
Haben die Clients einen ebenfalls einen Eintrag nfs/client.example.com@EXAMPLE.COM in Ihrer Keytab?

Wenn ich folgenden Befehl über kadmin -l ausführe bekomme ich folgendes:

Code:

kadmin> add nfs/dhaag.example.com@EXAMPLE.COM
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
nfs/dhaag.example.com@EXAMPLE.COM's Password: 
Verifying - nfs/dhaag.example.com@EXAMPLE.COM's Password: 
kadmin: kadm5_create_principal: Principal or policy already exists
kadmin: adding nfs/dhaag.example.com@EXAMPLE.COM: Principal or policy already exists

Wobei ich den Eintrag nicht in der Liste mit list * in kadmin -l sehe:

Code:

kadmin> list *
dhaag
default
default@example.com
thorsten
kadmin/admin
kadmin/admin@example.com
kadmin/hprop
kadmin/hprop@example.com
kadmin/changepw
kadmin/changepw@example.com
changepw/kerberos
changepw/kerberos@example.com
krbtgt/EXAMPLE.COM
krbtgt/example.com@example.com
nfs/dhaag.example.com
host/dhaag.example.com
nfs/kerberos.example.com
nfs/thorsten.example.com
host/kerberos.example.com
host/thorsten.example.com

hessijens schrieb:
O.T.: Wenn Du lediglich "/usr/home" per nfs exportieren willst, was spricht gegen nfsv4?

Im Grunde spricht nichts dagegen. Ich habe das mal versucht:

Server /etc/exports (ein Auszug):

Code:

root@kerberos:/root # cat /etc/exports 
V4: / -sec=krb5:krb5i:krb5p

Server /etc/rc.conf (ein Auszug):

Code:

mountd_flags="-r -l"
mountd_enable="YES"

nfs_client_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
nfs_reserve_port_only="NO"

kerberos5_server_enable="YES"
kadmind5_server_enable="YES"
gssd_enable="YES"

Client /etc/rc.conf (ein Auszug):

Code:

nfs_client_enable="YES"
gssd_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Wenn ich mit dem FreeBSD Client mounte blockiert der Befehl die Konsole:

Code:

mount -o sec=krb5 kerberos.rommerskirchen.roki:/tmp/from /mnt/from/

In /var/log/messages:

Code:

Apr 26 11:41:06 kerberos mountd[940]: mount request denied from 192.168.0.210 for /tmp/from

Das sieht letztlich nach dem gleichen Verhalten wie in meinem Eingangspost beschrieben aus, nur das hier eine Meldung in /var/log/messages auftaucht.

Crest · 26 April 2013

Ist der Kernel mit KGSSAPI Unterstützung übersetzt worden?

dhaag · 29 April 2013

Crest schrieb:
Ist der Kernel mit KGSSAPI Unterstützung übersetzt worden?

Ich habe zumindest das Modul geladen. Macht es einen Unterschied ob ich das kgssapi_krb5.ko oder kgssapi.ko verwende?

Code:

[root@dhaag ~]# kldstat
Id Refs Address            Size     Name
 1   45 0xffffffff80200000 12f79c0  kernel
 2    1 0xffffffff814f8000 21918    geom_mirror.ko
 3    3 0xffffffff8151a000 48528    linux.ko
 4    1 0xffffffff81563000 3230     speaker.ko
 5    1 0xffffffff81567000 c82038   nvidia.ko
 7    3 0xffffffff821f0000 59a60    vboxdrv.ko
 8    1 0xffffffff82412000 3e05     linprocfs.ko
 9    1 0xffffffff82416000 5a91     kgssapi_krb5.ko
10    1 0xffffffff8241c000 287      rc4.ko
11    2 0xffffffff8241d000 1b145    crypto.ko
12    1 0xffffffff82439000 a4d9     zlib.ko
13    1 0xffffffff82444000 a2d8     kgssapi.ko
14    2 0xffffffff8244f000 2b11     vboxnetflt.ko
15    2 0xffffffff82452000 87b2     netgraph.ko
16    1 0xffffffff8245b000 1579     ng_ether.ko
17    1 0xffffffff8245d000 3fea     vboxnetadp.ko
18    1 0xffffffff82461000 25b      linux_adobe.ko
19    1 0xffffffff82462000 ced1     geom_eli.ko

hessijens · 29 April 2013

Sorry wegen des Logfiles. In meinen /etc/krb5.conf habe ich immer folgendes verwendet

Code:

[logging]
        default = SYSLOG:INFO:USER
        kdc = FILE:/var/log/kdc.log
        kadmind = FILE:/var/log/kadmind.log

dann sind die Logs in /var/log/kdc.log, was sehr hilfreich bei Fehlern sein kann.

Das einzige was mir noch auffällt sind die Keytabs. Bitte nutze nur jeweils einen Key für host/ und nfs/ für den jeweiligen Computer.

host/kerberos.example.com@EXAMPLE.COM
nfs/kerberos.example.com@EXAMPLE.COM

für den Server kerberos.example.com und für den Client client.example.com

host/client.example.com@EXAMPLE.COM
nfs/client.example.com@EXAMPLE.COM

Ansehen und manipulieren lassen sich die Keys mit dem Programm "ktuil". Für meinen Client HONK sieht dass dann so aus:

Code:

# ktutil -k /etc/krb5.keytab list
FILE:/etc/krb5.keytab:

Vno  Type                     Principal
  5  aes256-cts-hmac-sha1-96  host/honk.example.com@EXAMPLE.COM
  5  aes128-cts-hmac-sha1-96  host/honk.example.com@EXAMPLE.COM
  5  des3-cbc-sha1            host/honk.example.com@EXAMPLE.COM
  5  arcfour-hmac-md5         host/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  aes256-cts-hmac-sha1-96  nfs/honk.example.com@EXAMPLE.COM
  [B]3[/B]  aes128-cts-hmac-sha1-96  nfs/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  des3-cbc-sha1            nfs/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  arcfour-hmac-md5         nfs/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  cifs/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  cifs/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            cifs/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         cifs/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  afp/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  afp/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            afp/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         afp/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  ipp/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  ipp/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            ipp/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         ipp/honk.example.com@EXAMPLE.COM

Ebenfalls wichtig, achte darauf, dass die Versionnummer Vno in der Keytab und in der Kerberosdatenbank gleich sind:

Code:

# kadmin -l get nfs/honk.example.com
            Principal: nfs/honk.example.com@EXAMPLE.COM
    Principal expires: never
     Password expires: never
 Last password change: 2011-11-10 09:33:03 UTC
      Max ticket life: 10 hours
   Max renewable life: 1 week
                 [B]Kvno: 3[/B]
                Mkvno: 0
Last successful login: never
    Last failed login: never
   Failed login count: 0
        Last modified: 2011-11-10 09:33:03 UTC
             Modifier: root/admin@EXAMPLE.COM
           Attributes: 
             Keytypes: aes256-cts-hmac-sha1-96(pw-salt), aes128-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt)
          PK-INIT ACL: 
              Aliases:

Crest · 29 April 2013

Wie sieht es mit dem enc_type im Kernel aus?

dhaag · 30 April 2013

hessijens schrieb:
Sorry wegen des Logfiles. In meinen /etc/krb5.conf habe ich immer folgendes verwendet

Code:

[logging] default = SYSLOG:INFO:USER kdc = FILE:/var/log/kdc.log kadmind = FILE:/var/log/kadmind.log

dann sind die Logs in /var/log/kdc.log, was sehr hilfreich bei Fehlern sein kann.

Habe das Logging eingeschaltet.
Es sieht so aus als würde hier nur etwas zur Ticketvergabe zu sehen sein (Server):

Code:

2013-04-30T09:15:56 AS-REQ dhaag@EXAMPLE.COM from IPv4:192.168.0.210 for krbtgt/EXAMPLE.COM@EXAMPLE.COM
2013-04-30T09:15:56 No preauth found, returning PREAUTH-REQUIRED -- dhaag@EXAMPLE.COM
2013-04-30T09:15:56 sending 482 bytes to IPv4:192.168.0.210
2013-04-30T09:15:56 AS-REQ dhaag@EXAMPLE.COM from IPv4:192.168.0.210 for krbtgt/EXAMPLE.COM@EXAMPLE.COM
2013-04-30T09:15:56 Client sent patypes: encrypted-timestamp
2013-04-30T09:15:56 Looking for PKINIT pa-data -- dhaag@EXAMPLE.COM
2013-04-30T09:15:56 Looking for ENC-TS pa-data -- dhaag@EXAMPLE.COM
2013-04-30T09:15:56 ENC-TS Pre-authentication succeeded -- dhaag@EXAMPLE.COM using aes256-cts-hmac-sha1-96
2013-04-30T09:15:56 Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, des-cbc-md5, des-cbc-md4, des-cbc-crc
2013-04-30T09:15:56 Using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
2013-04-30T09:15:56 AS-REQ authtime: 2013-04-30T09:15:56 starttime: unset endtime: 2013-04-30T19:16:04 renew till: unset
2013-04-30T09:15:56 sending 699 bytes to IPv4:192.168.0.210

Das Log vom Client bleibt leer.

hessijens schrieb:

Das einzige was mir noch auffällt sind die Keytabs. Bitte nutze nur jeweils einen Key für host/ und nfs/ für den jeweiligen Computer.

host/kerberos.example.com@EXAMPLE.COM
nfs/kerberos.example.com@EXAMPLE.COM

für den Server kerberos.example.com und für den Client client.example.com

host/client.example.com@EXAMPLE.COM
nfs/client.example.com@EXAMPLE.COM

Ansehen und manipulieren lassen sich die Keys mit dem Programm "ktuil". Für meinen Client HONK sieht dass dann so aus:

Code:

# ktutil -k /etc/krb5.keytab list
FILE:/etc/krb5.keytab:

Vno  Type                     Principal
  5  aes256-cts-hmac-sha1-96  host/honk.example.com@EXAMPLE.COM
  5  aes128-cts-hmac-sha1-96  host/honk.example.com@EXAMPLE.COM
  5  des3-cbc-sha1            host/honk.example.com@EXAMPLE.COM
  5  arcfour-hmac-md5         host/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  aes256-cts-hmac-sha1-96  nfs/honk.example.com@EXAMPLE.COM
  [B]3[/B]  aes128-cts-hmac-sha1-96  nfs/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  des3-cbc-sha1            nfs/honk.example.com@EXAMPLE.COM
 [B] 3[/B]  arcfour-hmac-md5         nfs/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  cifs/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  cifs/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            cifs/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         cifs/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  afp/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  afp/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            afp/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         afp/honk.example.com@EXAMPLE.COM
  3  aes256-cts-hmac-sha1-96  ipp/honk.example.com@EXAMPLE.COM
  3  aes128-cts-hmac-sha1-96  ipp/honk.example.com@EXAMPLE.COM
  3  des3-cbc-sha1            ipp/honk.example.com@EXAMPLE.COM
  3  arcfour-hmac-md5         ipp/honk.example.com@EXAMPLE.COM

Bei mir waren so viele doppelte Einträge, weil ich die keytab vor einem erneuten exportieren nicht gelöscht habe.

Hier sieht das ganze in kadmin wie folgt aus:

Code:

kadmin> list --short *
Principal                                       Expiration  PW-exp  PW-change   Max life   Max renew
dhaag                                           never       never   2013-03-19  1 day      1 week
default                                         never       never   2013-03-18  1 day      1 week
default@example.com                     never       never   2013-03-18  1 day      1 week
kadmin/admin                                    never       never   2013-03-18  1 hour     1 hour
kadmin/admin@example.com                never       never   2013-03-18  1 hour     1 hour
kadmin/hprop                                    never       never   2013-03-18  1 hour     1 hour
kadmin/hprop@example.com                never       never   2013-03-18  1 hour     1 hour
kadmin/changepw                                 never       never   2013-03-18  5 minutes  5 minutes
kadmin/changepw@example.com             never       never   2013-03-18  5 minutes  5 minutes
changepw/kerberos                               never       never   2013-03-18  1 hour     1 hour
changepw/kerberos@example.com           never       never   2013-03-18  1 hour     1 hour
krbtgt/EXAMPLE.COM                      never       never   2013-03-18  unlimited  unlimited
krbtgt/example.com@example.com  never       never   2013-03-18  unlimited  unlimited
nfs/dhaag.example.com                   never       never   2013-03-18  1 day      1 week
host/dhaag.example.com                  never       never   2013-03-18  1 day      1 week
nfs/kerberos.example.com                never       never   2013-03-18  1 day      1 week
host/kerberos.example.com               never       never   2013-03-18  1 day      1 week

Hier der Auszug mit ktutil -k /etc/krb5.keytab list

Code:

[root@kerberos ~]# ktutil -k /etc/krb5.keytab list
/etc/krb5.keytab:
Vno  Type                     Principal
  2  arcfour-hmac-md5         dhaag@EXAMPLE.COM
  1  arcfour-hmac-md5         default@EXAMPLE.COM
  1  arcfour-hmac-md5         default@example.com
  1  arcfour-hmac-md5         kadmin/admin@EXAMPLE.COM
  1  arcfour-hmac-md5         kadmin/admin@example.com
  1  arcfour-hmac-md5         kadmin/hprop@EXAMPLE.COM
  1  arcfour-hmac-md5         kadmin/hprop@example.com
  1  arcfour-hmac-md5         kadmin/changepw@EXAMPLE.COM
  1  arcfour-hmac-md5         kadmin/changepw@example.com
  1  arcfour-hmac-md5         changepw/kerberos@EXAMPLE.COM
  1  arcfour-hmac-md5         changepw/kerberos@example.com
  1  arcfour-hmac-md5         krbtgt/EXAMPLE.COM@EXAMPLE.COM
  1  arcfour-hmac-md5         krbtgt/example.com@example.com
  1  arcfour-hmac-md5         nfs/dhaag.example.com@EXAMPLE.COM
  1  arcfour-hmac-md5         host/dhaag.example.com@EXAMPLE.COM
  1  arcfour-hmac-md5         nfs/kerberos.example.com@EXAMPLE.COM
  1  arcfour-hmac-md5         host/kerberos.example.com@EXAMPLE.COM

Ich habe die Liste etwas verkürzt, alle Einträge gibt es in folgenden "Typen":

Code:

des-cbc-md5
des-cbc-md4
des-cbc-crc
aes256-cts-hmac-sha1-96
des3-cbc-sha1
arcfour-hmac-md5

Wobei ich dazu sagen muss, dass das ganze in der Einrichtungsphase "gewachsen" ist. Habe versucht die vermeintlich unwichtigen Einträge zu entfernen. Lief aber am Ende immer darauf hinaus, dass ich kein kinit mehr machen konnte bzw. kein Ticket mehr bekam.

Code:

[dhaag@dhaag ~]$ kinit 
dhaag@EXAMPLE.COM's Password: 
kinit: krb5_get_init_creds: KDC policy rejects request

hessijens schrieb:

Ebenfalls wichtig, achte darauf, dass die Versionnummer Vno in der Keytab und in der Kerberosdatenbank gleich sind:

Code:

# kadmin -l get nfs/honk.example.com
            Principal: nfs/honk.example.com@EXAMPLE.COM
    Principal expires: never
     Password expires: never
 Last password change: 2011-11-10 09:33:03 UTC
      Max ticket life: 10 hours
   Max renewable life: 1 week
                 [B]Kvno: 3[/B]
                Mkvno: 0
Last successful login: never
    Last failed login: never
   Failed login count: 0
        Last modified: 2011-11-10 09:33:03 UTC
             Modifier: root/admin@EXAMPLE.COM
           Attributes: 
             Keytypes: aes256-cts-hmac-sha1-96(pw-salt), aes128-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt)
          PK-INIT ACL: 
              Aliases:

Die Kvno ist bei allen Einträgen gleich. Ich wüsste auch nicht wo ich diese explizit setze bzw. beeinflussen kann, die Stimmen direkt überein. Hier zB für dhaag@EXAMPLE.COM

Code:

[root@kerberos ~]# kadmin -l get dhaag@EXAMPLE.COM
            Principal: dhaag@EXAMPLE.COM
    Principal expires: never
     Password expires: never
 Last password change: 2013-03-19 13:22:44 UTC
      Max ticket life: 1 day
   Max renewable life: 1 week
                 Kvno: 2
                Mkvno: 0
Last successful login: never
    Last failed login: never
   Failed login count: 0
        Last modified: 2013-03-19 13:22:44 UTC
             Modifier: kadmin/admin@EXAMPLE.COM
           Attributes: 
             Keytypes: des-cbc-md5(pw-salt), des-cbc-md4(pw-salt), des-cbc-crc(pw-salt), aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt)
          PK-INIT ACL: 
              Aliases:

Zu NFSv4/v3 hatte mir eine Kollege gesagt, dass v4 vom User gemountet wird. Ich brauche da letztlich einen fertig mount (fstab) in den der User Zugriff bekommt (Kerberos) ohne das der User mehr machen muss als die am Hauptlogin zu authentifizieren.
Letztlich funktioniert NFSv4 hier noch überhaupt nicht. NFSv3 kann ich zumindest mounten.

NFS (v3) & Kerberos + Fileaccess = Permission denied

dhaag

Member

hessijens

Well-Known Member

dhaag

Member

Crest

rm -rf /*

dhaag

Member

hessijens

Well-Known Member

Crest

rm -rf /*

dhaag

Member

Wir schützen deine Privatsphäre