JBoss Negotation SPNEGO / Kerberos

[jkueck92]

Hey guys,

we have a problem with kerberos / active directory and jboss. We try to find a solution last week but we dont know.

Our try is to build a SSO with our web application against the ad. I found many example to do this and i try a lot.

Wo did the following steps.

Domain Controller:

• Domain: test.local

Server machine:

• Name: serverMachine
• Domain: test.local
• User: tuser

• Download and install fresh JBoss AS 7.1.1.Final
• call on ad machine: setspn -a HTTP/serverMachine tuser
• call on ad machine: ktpass /princ HTTP/[e-mail] /pass ** /mapuser [e-mail] /out ** /ptype KRB5_NT_PRINCIPAL  /crypto AES256-SHA1
• configure JBoss:

    <system-properties>

       <property name="sun.security.krb5.debug" value="true"/>

        <property name="java.security.krb5.kdc" value="**"/>

        <property name="java.security.krb5.realm" value="TEST.LOCAL"/>

        <property name="java.security.krb5.conf" value="krb5.conf"/>

    </system-properties>

<security-domain name="host" cache-type="default">

          <authentication>

            <login-module code="Kerberos" flag="required">

              <module-option name="debug" value="true" />

              <module-option name="storeKey" value="true" />

              <module-option name="refreshKrb5Config" value="true" />

              <module-option name="useKeyTab" value="true" />

              <module-option name="doNotPrompt" value="true" />

              <module-option name="keyTab" value="key.keytab" />

              <module-option name="principal" value="HTTP/[e-mail]" />

            </login-module>

            <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="optional">

              <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory" />

              <module-option name="java.naming.provider.url" value="ldap://**" />

              <module-option name="java.naming.security.authentication" value="simple" />

              <module-option name="principalDNPrefix" value="" />

              <module-option name="principalDNSuffix" value="@test.local" />

              <module-option name="rolesCtxDN" value="OU=CS,DC=test,DC=local" />

              <module-option name="matchOnUserDN" value="false" />

              <module-option name="uidAttributeID" value="sAMAccountName" />

              <module-option name="roleAttributeID" value="memberOf" />

              <module-option name="roleNameAttributeID" value="name" />

              <module-option name="roleAttributeIsDN" value="true" />

              <module-option name="allowEmptyPasswords" value="false" />

            </login-module>

          </authentication>

        </security-domain>

        <security-domain name="SPNEGO" cache-type="default">

          <authentication>

            <login-module code="SPNEGO" flag="required">

              <module-option name="serverSecurityDomain" value="host" />

            </login-module>

          </authentication>

        </security-domain>

We test the configuration with the JBoss negotation toolkit and get when we call the secured page following error:

     GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))

If we test the security domain test it looks like we are authenticated, we get no error and i think we get an ticket.

We investigate and understand that the error might be occour when the kvno in the keytab file and in ad not the same.

We check that with wireshark from ad: in enc-part section under kvno stand 9.

In the keytab file i search with ktab -l -k key.keytab and there is only one entry with knvo 9.

Can anyone help us we have no idea why the problem occours.

Thanks for replys and help!

[mchoma]

Hi Jan,

Are you sure you use right version of jboss negotiation toolkit?

You can download a prebuilt WAR file of the JBoss Negotiation Toolkit https://repository.jboss.org/nexus/content/groups/public/org/jboss/security/jboss-negotiation-toolkit/. You should download the version of JBoss Negotiation Toolkit that matches the version of JBoss Negotiation included in JBoss EAP. For example, if you are using JBoss EAP 7.0.0, which uses JBoss Negotiation 3.0.2.Final-redhat-1, you should use jboss-negotiation-toolkit-3.0.2.Final.war. You can determine which version of JBoss Negotiation is being used by looking at EAP_HOME/modules/system/layers/base/org/jboss/security/negotiation/main/module.xml.

Martin

[jkueck92]

Hey Martin,

