trouble using kerberos between linux client and server

Discussion:

Guillaume Rousse

2010-04-22 06:15:21 UTC

Hello list.

I've been using kerberized NFS with NetApp filer without
kerberos-specific troubles so far. However, I'm currently trying to
setup a Linux kerberized server for the first time, and I'm facing
Kerberos issues.

First, I had troubles with the des-cbc-crc enctype limitation. When the
NFS server is a Netapp filer, I don't need to take special care for the
client keytab file content, everything works as expected. However, when
the NFS server is a linux box, if the client keytab contains all
available enctypes for the client principal, the client always request
an unsupported enctype for the TGS:

2010-04-21T23:11:46 TGS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for nfs/loubianka.zarb.home at ZARB.HOME [canonicalize]
2010-04-21T23:11:46 Server (nfs/loubianka.zarb.home at ZARB.HOME) has no
support for etypes
2010-04-21T23:11:46 Failed building TGS-REP to IPv4:192.168.0.7
2010-04-21T23:11:46 sending 106 bytes to IPv4:192.168.0.7

I guess this is because the NetApp filer advertise itself as not
supporting anything else as DES, whereas the Linux server advertise
itself as supporting AES. Am I correct ?

Second, even when restricting client keytab to des-cbc-crc enctype, I
have an unexpected failure getting a TGS. On client side, I have the
following error:
[root at beria ~]# mount -t nfs -o sec=krb5 loubianka:/ /mnt/filer/
mount.nfs: access denied by server while mounting loubianka:/

From KDC logs, it appears than the TGS-REQ is only submitted once,

without pre-authentication, making it fails, without the client retrying
it as expected:

2010-04-21T23:27:43 AS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for krbtgt/ZARB.HOME at ZARB.HOME
2010-04-21T23:27:43 No preauth found, returning PREAUTH-REQUIRED --
nfs/beria.zarb.home at ZARB.HOME
2010-04-21T23:27:43 sending 285 bytes to IPv4:192.168.0.7

The client logs seems to corroborate this hypothesis:

Apr 21 23:42:33 beria rpc.gssd[8727]: Full hostname for
'loubianka.zarb.home' is 'loubianka.zarb.home'
Apr 21 23:42:33 beria rpc.gssd[8727]: Full hostname for
'beria.zarb.home' is 'beria.zarb.home'
Apr 21 23:42:33 beria rpc.gssd[8727]: Key table entry not found while
getting keytab entry for 'root/beria.zarb.home at ZARB.HOME'
Apr 21 23:42:33 beria rpc.gssd[8727]: Success getting keytab entry for
'nfs/beria.zarb.home at ZARB.HOME'
Apr 21 23:42:34 beria rpc.gssd[8727]: WARNING: Key table entry not found
while getting initial ticket for principal
'nfs/beria.zarb.home at ZARB.HOME' using keytab 'FILE:/etc/krb5.keytab'
Apr 21 23:42:34 beria rpc.gssd[8727]: ERROR: No credentials found for
connection to server loubianka.zarb.home
Apr 21 23:42:34 beria rpc.gssd[8727]: doing error downcall
Apr 21 23:42:34 beria kernel: : nfs4_get_root: getroot error = 13

I couldn't exclude this specific principal from pre-auth requirement for
further testing.

Testing without krb5 security works OK. Other Kerberozed applications
(OpenLDAP, Apache) works OK. My KDC is heimdal 1.3.2, but nfs-utils is
linked against MIT kerberos 1.6.3. All the machines have
'allow_weak_crypto = true' in their configuration.

What's going on there ?

--
BOFH excuse #408:

Computers under water due to SYN flooding.

J. Bruce Fields

2010-04-22 16:09:26 UTC

Permalink

