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

This is a discussion on GSSAPI on Linux using Windows AD Servers as KDCs - Errors about KeytabEntries - Kerberos ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

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

  1. 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
    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:

    (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

  2. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors about Keytab Entries

    >>>>> "JDC" == Jason D McCormick 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@AD.EXAMPLE.COM 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
    res@qoxp.net


  3. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors aboutKeytab Entries

    Richard E. Silverman wrote:

    > A couple of questions:
    >
    > 1) What are the tkt and skey types on the tickets the client gets? The
    > etype of the service credentials?


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

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


    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

  4. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors aboutKeytab Entries



    Jason D. McCormick wrote:
    > Richard E. Silverman wrote:
    >
    >> A couple of questions:
    >>
    >> 1) What are the tkt and skey types on the tickets the client gets? The
    >> etype of the service credentials?

    >
    > klist -e reports:


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

    >
    > 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".
    >
    >> 2) I assume you generated the service keytabs from AD using ktpass.exe?
    >> If so, exactly what command did you use?

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


    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.

    >
    > I've also tried it with and without -ptype KRB5_NT_SRV_HST.
    >
    > - 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

  5. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors aboutKeytab Entries

    Douglas E. Engert wrote:

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


    I'll give that a shot, thanks.

    > Why are you using DES? All the newer Kerberos can use ArcFour. So try
    > ktpass witout the crypto option.


    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



  6. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors aboutKeytab Entries



    Jason D. McCormick wrote:
    > Douglas E. Engert wrote:
    >
    >> 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.

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

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


    Don't know, but a lot of the developers on the nfsv4@ietf.org list are also
    on the Kerberos list.

    >
    > - Jason
    >
    >
    >


    --

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

  7. Re: GSSAPI on Linux using Windows AD Servers as KDCs - Errors aboutKeytab Entries

    Douglas E. Engert wrote:
    > 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.


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

    - Jason

  8. Re: GSSAPI on Linux using Windows AD Servers as KDCs - ErrorsaboutKeytab Entries

    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 markus@SUSE.HOME:
    markus@Opensuse:~> ls /suse_work/
    src
    markus@Opensuse:~> klist -e
    Ticket cache: FILE:/tmp/krb5cc_1000
    Default principal: markus@SUSE.HOME

    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" wrote in message
    news:478274B5.3030700@devrandom.org...
    > Douglas E. Engert wrote:
    >> 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.

    >
    > This is EXACTLY what I needed. Everything works now. Thanks to
    > everyone for the help.
    >
    > - Jason
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >




+ Reply to Thread