SSO - Fail on first login

I setup SSO, however, whenever I setup a person who has never logged in before on that computer. If I choose SSO in the advanced login screen for the client it will find the username just fine. However, I can see in the client debug screen the xml response is: error code=“401” type-“AUTH” saying i’m “not-authorized”.

Even though debugging is turned on, there is no debug, warn, info, or error messages that show up in the logs.

The way I have been able to correct the problem is to have the person login once using their password, then log them out, then go to the Advanced Tab and turn on SSO. then they can login with SSO just fine. I have a feeling it’s using the stored password as a fall-back.

This isn’t standard practice is it? The debug information doesn’t seem to be showing up at all so I don’t know what to do. I do get a warning/error when the server starts up. It’s a Java Error.

java.lang.NullPointerException

at org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvid er.java:670)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:99)

at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:184)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:102)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:65)

at org.jivesoftware.openfire.group.GroupManager$2.run(GroupManager.java:122)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

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)

2007.09.20 12:07:18 [org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvi der.java:679)

]

java.lang.NullPointerException

at org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvid er.java:670)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:99)

at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:184)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:102)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:65)

at org.jivesoftware.openfire.roster.RosterManager.hasMutualVisibility(RosterManage r.java:862)

at org.jivesoftware.openfire.roster.Roster.<init>(Roster.java:132)

at org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:92)

at org.jivesoftware.openfire.user.User.getRoster(User.java:289)

at org.jivesoftware.openfire.handler.IQRosterHandler.manageRoster(IQRosterHandler. java:200)

at org.jivesoftware.openfire.handler.IQRosterHandler.handleIQ(IQRosterHandler.java :105)

at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:48)

at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:300)

at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:104)

at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:67)

at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:289)

at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:79)

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

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

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

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

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

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

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

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

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

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

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

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

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

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)

If on windows did you create and distribute a krb5.ini file and add the appropriate registry settings?

Sorry, I forgot to mention I was on Windows. I have not distributed the .ini file. I read to the bottom but I guess the instructions suggested that if the username showed up in the list that was all I needed to do. apparently that’s not all I had to do. I’ll do that…

I did set the registry entry…

Okay, I created my krb5.ini file and placed it in c:\windows It did not help my problem. I don’t have to reboot to make it work right?

One thing…under the line there is kdc=kdc.example.com in the example. My domain controller is pdc.cmaohio.org that is what I put in there. Not kdc.xxxxx Or is the name “kdc.” the required part?

The server will not put much in the debugging on failed logins because it likely didnt get much information to work with. Check the logs in Spark, that will likely give you more hints. My guess is your client system is missing the registry setting required to allow Java access to the full credential cache. Read up on SSO Configuration for details.

I have added the registry entry necessary for the Java Access to the information. I just exported the key and this is what the .reg file says:

“allowtgtsessionkey”=dword:00000001

I checked the .reg file and change the value of dword to 0x01 as in the example and it actually wouldn’t import the key. I had to change it back to “1” to make it work.

Spark send is this:

<stream:stream to=“po-test” xmlns=“jabber:client” xmlns:stream="[http://etherx.jabber.org/streams]" version=“1.0”>

<starttls xmlns=“urn:ietf:params:xml:ns:xmpp-tls”/>

<stream:stream to=“po-test” xmlns=“jabber:client” xmlns:stream="[http://etherx.jabber.org/streams]" version=“1.0”>

<iq id=“R9k75-0” type=“get”><query xmlns=“jabber:iq:auth”><username>thomas.deliduka</username></ query></iq>

<iq id=“R9k75-1” type=“set”><query xmlns=“jabber:iq:auth”><username>thomas.deliduka</username><p assword/><resource>spark</resource></query></iq>

Receive is this:

<iq id=“R9k75-1” to=“po-test/35b690a8” type=“error”>

<query xmlns=“jabber:iq:auth”>

<username>thomas.deliduka</username>

<password/>

<resource>spark</resource>

</query>

<error code=“401” type=“AUTH”>

<not-authorized xmlns=“urn:ietf:params:xml:ns:xmpp-stanzas”/>

</error>

</iq>

Perhaps I don’t have the “principle” setup right or something? I had a devil of a time getting that damn thing to work. I tried to follow the instructions perfectly and it would fail everytime. I’ll try again with that.

Okay, I re-did the Principle and keytab file and this is now what happens… the send command is this:

<stream:stream to=“po-test” xmlns=“jabber:client” xmlns:stream="[http://etherx.jabber.org/streams]" version=“1.0”>

<starttls xmlns=“urn:ietf:params:xml:ns:xmpp-tls”/>

<stream:stream to=“po-test” xmlns=“jabber:client” xmlns:stream="[http://etherx.jabber.org/streams]" version=“1.0”>

