Problems with SPNEGO

[antei]

I have carefully read the manual (User Guide for JBoss Negotiation) and set up the test network for using SPNEGO:

- 1st host - Windows 2003 Adv Server (Active Directory and DNS)
- 2nd host - Windows 2003 Adv Server (jboss-4.2.2.GA with all needed modules and negotiation toolkit)
- 3rd host Windows XP (just for accessing from browser)

Then I tried to run Negotiation Toolkit. Results:
- Basic Negotiation - passed
- Security Domain Test - passed
- Secured - failed

Could you explain me what is the problem ?
Thanks in advance!

The stack trace on the JBoss was:

2008-08-01 16:41:52,621 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] Logged in 'host' Login
Context
2008-08-01 16:41:52,621 INFO [STDOUT] [Krb5LoginModule]: Entering logout
2008-08-01 16:41:52,636 INFO [STDOUT] [Krb5LoginModule]: logged out Subject
2008-08-01 16:41:52,636 DEBUG [org.jboss.security.auth.spi.UsersRolesLoginModule] Loaded properties, users=[]
2008-08-01 16:41:52,636 DEBUG [org.jboss.security.auth.spi.UsersRolesLoginModule] Loaded properties, users=[Ad
[e-mail]]
2008-08-01 16:41:52,636 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOAuthenticator] authenticated princi
pal = null
2008-08-01 16:41:52,652 INFO [org.jboss.security.negotiation.spnego.SPNEGOAuthenticator] Header - Negotiate o
YIJszCCCa+iggmrBIIJp2CCCaMGCSqGSIb3EgECAgEAboIJkjCCCY6gAwIBBaEDAgEOogcDBQAgAAAAo4IDzWGCA8kwggPFoAMCAQWhDhsMTVl
ET01BSU4uQ09NoiowKKADAgECoSEwHxsESFRUUBsXdGVzdHNlcnZlci5teWRvbWFpbi5jb22jggOAMIIDfKADAgEXoQMCAQOiggNuBIIDao5og


2008-08-01 16:41:52,775 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] serverSecurityDomain=h
ost
2008-08-01 16:41:52,775 INFO [STDOUT] Debug is true storeKey true useTicketCache false useKeyTab true doNotP
rompt true ticketCache is null isInitiator true KeyTab is C:/testserver.host.keytab refreshKrb5Config is false
 principal is host/[e-mail] tryFirstPass is false useFirstPass is false storePass is false clea
rPass is false
2008-08-01 16:41:52,791 INFO [STDOUT] principal's key obtained from the keytab
2008-08-01 16:41:52,806 INFO [STDOUT] Acquire TGT using AS Exchange
2008-08-01 16:41:52,806 INFO [STDOUT] principal is host/[e-mail]
2008-08-01 16:41:52,822 INFO [STDOUT] EncryptionKey: keyType=23 keyBytes (hex dump)=0000: 83 B4 91 86 A1 5A E
7 91 F1 1B B0 29 FB 59 A2 06 .....Z.....).Y..
2008-08-01 16:41:52,822 INFO [STDOUT] Added server's keyKerberos Principal host/[e-mail] Ve
rsion 4key EncryptionKey: keyType=23 keyBytes (hex dump)=
0000: 83 B4 91 86 A1 5A E7 91 F1 1B B0 29 FB 59 A2 06 .....Z.....).Y..
2008-08-01 16:41:52,837 INFO [STDOUT] [Krb5LoginModule] added Krb5Principal host/testserver@MYDOMAI
N.COM to Subject
2008-08-01 16:41:52,837 INFO [STDOUT] Commit Succeeded
2008-08-01 16:41:52,853 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] Subject = Subject:
 Principal: host/[e-mail]
 Private Credential: Ticket (hex) =



