|
Found a post in the Psi (Jabber client) forums regarding single-sign on using AD credentials.
http://psi.affinix.com/forums/index.php?act=ST&f=1&t=2673&s=703e0ead877d8dcb7ae64b4112dc7c4a The last post is from Chris Mullins at Coversant, Inc. dated April 20, 2005 stating: [start post] This SASL mechanism lets us do native windows authentication - user don't have to enter their username or their password. We will at some point make a JEP out of it - I could probably be persuaded to make an Informational JEP without too much trouble. If anyone needs all the gory technical details, feel free to drop me an email. – Chris is listed on this page (http://www.coversant.com/portal/DesktopDefault.aspx?tabid=45 A quick google search turns up his e-mail address as chris.mullins at coversant.net. To avoid having multiple people e-mail him for the technical data, I've left that to the JM developers. If others do feel the need to e-mail him, I would simply ask if he had time to write up an informational JEP so that other servers/clients could interoperate with his company's products. Some comments from the Peanut gallery.
From the Pandion source, it looks like they're using a non-standard mechanism to get Kerberos/NTLM support - they're using the 'SPNEGO' mechanism name, which isn't even listed on the IANA's assignment list. If you're using the GSSAPI SPNEGO mechanism to offer a choice between NTLM, or Kerberos v5, the offered SASL mechanism should be GSS-SPNEGO. This mechanism is documented in draft-ietf-sasl-gssapi-02.txt. If you're only offering Kerberos v5, then the mechanism name should be GSSAPI (documented in the same place, and in RFC 2222). If you can, its best to offer both. Most Unix clients won't be able to support SPNEGO. If anyone's interested in working on GSSAPI support, I've implemented this for jabberd2, and have patches for a number of clients (Gaim, Psi, Coccinella). Cheers, Simon. Simon – you don't have any experience doing GSS-SPNEGO in Java, do you?
 We'd love to offer support for this but don't have a lot of experience in this area. I don't have much Java experience at all - hence why I ended up adding SASL and GSSAPI support to jabberd2, rather than anywhere else.
However, Java would seem to have a nice plugin interface to its security layers. As far as I can tell, you should be able to get GSSAPI support just by using the javax.security.sasl SASL provider. Perhaps this would be better discussed offline - you can email me on simon@sxw.org.uk, and xmpp: sxw@jabber.org http://jcifs.samba.org/
 may be of use.It's a java cifs/ntlm library written by the samba folks. Comes with an ntlm http servlet filter which some code may be borrowed from. SPNEGO support is supposed to be in mustang. Maybe a back port could be done.
