GSSAPI on Linux using Windows AD Servers as KDCs - Errors about KeytabEntries

Hello,

I'm attempting to get NFSv4 working using Krb5/GSS credentials. I've
successfully set this up a number of times using MIT KDCs. However for
this implementation I have to use existing MS Windows Active Directory
(2003R2) servers as the KDCs (ad0.loc1.example.com,
ad1.loc1.example.com). I've distilled my problem down to the GSSAPI
message "GSS-API error accepting context: Key table entry not found".
The keytab entry does, however, exist and works just fine if I do a
'kinit -k'. I've been testing configuration using the
gss-server/gcc-client tools and can reproduce the exact same behavior
(i.e. this isn't something in the NFSv4 code).

Here's the setup - There are two Windows AD servers providing a Kerberos
realm (and Windows domain) named AD.EXAMPLE.COM. The Linux hosts I'm
trying to use as clients and servers are named nfs.loc1.example.com and
client.loc1.example.com. This is a multi-site Active Directory forest
and my "location" is the domain loc1.example.com. Within krb5.conf I
have the following defined:

[libdefaults]
default_realm = AD.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
default_tkt_enctypes = des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des-cbc-md5 des-cbc-crc

[realms]
EXAMPLE.COM = {
kdc = ad0.loc1.example.com:88
kdc = ad1.loc1.example.com:88
admin_server = ad0.loc1.example.com:749
}

[domain_realm]
.example.com = AD.EXAMPLE.COM
example.com = AD.EXAMPLE.COM
.loc1.example.com = AD.EXAMPLE.COM
loc1.example.com = AD.EXAMPLE.COM

If I perform 'kinit jason' from the prompt, I get prompted for my
[email]jason@AD.EXAMPLE.COM[/email] password and successfully acquire a TGT. I have
stashed the principals host/nfs.loc1.example.com@AD.EXAMPLE.COM and
nfs/nfs.loc1.example.com@AD.EXAMPLE.COM in /etc/krb5.keytab. I can
successfully acquire a TGT when performing 'kinit -k' as one of these
principals. However if I setup a test GSS setup using gss-server and
gss-client I encounter the aforementioned keytab error. I am doing the
following:

(server)
$ gss-server -port 10000 -once -verbose nfs

(client)
$ gss-client -port 10000 nfs.loc1.example.com nfs hi

The client reports:

GSS-API error initializing context: Miscellaneous failure
GSS-API error initializing context: Generic error (see e-text)

If I run the server in an strace, it write()s back to the client

55GSS-API error accepting context: Miscellaneous Failure
59GSS-API error accepting context: Key table entry not found

The first message reports a return of 55 and the second reports 59. I
was able to dig around in rpc.svcgssd's logging and found a similar
error condition there about key table entries. If I perform a similar
test using at another site using MIT KDCs, gss-server/gss-client works
as I would expect. Am I missing some subtlety in the configuration
that's unique to using Windows as the KDC and how the realms and DNS
names are?

Thanks.

- Jason

>>>>> "JDC" == Jason D McCormick <jason@devrandom.org> writes:

JDC> Hello, I'm attempting to get NFSv4 working using Krb5/GSS
JDC> credentials. I've successfully set this up a number of times
JDC> using MIT KDCs. However for this implementation I have to use
JDC> existing MS Windows Active Directory (2003R2) servers as the KDCs
JDC> (ad0.loc1.example.com, ad1.loc1.example.com). I've distilled my
JDC> problem down to the GSSAPI message "GSS-API error accepting
JDC> context: Key table entry not found". The keytab entry does,
JDC> however, exist and works just fine if I do a 'kinit -k'. I've
JDC> been testing configuration using the gss-server/gcc-client tools
JDC> and can reproduce the exact same behavior (i.e. this isn't
JDC> something in the NFSv4 code).

JDC> Here's the setup - There are two Windows AD servers providing a
JDC> Kerberos realm (and Windows domain) named AD.EXAMPLE.COM. The
JDC> Linux hosts I'm trying to use as clients and servers are named
JDC> nfs.loc1.example.com and client.loc1.example.com. This is a
JDC> multi-site Active Directory forest and my "location" is the
JDC> domain loc1.example.com. Within krb5.conf I have the following
JDC> defined:

JDC> [libdefaults] default_realm = AD.EXAMPLE.COM dns_lookup_realm =
JDC> true dns_lookup_kdc = true default_tkt_enctypes = des-cbc-md5
JDC> des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc

JDC> [realms] EXAMPLE.COM = { kdc = ad0.loc1.example.com:88 kdc =
JDC> ad1.loc1.example.com:88 admin_server = ad0.loc1.example.com:749 }

JDC> [domain_realm] .example.com = AD.EXAMPLE.COM example.com =
JDC> AD.EXAMPLE.COM .loc1.example.com = AD.EXAMPLE.COM
JDC> loc1.example.com = AD.EXAMPLE.COM

JDC> If I perform 'kinit jason' from the prompt, I get prompted for my
JDC> [email]jason@AD.EXAMPLE.COM[/email] password and successfully acquire a TGT. I
JDC> have stashed the principals
JDC> host/nfs.loc1.example.com@AD.EXAMPLE.COM and
JDC> nfs/nfs.loc1.example.com@AD.EXAMPLE.COM in /etc/krb5.keytab. I
JDC> can successfully acquire a TGT when performing 'kinit -k' as one
JDC> of these principals. However if I setup a test GSS setup using
JDC> gss-server and gss-client I encounter the aforementioned keytab
JDC> error. I am doing the following:

JDC> (server) $ gss-server -port 10000 -once -verbose nfs

JDC> (client) $ gss-client -port 10000 nfs.loc1.example.com nfs hi

JDC> The client reports:

JDC> GSS-API error initializing context: Miscellaneous failure
JDC> GSS-API error initializing context: Generic error (see e-text)

JDC> If I run the server in an strace, it write()s back to the client

JDC> 55GSS-API error accepting context: Miscellaneous Failure
JDC> 59GSS-API error accepting context: Key table entry not found

JDC> The first message reports a return of 55 and the second reports
JDC> 59. I was able to dig around in rpc.svcgssd's logging and found
JDC> a similar error condition there about key table entries. If I
JDC> perform a similar test using at another site using MIT KDCs,
JDC> gss-server/gss-client works as I would expect. Am I missing some
JDC> subtlety in the configuration that's unique to using Windows as
JDC> the KDC and how the realms and DNS names are?

JDC> Thanks.

JDC> - Jason

A couple of questions:

1) What are the tkt and skey types on the tickets the client gets? The
etype of the service credentials?