0000: 61 82 01 0B 30 82 01 07 A0 03 02 01 05 A1 0E 1B a...0...........
0010: 0C 4D 59 44 4F 4D 41 49 4E 2E 43 4F 4D A2 21 30 .MYDOMAIN.COM.!0
0020: 1F A0 03 02 01 02 A1 18 30 16 1B 06 6B 72 62 74 ........0...krbt
0030: 67 74 1B 0C 4D 59 44 4F 4D 41 49 4E 2E 43 4F 4D gt..MYDOMAIN.COM
0040: A3 81 CC 30 81 C9 A0 03 02 01 17 A1 03 02 01 02 ...0............
0050: A2 81 BC 04 81 B9 83 9F 30 17 16 3D 68 C8 99 0D ........0..=h...
0060: 70 5F 7B F4 6A BD 6D 1E B5 F5 2F 44 18 9C 98 1C p_..j.m.../D....
0070: B5 98 C0 52 60 82 0B 22 67 38 19 CB B9 C4 C6 98 ...R`.."g8......
0080: 2C D9 E5 3B ED 55 ED 13 AB 45 43 1C D7 D4 1D AC ,..;.U...EC.....
0090: 9D B8 61 7B 97 BD F4 29 0A F5 8E D4 ED BA B2 7C ..a....)........
00A0: FC 34 36 15 52 19 AE A8 64 7D 91 36 53 0F 93 98 .46.R...d..6S...
00B0: DA 48 18 FA 83 0A 22 15 97 34 37 41 8A F7 6F 47 .H...."..47A..oG
00C0: 1E D0 22 F2 B4 5F 0D 79 51 93 DD 42 33 96 0E 67 ..".._.yQ..B3..g
00D0: 5F 8B B2 6E 87 0E 6A 9F 50 42 A1 4E 7F 85 3B 9C _..n..j.PB.N..;.
00E0: 4D 01 94 A5 10 34 D8 1B A4 53 9A 5A 46 6A 85 91 M....4...S.ZFj..
00F0: 97 81 E6 F5 1B 62 C2 8D 8B 38 60 00 17 47 D9 00 .....b...8`..G..
0100: 4D AD D5 D4 48 95 A4 93 C0 3E DB 7D 6A 9B 4E M...H....>..j.N

Client Principal = host/[e-mail]
Server Principal = krbtgt/[e-mail]
Session Key = EncryptionKey: keyType=23 keyBytes (hex dump)=
0000: 92 C3 CB F8 67 D8 31 B9 FE E8 68 7A 0C E7 67 74 ....g.1...hz..gt


Forwardable Ticket false
Forwarded Ticket false
Proxiable Ticket false
Proxy Ticket false
Postdated Ticket false
Renewable Ticket false
Initial Ticket false
Auth Time = Fri Aug 01 16:42:01 EEST 2008
Start Time = Fri Aug 01 16:42:01 EEST 2008
End Time = Sat Aug 02 02:42:01 EEST 2008
Renew Till = null
Client Addresses Null
 Private Credential: Kerberos Principal host/[e-mail] Version 4key EncryptionKey: key
Type=23 keyBytes (hex dump)=
0000: 83 B4 91 86 A1 5A E7 91 F1 1B B0 29 FB 59 A2 06 .....Z.....).Y..


2008-08-01 16:41:52,853 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] Logged in 'host' Login
Context
2008-08-01 16:41:52,853 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] Creating new GSSContex
t.
2008-08-01 16:41:52,868 ERROR [STDERR] Checksum failed !
2008-08-01 16:41:52,868 ERROR [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] Unable to authenticate
GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
 at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
 at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
 at org.jboss.security.negotiation.spnego.SPNEGOLoginModule$AcceptSecContext.run(SPNEGOLoginModule.java
:295)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAs(Subject.java:337)
 at org.jboss.security.negotiation.spnego.SPNEGOLoginModule.login(SPNEGOLoginModule.java:113)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
 at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
 at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:603)
 at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:537)
 at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
 at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:491)
 at org.jboss.security.negotiation.spnego.SPNEGOAuthenticator.authenticate(SPNEGOAuthenticator.java:103
)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 at java.lang.Thread.run(Thread.java:619)
Caused by: KrbException: Checksum failed
 at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:85)
 at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:77)
 at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:168)
 at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:267)
 at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:134)
 at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:79)
 at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:724)
 ... 32 more
Caused by: java.security.GeneralSecurityException: Checksum failed
 at sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:388)
 at sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:74)
 at sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:83)
 ... 38 more
