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

Jason D. McCormick jason at devrandom.org
Wed Jan 2 14:13:44 EST 2008


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
jason at AD.EXAMPLE.COM password and successfully acquire a TGT.  I have
stashed the principals host/nfs.loc1.example.com at AD.EXAMPLE.COM and
nfs/nfs.loc1.example.com at 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



More information about the Kerberos mailing list