Mailing List Message #92269
From: Sambedi Fahted <>
Subject: Re: SASL authentication with external LDAP - for SIP/XMPP/Pronto
Date: Fri, 17 Aug 2007 20:11:10 -0400
To: CommuniGate Pro Discussions <>
Is there a reasoning behind why SIP, XMPP, XIMSS, etc require plain text passwords via SASL+ external (LDAP)auth?
I created a dev environment ("community" CGate server and replicated OpenLDAP server running saslauthd) to test SASL authentication using the script. I was able to authenticate users to access XMPP and Pronto when their passwords were stored as plain text.... When the passwords were MD5 or SSHA, no luck. 

18:36:07.545 3 XIMSSI-000014([]) write failed. Error Code=connection reset by peer
18:36:15.916 4 EXTAUTH out(120): 17 SASL(CRAM-MD5) (XIMSS) 6dee5d41d714bc495fde8138bbb920ee "<>" []\n
18:36:15.916 4 EXTAUTH inp(32): * trying to connect to
18:36:15.921 4 EXTAUTH inp(74): * searching ou=users,dc=testdomain,dc=com for (&(uid=testuser)(objectclass=*))
18:36:15.955 4 EXTAUTH inp(65): 17 PLAIN "{SSHA}1Q91PicfbQp0zIeLBGxEfkc1K45RVGtGMFdnZ2ZTSWw4NU13"
18:36:15.955 1 EXTAUTH SASL/plain password is incorrect. Error Code=incorrect password
18:36:15.955 1 ACCOUNT(testuser) login(XIMSS) from [] failed. Error Code=incorrect password

Mail worked fine with either plain text or obfuscated passwords. Honestly though, I'm not sure if adding the SASL layer to LDAP was the right way to go about it.
Converting all of my existing LDAP accounts from SSHA to PLAIN would pose a series of problems and despite our secure network, it goes against my paranoid nature to keep passwords on disk in plain text.
I like Bret's suggestion of synching an external auth directory with Communigate's internal directory... could that be done by scripting ldif inputs or would there be a more efficient way to do it?
I would also suggest making all services authentication methods consistent with mail, but then that goes back to my opening question.

On 8/15/07, Bret Miller <> wrote:
> From: Bret Miller
> > In order to support this properly, two calls would be
> needed to the external
> > auth module:
> >
> > SASL-C = give me back something to challenge the user with.
> > SASL-R = here is what the user answered.
> P.S. It is crucial to recognize that if the LDAP/Directory
> implementation described above is doing SASL challenge/response
> authentication, then it too *is storing the plain text password*.
> CRAM-MD5/DIGEST-MD5/NTLM authentication cannot be accomplished without
> it. Even if the password is obfuscated in the database (using
> a two-way
> encryption mechanism), the directory must decrypt the
> password in order
> to perform the CRAM-MD5, DIGEST-MD5, or NTLM calculations.
> Therefore, the discussion of on-disk security is still not relevant
> here. (On-disk security is important, and can include methods such as
> encrypting the database, the filesystem, etc.; however, this
> discussion
> is tangential to our current one). The requirement for having
> access to
> the plain text password is not a CommuniGate Pro thing; it is a SASL
> challenge/response requirement.
> > The problem is that many implementations don't allow the password
> > to be read-- only checked.
> This is a separate problem. To my knowledge, there is only one
> implementation for which there may not be the ability to read the
> password *if it is stored*. And that implementation is Active
> Directory.
> This is not to say that it cannot be done, but just that I'm not aware
> of how to do this...yet.

Yes, exactly. I would like a secure method to work with Active Directory
here. I have spent several hours each on a few attempts to get Kerberos
authentication working here. I have followed directions that work for others
like Graeme, but they simply don't work here. I do not claim to understand
how Kerberos authentication works, nor have I been successful at debugging
the error codes I see from it. From what I can tell, we get some kind of
"unable to obtain credentials" error. I have supplied the MAPI client log
multiple times and get pretty close to the same steps back on how to make it
work. But it doesn't here. I don't know why.

So, if you ever do figure out how to read the password from AD, or can
figure out some other way of handling SASL with AD that works in normal mail
clients, I'd certainly welcome it.

Since CGPro has to act as the client in the AD interface, the only ways I
can think of is to obtain the password by transferring it via SSL so it's
reasonably secure across the network; or by acting as a proxy for the
protocol requesting the challenge from AD, forwarding it to the client,
taking the answer from the client and forwarding it to AD.

Then if there was some way to supply both the challenge and response to AD
and verify it, I see that would work since AD is not allowing anything based
on that-- simply verifying it for another service.

I only commented on this because AD integration seems to come up on here
over and over again. Hopefully we'll find a good solution someday.

> This is an important and complex topic, and we would encourage the
> community input on these matters. CommuniGate does very much want to
> find a solution for this issue on all implementations and platforms,
> including AD.


This message is sent to you because you are subscribed to
  the mailing list <>.
To unsubscribe, E-mail to: <>
To switch to the DIGEST mode, E-mail to <>
To switch to the INDEX mode, E-mail to <>
Send administrative queries to  <>

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster