How to configure sso

Dear All,

I implemented Open fire server with spark client in my organisation. The openfire fire server is on windows 2008 32 bit. Maped Ldap with my organisation windows AD and Using Microsoft SQL server, it is working fine, I want to implement SSO feature on my spark client Can someone please guide me step by step Procedure how to Configure SSO. Thanks in Advance,

hello please reply

Hi folks,

This is pretty much the same problem that I’m working on, except that I’m running Openfire 3.7.0 on Debian GNU/Linux squeeze and want to allow Kerberos users to authenticate and gain access. These users also run Debian squeeze on their workstations and prefer to use the Pidgin IM client using XMPP.

My feeling is that I’m close to getting it all working. I started by following these instructions. The first part of this seems to be what I need (no additional MIT software necessary):

Stanford University IT Lab Blog - Openfire and Kerberos implementation notes -implementation-notes

Currently, when the Pidgin client attempts to contact the Openfire server, it first acquires a Kerberos XMPP ticket, which is encouraging, but is then asked for a password, which IMO should not happen. It would seem that my Openfire server is ignoring its Kerberos configuration, causing the client to revert to SSL (I think).

The guys at Stanford got SSO to run using Openfire 3.5.2 and are now running 3.6.4. I don’t know if 3.7.0 is siginificantly different in this respect. At any rate, they say they have no problems working with Pidgin.

In my case, after installing Openfire 3.7.0 and feeding it the Stanford configuration mentioned above (their “Initial Kerberos Setup”), but of course with my own host and realm names, I will login to the admin console and see that the following server preferences have been set:

sasl.gssapi.config /etc/openfire/gss.conf

sasl.gssapi.debug true

sasl.mechs GSSAPI

update.lastCheck 1306240531243

xmpp.auth.anonymous true

Am I missing any preferences that must be added to the database manually?

Openfire’s behavior is sometimes curious in that it will occasionally delete information from its openfire.xml file with no explanation. It may consider those settings to be redundant, or prefer to store them in its database instead. It may also be ignoring other openfire.xml preferences, but there’s nothing about any of this in the Openfire logs. If only I could find some documentation on this subject.

Also, despite various debug options being set to “on”, Openfire generates remarkably little log output, so it’s hard to know what’s going on. The only indication it gives that something is amis when my Pidgin client’s Kerberos authentication fails, is this message in the info.log file:

User Login Failed. Failure to initialize security context

What does this mean? That it failed to process /etc/openfire/gss.conf properly, or to read the keytab?

Any help would be appreciated.



The Stanford blog entry was from the original researcher and has not been updated with the information from out production deployment. Our current production server is running Debian lenny and Openfire 3.6.4.

There are no preferences that are added to the database outside of the Openfire application. Indeed, having tried that a couple times I can tell you it generally doesn’t work. At best, the changes made directly to the database require a restart of the server and at worst they disable the server.

The processing of the openfire.xml file makes the system a bit of a challenge to maintain. You are right, for some of the entries in the configuration file the server will record the value in the database and remove it from the configuration file. Also, once a value has been read from the configuration file updates to those values will be ignored. You can see this by looking at the error.log file. Here is an example:

2011.05.19 16:11:28 JiveGlobals: Deleting duplicate XML property ‘provider.user.className’ that is already in database.

When this happens you have to change the value using the admin interface.

Here are the sasl properties that we are using. I have also included the xmpp.domain property. We needed to set this because the name of the physical server differs from the service name.

| name                            | propValue               |
| sasl.gssapi.config              | /etc/openfire/jaas.conf |
| sasl.gssapi.debug               | true                    |
| sasl.gssapi.useSubjectCredsOnly | false                   |
| sasl.mechs                      | GSSAPI                  |
| sasl.realm                      |            |
| xmpp.domain                     |   |

Just for completeness here is our jaas.conf. {
}; xmpp { required storeKey=false debug=true;

The debugging output is non-existent. Basically we were stuck with making a change, restart the server, see that it didn’t work, and iterate. The server has been pretty stable once we got it working, but like a friend of my responded when I complained how hard it was to get a water pump out of an old Chevy, “it was designed to be manufactured not maintained.”.


I have the same issue and scenario as Jaap Winius.

I have a Linux Openfire 3.7.0 server (Debian Lenny) and Linux Pidgin clients (Debian Lenny too). I have a MIT kerberos working properly and the Linux clients could auth in my kerberos server (Debian too). I don’t have any Windows machine in my network.

I’m trying to make SSO auth with pidgin, but I always get the message: User Login Failed. Failure to initialize security context.

Is there some news about this configuration? Any one get success?


Not me. Although Bill was extremely helpful, corresponding with me for several weeks in late May and early June, showing me exactly how his working system was configured, I could never get Openfire to work the same way on my system. I never found out why, but it might have something to do with some customized authentication modules that they use at Stanford University – the only thing I couldn’t duplicate even if he had given me the modules. Or, maybe I just some stupid mistake over and over again; I don’t know.

What I do know is that I would always see that “Failure to initialize security context” error show up in the info.log, which looks like it might relate to a Kerberos problem of some sort. Except that my Kerberos system was working perfectly and that it’s configuration essentially was no different from Bill’s. It would really have been helpful if Openfire had produced more log output.

OK. I will try to contact Bill. If successful I’ll let you know.


Hi Bill, how are you?

I am trying to configure a Openfire 3.7.0 server with SSO and pidgin 2.4.3 clients. Both are in linux.

I’m having the same problems that Jaap Winius reported. When I try to log into the pidgin, the Openfire log file (info.log) show the message: “**User Login Failed. Failure to initialize security **context”.

And in pidgin the message is: “Not Authorized”. I believe that the authentication was successful, but the user does not have permission to log (not sure about it).

I suspect it is something related with the the Property provider, but I’m not sure. Follow my server properties:

provider.auth.className: org.jivesoftware.openfire.ldap.LdapAuthProvider org.jivesoftware.openfire.ldap.LdapGroupProvider

provider.user.className: org.jivesoftware.openfire.ldap.LdapUserProvider

provider.vcard.className: org.jivesoftware.openfire.ldap.LdapVCardProvider

The property provider.auth.className is correct? LdapAuthProvider? I think that it should be KerberosAuthProvider…

I have an integrated LDAP and Kerberos server with GSSAPI. This server is working normally with LDAP authentication using SSL and Kerberos GSSAPI. Even my Samba is integrated with LDAP and Kerberos authentication too.

I tried the settings as you suggested, but without success.

Could you help me?


We have been having problems with OS X 10.7 clients connecting to our OpenFire server. Just got this back from Love at Apple about the problem. I haven’t tried it yet, but I will sometime today. It might help with the problems you are seeing.

Here are the bugs in Sun Java Kerberos that make stop working, first java gss cfx doesn’t handle rrc != 0

and then they set ACCEPTOR_SUBKEY even when they don’t have acceptor subkeys:

You should try use the native JNI support in java gss to workaround the issue.


The native support documented here: tures.html



Bill MacAllister

Infrastructure Delivery Group, Stanford University

I was not able to get the native JNI support to work. I ended up patching openjdk-7 with the patches referenced above, i.e. I can now successfully connect to an Openfire server using Adium on a Mac OS X 10.7 system.

So the version of Java 1.6.0_26 has a bug that kills SSO authentication.

4 days of hell, and upgrading to Java 1.7.0_147 fixed my install.

Will post more details on my thread.