[horde] Patch - New "Encryption" type added to framework Auth.php for MS Active Directory unicodePwd encoding.

LRM lrm at ionline.com.br
Mon May 3 16:57:00 PDT 2004


Jan,

First, thanks for the replies and suggestions so far, I really appreciate it
and if you can follow my findings a bit more maybe you can help me get out
of this cursed attempt to integrate passwd change on Active Directory,
you'll see why I'm going nuts here if u get some time to read this ;-)

Indeed, I'm kinda amazed by the differences you observed:

Using mb_convert_encoding to encode "newPassword" string produces:

00000000h: 22 00 6E 00 65 00 77 00 50 00 61 00 73 00 73 00 ;".n.e.w.P.a.s.s.
00000010h: 77 00 6F 00 72 00 64 00 22 00                   ;w.o.r.d.".

Base_64 this and you get: IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgA=


Using String::convertCharset to encode "newPassword" string produces:

00000000h: 22 00 6E 00 65 00 77 00 50 00 61 00 73 00 73 00 ;".n.e.w.P.a.s.s.
00000010h: 77 00 6F 00 72 00 64 00 22 00 78                ;w.o.r.d.".x

Base_64 this and you get: IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgB4

So I'm guessing String::convertCharset is doing some additional formatting
or something, but the resulting base64 string is not valid for unicodePwd
attribute of MS AD, as I've tested with LDIFE.

My real dilema now is that using the first method mb_convert_encoding I
generate a valid "identical" base64 string of the password compared to the
MS Article I've posted before
(http://support.microsoft.com/default.aspx?scid=kb;en-us;263991). So I
copied this php-generated base64 string and pasted it into a file to test it
with LDIFE, a command line tool to access and modify the Active Directory.

Running LDIFE with that string as value for unicodePwd attribute of a User,
changed the password successfully to newPassword!!! I'M LIKE, WTF?!

For now this means only one thing: the base64 string generated by
mb_convert_encoding is valid for a value of unicodePwd user attribute on AD.

However, when running the call ldap_mod_replace inside passwd module, and
properly passing this same base64 string as value for unicodePwd attribute,
I get the infamous Constraint Violation error, which usually means a badly
formatted value trying to be passed to an attribute, as logged by the AD
Server:

The LDAP server returned the following error string: 
 0000216C: AtrErr: DSID-031D0AC0, #1:
	0: 0000216C: DSID-031D0AC0, problem 1005 (CONSTRAINT_ATT_TYPE), data
0, Att 9005a (unicodePwd)

So my best (and only) shot now is that the php_ldap.dll which handles
ldap_mod_replace is screwing up the contents/encoding of that string when
passing it to the server or something. Howcome I can successfully use that
base64 string with LDIFE and the same value won't get accepted by AD with a
simple ldap_mod_replace call?

(Yes, I'm connecting with SSL to AD as admin and all the other zillion
requisites are fulfilled).

Please lemme hear your toughts about this situation, or anyone on the
community, some help on this issue is really appreciated :-)

LRM




More information about the horde mailing list