Post by Guillaume Rousse
Hello list.
I've been using kerberized NFS with NetApp filer without
kerberos-specific troubles so far. However, I'm currently trying to
setup a Linux kerberized server for the first time, and I'm facing
Kerberos issues.
First, I had troubles with the des-cbc-crc enctype limitation. When the
NFS server is a Netapp filer, I don't need to take special care for the
client keytab file content, everything works as expected. However, when
the NFS server is a linux box, if the client keytab contains all
available enctypes for the client principal, the client always request
2010-04-21T23:11:46 TGS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for nfs/loubianka.zarb.home at ZARB.HOME [canonicalize]
2010-04-21T23:11:46 Server (nfs/loubianka.zarb.home at ZARB.HOME) has no
support for etypes
2010-04-21T23:11:46 Failed building TGS-REP to IPv4:192.168.0.7
2010-04-21T23:11:46 sending 106 bytes to IPv4:192.168.0.7
I guess this is because the NetApp filer advertise itself as not
supporting anything else as DES, whereas the Linux server advertise
itself as supporting AES. Am I correct ?
Second, even when restricting client keytab to des-cbc-crc enctype, I
have an unexpected failure getting a TGS. On client side, I have the
[root at beria ~]# mount -t nfs -o sec=krb5 loubianka:/ /mnt/filer/
mount.nfs: access denied by server while mounting loubianka:/

From KDC logs, it appears than the TGS-REQ is only submitted once,

without pre-authentication, making it fails, without the client retrying
2010-04-21T23:27:43 AS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for krbtgt/ZARB.HOME at ZARB.HOME
2010-04-21T23:27:43 No preauth found, returning PREAUTH-REQUIRED --
nfs/beria.zarb.home at ZARB.HOME
2010-04-21T23:27:43 sending 285 bytes to IPv4:192.168.0.7

Is it possible you just need to modify the client principal with

modprinc +requires_preauth nfs/principal

?

On the surface both problems look like they should be due to keytab
differences rather than server implementation differences, but I'm not
enough of a kerberos export, unfortunately.

--b.

Post by Guillaume Rousse
Apr 21 23:42:33 beria rpc.gssd[8727]: Full hostname for
'loubianka.zarb.home' is 'loubianka.zarb.home'
Apr 21 23:42:33 beria rpc.gssd[8727]: Full hostname for
'beria.zarb.home' is 'beria.zarb.home'
Apr 21 23:42:33 beria rpc.gssd[8727]: Key table entry not found while
getting keytab entry for 'root/beria.zarb.home at ZARB.HOME'
Apr 21 23:42:33 beria rpc.gssd[8727]: Success getting keytab entry for
'nfs/beria.zarb.home at ZARB.HOME'
Apr 21 23:42:34 beria rpc.gssd[8727]: WARNING: Key table entry not found
while getting initial ticket for principal
'nfs/beria.zarb.home at ZARB.HOME' using keytab 'FILE:/etc/krb5.keytab'
Apr 21 23:42:34 beria rpc.gssd[8727]: ERROR: No credentials found for
connection to server loubianka.zarb.home
Apr 21 23:42:34 beria rpc.gssd[8727]: doing error downcall
Apr 21 23:42:34 beria kernel: : nfs4_get_root: getroot error = 13
I couldn't exclude this specific principal from pre-auth requirement for
further testing.
Testing without krb5 security works OK. Other Kerberozed applications
(OpenLDAP, Apache) works OK. My KDC is heimdal 1.3.2, but nfs-utils is
linked against MIT kerberos 1.6.3. All the machines have
'allow_weak_crypto = true' in their configuration.
What's going on there ?
--
Computers under water due to SYN flooding.
_______________________________________________
NFSv4 mailing list
NFSv4 at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Guillaume Rousse

2010-04-23 20:40:08 UTC

Permalink

Post by J. Bruce Fields
Is it possible you just need to modify the client principal with
modprinc +requires_preauth nfs/principal
?

No idea. I couldn't make this single principal usable without
pre-authentication, so I disabled preauth globally (this is just a demo
environment...). The pre-auth issue disapears, the server apparently
send a correct answer, but the problem is still there...

