Single Sign-On Error

Openfire Openfire Support
1

My wildfire server (currently running the latest v. 3.1) has been authenticating via RADIUS for about 3 months now… everything runs smoothly. I just recently attempted to integrate Norman’'s SASL/SSPI to use single sign-on with Pandion clients. When I attempt to use the integrated windows authentication I get the following debug error on the wildfire server:

2006.10.26 14:25:14 Connect Socket[addr=/xxx.xxx.xxx.xxx,port=1324,localport=5222]

2006.10.26 14:25:14 SaslException

javax.security.sasl.SaslException: AcceptSecurityContext failed (0x8009030c): The logon attempt failed

at net.za.darkskies.security.sasl.SSPIImpl.evaluateResponse(Native Method)

at org.jivesoftware.wildfire.net.SASLAuthentication.handle(SASLAuthentication.java :251)

at org.jivesoftware.wildfire.net.SocketReadingMode.authenticateClient(SocketReadin gMode.java:117)

at org.jivesoftware.wildfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:136)

at org.jivesoftware.wildfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 62)

at org.jivesoftware.wildfire.net.SocketReader.run(SocketReader.java:123)

at java.lang.Thread.run(Unknown Source)

2006.10.26 14:25:14 Logging off xxx.xxx.com/c8bb2044 on org.jivesoftware.wildfire.net.SocketConnection@5354a socket: Socket[addr=/xxx.xxx.xxx.xxx,port=1324,localport=5222] session: org.jivesoftware.wildfire.ClientSession@4577f9 status: 1 address: xxx.xxx.com/c8bb2044 id: c8bb2044 presence:

I’'ve been through the instructions twice - dropped the files in their place and made the necessary changes to wildfire.xml and java.security.

Any ideas of where to look and how to proceed with this one?

Thanks.

2

Can you download the SSPI Workbench and see if you can reproduce the issue.

The client and server machines should both be domain members, and you should log in to the client machine using a domain account.

It’'s currently un-tested if the domain account needs log in access to the server. (do you have a policy blocking this btw?)

3

I’‘ll take a look at the SSPI Workbench as you suggested… I figured I’'d throw this additional info out first though:

There are 2 domains involved. Domain ABC contains 95% of the users. We don’'t control this domain. We have a domain XYZ that has a 2-way trust with ABC… therefore, most of our client machines are part of the XYZ domain but can select domain ABC from the windows login and use their ABC credentials. (hopefully that made sense) The RADIUS (steel belted radius) server is also part of the XYZ domain, however, because of the trust between ABC and XYZ, can authenticate users in the ABC domain. The wildfire server is also part of XYZ. Since it sends authentication requests to the RADIUS server, users of ABC can login successfully.

So… the client machine is part of XYZ, however, the user that logged into Windows selected the ABC domain at login and supplied their ABC credentials (authentication is sent to XYZ domain controllers and then up the trust to ABC).

In the section of wildfire.conf I have tried both ABC and XYZ.

Does this shed any light as to what might be causing the error?

4

Mmm, try running the workbench client on the machine that you’‘re running pandion from. Run the server side on the wildfire server. I’'m not sure how cross-domain trust works, nor how RADIUS works

If you can get SSPI Workbench working in NTLM mode, then you’'ve got a good chance that the Wildfire SASL-SSPI bridge should work correctly. (btw: Have you tried a client logging in as a XYZ domain user?)

5

I upgraded to the latest 3.1.1 and decided before upgrading that I would wipe my current settings (since this a test box) and start from scratch. Long story short… the single sign-on is working now. I’'m not really sure what I did different. The only big difference was the upgrade to 3.1.1.

Thanks for your help… and the plugin.

6

I’'m running 3.1.0 still (3.1.1 was released the day after we rebuilt our server). My guess is still that there was some other authentication issue that was causing the failure. (e.g: something like Group Policies that denies log on the server)