powered by Jive Software

Single sign on help needed

Hi, I have hit problems trying to get our openfire 3.3.2 server running SSO

Server 3.3.2 running on debian linux called comms.shs.wilts.sch.uk (fqdn)

Client Spark 2.5.6 on Windows XP

KDC Windows 2003 PDC casper.shs.wilts.sch.uk

xmpp user acct xmpp-comms

I have read the wiki and followed that thorugh, and looking at other posts, i think i’ve done everything correctly. However, When i login via spark, i am getting “unable to connect using Single Sign-On. Please Check you princple and server settings”

Obviously I’ve missed something, can anyone spot it? thanks

The princlple was created on the KDC/PDC 2003 server using ktpass -princ xmpp/comms.shs.wilts.sch.uk@SHS.WILTS.SCH.UK -mapuser xmpp-comms@shs.wilts.sch.uk and copied to /opt/openfire/conf/

gss.conf contains

com.sun.security.jgss.accept {











my klist is

Default principal: AWOOKEY@SHS.WILTS.SCH.UK

Valid starting Expires Service principal

08/29/07 13:13:05 08/29/07 23:13:07 krbtgt/SHS.WILTS.SCH.UK@SHS.WILTS.SCH.UK

renew until 08/30/07 13:13:05

Kerberos 4 ticket cache: /tmp/tkt0

my openfire.xml is

<?xml version=“1.0” encoding=“UTF-8”?>


This file stores bootstrap properties needed by Openfire.

Property names must be in the format: “prop.name.is.blah=value”

That will be stored as:








Most properties are stored in the Openfire database. A

property viewer and editor is included in the admin console.


<!-- root element, all properties must be under this element -->



<!-- Disable either port by setting the value to -1 -->





<!-- Use this section to define users that will have admin privileges. Below,

you will find two ways to specify which users are admins. Admins will

have access to the admin console (only local users) and may have also access

to other functionalities like ad-hoc commands. -->

<!-- By default, only the user with the username “admin” can login

to the admin console. Alternatively, you can specify a comma-delimitted

list usernames that should be authorized to login to the admin console

by setting the <authorizedUsernames> field below. -->

<!-- <authorizedUsernames></authorizedUsernames> -->

<!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local

or remote users. -->

<!-- <authorizedJIDs></authorizedJIDs> -->




<!-- Network settings. By default, Openfire will bind to all network interfaces.

Alternatively, you can specify a specific network interfaces that the server

will listen on. For example, This setting is generally only useful

on multi-homed servers. -->







<className>org.jivesoftware.database.DefaultConnectionProvider</classN ame>

















<adminDN>CN=A Wookey,OU=Support Staff,OU=Teachers,DC=shs,DC=wilts,DC=sch,DC=uk</adminDN>









<vCard xmlns=“vcard-temp”>













</ADR> <ADR>










</TEL> <TEL>
</TEL> <TEL>



























<classList>org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList>

<!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy–>



<className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className >



<className>org.jivesoftware.openfire.ldap.LdapUserProvider</className& gt;



<className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className& gt;



<className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className >




<!-- sasl configuration -->


<!-- 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. -->



<!-- Specify the realm you used when you created the service principal

and keytab.–>


<!-- Mechanism-specific configuration here -->


<!-- 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. -->


<!-- Specify the location of the GSSAPI configuration file you edited. -->


<!-- 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 -->










Did you modify the registry for the client? By default Java dosnt have full access to the credential cache in Windows. See http://wiki.igniterealtime.org/display/SPARK/SSO+Usage (the Registry section)

Did you also make a krb5.ini for the client machines? The registry entry and the krb5.ini appear to be the only aspects you are missing.

@slushpupie yup, forgot to mention that

Also got my krb5.conf in /etc/ set up corectly too.

Why do i need a ini for the client machines? is this for the ssoMethod section of the spark.properties? If so I have set it to manual then set

ssoRealm and ssoKDC to the correct strings. I have tried ssoMethod DNS (after setting up my dns ) and now the file method, all give the same error.

after running the ktpass command (KDC on windows 2003 server) the username/account i nominated xmpp-comms changes to xmpp/comms.shs.wilts.sch.uk windows 2000 un stay as xmpp-comms

im stuck. any other pointers? thanks


ps added another user xmpp-comms.shs.wilts.sch.uk just in case. but that doesnt work either!

Yes, the ssoMethod is in the spark.properties file. The client needs to know how to find the KDC.

If you selected DNS, did you add the TXT record? The SRV records are set by default in AD, but the TXT record is not. Im almost positive it wont work in a multi-realm environment either, if you are trying that. DNS is the best method if all your clients support lookups via DNS, the file method is almost always best for complex environments where DNS isnt always an option.

One thing you can try is setting debug=true in the preferences file and try again, there should be more logging information to see whats going on.

yup tried that the DNS TXT file looks like

kerberos.udp.shs.wilts.sch.uk 7200 IN SRV 0 0 88 casper.shs.wilts.sch.uk.

kerberos.udp.shs.wilts.sch.uk 7200 IN SRV 1 0 88 westwood.shs.wilts.sch.uk.


does that look right?

ok… spent lots of time on it today, I now get an error

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!)

had a look on forum cant seem to find anything that helps my situation.

You listed two SRV records, and an incomplete TXT record. The most recent documentation shows an example: SSO Configuration

oops my bad i didnt paste corectly, last line should be

_kerberos.shs.wilts.sch.uk 7200 IN TXT “SHS.WILTS.SCH.UK

I cannot set a dword ro 0x01 is this then a value of 1?

Value Name: *allowtgtsessionkey*
Value Type: REG_DWORD
Value: 0x01

i have a very similar problem? have you ever solved yours?