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

[Richard E. Silverman]

>>>>> "JDC" == Jason D McCormick <jason at 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> jason at AD.EXAMPLE.COM password and successfully acquire a TGT.  I
    JDC> have stashed the principals
    JDC> host/nfs.loc1.example.com at AD.EXAMPLE.COM and
    JDC> nfs/nfs.loc1.example.com at 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
  res at qoxp.net