2) I assume you generated the service keytabs from AD using ktpass.exe?
If so, exactly what command did you use?

Not sure if it's relevant, but Windows defaults to using the rc4-hmac
keys..

--
Richard Silverman
[email]res@qoxp.net[/email]

Richard E. Silverman wrote:
[color=blue]
> A couple of questions:
>
> 1) What are the tkt and skey types on the tickets the client gets? The
> etype of the service credentials?[/color]

klist -e reports:

Etype (skey, tkt): DES cbc mode with RSA-MD5, ArcFour with HMAC/md5

for the TGT. The keytab lists the key tytpe as "DES cbc mode with CRC-32".
[color=blue]
> 2) I assume you generated the service keytabs from AD using ktpass.exe?
> If so, exactly what command did you use?[/color]

Yes, I did. I don't have the exact command handy because getting this
working has been an iterative process. I definitely set the key type to
be des-cbc-crc with ktpass. It would have been something like:

ktpass -princ nfs/nfs1.loc1.example.com@AD.EXAMPLE.COM -mapuser
AD\nfs-nfs1 +rndPass -crypto DES-CBC-CRC -out nfs1.keytab

I've also tried it with and without -ptype KRB5_NT_SRV_HST.

- Jason

Jason D. McCormick wrote:[color=blue]
> Richard E. Silverman wrote:
>[color=green]
>> A couple of questions:
>>
>> 1) What are the tkt and skey types on the tickets the client gets? The
>> etype of the service credentials?[/color]
>
> klist -e reports:[/color]

(Normally Kerberos does not save a ticket in tha cache if it does not work
so you may not see the ticket for the service. Wireshark can show a lot more.)
[color=blue]
>
> Etype (skey, tkt): DES cbc mode with RSA-MD5, ArcFour with HMAC/md5
>
> for the TGT. The keytab lists the key tytpe as "DES cbc mode with CRC-32".
>[color=green]
>> 2) I assume you generated the service keytabs from AD using ktpass.exe?
>> If so, exactly what command did you use?[/color]
>
> Yes, I did. I don't have the exact command handy because getting this
> working has been an iterative process. I definitely set the key type to
> be des-cbc-crc with ktpass. It would have been something like:
>
> ktpass -princ nfs/nfs1.loc1.example.com@AD.EXAMPLE.COM -mapuser
> AD\nfs-nfs1 +rndPass -crypto DES-CBC-CRC -out nfs1.keytab[/color]

The problem might be that on the AD account the UserAccountControl flag
does not have the USE_DES_KEY_ONLY 0x200000 set, So AD is returning an
ArcFour ticket, which is not in the keytab. ktpass has a /DESOnly option
to set this.

See kb 305144 too.