KDC logs:
2010-04-23T22:31:52 AS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for krbtgt/ZARB.HOME at ZARB.HOME
2010-04-23T22:31:52 Client supported enctypes: aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc,
des-cbc-md5, des-cbc-md4, using
aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
2010-04-23T22:31:52 Requested flags: renewable-ok
2010-04-23T22:31:52 AS-REQ authtime: 2010-04-23T22:31:52 starttime:
unset endtime: 2010-04-24T22:31:52 renew till: unset
2010-04-23T22:31:52 sending 673 bytes to IPv4:192.168.0.7

Server logs:
Apr 23 22:31:52 beria rpc.gssd[3543]: Success getting keytab entry for
'nfs/beria.zarb.home at ZARB.HOME'
Apr 23 22:31:52 beria rpc.gssd[3543]: WARNING: Key table entry not found
while getting initial ticket for principal
'nfs/beria.zarb.home at ZARB.HOME' using keytab 'FILE:/etc/krb5.keytab'
Apr 23 22:31:52 beria rpc.gssd[3543]: ERROR: No credentials found for
connection to server loubianka.zarb.home
Apr 23 22:31:52 beria rpc.gssd[3543]: doing error downcall
Apr 23 22:31:52 beria rpc.gssd[3543]: destroying client
/var/lib/nfs/rpc_pipefs/nfs/clnt19
Apr 23 22:31:52 beria rpc.gssd[3543]: destroying client
/var/lib/nfs/rpc_pipefs/nfs/clnt18

Post by J. Bruce Fields
On the surface both problems look like they should be due to keytab
differences rather than server implementation differences, but I'm not
enough of a kerberos export, unfortunately.

My client tools (kadmin, notably, used to generate the keytab) also come
from heimdal suite, indeed.

--
BOFH excuse #6:

global warming

Kevin Coffman

2010-04-22 17:18:10 UTC

Permalink

On Thu, Apr 22, 2010 at 2:15 AM, Guillaume Rousse

Post by Guillaume Rousse
Hello list.
I've been using kerberized NFS with NetApp filer without
kerberos-specific troubles so far. However, I'm currently trying to
setup a Linux kerberized server for the first time, and I'm facing
Kerberos issues.
First, I had troubles with the des-cbc-crc enctype limitation. When the
NFS server is a Netapp filer, I don't need to take special care for the
client keytab file content, everything works as expected. However, when
the NFS server is a linux box, if the client keytab contains all
available enctypes for the client principal, the client always request
2010-04-21T23:11:46 TGS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for nfs/loubianka.zarb.home at ZARB.HOME [canonicalize]
2010-04-21T23:11:46 Server (nfs/loubianka.zarb.home at ZARB.HOME) has no
support for etypes
2010-04-21T23:11:46 Failed building TGS-REP to IPv4:192.168.0.7
2010-04-21T23:11:46 sending 106 bytes to IPv4:192.168.0.7
I guess this is because the NetApp filer advertise itself as not
supporting anything else as DES, whereas the Linux server advertise
itself as supporting AES. Am I correct ?
Second, even when restricting client keytab to des-cbc-crc enctype, I
have an unexpected failure getting a TGS. On client side, I have the
[root at beria ~]# mount ?-t nfs -o sec=krb5 loubianka:/ /mnt/filer/
mount.nfs: access denied by server while mounting loubianka:/
From KDC logs, it appears than the TGS-REQ is only submitted once,
without pre-authentication, making it fails, without the client retrying
2010-04-21T23:27:43 AS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for krbtgt/ZARB.HOME at ZARB.HOME
2010-04-21T23:27:43 No preauth found, returning PREAUTH-REQUIRED --
nfs/beria.zarb.home at ZARB.HOME
2010-04-21T23:27:43 sending 285 bytes to IPv4:192.168.0.7

It is up to the MIT client code to take this error and re-issue the
request with proper pre-auth information. In the error return, the
KDC should be returning a list of suitable pre-authentication methods.
If it doesn't, I don't think the client will retry.

What does "klist -ekt" produce on the client?