<auth mechanism=“GSSAPI” xmlns=“urn:ietf:params:xml:ns:xmpp-sasl”>YIIFXgYJKoZIhvcSAQICAQBuggVNMIIFSaA DAgEFoQMCAQ6iBwMFAAAAAACjggRxYYIEbTCCBGmgAwIBBaENGwtDTUFPSElPLk9SR6ImMCSgAwIBAKE dMBsbBHhtcHAbE3BvLXRlc3QuY21hb2hpby5vcmejggQpMIIEJaADAgEDooIEHASCBBj1j5H9J9tiKwLJhmP8cWBgyPm7NaU1AvLzvJhDb2W/lFOenLC4uadejOhJegPeCVwaPM7pMVG6Kp/XIS0P9wDnOt6kzVPvtYL08ECC1WS6LjBGK3zi7477nGF8AqregTLwy1xvHxNQbzkktx4AkxkkGAi9eItVm5YzOjm1AD5iMDZPPpnaxVqv1J8xE7T60wt2b39hZxVrzHpejsH8hJ5Mk9WGjGNxQwJls36gKKrll 9AEYbZ1FsQStbxc8ZYkG1FfIwFud52SnuljK7K869zi1qgBeOG7FzxeG6e5nTHVrgzSaW/mAiocia2Ft UdTHjV07kLTp7jdc1FypxfwS0t1HrGSdMYNR25AnhfhZ78Zc1URi8J1mfYnLO5kO57MCH8X3h4nqb/8YvNZ7x7CJVvNgZcWBf6MxWGYSL56B l6yJZ4NeslitpaexfIqeD/LYTyNEGKiDt53u7lGUhdTtoSjzgIraZiJ3eAROOqMfIGqhrJYL95T5tqoZjIe21DvWUHKnZpagbiDEnbqvWfDNxZdWOmG1hMnGBGa8gWaUsyileqF5oHznxAHhE3QGa/4W5gkR1Aboy2qBwcfXtrzGgkg6UcuxZZgNIOzYCdMsnU 19dXNpYsayUxe2UnjGh21p7RpQDdSyp9m4GA0hj7LgDolKCmHFjGFtbw17Hn3GhTIzQrJEGM7cnWy/K0fVeCydS2W2zygqCcLmoqrzCTmXl7CcRxL4/Z77JUBvJQUkzSt0SsAaXDjgB20OzgO8y 4RwyB1GxONN44OahgNyYG3xUEIoaX9gTFRPEjmgel1/Ua5YXETXn4c5cx8hr2A3o6UVqLgFsFPgdysva7wlIdDWoiVKK0VB4KANf5au2DL2V5sSoralOH1eihcPOHu02aacTupXejTsPNjBZYb4B4aMk56Go9QczM2TJgq5L2RiF90ySRLFIWBZ1Y4Y6OG16+E7LaLHk7z5ZZ9QTo1voGvVHWVKbinTyRZZPMfuQLKxTQL3IkDzJJyMuoWORx85kbNLV5Ab1rOw2dISZEcA6N62FbHVVcs/mYZXuecHEK A9dN/y0BWSo6iFi8YB4UEQeGcjA7Z6UeiEIlhWd6A1KeKvkHnSn6tVzPfT23rUZHArq7UQhNGW8qkp/mTrYjKnt2NLUEAfyyQZuGxOj/MH/j28p27q4LluJ1L3X3UXoMd1YBUET8gboQy8ZPYfqIezyLyGmzj7pqYGCopSWcoBKBg8v2DJiIoIZOdD7JqyYnQvnAD89ksvbtTcpgSzz3CSIJbWpYTpmVz5qERmlLf0DuKoRa72guRBH70C3xTqSf5Qt2WQDwtkNvibzVseVatwZZqQDLxgZA4MsbZFyy6VwgHyrWxoFXGrMp IGMIG7oAMCAQOigbMEgbAEzth1uGyDzi4viL3ulGk8LaJVsMnPt7Zq4Z9qXDTvjPhFsDGDLLaXo6i12/rJ2V4pc2ybZarfC/uO4tdCro1htflRWjEyV0i1M2aJcwFVFPzB4s BBadDDfN9CZED4tgfm9ZaFDj01rnirweHN6hl1PsXRolId4jtqU22W/D1eGBHCsSl3wT79ggxL95nidf rO/bZsK23kp5p/mZr3P5ni7PyfPyrAIMq5VgehmENHQ==</auth>

The receive is:

<failure xmlns=“urn:ietf:params:xml:ns:xmpp-sasl”><not-authorized/></failure >

So, it looks like I’m getting farther. At least there’s some code being sent…

The gssapi token sent to the server looks good. I see the prinipal, realm and domain all in there, so it should be good to go on that end.

The “not authorized” message likely means your provider is not set up correctly, or you did not list the realm correctly in the sasl section. Check the debug log on openfire for more information.

When reading the directions I didn’t put a provider in there initially because it said most installations wouldn’t need it, but I did put it in there while debugging today and it still doesn’t work. I’m not getting any errors in the debug log related to the authorization or anything. here is the portion of the XML document that pertains to SASL.

<sasl>

<mechs>GSSAPI</mechs>

