On 5 November 2012 09:28, Andrew Bartlett <abart...@samba.org> wrote:
> On Mon, 2012-11-05 at 08:18 +0100, Thomas Mueller wrote:
>> Am 05.11.2012 04:31, schrieb Andrew Bartlett:
>> > On Thu, 2012-11-01 at 12:44 +0000, Thomas Mueller wrote:
>> >> hi
>> >>
>> >> trying to create a user with ldap from a remote server. The user is
>> >> created successfully. I'm failing setting the initial password.
>> >>
>> >> Setting the unicodePwd with kerberos administrator credentials with
>> >> ldbmodify and the ldif below results in "00002035: setup_io: it's not
>> >> allowed to set the NT hash password directly".
>> >>
>> >> searching the web I've found s4 mailinglist entries telling "do not set
>> >> unicodePwd with ldap". this KB article tells in AD it's possible to set
>> >> it: http://support.microsoft.com/kb/263991/en-us
>> >>
>> >> Is there a supported method to supply the initial user password with s4
>> >> and ldap?
>> >>
>> >> - Thomas
>> >>
>> >> LDIF:
>> >> dn: CN=Thomas Mueller,OU=Users,DC=test,DC=testing
>> >> changetype: modify
>> >> replace: unicodePwd
>> >> unicodePwd:: $IlRlc3QxMjMtLSIK
>> > To set it via unicodePwd, you need to have it as UTF16, not ascii/utf8.
>> i was using the following command to address this utf16-le requirement:
>>
>> echo \"PASSWORD\" | iconv -t UTF16LE | base64
I get "IgBQAEEAUwBTAFcATwBSAEQAIgAKAA==" from the above, which seems
OK to me, except that it has an extra "\n" on the end before encoding.
This works better:
$ echo -n \"PASSWORD\" | iconv -t UTF16LE | base64
IgBQAEEAUwBTAFcATwBSAEQAIgA=
Python gives me the same thing:
>>> '"PASSWORD"'.encode("utf-16le").encode("base64")
'IgBQAEEAUwBTAFcATwBSAEQAIgA=\n'
> Either way, the base64 string just doesn't look long enough for that.
>
> This seems closer:
> //4iAFQAZQBzAHQAMQAyADMALQAtACIA
Are you sure? Yours includes a BOM, which I don't think is necessary:
>>> "//4iAFQAZQBzAHQAMQAyADMALQAtACIA".decode("base64").decode("utf-16le")
u'\ufeff"Test123--"'
>> > See however the userPassword, which is a normal, utf8 unquoted string
>> > (ie, sane :-)
>> Just tried it. Problems:
>>
>> 1) the userPassword attribute is plaintext readable with ldap afterwards
>> 2) the kerberos password is not set ("kinit user" fails)
>
> You may not have the userPassword feature enabled. It's odd that we let
> it stick in ldap however - can you confirm exactly what AD does here, so
> I can match it?
--
Michael Wood <esiot...@gmail.com>
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
