powered by Jive Software

Problem with SSO too

Hi everyone,

I want to realize the SSO by using openfire 3.4.1+kerberos according some guides, but failed at the sasl negotiation stage.

I use pidgin as client and openfire as im server.

And something i think should be spot are marked with red color.

Below is my settings:

my kdc server and openfire server are on the same machine with name “verdant.prc.sun.com”.

my kdc data:

K/M@BJFU.EDU.CN

           ftp/verdant.prc.sun.com@BJFU.EDU.CN

           host/verdant.prc.sun.com@BJFU.EDU.CN

           kadmin/admin@BJFU.EDU.CN

           kadmin/changepw@BJFU.EDU.CN

           kadmin/history@BJFU.EDU.CN

           kadmin/localhost.localdomain@BJFU.EDU.CN

           krbtgt/BJFU.EDU.CN@BJFU.EDU.CN

           root@BJFU.EDU.CN

           ssh/verdant.prc.sun.com@BJFU.EDU.CN

           super/admin@BJFU.EDU.CN

           test1@BJFU.EDU.CN

           xmpp/verdant.prc.sun.com@BJFU.EDU.CN

the output of “klist -k”

klist -k

Keytab name: FILE:/etc/krb5.keytab

KVNO Principal



           3 ftp/verdant.prc.sun.com@BJFU.EDU.CN

           3 ftp/verdant.prc.sun.com@BJFU.EDU.CN

           3 ftp/verdant.prc.sun.com@BJFU.EDU.CN

           3 ftp/verdant.prc.sun.com@BJFU.EDU.CN

           6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN

           6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN

           6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN

           6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN

           4 host/verdant.prc.sun.com@BJFU.EDU.CN

           4 host/verdant.prc.sun.com@BJFU.EDU.CN

           4 host/verdant.prc.sun.com@BJFU.EDU.CN

           4 host/verdant.prc.sun.com@BJFU.EDU.CN

after click login, the output of “klist” is :

klist

Ticket cache: FILE:/tmp/krb5cc_0

           Default principal: test1@BJFU.EDU.CN

Valid starting Expires Service principal

           11/20/07 17:00:06  11/21/07 17:00:06  krbtgt/BJFU.EDU.CN@BJFU.EDU.CN

11/20/07 17:00:17 11/21/07 17:00:06 xmpp/verdant.prc.sun.com@BJFU.EDU.CN

so the client had got the service tickets from the kdc

Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached

my openfire’s configure file

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

–>

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

<jive>

<adminConsole>

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

<port>9090</port>

<securePort>9091</securePort>

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

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

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

or remote users. -->

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

</admin>

<locale>en</locale>

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

<interface></interface>

</network>

–>

<connectionProvider>

<className>org.jivesoftware.database.EmbeddedConnectionProv ider</className>

</connectionProvider>

<!-- sasl configuration -->

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

<!-- <mechs>CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS</mechs> -->

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

and keytab.–>

<realm>BJFU.EDU.CN</realm>

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

<gssapi>

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

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

<provider>

<authorization>

<classList>org.jivesoftware.openfire.sasl.LooseAuthorizatio nPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList>

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

</authorization>

</provider>

<setup>true</setup>

</jive>

and gss.conf’s content

com.sun.security.jgss.accept {

com.sun.security.auth.module.Krb5LoginModule

required

storeKey=true

keyTab="/etc/krb5.keytab"

doNotPrompt=true

useKeyTab=true

realm=“BJFU.EDU.CN

           principal="xmpp/verdant.prc.sun.com@BJFU.EDU.CN"

debug=true;

};

the debug info of communications:

