SSO error: Attempt to obtain new ACCEPT credentials failed!

Openfire Openfire Support
1

Hi all,

I have an Openfire 3.3.2 server setup on a RHEL4 box. It is using Active Directory as the directory. It works fine if users login with their usernames and passwords, but I can’t get SSO to work properly.

I have followed the instructions in the Configuring Openfire for Use with Kerberos document and even set the kerberos registry key on my WinXP SP2 box that was mentioned in a couple of other threads. Below is the most recent entry from my warn.log on the server:

================================================

2007.08.23 12:16:21 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.(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 :220)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:141)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:200)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :266)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:326)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

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.(Unknown Source)

at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)

… 20 more

Caused by: javax.security.auth.login.LoginException: Unable to obtain password from user

at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Unknown Source)

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)

… 26 more

Any ideas what this error means or what I could do to fix it? Thanks.

2

OK, it’s fixed now. It was a couple of issues:

  1. I had transposed 2 letters in the principle name in my gcc.conf file. When I fixed that, I got another error like the following:

JSmith@MY.DOMAIN.COM is not authorized to connect as jsmith

  1. That lead me to this thread:

So, I did 2 things. First, I changed the provider to LooseAuthorizationPolicy because that was the file in my openfire.jar.

NOTE: someone should really change the Kerberos config document. It says that in 3.3.1 and later the provider name should be LooseAuthorizationProvider instead of the correct LooseAuthorizationPolicy that is actually in the jar file.

Second, I had to change my username in AD to all lower case. This last step is what finally got it to work.

Now, here’s a followup question: is there any way the account lookup case insensitive? Right now, I don’t know how many usernames are a mix of upper and lower case in AD. I don’t want to deploy this and be flooded with requests for people who can’t log in just because their usernames in AD aren’t all lower case.

3

Kerberos principals are case-sensitive, while AD accounts are not. Its important to understand this distinction because when you log in with Kerberos (for Openfire SSO or other applications using Kerberos) you are using the Kerberos principal, not the AD account name. The command you used to generate the server principal really only changes the kerberos principal for a given account, you can do simalar things to regular accounts too, if needed. I dont know what the default is- I seem to recall that the kerberos principal is always the lowercase version of the username- but I could be wrong about that.