Why are you using DES? All the newer Kerberos can use ArcFour. So try
ktpass witout the crypto option.
[color=blue]
>
> I've also tried it with and without -ptype KRB5_NT_SRV_HST.
>
> - Jason
> ________________________________________________
> Kerberos mailing list [email]Kerberos@mit.edu[/email]
> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>
>[/color]

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Douglas E. Engert wrote:
[color=blue]
> The problem might be that on the AD account the UserAccountControl flag
> does not have the USE_DES_KEY_ONLY 0x200000 set, So AD is returning an
> ArcFour ticket, which is not in the keytab. ktpass has a /DESOnly option
> to set this.
>
> See kb 305144 too.[/color]

I'll give that a shot, thanks.
[color=blue]
> Why are you using DES? All the newer Kerberos can use ArcFour. So try
> ktpass witout the crypto option.[/color]

Do you know if the Linux NFSv4 stuff can use ArcFour? I've only been
able to find (older - circa '06) docs that state the only working type
is des-cbc-crc.

- Jason

Jason D. McCormick wrote:[color=blue]
> Douglas E. Engert wrote:
>[color=green]
>> The problem might be that on the AD account the UserAccountControl flag
>> does not have the USE_DES_KEY_ONLY 0x200000 set, So AD is returning an
>> ArcFour ticket, which is not in the keytab. ktpass has a /DESOnly option
>> to set this.
>>
>> See kb 305144 too.[/color]
>
> I'll give that a shot, thanks.
>[color=green]
>> Why are you using DES? All the newer Kerberos can use ArcFour. So try
>> ktpass witout the crypto option.[/color]
>
> Do you know if the Linux NFSv4 stuff can use ArcFour? I've only been
> able to find (older - circa '06) docs that state the only working type
> is des-cbc-crc.[/color]

Don't know, but a lot of the developers on the [email]nfsv4@ietf.org[/email] list are also
on the Kerberos list.
[color=blue]
>
> - Jason
>
>
>[/color]

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

Douglas E. Engert wrote:[color=blue]
> The problem might be that on the AD account the UserAccountControl flag
> does not have the USE_DES_KEY_ONLY 0x200000 set, So AD is returning an
> ArcFour ticket, which is not in the keytab. ktpass has a /DESOnly option
> to set this.
>
> See kb 305144 too.[/color]

This is EXACTLY what I needed. Everything works now. Thanks to
everyone for the help.

- Jason

Jason,

BTW I tested with my Linux MIT kdc and used an RC4-HMAC key for nfs/fqdn in
the keytab only and it seems to work too.

I see: Etype (skey, tkt): DES cbc mode with CRC-32, ArcFour with HMAC/md5

So I would expect to work with a Windows kdc and handling RC4 is easier as
you don't need to worry about the DES flag and salt.

Markus

root@Opensuse:# mount -t nfs4 -o rw,sec=krb5 opensuse.suse.home:/
/suse_work

markus@Opensuse:~> ls /suse_work/
ls: cannot access /suse_work/: Permission denied
markus@Opensuse:~> kinit
Password for [email]markus@SUSE.HOME[/email]:
markus@Opensuse:~> ls /suse_work/
src
markus@Opensuse:~> klist -e
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email]markus@SUSE.HOME[/email]

Valid starting Expires Service principal
01/07/08 20:37:05 01/08/08 06:37:05 krbtgt/SUSE.HOME@SUSE.HOME
renew until 01/08/08 20:37:05, Etype (skey, tkt): ArcFour with
HMAC/md5, ArcFour with HMAC/md5
01/07/08 20:37:11 01/08/08 06:37:05 nfs/opensuse.suse.home@SUSE.HOME
renew until 01/08/08 20:37:05, Etype (skey, tkt): DES cbc mode with
CRC-32, ArcFour with HMAC/md5


markus@Opensuse:~> sudo klist -ekt
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 01/07/08 20:25:41 host/opensuse.suse.home@SUSE.HOME (ArcFour with
HMAC/md5)
6 01/07/08 20:25:41 nfs/opensuse.suse.home@SUSE.HOME (ArcFour with
HMAC/md5)



"Jason D. McCormick" <jason@devrandom.org> wrote in message
news:478274B5.3030700@devrandom.org...[color=blue]
> Douglas E. Engert wrote:[color=green]
>> The problem might be that on the AD account the UserAccountControl flag
>> does not have the USE_DES_KEY_ONLY 0x200000 set, So AD is returning an
>> ArcFour ticket, which is not in the keytab. ktpass has a /DESOnly option
>> to set this.
>>
>> See kb 305144 too.[/color]
>
> This is EXACTLY what I needed. Everything works now. Thanks to
> everyone for the help.
>
> - Jason
> ________________________________________________
> Kerberos mailing list [email]Kerberos@mit.edu[/email]
> [url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]
>[/color]