(17:34:50) jabber: Sending: <?xml version=‘1.0’ ?>

           (17:34:50) jabber: Sending: &lt;stream:stream to='verdant.prc.sun.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'&gt;

           (17:34:50) jabber: Recv (582): &lt;?xml version='1.0' encoding='UTF-8'?&gt;&lt;stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="verdant.prc.sun.com" id="fbd27ef" xml:lang="en" version="1.0"&gt;&lt;stream:features&gt;&lt;starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"&gt;&lt;/starttls&gt;&lt;mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;&lt;mechanism&gt;GSSAPI&lt;/mechani sm&gt;&lt;/mechanisms&gt;&lt;compression xmlns="http://jabber.org/features/compress"&gt;&lt;method&gt;zlib&lt;/method&gt;&lt;/compression&gt;&lt;auth xmlns="http://jabber.org/features/iq-auth"/&gt;&lt;register xmlns="http://jabber.org/features/iq-register"/&gt;&lt;/stream:features&gt;

(17:34:50) jabber: Sending: <starttls xmlns=‘urn:ietf:params:xml:ns:xmpp-tls’/>

(17:34:50) jabber: Recv (50): <proceed xmlns=“urn:ietf:params:xml:ns:xmpp-tls”/>

           (17:34:51) jabber: Sending (ssl): &lt;stream:stream to='verdant.prc.sun.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'&gt;

           (17:34:51) jabber: Recv (ssl)(521): &lt;?xml version='1.0' encoding='UTF-8'?&gt;&lt;stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="verdant.prc.sun.com" id="fbd27ef" xml:lang="en" version="1.0"&gt;&lt;stream:features&gt;&lt;mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;&lt;mechanism&gt;GSSAPI&lt;/mechani sm&gt;&lt;/mechanisms&gt;&lt;compression xmlns="http://jabber.org/features/compress"&gt;&lt;method&gt;zlib&lt;/method&gt;&lt;/compression&gt;&lt;auth xmlns="http://jabber.org/features/iq-auth"/&gt;&lt;register xmlns="http://jabber.org/features/iq-register"/&gt;&lt;/stream:features&gt;

(17:34:51) sasl: Mechs found: GSSAPI

(17:34:51) jabber: Sending (ssl): <auth xmlns=‘urn:ietf:params:xml:ns:xmpp-sasl’ mechanism=‘GSSAPI’>YIICDwYJKoZIhvcSAQICAQBuggHMIIBqADAgEFoQMCAQ6iBwMFACAAAACjggEWYYIBEjCCAQ6gAwIBBaENGwtCSkZVLkVEVS5DTqImMCSgAwIBA 6EdMBsbBHhtcHAbE3ZlcmRhbnQucHJjLnN1bi5jb22jgc8wgcygAwIBEKEDAgEFooG/BIG8YtYIKIsgo ypX5ixnKjj/mBYPciLitJj3AT3Rol0H883UqPzy6mwqO83aEB3aoidX/fKcN/BlnlSSAo2OOCrs9AfqKGgwzV7sRhCrZEDgke/FOuuTooA/XxjPhc VnLB9PSCk3KGrtNbvHg6xYF5tq4y5tj0v1bmBOmE95jH7EXAryZ80Nw97UoOfgM57cEURCvEZuCCYzeuFBjSueHKVqDyiOl9gTj6oTGYHFnc43Vyx6uIb7PppH4C Um2kgcowgcegAwIBEKKBvwSBvAH9MsZ5x6r2RnTESIWP85upWdvbzHVS/iSL2KCLIQMW8bytqHiMLDqkzEs1wbwZthPgZQkxIbrs0qOKm4wa35pRVU4QAOOVwlIdEaqvo 2g7xtxz3qvdZeWk6canzdNRYxSqa6jkwNMltyyHM4VBNQjBgCT/D0pjyXvdoCfhFwzp9H2K0W85mg5GU ZGpq3w5BGJvDdofHYxftZWSrjoQOombKs0YwzKQjyaOowfREGqVtvdAKRVZbn/z</auth>

(17:36:21) jabber: Recv (ssl)(77): <failure xmlns=“urn:ietf:params:xml:ns:xmpp-sasl”><not-authorized/></failure >

(17:36:21) account: Disconnecting account 0x8524510

(17:36:21) connection: Disconnecting connection 0x895a9c8

(17:36:21) connection: Destroying connection 0x895a9c8