<realm>CMAOHIO.ORG</realm>

<gssapi>

<debug>true</debug>

<config>C:/Program Files/Openfire/conf/gss.conf</config>

<useSubjectCredsOnly>false</useSubjectCredsOnly>

</gssapi>

</sasl>

<provider>

<authorization>

<classList>org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy</cla ssList>

</authorization>

</provider>

Hope this helps. Should the config location be backslashes instead of forward? I couldn’t find any other example in the samples given.

I answered my own question, I changed the path to have backslashes and it still didn’t work.

The only errors I get in the debug log are errors for retrieving groups:

java.lang.NullPointerException

at org.jivesoftware.openfire.ldap.LdapGroupProvider.populateGroups(LdapGroupProvid er.java:673)

at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:99)

at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:184)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:102)

at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:65)

at org.jivesoftware.openfire.group.GroupManager$2.run(GroupManager.java:122)

at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

at java.util.concurrent.FutureTask.run(Unknown Source)

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)

I figure this is something that I will deal with at another time with another thread.

I know I should save up and post only once… I thought I’d add my gss.conf file for you. It’s this:

com.sun.security.jgss.accept {

com.sun.security.auth.module.Krb5LoginModule

required

storeKey=true

keyTab=“C:/Program Files/Openfire/resources/jabber.keytab”

doNotPrompt=true

useKeyTab=true

realm=“CMAOHIO.ORG

principal=“xmpp/po-test.cmaohio.org@CMAOHIO.ORG”

debug=true;

};

This is directly from the instructions in the SSO Configuration.

I really appreciate the help you’re giving me so far.

More Information

Openfire is on Windows 2003 server
Version 3.3.3 as of today.
Spark latest x.x.7 whatever that is.
AD Server = Windows 2000 server.
I notice that when logging into the admin console on the PO test server, I have to have the username be lowercase (thomas.deliduka) or else it will complain I cannot login (bad password) but in Spark when I’m attempting SSO, it is in there with uppercase (Thomas.Deliduka) and I wonder if the server is rejecting it because of the case sensitive username?

Okay, I’m getting somewhere. With further research I found that the krb5.ini file had to be on the SERVER!! not on the workstation! Ack!

Once I put it on there, I now get debug information at least. It is this:

Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is C:/Program Files/Openfire/resources/jabber.keytab refreshKrb5Config is false principal is xmpp/po-test.cmaohio.org@CMAOHIO.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false

principal’s key obtained from the keytab

Acquire TGT using AS Exchange

authentication failed

Cannot get kdc for realm CMAOHIO.ORG

I noticed someone else when using ktpass they set the encryption to Kerberos or something, I didn’t do that and it’s the default, whatever that was. Could that be the probelm? It said it can’t get the kdc for realm I’m going to search on that now. I’m 99% positive I put in my AD server just right I think I copied the krb5.ini file in a post above.

Things are moving quickly now. I figurd out the problem with the krb5.ini file. Now I see this error in the debug.

Caused by: javax.security.sasl.SaslException: thomas.deliduka@CMAOHIO.ORG is not authorized to connect as thomas.deliduka

The debug window also has this which looks like it’s a successful login!

Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is C:/Program Files/Openfire/resources/jabber.keytab refreshKrb5Config is false principal is xmpp/po-test.cmaohio.org@CMAOHIO.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false

principal’s key obtained from the keytab

Acquire TGT using AS Exchange

principal is xmpp/po-test.cmaohio.org@CMAOHIO.ORG

EncryptionKey: keyType=1 keyBytes (hex dump)=0000: A8 4C 7C 54 3B 64 62 13

Added server’s keyKerberos Principal xmpp/po-test.cmaohio.org@CMAOHIO.ORGKey Version 1key EncryptionKey: keyType=1 keyBytes (hex dump)=

0000: A8 4C 7C 54 3B 64 62 13

added Krb5Principal xmpp/po-test.cmaohio.org@CMAOHIO.ORG to Subject

Commit Succeeded

I may have an answer to this by the time anyone reads it but in case I don’t it’d be great if anyone knows what is going on.

You have successfully authenticated, but not authorized (there is a key difference there). Make sure you have the authorization provider correctly set up in your openfire.xml, as that is the most common cause of that error.

My provider code in the XML looks like this:

<provider>

<authorization>

<classList>org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy</cla ssList>

</authorization>

</provider>

But still in the debug it says: No AuthorizationProvider’s found. Loading DefaultAuthorizationPolicy

And then it gives the error I posted above. What are valid options I can put in there? Some I have seen the use of “Provider” instead of “Policy”

Message was edited by: Tomnibus (To remove “code” values)

My guess is you have two sections. You can only have one, just combine them.

SUCCESS! I successfully logged in! That was it, I didn’t realize there was more than one provider tag in there.

Now it looks like, based on my initial tests, for those who are not on with “SSO” I will have to trash their spark folder and start from scratch on those people.

Thanks again slushpupie, you were a great help.

Message was removed by: Matt Tanksley new discussion created.