2008-08-01 16:41:53,038 INFO [STDOUT] [Krb5LoginModule]: Entering logout
2008-08-01 16:41:53,038 INFO [STDOUT] [Krb5LoginModule]: logged out Subject
2008-08-01 16:41:53,038 DEBUG [org.jboss.security.auth.spi.UsersRolesLoginModule] Loaded properties, users=[]
2008-08-01 16:41:53,053 DEBUG [org.jboss.security.auth.spi.UsersRolesLoginModule] Loaded properties, users=[Ad
[e-mail]]
2008-08-01 16:41:53,053 DEBUG [org.jboss.security.negotiation.spnego.SPNEGOAuthenticator] authenticated princi
pal = null
2008-08-01 16:42:48,778 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <Fri, 1
 Aug 2008 16:42:48>
2008-08-01 16:42:48,778 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass
2008-08-01 16:42:48,778 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recov
ery.TORecoveryModule_3] - TORecoveryModule - first pass

[dlofthouse]

Developing the authenticator I did see a similar error, in my situation the client machine had cached an old ticket for the host so when the ticked was decoded there was a checksum problem.

In my situation logging out of the test client and back in caused the tickets to be correctly reloaded.

I would suggest doing this and possibly the same on the machine hosting JBoss as well.

[antei]

Developing the authenticator I did see a similar error, in my situation the client

machine had cached an old ticket for the host so when the ticked was decoded there was a checksum problem.

In my situation logging out of the test client and back in caused the tickets to be correctly reloaded.

I would suggest doing this and possibly the same on the machine hosting JBoss as well.

Thank you, Darran, for your response.

Unfortunately you suggestion didn't help me.

I decided to describe the settings I made according your User Guide. May be you will point me what is wrong...

In my last experiment I had configuration as below:

1st host: Windows 2003 Server
Host Name: ws2003e
Domain: mydomain.com
Software:
- Active Directory
- DNS

2nd host: Windows 2003 Server
Host Name: testserver
Domain: mydomain.com
Software:
- Active Directory (just second controller)
- jdk1.6.0_06
- jboss-4.2.2.GA

3rd host: Windows XP SP2
Software:
- IE 6.0

To model real network configuration I am going to apply SPNEGO to I have 2 domain controllers. But it doesn't matter, I

think. All tunes I made on the 2nd host.

1. I created 'testserver' user in Active Directory, entered valid password 'c,jhybr1' and selected 'Do not requires

Kerberous preauthentication' option.

2. Then I executed the commands as in User Guide:

C:\Tools\MS Windows tools\support>setspn.exe -a host/testserver.mydomain.com testserver
Registering ServicePrincipalNames for CN=TESTSERVER,OU=Domain Controllers,DC=mydomain,DC=com
 host/testserver.mydomain.com
Updated object

C:\Tools\MS Windows tools\support>setspn.exe -a HTTP/testserver.mydomain.com testserver
Registering ServicePrincipalNames for CN=TESTSERVER,OU=Domain Controllers,DC=mydomain,DC=com
 HTTP/testserver.mydomain.com
Updated object

C:\Tools\MS Windows tools\support>setspn -l testserver
Registered ServicePrincipalNames for CN=TESTSERVER,OU=Domain Controllers,DC=mydomain,DC=com:
 HTTP/testserver.mydomain.com
 GC/testserver.mydomain.com/mydomain.com
 HOST/testserver.mydomain.com/mydomain.com
 HOST/testserver.mydomain.com/MYDOMAIN
 ldap/c5439fc5-8c99-4e04-9046-498d9d5c635d._msdcs.mydomain.com
 ldap/testserver.mydomain.com/MYDOMAIN
 ldap/TESTSERVER
 ldap/testserver.mydomain.com
 ldap/testserver.mydomain.com/mydomain.com
 E3514235-4B06-11D1-AB04-00C04FC2DCD2/c5439fc5-8c99-4e04-9046-498d9d5c635d/mydomain.com
 NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/testserver.mydomain.com
 HOST/TESTSERVER
 HOST/testserver.mydomain.com

C:\Tools\MS Windows tools\support>ktpass -princ host/[e-mail] -pass c,jhybr1 -mapuser

 MYDOMAIN\testserver -out C:\testserver.host.keytab

Using legacy password setting method
WARNING: realm "mydomain.com" has lowercase characters in it.
 We only currently support realms in UPPERCASE.
 assuming you mean "MYDOMAIN.COM"...