and the openfire’s log file:

2007.11.20 17:36: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.<init>(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 :211)

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

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

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

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

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

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

… 20 more

Caused by: javax.security.auth.login.LoginException: Receive timed out

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

Caused by: java.net.SocketTimeoutException: Receive timed out

at java.net.PlainDatagramSocketImpl.receive0(Native Method)

at java.net.PlainDatagramSocketImpl.receive(Unknown Source)

at java.net.DatagramSocket.receive(Unknown Source)

at sun.security.krb5.internal.UDPClient.receive(Unknown Source)

at sun.security.krb5.KrbKdcReq$KdcCommunication.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at sun.security.krb5.KrbKdcReq.send(Unknown Source)

at sun.security.krb5.KrbKdcReq.send(Unknown Source)

at sun.security.krb5.KrbKdcReq.send(Unknown Source)

at sun.security.krb5.KrbAsReq.send(Unknown Source)

at sun.security.krb5.Credentials.sendASRequest(Unknown Source)

at sun.security.krb5.Credentials.acquireTGT(Unknown Source)

… 42 more

Any help would be appreciated.

Thanks in advance!

Well, the client is all good, the problem is on the server. A few things to check:

Can openfire read the keytab? (is it running as root?)

Do you have the xmpp.fqdn property set in the admin console?

One other possible problem is the version of Java you are running (java -version) versus what encryption types you are using (klist -ke). Its possible you need the unlimited strength JCE or upgrade to Java 6 if you are using certain encryption types (or alternatively configure kerberos to use a weaker encryption type if you dont want to change java).

Thanks for your response!

  1. Can openfire read the keytab? (is it running as root?)yes, i run it as root and root has the access to the krb5.keytab file.2. Do you have the xmpp.fqdn property set in the admin console?

I don’t know what you mean “admin console”. Please tell me details.

  1. sth about JCE

My jre version is 1.6 u3

ant the output of klist -ke:

klist -ke

Keytab name: FILE:/etc/krb5.keytab

KVNO Principal



              3 ftp/verdant.prc.sun.com@BJFU.EDU.CN (Triple DES cbc mode with HMAC/sha1)

              3 ftp/verdant.prc.sun.com@BJFU.EDU.CN (ArcFour with HMAC/md5)

              3 ftp/verdant.prc.sun.com@BJFU.EDU.CN (DES with HMAC/sha1)

              3 ftp/verdant.prc.sun.com@BJFU.EDU.CN (DES cbc mode with RSA-MD5)

              6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN (Triple DES cbc mode with HMAC/sha1)

              6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN (ArcFour with HMAC/md5)

              6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN (DES with HMAC/sha1)

              6 xmpp/verdant.prc.sun.com@BJFU.EDU.CN (DES cbc mode with RSA-MD5)

              4 host/verdant.prc.sun.com@BJFU.EDU.CN (ArcFour with HMAC/md5)

              4 host/verdant.prc.sun.com@BJFU.EDU.CN (DES with HMAC/sha1)

              4 host/verdant.prc.sun.com@BJFU.EDU.CN (Triple DES cbc mode with HMAC/sha1)

              4 host/verdant.prc.sun.com@BJFU.EDU.CN (DES cbc mode with RSA-MD5)

Thanks a lot!

The Openfire admin console (http://localhost:9090) has a section to set properties. You need to make sure the xmpp.fqdn property is set correctly, as described in SSO Configuration

You mean “server setting” tab:

Domain:verdant.prc.sun.com

Admin Console Port:9090

Secure Admin Console Port:9091

is that right?

My former setting is the same.

I carefully read your article, i found:

nslookup verdant.prc.sun.com

Name: verdant.prc.sun.com

Address: 129.158.219.58

nslookup 129.158.219.58

58.219.158.129.in-addr.arpa name = verdant.PRC.Sun.COM.

is the " verdant.PRC.Sun.COM." equal “verdant.prc.sun.com”?

Except this, i couldn’t find any difference with your steps. So please check my situation again.

Thanks a lot!