Single sign on help needed

aaron_wookey · August 29, 2007, 1:55pm

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 {

com.sun.security.auth.module.Krb5LoginModule

required

storeKey=true

keyTab="/opt/openfire/conf/jabber.keytab"

doNotPrompt=true

useKeyTab=true

realm=“SHS.WILTS.SCH.UK”

principal="xmpp/comms.shs.wilts.sch.uk@SHS.WILTS.SCH.UK"

debug=true;

};

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:

<prop>

<name>

<is>

<blah>value</blah>

</is>

</name>

</prop>

Most properties are stored in the Openfire database. A

property viewer and editor is included in the admin console.

–>

<jive>

</adminConsole>

<admin>

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

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

or remote users. -->

</admin>

<!-- 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, 127.0.0.1. This setting is generally only useful

on multi-homed servers. -->

<!–

</network>

–>

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

</connectionProvider>

<driver>com.mysql.jdbc.Driver</driver>

<serverURL>jdbc:mysql://10.4.136.50:3306/wildfire</serverURL>

<username>wilduser</username>

</defaultProvider>

</database>

<ldap>

<host>casper.shs.wilts.sch.uk</host>

<baseDN>OU=Teachers,DC=shs,DC=wilts,DC=sch,DC=uk</baseDN>

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

<sslEnabled>false</sslEnabled>

<ldapDebugEnabled>false</ldapDebugEnabled>

<autoFollowReferrals>false</autoFollowReferrals>

<usernameField>sAMAccountName</usernameField>

<searchFilter>(objectClass=organizationalPerson)</searchFilter>

<vcard-mapping><![CDATA[

<N>

</N>

<EMAIL>

</EMAIL>

<ADR>

<HOME/>

</ADR>

<TEL>

<HOME/>

</TEL>

<TEL>

<HOME/>

<CELL/>

</TEL>

<TEL>

<WORK/>

<FAX/>

</TEL>

<TEL>

<WORK/>

</TEL>

<ORG>

</ORG>

</vCard>]]></vcard-mapping>

<groupMemberField>member</groupMemberField>

<groupDescriptionField>description</groupDescriptionField>

<posixMode>false</posixMode>

<groupSearchFilter>(objectClass=group)</groupSearchFilter>

</ldap>

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

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

</authorization>

<vcard>

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

</vcard>

<user>

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

</user>

<auth>

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

</auth>

<group>

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

</group>

</provider>

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

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

and keytab.–>

<realm>SHS.WILTS.SCH.UK</realm>

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

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

<log>

<debug>

</debug>

</log>

</jive>

Jay · August 29, 2007, 2:52pm

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)

NO_MESSAGES_OR_FRIEN · August 29, 2007, 4:21pm

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.

aaron_wookey · September 2, 2007, 4:54pm

@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

aaron

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

Jay · September 4, 2007, 1:11pm

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.

aaron_wookey · September 4, 2007, 3:51pm

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.

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

Jay · September 4, 2007, 4:01pm

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

aaron_wookey · September 4, 2007, 4:23pm

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

wrt · February 27, 2008, 1:24pm

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