Jason D. McCormick wrote:
> 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 = {


This may not be a problem but, shouldn't the above be AD.EXAMPLE.COM?
Otherwise, DNS lookup is being use to find the KDCs. T

> 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
> jason@AD.EXAMPLE.COM 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:
>


Richard Silverman asked how did you add the principals to AD?
If you used the same AD account for both principals, they will use the
same password to generate the key, and will use the same kvno.

Thus your first problem might be the kvno is not found, in the keytab.


> (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.


Are 55 and 59 the length of the message as seen by strace or an error code?
I assume you ran the gss-server as root, so it could access/etc/krb5.keytab

> 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?


The uses of a single AD account for two principals with the same pasword
is a difference.

>
> Thanks.
>
> - Jason
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>


--

Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444