9 Replies Latest reply on Sep 26, 2016 4:40 AM by Jan Kück

    JBoss Negotation SPNEGO / Kerberos

    Jan Kück Newbie

      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/serverMachine@TEST.LOCAL /pass ** /mapuser tuser@TEST.LOCAL /out ** /ptype KRB5_NT_PRINCIPAL  /crypto AES256-SHA1
      • configure JBoss:



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



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


                  <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/serverMachine@TEST.LOCAL" />


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




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


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

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





      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!

        • 1. Re: JBoss Negotation SPNEGO / Kerberos
          Martin Choma Master

          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.



          1 of 1 people found this helpful
          • 2. Re: JBoss Negotation SPNEGO / Kerberos
            Jan Kück Newbie

            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.



            1 of 1 people found this helpful
            • 3. Re: JBoss Negotation SPNEGO / Kerberos
              Martin Choma Master


              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

              • 4. Re: JBoss Negotation SPNEGO / Kerberos
                Jan Kück Newbie



                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!



                • 5. Re: JBoss Negotation SPNEGO / Kerberos
                  Martin Choma Master

                  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.

                  • 6. Re: JBoss Negotation SPNEGO / Kerberos
                    Martin Choma Master

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

                    • 7. Re: JBoss Negotation SPNEGO / Kerberos
                      Jan Kück Newbie



                      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.



                      • 8. Re: JBoss Negotation SPNEGO / Kerberos
                        Martin Choma Master

                        It is written there:



                        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.

                        • 9. Re: JBoss Negotation SPNEGO / Kerberos
                          Jan Kück Newbie

                          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:




                          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/jkueck-pc2012.test.local@TEST.LOCAL /mapuser jkueck@TEST.LOCAL /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 !");






                          if (cksumFailed) {

                               throw new GeneralSecurityException("Checksum failed");


                          We think that could be a problem with encryption?!