Kerberos SSO with mod_auth_kerb: Verification code 589824 and Token seems to be NTLM

Question

I've run into some difficulties kerberizing a host, t.p.no. I'm follwing http://grolmsnet.de/kerbtut, which have worked for others kerberizing a host not added to the windows domain.

The problem seems to be the client NTLM tokens for some reason.

I'll go through the setup and state of the server and then the test client:

Server

Environment:

OS is CentOS 5.9,

Kerberos, Apache and mod_auth_kerb installed with yum:

httpd.x86_64                              2.2.3-76.el5.centos          installed
httpd-devel.i386                          2.2.3-76.el5.centos          installed
httpd-devel.x86_64                        2.2.3-76.el5.centos          installed

mod_auth_kerb.x86_64                      5.1-5.el5                    installed

krb5-devel.x86_64                         1.6.1-70.el5                 installed
krb5-libs.i386                            1.6.1-70.el5                 installed
krb5-libs.x86_64                          1.6.1-70.el5                 installed
krb5-workstation.x86_64                   1.6.1-70.el5                 installed
pam_krb5.i386                             2.2.14-22.el5                installed
pam_krb5.x86_64                           2.2.14-22.el5                installed

KDC/DC is a Windows Server 2003 SP2

Kerberos:

I've had a domain admin create AD account and run ktpass to map SPN to this account with:

ktpass.exe /princ HTTP/t.p.no@TESTSONE2.P.LOCAL /mapuser testsone2\user 
/crypto DES-CBC-MD5 +DesOnly /Pass *** /ptype KRB5_NT_PRINCIPAL /out t.keytab

On the server/host im trying to kerberize, I've done this to verify kerberos is configured properly:

# kinit -V jhs@TESTSONE2.P.LOCAL
Password for jhs@TESTSONE2.P.LOCAL: 
Authenticated to Kerberos v5

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jhs@TESTSONE2.P.LOCAL

Valid starting     Expires            Service principal
05/13/13 15:32:13  05/14/13 01:32:17  krbtgt/TESTSONE2.P.LOCAL@TESTSONE2.P.LOCAL
  renew until 05/14/13 15:32:13


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

And I've checked that KDC sends me tickets for my principal:

# kvno HTTP/t.p.no@TESTSONE2.P.LOCAL
HTTP/t.p.no@TESTSONE2.P.LOCAL: kvno = 9

# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jhs@TESTSONE2.P.LOCAL

Valid starting     Expires            Service principal
05/13/13 15:32:13  05/14/13 01:32:17  krbtgt/TESTSONE2.P.LOCAL@TESTSONE2.P.LOCAL
  renew until 05/14/13 15:32:13, Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 
05/13/13 15:34:27  05/14/13 01:32:17  HTTP/t.p.no@TESTSONE2.P.LOCAL
  renew until 05/14/13 15:32:13, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with RSA-MD5 

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

The kvno matches the one in keytab:

# ktutil 
ktutil: rkt t.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    9 HTTP/t.p.no@TESTSONE2.P.LOCAL

t.p.no is an A-record resolving to an ip address that reverse-resolves to t.p.no

This is my Virtual Host config, it's a simple passenger-served rails app. Tested working before adding Location section with authentication-related directives:

<VirtualHost *:80>
  DocumentRoot /home/p/testapp/public
  ServerName t.p.no

  RackEnv staging
  RailsEnv staging

  <Directory /home/p/testapp/public>
    Options -MultiViews
  </Directory>

  <Location />
    AuthType Kerberos
    AuthName "Logg inn"
    KrbMethodNegotiate On
    KrbMethodK5Passwd Off
    KrbAuthRealms TESTSONE2.P.LOCAL
    KrbServiceName HTTP # No difference if using full SPN here
    Krb5KeyTab /etc/httpd/keys/t.keytab
    require valid-user
  </Location>

  LogLevel debug
  CustomLog logs/t.p.no-access_log combined_forwarded
  ErrorLog logs/t.p.no-error_log

</VirtualHost>

When the client enters t.p.no in Internet Explorer, Apache logs the following:

[debug] src/mod_auth_kerb.c(1496): [client 139.x.x.201] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1496): [client 139.x.x.201] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1151): [client 139.x.x.201] Acquiring creds for HTTP/t.p.no@TESTSONE2.P.LOCAL
[debug] src/mod_auth_kerb.c(1270): [client 139.x.x.201] Verifying client data using KRB5 GSS-API
[debug] src/mod_auth_kerb.c(1286): [client 139.x.x.201] Verification returned code 589824
[debug] src/mod_auth_kerb.c(1313): [client 139.x.x.201] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[error] [client 139.116.152.201] gss_accept_sec_context() failed: Invalid token was supplied (No error)

Client

OS: Windows Server 2008 SP1

The IE has IWA enabled and http://t.p.no is added to its list of intranet hosts.

On the client, when attempting to access t.p.no, I'm seeing two requests in Fiddler, in the first, the client sends no Authentication-headers, the server responds with status 401 and header WWW-Authenticate: Negotiate.

In the second request, the client sends a header: Authorization: Negotiate [token data] In the Auth-tab in fiddler the token data is shown:

-[NTLM Type1: Negotiation]------------------------------
Provider: NTLMSSP
Type: 1
OS Version: 6.1:7601
Flags:  0xe2088297
    Unicode supported in security buffer.
    OEM strings supported in security buffer.
    Request server's authentication realm included in Type2 reply.
    Sign (integrity)
    NTLM authentication.
    Negotiate Always Sign.
    Negotiate NTLM2 Key.
    Supports 56-bit encryption.
    Supports 128-bit encryption.
    Client will provide master key in Type 3 Session Key field.
Domain_Offset: 0; Domain_Length: 0; Domain_Length2: 0
Host_Offset: 0; Host_Length: 0; Host_Length2: 0
Host: 
Domain: 
------------------------------------

All help in finding out the cause NTLM tokens being sent will be greatly appreciated!

Answer 1

As mentioned, my test client is a 2008 server R2. An article (http://support.microsoft.com/kb/977321) pertaining to Windows 7 clients and Windows Server 2008 R2 states that DES encryption for Kerberos authentication is disabled by default in these products.

I followed the steps in the article to re-enable DES on the client, the KDC is 2003, so it should still support DES. Authentication then succeeded.

Answer 2

your krb5 packages are outdated. these need to be updated to support stronger encryption.

DES should definitely be disabled. all my linux systems use 128 AES for kerberos.