Guillaume Rousse

2010-04-23 20:25:55 UTC

Permalink

Post by Kevin Coffman
It is up to the MIT client code to take this error and re-issue the
request with proper pre-auth information. In the error return, the
KDC should be returning a list of suitable pre-authentication methods.
If it doesn't, I don't think the client will retry.

I'm attaching server answer.

Post by Kevin Coffman
From wireshark analysis, the message contains: 'need to use

PA-ENC-TIMESTAMP/PA-PK-AS-REQ', in e-text section, which seems to be OK.
However, one of the padata item in the e-data section has a reference to
AES256, whereas the client only has a DES key for this principal...
[..]

Post by Kevin Coffman
What does "klist -ekt" produce on the client?

[root at botzaris guillaume]# klist -ekt
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- -----------------
--------------------------------------------------------
1 04/21/10 23:23:53 nfs/beria.zarb.home at ZARB.HOME (DES cbc mode with
CRC-32)
--
BOFH excuse #28:

CPU radiator broken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out
Type: application/octet-stream
Size: 607 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100423/0e01888d/attachment.obj

Kevin Coffman

2010-04-25 02:40:58 UTC

Permalink

On Fri, Apr 23, 2010 at 4:25 PM, Guillaume Rousse

Post by Guillaume Rousse

Post by Kevin Coffman
It is up to the MIT client code to take this error and re-issue the
request with proper pre-auth information. ?In the error return, the
KDC should be returning a list of suitable pre-authentication methods.
?If it doesn't, I don't think the client will retry.

I'm attaching server answer.

And in response the client just gives up?

Post by Guillaume Rousse
From wireshark analysis, the message contains: 'need to use
PA-ENC-TIMESTAMP/PA-PK-AS-REQ', in e-text section, which seems to be OK.
However, one of the padata item in the e-data section has a reference to
AES256, whereas the client only has a DES key for this principal...
[..]

For the AS-REQ, the client *should* support AES unless you've disabled
that via krb5.conf. From the enctypes in the request, it looks like
you haven't.

K.C.

Guillaume Rousse

2010-04-25 23:42:51 UTC

Permalink

Post by Kevin Coffman
On Fri, Apr 23, 2010 at 4:25 PM, Guillaume Rousse

Post by Guillaume Rousse

I'm attaching server answer.

And in response the client just gives up?

Exactly. I've tried to get additional informations, through -vvvv
option, or through gdb, without luck.

However, the fact than even when pre-authentication is disabled, I still
get a an error make me think the problem isn't really there. I'll first
try to update the MIT krb5 package, to test with an up-to-date version.

--
BOFH excuse #26:

first Saturday after first full moon in Winter

Guillaume Rousse

2010-04-26 21:56:42 UTC

Permalink

Post by Guillaume Rousse
However, the fact than even when pre-authentication is disabled, I still
get a an error make me think the problem isn't really there. I'll first
try to update the MIT krb5 package, to test with an up-to-date version.

Indeed.

Here is a new capture of client-server dialog, when pre-authentication
is disabled. The 'unknown error code 0x4252415a' seems to means there is
something wrong on the server side.

According to KDC logs, everything is OK, tough:
2010-04-26T23:48:37 AS-REQ nfs/beria.zarb.home at ZARB.HOME from
IPv4:192.168.0.7 for krbtgt/ZARB.HOME at ZARB.HOME
2010-04-26T23:48:37 Client sent patypes: 149
2010-04-26T23:48:37 Looking for PKINIT pa-data --
nfs/beria.zarb.home at ZARB.HOME
2010-04-26T23:48:37 Looking for ENC-TS pa-data --
nfs/beria.zarb.home at ZARB.HOME
2010-04-26T23:48:37 Client supported enctypes: aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc,
des-cbc-md5, des-cbc-md4, using
aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
2010-04-26T23:48:37 Requested flags: renewable-ok
2010-04-26T23:48:37 AS-REQ authtime: 2010-04-26T23:48:37 starttime:
unset endtime: 2010-04-27T23:48:37 renew till: unset
2010-04-26T23:48:37 sending 673 bytes to IPv4:192.168.0.7