we try this, our negotation version in JBoss is 2.2.2 and we download the negotation toolkit with version 2.2.2.

The error is still available!

Additional info, because we test the authentication system our JBoss running on the same machine as the client. We think that this could be the problem? We did not create a new user in active directory for the JBoss service. The JBoss service running on the same username as the client.

We hope there are a solution. We have no idea any more.

Jan

[mchoma]

Jan,

There are couple of similar problems reported on  Google . Does anything from that apply to you? Especially could you try to speciffy explicitelly -kvno 0 in your ktpass command

[jkueck92]

Hey,

thanks for the reply! We generate a new keytab file with argument /kvno 0. The error is not available any more. But we ran into an new error.

Login failure: javax.security.auth.login.LoginException: Unable to authenticate - Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

We try this example from Stackoverflow : java - checksum failed: Kerberos / Spring / Active Directory (2008) - Stack Overflow  

The java code says we have no errors. There are no exceptions. Wireshark says that it was send a AS-REQ and we getting a AS-REP. Seems corectly.

It is very confused!

Jan

[mchoma]

So I would say you get further. Do you get here Why does JBoss Negotiation throw a GSSException Checksum failed error? - Red Hat Customer Portal  ? That error could be related to server hostname you use in your AD / keytab / URL.

[mchoma]

jkueck92 , did you manage to resolve?  Could you share with us whole proper solution?

[jkueck92]

Hey,

no we found no solution. We inspect with our admin the ad and we checked the local settings but we found no thing that could be the problem.

We can not see the entiry solution from your link you send us.

Why does JBoss Negotiation throw a GSSException Checksum failed error? - Red Hat Customer Portal    

We create a new keytab file but it dosent work.

Jan

[mchoma]

It is written there:

Resolution

1) First, verify the keytab is valid using the kinit util described here: https://access.redhat.com/solutions/44534

2) Install the patch from Microsoft on the client machines (Windows XP, Windows 7) or

3) Regenerate the keytab using the service principal name that matches an A record DNS entry

Root Cause

Windows based clients use the hostname of the server instead of the CNAME when attempting SPNEGO based authentication.

SPENGO client's do not use CNAMEs, rather they dereference to the canonical name and use that hostname. Therefore, SPNs (Service Principal Names) like http/${CNAME}@${REALM} do not work.

Diagnostic Steps

Verify the hostname that is used as the service principal name

Determine what type of DNS entries point at the server

Capture the traffic between the client and server. Look for what hostname the client is using as the service principal name.

[jkueck92]

1) We can create a ticket with kinit there are no problems.

2) We rest the spn mappings and our admin send following instructions to the ad/domain controller:

http://jkueck-pc2012.test.local

hostname : jkueck-pc2012.test.local

realm/domain : test.local

machineName : jkueck-pc2012

The JBoss service and client are the same machine. We did not create a new user in AD for the service. The client login with the following username and the service run on this username/user. Could this be the problem, too?

username : jkueck

password : ***

1. Show registered SPN

setspn -L jkueck-pc2012

2. Delete existing SPN

setspn -D HTTP/jkueck-pc2012 jkueck

setspn -D host/jkueck-pc2012 jkueck

3. Register new SPN

setspn -a HTTP/jkueck-pc2012 jkueck

4. create keytab file

ktpass /princ HTTP/[e-mail] /mapuser [e-mail] /pass *** /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1 /kvno 0

We search the checksum exception in the source code of the class and we found this position:

boolean cksumFailed = false;
if (calculatedHmac.length >= hashSize) {
     for (int i = 0; i < hashSize; i++) {
        if (calculatedHmac[i] != ciphertext[hmacOffset+i]) {
             cksumFailed = true;
             if (debug) {
                  System.err.println("Checksum failed !");
             }
             break;
        }
   }
}
if (cksumFailed) {
     throw new GeneralSecurityException("Checksum failed");
  }

We think that could be a problem with encryption?!