powered by Jive Software

Sso + ad

this is my situation

  1. openfire runnin on linux ubuntu. (started by root user)

  2. KDC server running on windows 2000 server named teldc01.DOMINIO.INT

this is the gss.conf

com.sun.security.jgss.accept {

in openfire.xm i have added

<!-- sasl configuration -->
    <!-- Include a comma-separated list of the authentication mechanisms
        to advertise support <b>for</b> to clients. Make sure GSSAPI is listed,
        and best <b>if</b> it's listed first. The order of mechanisms is important;
        clients should <b>try</b> to use the first mechanism they support
        (although not all will). Some clients will <b>try</b> 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 <b>this</b> list will
        disallow non-SASL authentication. -->
    <!-- <mechs>CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS</mechs> -->     <!-- Specify the realm you used when you created the service principal
        and keytab.-->
    <realm>DOMINIO.INT</realm>     <!-- Mechanism-specific configuration here -->
    <gssapi>         <!-- Use <b>true</b> 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 <b>default</b>). For more details, see
            [http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html] -->
</sasl> <provider>
        <classList>org.jivesoftware.openfire.sasl.LazyAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList>
        <!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy-->

if try a kinit of user root it seems to work

klist output

root@FeApache01:/opt/openfire/conf# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root@DOMINIO.INT Valid starting     Expires            Service principal
10/10/07 17:15:08  10/11/07 03:15:01  krbtgt/DOMINIO.INT@DOMINIO.INT renew until 10/11/07 17:15:08 Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

i’ve created the keylist using

ktpass -princ xmpp/feapache01.dominio.int@DOMINIO.INT -mapuser root -pass PASSWORD -out feapache01.keytab

on the AD server running as a DomainAdmins (i have created a user named root yet on the AD domain)

when i try to use spark i’ve the errore message

“unable to connect using Single Sign-On. Please check your principal and server settings”

any suggestion??


sorry for my english

What version of Openfire? What you have listed for the authorization provider may not be correct. Read SSO Configuration and make sure you use the correct provider. Recent versions require using org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy . If you are using an older version or a nightly build it is different.

Also, do you see any errors in your openfire logs?


3.3.3…i have changed the provider but nothing change.


no one??

please help me

Are you getting any errors in your log files?

make sure you do the registry change on both the server and client pc…

On Windows 2003 and Windows 2004 SP4 and later:


Value Name: allowtgtsessionkey

Value Type: REG_DWORD

Value: 0x01 ( default is 0 )

On Windows XP SP2 and later:


Value Name: allowtgtsessionkey

Value Type: REG_DWORD

Value: 0x01

also make sure you have the krb5.ini file in the windows directory on both the server and the client pc.

The registry change is only needed for the client, not the server. As I mentioned in another discussion, if you wish to use Spark on the server to test things, then you will need to make the registry change on the server (but only because it is acting in the capacity of a client)

it seemed to help my case… but maybe it was just placebo effect.

this is my error log

2007.11.08 17:07:21 org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandle r.java:134) Closing connection due to error while processing message:


at java.util.StringTokenizer.nextToken(StringTokenizer.java:332)

at org.jivesoftware.openfire.net.SASLAuthentication.doPlainAuthentication(SASLAuth entication.java:442)

at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :202)

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:570)

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

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

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

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

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

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

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

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

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

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

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:619)

reg change are yet make

no one can help me?

Do you have any errors in the log files in Spark?

Maybe try expanding your authentication mechs. You currently have:

<mechs>GSSAPI</mechs> Try moe options, like:


There could also be an error with the keytab file you generated. Do you have the user “root” in your domain? You should probably create a user specific for this task in the domain. Then recreate the keytab.

Adding the other options will allow logins to work, but it wont fix the SSO issues. In fact, it can make it a little harder to figure out what is going on since a login might succeed and you dont know how it happened without looking at the logs. I guess it depends on the priorities- if you need to have logins working then yes, enable PLAIN and/or the others

nothing change with new mechs tag. The keytab?? what’s the exact procedure to do??


I was looking at your keytab config, and it shows that you used the username root in its creation. Is root a valid user in your Domain. You need create the keytab using a Domain account. i created a new domain account specifically for this task.

The other possibility is that the Openfire server is not listed in you Domain DNS correctly.

the user root exist on my AD domain and the dns is ok