I'm CCing heimdal-discuss. Full details available at
http://linux-nfs.org/pipermail/nfsv4/2010-April/012312.html

Software versions:
- heimdal 1.3.1
- nfs-utils 1.2.2, linked against MIT krb5 1.8.1
--
BOFH excuse #49:

Bogon emissions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out
Type: application/octet-stream
Size: 1011 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100426/a834ef24/attachment.obj

Guillaume Rousse

2010-04-28 22:00:10 UTC

Permalink

Post by Guillaume Rousse

Indeed.
Here is a new capture of client-server dialog, when pre-authentication
is disabled. The 'unknown error code 0x4252415a' seems to means there is
something wrong on the server side.

I just noticed this 'unknown code' was actually due to bad parsing of
PA-PW-SALT section, as the ASCII content of underlying data match
principal name... I don't understand why does the KDC send PA-PW-SALT
whereas pre-authentication is disabled.

Anyway, it seems this erroneous KDC reply is due to the way I generate
my principal keys.

Without specific configuration, principals are created with 3 enctypes:
aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
arcfour-hmac-md5(pw-salt)

I manually add des-cbc-crc thereafter:
add_enctype -r nfs/beria.zarb.home des-cbc-crc

The resulting principal looks like:
Keytypes: aes256-cts-hmac-sha1-96(pw-salt),
des3-cbc-sha1(pw-salt), arcfour-hmac-md5(pw-salt), des-cbc-crc(pw-salt())
-> notice the "pw-salt()" for des-cbc-crc, whereas other enctypes have
"pw-salt" only

I just changed the configuration to add des-cbc-crc by default, with the
following section in krb5.conf:
[kadmin]
default_keys = des-cbc-crc:pw-salt aes256-cts-hmac-sha1-96:pw-salt
des3-cbc-sha1:pw-salt arcfour-hmac-md5:pw-salt

Creating principal now automatically add des-cbc-crc, with a nicer
output format:
Keytypes: des-cbc-crc(pw-salt),
aes256-cts-hmac-sha1-96(pw-salt), des3-cbc-sha1(pw-salt),
arcfour-hmac-md5(pw-salt)
-> des-cbc-crc now has exactly the same salt string as other enctypes

The KDC answer is much better in this case, no unknown error code (see
capture included).

So, is this a bug in enctypte handling, or is the whole idea of adding a
new enctype, with a random password, after principal creation wrong (I'm
a bit surprised kvno isn't incremented in this last case) ?

NFS still doesn't work, but that seems to be a different issue.
--
BOFH excuse #256:

You need to install an RTFM interface.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-preauth
Type: application/octet-stream
Size: 969 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100429/fa434f9a/attachment.obj

Henry B. Hotz

2010-04-28 23:08:15 UTC

Permalink

Post by Guillaume Rousse
So, is this a bug in enctypte handling, or is the whole idea of adding a
new enctype, with a random password, after principal creation wrong (I'm
a bit surprised kvno isn't incremented in this last case) ?

Perhaps "wrong", but at least undefined. I suspect the behavior when the salt is different for different enctypes is not supported for all situations. For example, the KDC can't know what salt to give the client unless it knows which enctype is going to be used.

As you noted, the "-r" creates keys with no salt at all, while the pre-existing ones have the standard salt.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

Guillaume Rousse

2010-04-29 07:47:39 UTC

Permalink

Post by Henry B. Hotz

So, 'cpw -r' has a different behaviour than 'add -r' ?
--
BOFH excuse #264:

Your modem doesn't speak English.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4251 bytes
Desc: S/MIME Cryptographic Signature
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20100429/59f121b1/attachment.bin

Continue reading on narkive:

Search results for 'trouble using kerberos between linux client and server' (Questions and Answers)

replies

samba server?

started 2007-04-06 11:34:55 UTC

computer networking