I’'m using Wildfire 3.1.1 with LDAP integration.
All the clients I’'ve tried (Pandion, SoapBox, Spark, Exodus…) work great.
But there is this new .NET SoapBox Studio 2007 I’‘m considering using for some client development, but it’'s sample program cannot logon to my server.
I turned on debug tracing, and I see the issue, but I don’'t know if it is an issue with WildFire or the client library.
When the logon request arrives from the new Soapbox Studio 2007 client, it traces that it is looking for "username@my.domain.org" in OU… So it seems to be sending the full JID as the userid in the connect request.
When I logon from Spark, WildFire debug traces that it is looking for “username” in OU…
Now, I also tried the Soapbox sample program against google talk, and it logged me on just fine. So perhaps this is either a “bug” or a “feature request” for LDAP logon requests that if the userid is passed in the form of a JID, that the userid portion of the JID be used when searching the LDAP database.
The Soapbox Studio is open source, but I haven’'t successfully built it from source yet, but when I do I can try to change it there if necessary.
What do you think? Is this a server issue or client? I don’'t know the XMPP spec enough to say…
Ok, I see that I didn’‘t give enough info here, probably… Let’‘s say my Active Directory domain name is mydomain.com. But for testing, I put the program onto a machine at wildfire.mydomain.com. I didn’'t know about SRV records, I setup the machine as @wildfire.mydomain.com.
So I then configured to use LDAP with my AD server. With clients such as Spark, it logs onto wildfire.mydomain.com just fine, because it passes just my user id when logging on. But this new library passes the JID as the userid. So it is trying to find userid@wildfire.mydomain.com in my domain. This will always fail.
Had I set up the server with the name mydomain.com, so the user JID would be userid@mydomain.com, it would work fine with this client. I can logon to other servers, including JIVE servers with LDAP integration, as long as the JID and the AD domain have the same domain name.
So perhaps one could say this is a low priority issue with a test server. Personally, unless the spec says to send the JID for the userid when authenticating, I think it is a bug in the client library.
So do I take credit answering my own question?
We came across this issue a few weeks ago, and it started a big long ugly thread on the XMPP standards mailing list about what is “right” to pass as the authid for SASL Plain Authentication.
At the end of the day, we couldn’'t figure out what the right way was (SoapBox, and all the other servers we tested pass a full JID there, but Wildfire sends only the user name), so we implemented “both” in our framework. The default is to a full JID as the authid.
To force the SDK to pass only the user name for the authid, call:
// Tell the Auth Mechanism to use only the user name
// portion of the JID for the AuthID.
PlainAuthMechanism.AuthIdType(false, jid.Server);
The “server” name that is passed in is the domain name of the server.
Current versions of the SoapBox Studio have this fix:
http://www.coversant.com/downloads/nontrial/SoapBox.Studio.x86.exe
This was verified to fix the problem that you’'re seeing.
–
Chris Mullins
Coversant Chief Architect, XMPP Council Member, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins