Mailing List CGatePro@mail.stalker.com Message #92415
From: Thom O'Connor <thom@communigate.com>
Subject: Re: authLDAPNew2.pl with AD
Date: Fri, 31 Aug 2007 17:04:43 -0700
To: <cgatepro@communigate.com>
Here's an interesting (and quite recent) article on the topic:

http://journals.eyrie.org/eagle/archives/001022.html
Posted by eagle at July 12, 2007 09:13 PM
> Active Directory unicodePwd
>
> In case anyone else ever needs this:
>
> You can change the password of an Active Directory account by
> changing the unicodePwd attribute (or setting it, for that matter,
> for new accounts). However, you have to jump through some security
> hoops.
>
> First, you have to use TLS (and if you're using OpenLDAP clients,
> make sure that TLS_CACERT in your ldap.conf points to the right root
> cert). Since you're using TLS, if you're using GSSAPI, you need to
> tell GSSAPI not to negotiate a security or privacy layer since AD
> doesn't support nested security or privacy layers. (Dumb.) The magic
> incantation for ldap.conf is SASL_SECPROPS minssf=0,maxssf=0.
>
> Then you need to set the attribute. Windows uses little-endian UCS-2
> as the character set (which they, unhelpfully, call "Unicode" in all
> their articles, as if there's only one Unicode encoding). Perl, for
> example, defaults to big-endian UCS-2 if you just say to use UCS-2.
>
> The password also has to be enclosed in double-quotes. The
> double-quotes aren't part of the password. I have no idea why Windows
> does this.
>
> So, to transform the password in a Perl script into the string that
> AD wants, try: encode("ucs-2be", qq{"$password"}). (This assumes
> you're using the Encode module that comes with Perl 5.8 and takes
> care of the charset issues for you.) Then, if you're putting that
> password in LDIF (because, for instance, you're piping it into
> ldapadd), you need to base64-encode it. Use MIME::Base64 and then
> call the encode_base64 function. Finally, you can take the resulting
> string and put it into the LDIF as:
>
> unicodePwd:: <base64-encoded-string>
>
> It took Ross and I far too long to figure this out. Ross found the
> last key detail in some web site where the person was byteswapping
> the encoded output to get around the little- vs. big-endian problem.



Note that the password does appear to be stored only Base64-encoded,
which means it is probably there in plain-text (just obfuscated) format.
Now give it up!

Cheers,
 -t



Thom O'Connor wrote:
> 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