Question

I am attempting to get a test Kerberos client/server pair working against Active Directory. I have created three users in a spare domain in our corporate network, “RichardC”, “Server1” and “Server2”. My Server users have been mapped to different Service Principal Names, one with KRB5_NT_PRINCIPAL, the other with KRB5_NT_SRV_HOST.

ktpass -out server2.keytab 
          -princ server2/[e-mail]
          -mapuser [e-mail]
          -pass ThePassword
          -crypto All
          -pType KRB5_NT_SRV_HOST
          -kvno 2

I have not used the +DesOnly option this time, hoping that in today’s systems I don’t need DES. I have replaced the real domain name with mydomain in this question to avoid management concern.

This gives me a keytab. I can klist it:

KVNO Principal
---- --------------------------------------------------------------------------
   2 server2/[e-mail] (DES cbc mode with CRC-32)
   2 server2/[e-mail] (DES cbc mode with RSA-MD5)
   2 server2/[e-mail] (ArcFour with HMAC/md5)
   2 server2/[e-mail] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   2 server2/[e-mail] (AES-128 CTS mode with 96-bit SHA-1 HMAC)

I can even use kinit -k to log in using the key from the keytab – so it seems to work.

I have both my own test program, and failing that the test program from http://download.oracle.com/docs/cd/E19683-01/816-1331/sampleprogs-1/index.html. In that program, on the server, I have changed GSS_C_NT_HOSTBASED_SERVICE to GSS_C_NT_USER_NAME with both keytabs to make it recognise the name. I am running the Oracle Demo server as

./gss-server -mech 1.2.840.113554.1.2.2 server2/serbia.mydomain.com    

and the client

./gss-client -mech 1.2.840.113554.1.2.2 serbia.mydomain.com server2 "Hello"

The result:

GSS-API error accepting context: Invalid credential was supplied
GSS-API error accepting context: Service key not available

In both this case and with my own test code the error happens after the client has sent its first token, while the server is trying to decode it.

klist shows the key granted for the client. It is using ArcFour, which is in the keytab

Default principal: [e-mail]

Valid starting                Expires                Service principal
07/25/11 17:36:49  07/26/11 03:35:18  krbtgt/[e-mail]
    renew until 08/01/11 17:36:49
07/25/11 17:36:03  07/26/11 03:35:18  server2/[e-mail]
    renew until 08/01/11 17:36:03

The UNIX machine (Serbia) could conceivably belong to another realm (the one I’ve called mydomain.com here), though it does not appear to have Kerberos setup. I am using a local krb5.conf file which I have pointed to the BENCHMARKING.RDDEV.LOCAL realm, though if the machine tries to use the DNS with its host name it may get the wrong answer. My krb5.conf has

[libdefaults]
    default_keytab_name = /users/dev/core/richardc/server1.keytab
    default_realm = BENCHMARKING.RDDEV.LOCAL
    dns_lookup_kdc = false
    default_tkt_types = DES-CBC-MD5

[realms]
BENCHMARKING.RDDEV.LOCAL = {
    kdc = gbha-dcbench01p.benchmarking.rddev.local
    admin_server = gbha-dcbench01p.benchmarking.rddev.local
}

[domain_realm]
benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
.benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
mydomain.com = BENCHMARKING.RDDEV.LOCAL
.mydomain.com = BENCHMARKING.RDDEV.LOCAL

It looks like options such as default_tkt_types have been ineffective.

Question is – how do I fix my error?

Thanks
– Richard

Answer 1

The problem was in the

ktpass -out server2.keytab 
      -princ server2/[e-mail]
      -mapuser [e-mail]
      -pass ThePassword
      -crypto All
      -pType KRB5_NT_SRV_HOST
      -kvno 2

This causes Windows to increase the key version number. The resulting key is not a problem for “kinit -k” login for some reason, but does cause GSS-API server code to fail with the unhelpful “Service key not available” on Solaris systems.

The Windows system was 2008R2. I understand that the behaviour of this command has varied between different versions of Windows.

I have successfully tested with DesOnly. I’d need to return to the poor beleaguered IT department for any other tests 🙂

The solution is to miss the -kvno argument.

 ktpass -out server4.keytab 
      -princ server4/[e-mail]
      -mapuser [e-mail]
      -pass ThePassword
      -crypto DES-CBC-MD5
      -pType KRB5_NT_USER_PRINCIPAL

This gives the output

Targeting domain controller: GBHA-DCBENCH01P.benchmarking.rddev.local
Using legacy password setting method
Successfully mapped server4/serbia.mydomain.com to Server4.
Key created.
Output keytab to server4.keytab:
Keytab version: 0x502
keysize 79 server4/[e-mail] ptype 1
     (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xd1532a6d0f2a8631)
Account Server4 has been set for DES-only encryption.

Note the “vno 5” in the output.

I have tested with both values for -pType. Both work.

My GSS code is using GSS_C_NT_HOSTBASED_SERVICE, but all this seems to alter is the format required to input the name.

(I have changed the key above)

Addendum

My final solution uses -pType KRB5_NT_USER_PRINCIPAL

My GSS code uses GSS_C_NT_USER_NAME to look up the name, and I specify the full name server4/[e-mail]. I found that not all of the platforms I was working on accepted the GSS_C_NT_HOSTBASED_SERVICE, but they all accept GSS_C_NT_USER_NAME.

The person who installs our server application sets the Server Principal Name as a configuration option. This seemed the most reliable way. The person who sets up the key, so knows what it is, tells the application directly what key to use.