Successfully mapped host/testserver to testserver.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to C:\testserver.host.keytab:
Keytab version: 0x502
keysize 63 host/[e-mail] ptype 0 (KRB5_NT_UNKNOWN) vno 4 etype 0x17 (RC4-HMAC) keylen
gth 16 (0x83b49186a15ae791f11bb029fb59a206)

After 'ktpass' command 'C:\testserver.host.keytab' file was created and its lenght was 69 bytes.
Then I run 'ktab' command

C:\Program Files\Java\jdk1.6.0_06\bin>ktab -k c:\testserver.host.keytab -a [e-mail]
Password for [e-mail]:c,jhybr1
Done!
Service key for [e-mail] is saved in c:\testserver.host.keytab

After 'ktab' 'C:\testserver.host.keytab' file was overwritten and its lenght became 366 bytes.


I made JBoss settings as below:

jboss-4.2.2.GA/server/default/deploy/properties-service.xml:

<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss:type=Service,name=SystemProperties">
 <attribute name="Properties">
 java.security.krb5.kdc=testserver.mydomain.com
 java.security.krb5.realm=MYDOMAIN.COM
 </attribute>
 </mbean>

jboss-4.2.2.GA/server/default/deploy/jboss-web.deployer/META-INF/jboss-service.xml:

<server>
 <mbean code="org.jboss.web.tomcat.service.JBossWeb" name="jboss.web:service=WebServer"

xmbean-dd="META-INF/webserver-xmbean.xml">

 <attribute name="Authenticators" serialDataType="jbxb">
 <java:properties xmlns:java="urn:jboss:java-properties" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"

xs:schemaLocation="urn:jboss:java-properties resource:java-properties_1_0.xsd">

 ...

 <java:property>
 <java:key>SPNEGO</java:key>
 <java:value>org.jboss.security.negotiation.spnego.SPNEGOAuthenticator</java:value>
 </java:property>
 </java:properties>
 </attribute>
...

jboss-4.2.2.GA/server/default/conf/login-config.xml:

<application-policy name="host">
 <authentication>
 <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
 <module-option name="storeKey">true</module-option>
 <module-option name="useKeyTab">true</module-option>
 <module-option name="principal">host/[e-mail]</module-option>
 <module-option name="keyTab">C:/testserver.host.keytab</module-option>
 <module-option name="doNotPrompt">true</module-option>
 <module-option name="debug">true</module-option>
 </login-module>
 </authentication>
 </application-policy>


 <application-policy name="SPNEGO">
 <authentication>

 <login-module code="org.jboss.security.negotiation.spnego.SPNEGOLoginModule" flag="requisite">
 <module-option name="password-stacking">useFirstPass</module-option>
 <module-option name="serverSecurityDomain">host</module-option>
 </login-module>

 <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
 <module-option name="password-stacking">useFirstPass</module-option>
 <module-option name="usersProperties">props/spnego-users.properties</module-option>
 <module-option name="rolesProperties">props/spnego-roles.properties</module-option>
 </login-module>

 </authentication>
 </application-policy>

I run JBoss with parameter --host=testserver.mydomain.com
After that I tried to access http://testserver.mydomain.com:8080/jboss-negotiation-toolkit from 3rd host (Windows XP, IE

6.0):
- Basic Negotiation - passed
- Security Domain Test - passed
- Secured - failed

What is wrong in my settings?
Thanx in advance.

[asa951]

HI Antei,

Did you manage to solve the issue? I'm facing the same problem, and am getting nowhere :(

Cheers,
Asa

[betogf]

I'm running into the exact same issue. Anybody out there willing to shed some light on this?

Thanks!

[soverbosch]

I'm having the same problem right now, did any of you find the solution to this and is willing to share this solution?

[betogf]

What solved it for me was having the Windows Admin re-execute the setspn command. He had executed for the first time but I had this issue. I checked everything and couldn't find any error on my server. There was another server already setup and running just fine, copied everything from that server to the one with this problem and the exact same problem would show up. At this point I realized it was a problem beyond my server. The Windows Admin suggested to delete the spn config and re-execute the exact same setspn command he did at first, which he did. I retested it and it worked like a charm and has worked ever since.

I found this hard to believe but now I'm a believer. I remember reading some posts about folks who had the exact same experience but I decided to move on to the next post as it didn't seem to be logical. If you are absolutely certain is not an issue in your server, give this a try. Maybe you are as "lucky" as some of us have been.