I have implemented Kerberos in servlets for web authentication using JAAS. Simon, I'd be interested in how you implemented it in jabberd2, particularly regarding principals and realms, so everything works together in a happy fashion.
I'm not sure how the principal should work in environments where the XMPP server is not running at the root of the domain. For example: I want my users to be known as user@company.foo, NOT user@server.company.foo, so if the server name changes, or if the servers are behind a load balancer of some sort, everything still works. So should the server principal be "xmpp/server.company.foo@COMPANY.FOO" or "xmpp/company.foo@COMPANY.FOO"? Re: Matthew Willis' last comment
The server principal should be xmpp/server.company.foo@COMPANY.FOO as the server principal should indicate the DNS hostname the client is connecting to. Since its not a host/ principal, you could get away with either assuming the clients knew what to expect. Sorry, I haven't been watching this issue, so I've missed some of the responses here.
Matthew: jabberd2 currently uses the FQDN of the server as the server principal. So, we'd have xmpp/server.company.foo@COMPANY.FOO By my reading the RFCs are vague as to whether this is acceptable or not. The same MITM attacks apply as with I had a chat with stpeter about this a while back. My feeling is that the language in the RFC is rather woolly, in particular when you come to implementing s2s GSSAPI. If anyone wants more information, or to do interop testing, feel free to contact me - simon (at) sxw (dot) org (dot) uk I've done some playing around with xmpp.py and I've managed to get Padion to login via it's sspi method.
The easy ('right'?) way to implement this in wildfire would be to use the native java api's (see http://java.sun.com/j2se/1.5.0/docs/api/org/ietf/jgss/GSSContext.html If I can get a JDK up and running, I'll try and build a SASL module that supports gssapi/gss-spnego? (probably 'spnego'/'ntlm' to make Pandion work) 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: Looking for ideas using google it seems that I've missed a crucial step here somewhere. 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. We cab contact Hal to get in contact with NTLM experts so we can implement this feature. Thanks Hal.
I also looked at the wildfire sources. IMHO Wildfire should already be able to do GSSAPI if the client requests it, because it already uses javax.security.sasl. I could not yet figure out how to supply wildfire/sasl with a keytab, so I could not test it?!?
I would suggest to let wildfire announce itself as able to do GSSAPI and just try it using psi with simons patch I've managed to stick together a SASL-SSPI module for Win32 [1].
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 user@xmpp.domain) 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. [1] http://www.darkskies.za.net/~norman/jabber/java-sasl-sspi.zip Please please please add this feature as soon as possible. In corporate environments, this is a huge benefit.
great, delayed for another revision...I'm getting tired of employees asking me why they cant logon (changed their windows password), of course nobody reads IT emails or FAQS...
For those or you wanting to try your own builds, here's a copy of the patch sent to me by Jay:
http://www.darkskies.za.net/~norman/jabber/wildfire.gssapi.tar.gz I haven't downloaded and installed ant yet, so I have no idea of how well this works, etc. Basically someone needs to sit down and write a patch that enables Kerberos and NTLM and has the ability to disable the other methods. If the patch is solid enough, and doesn't break the default install, then I'm sure Matt would be happy to apply it. In fact I think with the new 2.6 release, that the only thing missing is the sspi libs (which Jive are free to use mine), and announcing the support for NTLM.
Norman – that sounds quite simple.
What are the steps we should follow to integrate and then test this out? If you want to drop me an email, that would be great. Ok, after some testing, I have discovered that Windows Active Directory is enough Kerberos that the generic GSSAPI methods will work with it. My patches should be all thats needed, along with some detailed documents describing how to set it up. Those will come shortly. Since this dosnt support NTLM (thats the older NT4.0 method) and there is still a lot of that out there, I think there is still reason to get the SSPI libs in there. But keep in mind that Microsoft has basicly deprecated its use, so Kerberos methods should be used when possible.
My patches from above are a quick hack, however. Im working on the more elegant solution, but that requires changing the way SASL works in wildfire. Those changes will not only make GSSAPI possible, but provide a nice way to introduce new mechanisms as well (like NTLM, etc) Also: I got NTLM working today with the latest nightly build of Wildfire, a slightly patched version of Pandion and v3 of my sasl-sspi libs. (http://norman.rasmussen.co.za/dl/sasl-sspi/
)
There are one or two rough edges that need smoothing out, but for willing alpha testers - we're definitely heading towards a testable implementation. I'd love to do testing. I think I've got the sasl-sspi libs installed, but I don't know what to do to patch Pandion. Can you fill me in?
Thanks! I've put a howto up on the download site - http://norman.rasmussen.co.za/dl/sasl-sspi/
It's very brief, but it should contain enough to get started. I have a patch that changes the way SASL works in Wildfire, and adds GSSAPI support. This is a fairly significant change, and thus requires testing on a bunch of platforms. The patch is still young, but it does work. I wont bother putting full documentation here in JIRA, but I do have some.
This patch applies against Wildfire in subversion- revision 3814. It should apply against other versions pretty easily though. Patch looks fine, but I would change the "Check that the mech is a supported mechansim. Maybe we shouldnt check this and allow any?" in getMechList to allow "PLAIN", "ANONYMOUS", "EXTERNAL" (which you patch seems to treat as server only - client could do external too), and whatever Sasl.getSaslClientFactories().getMechanismNames() supports. (fyi: my sasl-sspi package has pure-java server side SASL implementations for "EXTERNAL" and "PLAIN" too)
Perhaps also change the way sasl mechs are checked, add a: "if (not getMechList().contains(mechanism)) { Log(); success = false; isComplete = true; break; }" right at the top of the case AUTH, then continue with the rest of the checks as before. This means that the mechlist is only checked once, so less code to add/debug/test. It would be useful to put the System.setProperty values into the config file - Possibly as a sub-xml node of the mech node. That way, there's no hard coding of 'for GSSAPI add this stuff'. Also the 'props.put' of "Sasl.QOP" and "Sasl.SERVER_AUTH" shoudl be in the config file. That way any future SASL mechanism that needs global or specific properties is catered for. Is there still work on this topic? Last post is about 2 month old.
When will there be a wildfire release with kerberos support? I believe that a lot of the required changes for external SASL libs to work are already in the 3.0 codebase. (2.6.2 has about half of them - enough to work for NTLM)
If you're adventurous, there's some effort to begin this integration a bit early:
Added to Wildfire 3.0.0 as experimental code.
Documentation is also missing. Future version should provide good documentation so that admins can easily configure the service.
I'd like to migrate from jabberd2+GSSAPIpatches to Wildfire 3.x.x. Can some post even some basic docs on how to set this up? I'd like to use LDAP+GSSAPI/Kerberos.
Typical bloody developers (I am a SysAdmin for a development house
). No documentation, but the ticket is closed 
Seriously, though. I'm itching to set this up, but don't have time to experiment. I would greatly appreciate some doco from someone who does have the time to experiment. Marking the issue as "fixed" was actually a tough call. We wanted some way to indicate that kerberos was entering "experimental" status in the server, and closing the issue was our best way of doing so. Over the coming weeks, we'll be filing a bunch of new issues that cover the work that needs to be done to actually make the feature usable.
I have some (limited) documentation on this, but no place to put it. As soon as Jivesoftware gets a Wiki-like feature set up, Ill have a place to put it. Or if someone has a place it can be hosted online for me, its a start. But being experimental, it would be best if I have some ability to update it.
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. Today I am setting this up with Wildfire 3.0.1 on a SUSE Enterprise Linux 10 (MIT Kerberos now) server. I'm trying to migrate from jabberd2+GSSAPI to Wildfire 3.0.1.
I think I've run into a snag. A little background. I want my JIDs t o be: username@gurulabs.com I have DNS SRV records setup to point at the actual host such as: _xmpp-client._tcp IN SRV 5 0 5222 mail.gurulabs.com. This is same as what Matthew Willis wanted at the begining of this thread, see: http://www.jivesoftware.org/issues/browse/JM-281#action_10890 In Wildfire GSSAPI/Kerberos auth DOES WORK if I set xmpp.domain = "mail.gurulabs.com" but if I set xmpp.domain = "gurulabs.com" (which I believe is what I need to do so I have my JIDs like I want them) then it does not work and I get the following error: javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)] Any ideas? BTW, my confgs are:
[snippet from wildfire.xml] /opt/wildfire/conf/gssapi.conf] This does work if I set xmpp.domain = "mail.gurulabs.com" but not if I set xmpp.domain = "gurulabs.com". I think you need to try:
com.sun.security.jgss.accept { (note the removal of 'mail' from the principal) Norman,
Thanks for the response. From what I've read (including comments (from Jay and Simon) at the top of this bug/rfe) the principle should be the FQDN of the server that is running the Jabber software. My client (gaim) obtains a service ticket for xmpp/mail.gurulabs.com@GURULABS.COM. So, is this is a bug then in the current Wildfire GSSAPI implementation? I hate Kerberos errors. "Failed to find any Kerberos Key" could mean just about anything. The fact that it works with the domain==realm tells me Kerberos and DNS are configured correctly. I would like to see Kerberos debugging output from the client side as well. Also, there is more debugging output- you have debug=true in the gssapi.conf, that output goes to stderr, so nohup.out or something should have more messages.
It concerns me that the exception is coming from org.jivesoftware.wildfire.net.SASLAuthentication, since none of my code has had a chance to look at the credentials yet (its all Java internals at that point). Can you double check that NOTHING else has changed but the domain setting between your configurations? I fixed a bug with GSSAPI-
In SASLAuthentication.java (near line 194) when we create the SaslServer object, we have to give the server name. To get the server name, we had just used session.getServerName() . The problem with that, is that method returns whatever the xmpp.domain property is set to. When using GSSAPI the server name needs to be the FQDN. So to get the FQDN we can use session.getConnection().getInetAddress().getCanonicalHostName() instead. Fairly simple change. However, if the SASL method is not GSSAPI but using some other method that is expecting the xmpp.domain, it will break. An example is DIGEST-MD5. The JavaDoc for SaslServerFactory says that the server name paramater to createSaslServer must be the FQDN, so it might work. Currently my SASL libraries on my client has a bug in it that crashes every time CRAM-MD5 gets used, so I cant verify. I use
Pandion v2.5 WildFire v3.2.4 config with SASL-SSPI v6.2 http://norman.rasmussen.co.za/dl/sasl-sspi/wildfire-sasl-sspi.v6.2.zip
if I configured Pandion Integarded Windows Authentication and not conect the logs of WildFire is: 2007.05.03 13:23:07 No AuthorizationProvider's found. Loading DefaultAuthorizationPolicy Somebody knows that it is what he passes Your config.jive.sasl.realm variable should be set to ECOA30, and you need to configure the authorization.classList to include the StrictAuthorizationPolicy. It looks like openfire can't find the authorization element, so my guess is that either you missed it, or you duplicated the provider element.
Many thanks the problem was :
<sasl> <mechs>ANONYMOUS,PLAIN,DIGEST-MD5,CRAM-MD5,NTLM</mechs> <realm>ECOA30.ERY.COM</realm> (fails) </sasl> Instead of this <sasl> |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Add support for Kerberos/NTLM (experimental status)
http://forums.pandion.be/viewtopic.php?t=441
===
You need to use Pandion 2.1.2 beta to have single sign-in support.
The single sign-in code is in XMPPOnStream.js where it checks for SPNEGO or NTLM mechanisms in the SASL handling.
Read this information to learn more about SSPI:
http://msdn.microsoft.com/msdnmag/issues/01/04/security/
http://msdn.microsoft.com/msdnmag/issues/0800/security/default.aspx
Dries wrote a summary of that information and explains how to use it in XMPP:
http://www.pandion.be/upload/gssapi-sasl-draft.txt
(Note that GSSAPI is similar but not identical to what we ended up implementing.)