copy & paste from JM issue:
Comment by Norman Rasmussen [/i]
I did some digging inside of Wildfire, and found that Java’'s javax.security.sasl.Sasl supports: CRAM-MD5, DIGEST-MD5 and GSSAPI.
So I figured I could hardwire Pandion to force GSSAPI (which wildfire accepts as a SASL mech), well doesn’'t seem to work - yet.
Wildfire gives me:
javax.security.sasl.SaslException: Failure to initialize security context Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
Looking for ideas using google it seems that I’'ve missed a crucial step here somewhere.
I’'m running wildfire on win2k3 as user INTERNAL_SVC_Wildfire serving xmpp domain externaldomain.com.
I’'ve created a krb5.ini (copy & paste for working linux copy - that got rid of the first exception)
I used setspn to add both xmpp/externaldomain.com and xmpp/internal.server.local. (doesn’'t seem to help)
Lot of people seem to be using a jaas.conf, but I’‘m not sure what it should look like. (apparently newer versions of java don’‘t need it, not sure if 1.5.0 counts as new enough, requires a -D to set the path to the file, which I’'m not sure how to set for wildfire)
Of course, the whole operation is moot, because I think Padion only supports NTLM (and not Kerberos), but I could always try and implement the Kerberos stuff in python and/or Psi, or we can kick the Padion guys into enabling Kerberos too. Maybe the new version (mustang, aka java 1.6.0) of SASL will support SPNEGO and/or NTLM.
Comment by Norman Rasmussen [/i]
I’'ve managed to stick together a SASL-SSPI module for Win32 .
Contains full sources, for both SSPI ‘‘pass-through’’, and server-side implementations of PLAIN and EXTERNAL.
There’‘s no ‘‘licence’’ as such, but consider it GPL, with an exclusion for the jive team to release the code under it’'s dual-licence.
Doesn’‘t support wrap and unwrap, (not required for XMPP-SASL). Also hasn’‘t actually been tested with anything but the SASLCheck tool that comes with it. This includes the fact that I’‘ve not changed it against Pandion or xmpp.py, and I certainly haven’‘t installed the module on the wildfire box, and poked it to see if it works. (probably wouldn’'t because NTLM gives authid: ntdomain\user and it needs to be mapped to email@example.com)
See SASLCheck comments for how to handle passwords supplied by client via callbacks (eg: when mech is PLAIN) This would be most useful to make the XMPPCallback handler in wildfire implemented on the stream object directly. Then it could handle PLAIN and EXTERNAL directly, i.e. only with sasl framework.
(that url could be unstable over the next few days, as we’'re having power issues where that box is hosted)
I’‘ve done a minor fix in the sspi libs, fixes a JVM null pointer crash, but it requires some java class changes too. If I have some spare time this weekend I might look at getting wildfire building, and then I’‘ll try and patch the SASLAuthentication class in wildfire\src\java\org\jivesoftware\wildfire\net to support NTLM via my library properly. (’‘case AUTH’’ needs to send the initial response if it’'s supplied)
Of course, my library only works on a win32 environment, you probably find that the default java libs are fine for *nix. Also I expect my library to be replaced with native java code when Java 1.6 (mustang) is released - so I’'ve made it match the existing APIs as much as possible.