Glad I could be of assistance… Did you see my second post about using Wordpad to edit your openfire.xml?
Poppa
Yes I did, I was using Wordpad already for that very reason. The problem isn’t occurring on my production server(which is a linux box) so I’m not gonna worry about it for now.
Thanks again!
M@
I had such high hopes!
Ok, so I tested the new SSO implementation on my production server last night and now I’m getting a different error logged on the server:
2007.12.18 13:10:48 SaslException
javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)]
at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(Unknown Source)
at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(Unknown Source)
at javax.security.sasl.Sasl.createSaslServer(Unknown Source)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:211)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:152)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:173)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)
Caused by: GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.add(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)
... 21 more
Caused by: javax.security.auth.login.LoginException: Integrity check on decrypted field failed (31)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Unknown Source)
at com.sun.security.auth.module.Krb5LoginModule.login(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$5.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at sun.security.jgss.GSSUtil.login(Unknown Source)
at sun.security.jgss.krb5.Krb5Util.getKeys(Unknown Source)
at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 27 more
Caused by: KrbException: Integrity check on decrypted field failed (31)
at sun.security.krb5.internal.crypto.DesCbcEType.decrypt(Unknown Source)
at sun.security.krb5.internal.crypto.DesCbcMd5EType.decrypt(Unknown Source)
at sun.security.krb5.internal.crypto.DesCbcEType.decrypt(Unknown Source)
at sun.security.krb5.internal.crypto.DesCbcMd5EType.decrypt(Unknown Source)
at sun.security.krb5.EncryptedData.decrypt(Unknown Source)
at sun.security.krb5.KrbAsRep.<init>(Unknown Source)
at sun.security.krb5.KrbAsReq.getReply(Unknown Source)
at sun.security.krb5.Credentials.sendASRequest(Unknown Source)
at sun.security.krb5.Credentials.acquireTGT(Unknown Source)
... 43 more
I created a new AD user as the principal, new keytab file using Java’s ktab utility, set the spn, modified the gss.conf and openfire.xml files to match what was working on the test box. This same client can connect using SSO to the test box just fine, but not the production server.
M@
What does your gss.conf and the sections of your openfire.xml look like?
Poppa
My gss.conf:
com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="/opt/openfire/resources/xmpp.keytab" doNotPrompt=true useKeyTab=true realm="DOCMAGIC.COM" principal="xmpp/imsrv.docmagic.com@DOCMAGIC.COM" debug=true; };
Snippets from my openfire.xml:
<provider>
<authorization>
<classList>org.jivesoftware.openfire.auth.DefaultAuthorizationPolicy</classList>
</authorization>
<vcard>
<className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className>
</vcard>
<user>
<className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
</user>
<auth>
<className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
</auth>
<group>
<className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
</group>
</provider>
<setup>true</setup>
<!-- sasl configuration -->
<sasl>
<!-- Include a comma-separated list of the authentication mechanisms
to advertise support for to clients. Make sure GSSAPI is listed,
and best if it's listed first. The order of mechanisms is important;
clients should try to use the first mechanism they support
(although not all will). Some clients will try to use the most
secure first. You can add other mechanisms in order to support non-GSSAPI clients,
or clients who cannot authenticate to the realm (like Windows 9X,
off-site, and so on). Keep in mind that by allowing other mechanisms
you are compromising the security of your realm. Be sure to talk
to the Security Officer/Directory/Manager/Administrator about any
policies your organization might have before enabling less secure
mechanisms. By removing PLAIN and ANONYMOUS from the list, you will
also disable non-SASL authentications. Keep in mind that a mechanism listed here might not actually be
advertised, such as when the authProvider can't support the mechanism.
PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication
(the old style XMPP auth), so removing them from this list will
disallow non-SASL authentication. -->
<mechs>GSSAPI</mechs>
<!-- <mechs>CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS</mechs> -->
<!-- Specify the realm you used when you created the service principal
and keytab.-->
<realm>DOCMAGIC.COM</realm>
<!-- Mechanism-specific configuration here -->
<gssapi>
<!-- Use true to turn on debugging information. This adds a lot
of noise to your log files, but it can help you spot problems
sooner in the initial setup. -->
<debug>true</debug>
<!-- Specify the location of the GSSAPI configuration file you edited. -->
<config>/opt/openfire/conf/gss.conf</config>
<!-- Sets the system property with the same name. You'll probably want
"false" here (the default). For more details, see
[http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html] -->
<useSubjectCredsOnly>false</useSubjectCredsOnly>
</gssapi>
</sasl>
M@
check the persmissions on your gss.conf and xmpp.keytab and make sure the user running the openfire daemon can access them. Try setting thier perms to 777 just to test.
Poppa
One other thing, what does the krb5.conf on your Linux production box look like? And do you have it in the correct location?
These were the two things I checked last night while waiting for your response! I’m getting better at this!
The perms and ownership of the keytab file was set to root when I copied it over, but I changed it to daemon, 440. The file just needs to get read right?
I checked the krb5.conf file(/etc/) this is config’d automagically for us as part of our kickstart process, but I noticed that there were a few lines missing in the [libdefaults] section from the suggested settings.
default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5 default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5 permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
So I added them in.
Also, noticed that there were two entries for the kdc(both IP:port rather than DNS), and one of them was for the old IP address of one of our DCs. So I removed the entry for that kdc in favor of the server that I’ve been using as primary for the rest of this setup.
I then rebooted the server, restarted the openfire service and I’m still getting the same error message.
M@
I’m truly stumped on this one. Sorry I can’t help much with the Linux box. Is it bound to your Active Directory?
Poppa
Yeah it is, using samba/winbind’s net ads join utility.
M@