Mailing List CGatePro@mail.stalker.com Message #92414
From: Thom O'Connor <thom@communigate.com>
Subject: RE: authLDAPNew2.pl with AD
Date: Fri, 31 Aug 2007 16:37:00 -0700
To: <cgatepro@communigate.com>
Yes, we've been banging on this one too, and it's not easy.

[Tangentially - please note that we've added a page to the Support
Knowledge Base which explains how to authenticate via LDAP against
Active Directory using authLDAPNew2.pl. However, as Bret notes, this
will still not help for secure Pronto authentication or other forms of
SASL challenge-response authentication:]
https://support.communigate.com/tickets/kb_article.php?ref=3799-FIBM-9462

It appears that Active Directory stores the password by default in an
attribute called "unicodePwd". However, retrieving this is challenging
(Microsoft site says it cannot be read, but does anyone believe them?),
and it may be encrypted as well as stored in Unicode. Some references on
this include:
  http://support.microsoft.com/kb/269190

However, what is interesting is that "NTLM" (which is Microsoft's
proprietary challenge-response mechanism) appears to require access to
the plain-text password. So, it appears that Active Directory does store
this plain-text password, but doesn't want to give it up.

Bret's suggestion on password synchronization in an external web
interface is one possibility.

Another possibility is to figure out how to "automatically" copy or
replicate the user's plain-text (or obfuscated but not encrypted)
password in Active Directory into a second custom attribute in Active
Directory - for example, create a custom attribute in Active Directory
called "userPassword", and have this attribute filled by the user's new
password automatically whenever a user modifies their password. Then,
configure authLDAPNew2.pl to simply retrieve this alternate field. This
would probably require some domain-controller-level scripting on the AD
side of thing, and again - not being AD experts - we welcome any
thoughts on this.

Another similar but slightly different technique is to synchronize the
CommuniGate Pro internal password "whenever possible" with Active
Directory - for example, use a special authLDAP script which first
attempts to authenticate the user against AD, and if successful, also
copies the plain-text password (if provided) into the internal
CommuniGate Pro account.settings location for that user. Then, on any
subsequent challenge-response auth attempt (such as Pronto) - the first
auth attempt (against AD) will fail, but add a second attempt which
retrieves the plain-text password from CommuniGate Pro's internal
account database, and use this for the challenge-response/SASL
calculations. Okay...yes, this is a hack, and would have some trouble
spots regarding synchronization, or if a user ALWAYS used
challenge-response mechanisms such that the plain-text password was
never made available to CommuniGate Pro and so could not insert that
password into the internal account database.

One last hope is if there were a way to retrieve the unicodePwd
unencrypted...

So, that's where we are on this, and are welcome to ideas. We've been
looking at the OpenLDAP and Samba projects for other possibilities,
though they don't seem to have solved this problem either...

Have a great weekend.

Cheers,
 -t

> From:   "Bret Miller"
>> I'm trying to get things figured out with authenticating against my
>> AD server (windows 2003 SP2) for users who are out of my office. As
>> it stands now I'm able to authenticate locally and over the VPN's
>> using Kerberos. This is not the case for web-users, and obviously,
>> Pronto! My main concern is that the password be encrypted and
>> secure.
>>
>> I downloaded the new authLDAPNew2.pl script and added it as an
>> external authenticator. I disabled the internal CGP password for
>> the user and then try to log in.

Andy Kunkle wrote
> AFAIK, authLDAPNew2.pl addresses SASL login with directories that can
> provide the plain text password to CGPro. The problem is that
> Microsoft Active Directory will not provide that information, so
> challenge-response type login is not possible.
>
> And at this point, the only possibility for using a secure password
> with CGPro in an AD environment is to use CGPro's own password. It's
> a pain, I know. So, what possible solutions do you have?
>
> Well, we use plain text auth with external auth that copies to the
> cgpro password. BUT, that's not really secure unless the password is
> passed over SSL.
>
> You could create a "synchronize password" page that would be
> SSL-protected where a user would enter his email and password, you'd
> validate the password against AD and then set the CGPro password to
> match. It's a crude workaround, but there's not much else you can do
> if you want both secure authentication AND integration with AD.


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