[soverbosch]

How did your administrator delete the spn config? I've upgraded the server to using java 1.6.0_22 and now the message is slightly different. Now it is like this:

2011-03-31 13:23:03,571 TRACE [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] (http-0.0.0.0-8888-7) Result - GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))

2011-03-31 13:23:03,571 ERROR [org.jboss.security.negotiation.spnego.SPNEGOLoginModule] (http-0.0.0.0-8888-7) Unable to authenticate

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

And according to this http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6984764 it is a know bug, so I decided to have a look at what version I was running on my own test server which was 1.6.0_24 so I updated the server to also have this version but still the problem stays.

So back to deleting the spn config, is this done by deleting the user (jbossserver in this case) or is it something you do with the spn command?

[sschmidt]

I have had to use java 1.6.0_18.  Subsequent versions have all failed for me.  Also, were you following the Active Directory instructions?  The username for the SPN cannot be the same as the server name.

[soverbosch]

Tried using 1.6.0_18 but the only thing which changes it the error message, Checksum failed!

I am a bit curious about the username for the SPN, according to the jboss negotiation documentation they do this:

     setspn.exe -a host/testserver.kerberos.jboss.org testserver

     setspn.exe -a HTTP/testserver.kerberos.jboss.org testserver

IMO they do make the username the same as the name as the server name, they state:

     In these examples the example KDC realm is 'KERBEROS.JBOSS.ORG' and the server hosting JBoss is 'testserver', the IP address of the server      should be resolvable as 'testserver.kerberos.jboss.org'.

This is also what I did for two previous install/configurations and it all worked just fine!

[betogf]

Looking back at my notes, my Windows Admin actually didn't delete the account. He simply re-ran the same setspn command he had executed weeks earlier and that seemed to have done the trick. His suspicion was that something had changed somewhere in the environment and required an update to the spn configuration. But he wasn't sure what was the cause of the problem. All we know is that running the command again seemed to have fixed whatever was the problem.

Just as a future reference, I'm running Jboss with:

java version "1.6.0_05"

Java(TM) SE Runtime Environment (build 1.6.0_05-b13)

Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)

Now, I was 100% sure it was either an SPN configuration issue or a network issue because I was able to isolate the problem thanks to another server that was correctly configured and fully working. I'm not sure if this applies to you unless you have isolated the problem as well.

I hope this helps someone. Good luck!

[fobos]

I have the same problem, in my company.

Investigating i found a problem with register of machine in Domain/ActivieDirectory and setspn command.

When machine is registered in Domain a ID is assigned to this machine in AD, when your set SPN for this machine this ID is used by AD to validate kerberos tokens, if you remove this machine from AD and add again the ID is changed and SPN is invalid in this moment, causing this error "Specified version of key is not available (44))" other operations in domain also can cause this problem.

To solve my problem:

1o. remove machine from Domain and all registers of this machine in AD like SPN.

2o. add again machine in Domain

3o. set SPN again for this machine

how betogf said, "when again add machine with setspn can solve this problem",  if have changes in machine on domain after this setspn again can solve, in my case not, was necessary steps above.

Its all.

Hope helped.

[m1452]

Kerberos SPNEGO Checksum failed problem

source Java, middleware, security и не только: Kerberos SPNEGO Checksum failed problem

I made SPNEGO authentication for my web apps. During development I met a problem authenticating users using keytab file for HTTP services:

Caused by: org.ietf.jgss.GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

I've found solution how to resolve a problem. I've used RHEL 7 on servers and clients, and FreeIPA as a KDC/LDAP server:

1. Open /etc/krb5.conf on web app server and add into section [libdefaults] one line

[libdefaults]

default_tkt_enctypes = arcfour-hmac-md5

This is most important thing. This line resolves "Checksum failed" problem

2. On a client:

kinit username

Password for [e-mail]:

after successful authentication in Kerberos domain we can access Kerberized web apps using curl:

curl -v -k --negotiate -u :  --cacert /etc/ipa/ca.crt  https://myservice.com:8090/krb

3. In FireFox, print about:config in address bar -> I promise -> then find

network.negotiate-auth.delegation-uris     value     http://,https://

network.negotiate-auth.trusted-uris           value     .myservice.com