After I have upgraded my Wildfire 2.6.2 to 3, I was unable to use Integrated Windows Authentication. Looks like that Pandion patch plus the SASL-SSAPI files is not working on version 3. Did anyone make it work ?
I was also wondering if the native support for kerberos could be used to replace this patches and if so, how to do it ?
Thanks
I am interested in hearing about getting Integrated Windows Authentication working with Pandion and Wildfire 3.0 as well. Appears not to work for me thus far, but I haven’'t followed any special instrucitons that might involve patching anything or the like.
I dont have any experience with Pandion, but I have gotten SSO working with Wildfire. It is still very experimental and a bit of work. Does Pandion use GSSAPI by chance? If it does, you are in luck and can use wildfire without patches. To get it working you will need to have Active Directory or Kerberos, with some level of administrative privledges.
Hi,
I’‘m not sure if it does use it GSSAPI, but I’'m willing to give it a try anyway. Could you guide me through ? What did you do in Wildfire ? What client are you using ?
Thanks
Right now the only client tested is a modified version of Spark (Smack has the support, really). I hope to test Gaim sometime soon. I have some half written docs, Im going to try to finish them up this week.
This is a little old, but it may give clues as to what Pandion uses:
http://forums.pandion.be/viewtopic.php?t=441&highlight=gssapi
Hopefully they will eventually work with SSO. We won’‘t be able to use Spark for our client at the office as it’'s memory usage has no place on our terminal server environment. Looking forward to getting more information on Wildfire + Pandion SSO.
Does anyone has any idea why the patch (SASL-SSAPI) that used to work on 2.6.2 is not working on 3.0.0 ?
It was pretty simple to implement and use.
I’‘m going to have to toss out a guess that it has to be a factor of enough difference between 2.x and 3.x, plus the fact that there is some experimental SASL-SSPI code (or something like that) in 3.0. Something new probably has to be done to make this work. I can’‘t make this work at all in 3.0, but I didn’'t try it in 2.6 before I had moved to this new version.
I dont know that the SSPI code made it in, but the GSSAPI code did. And in all fairness, the SSPI code dosnt need much to get it, only a simple code change to allow arbitrary SASL mechs is needed, in addition to adding the SSPI classes to the classpath.
To get GSSAPI working, you have to do a few things. First, you need to have that mechanism listed in the wildfire.xml config. Its a new option that has not yet been documented, but its pretty easy. Just add this into your config:
/code
This will set the server to advertise GSSAPI. The is a comma/space seperated list, so you can keep PLAIN, etc if you want. Order is important though, put it in the order of preference, which should be most secure first (like GSSAPI). The realm is important, it must match your kerberos realm. If you use Windows AD, it is the domain name. There have been a few issues if your domain is not all upper case, so try it all upper case.
Next, you need /opt/wildfire/conf/gssapi.conf to be created. Its a simple file:
/**
*/
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="/etc/jabber.keytab" doNotPrompt=true useKeyTab=true realm=“REALM.COM” principal=“xmpp/jabber.example.com@REALM.COM” debug=true;
};
/code
Again, make sure your realm is set correctly. If you are on windows, you need to figure out how to make a keytab. Thats the part of the documentation Ive been working on and is incomplete. But, you can get a head start by reading this: http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx
After you get this all set up, Wildfire should now accept Kerberos. A few things Ive learned:
Most Kerberos implementations use stronger encryption types than the default Java install understands. You must download the “Unlimited Strength JCE” for your Java version (it is free, but not availible in all countries due to US export regulations). Some encryption types in MIT kerberos (AES, in particular) are only supported in the Java 6 betas.
With windows active directory, you will likely need to enabled Single-DES for each user. A bit of a pain, I know.
If you want to map principals to usernames you will need to set up some authorization providers (these are new, and different from the authentication providers). The defaults will work for most people, however.
Whew–that’‘s a lot of information that just shoots right past my know-how. I think for the time being I’‘ll live without SSO as it’‘s going to be more work than just having people sign in with their AD user/pass and making them aware that they need to use their new password with our messenger when their password has to be changed. I do look forward, though, to the future of SSO and it being mainstream with Wildfire. Hopefully it won’'t require a lot of overhauling on the backend to make it work, either.
Thanks for the information, though. I may sift through some of it when I get some time.
Yeah, right now SSO is not simple. It requires some understanding of what AD and Kerberos is all about. I hope when I finish writing documentation it will at least be an easy to follow guide, but its still a bit involved.
I also try to configure Integrated Windows Authentication with Wildfire 3.0.1 and Pandion 2.5. It seems to me that Pandion doesn’'t send username to server. This is what I get after trying to login:
2006.07.17 16:46:10 Connect Socket[addr=/192.168.64.199,port=3129,localport=522
2]
2006.07.17 16:46:13 Logging off mywindowsserver.mydomain.reg/cc4c695f o
n org.jivesoftware.wildfire.net.SocketConnection@1cefde4 socket: Socket[addr=/1
92.168.64.199,port=3129,localport=5222] session: org.jivesoftware.wildfire.Clie
ntSession@7e5619 status: 1 address: mywindowsserver.mydomain.reg/cc4c69
5f id: cc4c695f presence:
section to wildfire.xml and made gssapi.conf, but didn’'t configure realm
Waiting for full guide for Windows AD.
I did some docs for wildfire 2.6.2 based upon the work of Norman Rasmussen have you got pandion working with wildfire 3.0?
Berny
Hi,
I used your paper on version 2.6.2. But it doesn’'t work on version 3.
I’‘m still waiting for an update. I heard that the version 3.1 is about to come out (end of this month) let’'s hope this feature is documented there.
If anyone has any idea how to accomplish it would be perfect.
Hey slushpuppie,
I am willing to do / get done the scripting side and do the docs to make everyone understand it.
I have a good idea on Kerberos and AD, I saw your post over here:
http://www.jivesoftware.org/community/thread.jspa?messageID=123718
But from the looks of things, clients aren’‘t up to speed yet. Unless of course, I am missing something and some of the clients are up to speed and I just haven’'t seen it yet.
Berny
I have updated my libs at http://norman.rasmussen.co.za/dl/sasl-sspi/ to support NTLM in Wildfire 3.0+ for Windows. That should get everyone that was using NTLM in 2.6.2 back on their feet with the new version.
I just wanted to say thanks Norm!
THANK YOU VERY MUCH!!!
I will update the doco tomorrow evening I guess, once I get V3 re-installed in the lab.
Berny
normanr, many thanks for your job, I appreciate it. I’‘ve installed it on my test Wildfire 3.0.1 and patched Pandion is working nice. However, now I can’'t get an access to admin console using my Windows credentials (previously ,on Wildfire 2.6.2, I could), in admin-console.log I found the following:
16:53:45.173 TRACE [Acceptor ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9090]] org.mortbay.util.LogSupport.ignore(LogSupport.java:36) >03> IGNORED
java.net.SocketTimeoutException: Accept timed out
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at org.mortbay.util.ThreadedServer.acceptSocket(ThreadedServer.java:432)
at org.mortbay.util.ThreadedServer$Acceptor.run(ThreadedServer.java:634)
Furthermore, now I can’‘t use Jabber client doesn’‘t support NTLM auth, only Pandion is accepted by server. Previously I could. It looks like my Wildfire doesn’'t understand plain auth. Is it possible to fix?
bstapleton wrote:
I just wanted to say thanks Norm!
THANK YOU VERY MUCH!!!
I will update the doco tomorrow evening I guess, once I get V3 re-installed in the lab.
Berny
I just wanted to say thanks for your previous guide! I am looking forward to the updated one for Wildfire 3.
Hrm, I’'ve just upgraded to Wildfire 3.0.1 (at work) today. Both Pandion, Psi, and the admin console are all working fine. (Not sure about the log message, maybe ask in a more general sort of thread)
Things to check:
what’'s in the config file for jive.sasl.mechs? (have you used the default?)
what providers are you using? (I’'m using authorization (new) and user,auth,group,vcard (from LDAP integration))
are all the providers in one stanza? (i.e. you haven’'t got two sets of providers by mistake?)