[Samba] Changing password in PDC using a pre-hashed value

[Rowland Penny]

On 25/11/14 13:47, Emond Papegaaij wrote:
> On Tuesday, November 25, 2014 01:28:21 PM Rowland Penny wrote:
>> On 25/11/14 12:43, Emond Papegaaij wrote:
>>> In short, we would like to add users to a Samba PDC, using a pre-hashed
>>> value for their password. Is this possible, if so, how?
> <cut long version>
>   
>> Firstly, it's DC not PDC, a PDC is something else, similar but not the
>> same.
> Ow, I'm not that into AD-terminology.

Well, it sounds like you need to learn it.

>   
>> Now to your main question, do you realise that your users can and will
>> change their passwords at will, in fact, unless you change the default
>> settings, their passwords will expire every 41 days.
> The accounts should only exist for a maximum of 8 hours, so a 41 day-limit is
> not a problem.
>   
>> To create a password for an AD user on Linux, you need to do something
>> like this:
>>
>>    echo -n "\"$_USER_PW\"" | $_ICONV -f UTF-8 -t UTF-16LE | $_BASE64 -w 0
> This 'algorithm' only converts UTF-8 to UTF-16LE and performs base64 encoding.
> Doing the reverse, will give me the plain password again. I see a base64-
> encoded string the same way as a plain string. Character encoding-conversion
> and base64 encoding are both encoding strategies, not hashing.
>   
>> Where $_USER_PW is the users PLAIN password, so if you feed into this a
>> hashed password, it will either not work or the users password will be
>> set to the hashed value, not the plain password.
> That's indeed the problem I'm having. From what I've read, Samba hashes the
> unicodePwd internally when the attribute is modified.
>
> I suppose flow is like this:
> PLAIN -> encode -> modify unicodePwd -> HASH -> store hashed value
> What I would like to do:
> PLAIN -> encode -> HASH -> modify unicodePwdHashed -> store hashed value
>

You cannot do this, for the reasons I have already given.

>> So, to answer your question, no, I do not think you can do what you
>> want, I also cannot understand why you want to keep creating the user,
>> the whole idea of AD is SSO.
> That would be very unfortunate. The key thing is that the AD only serves as an
> authentication mechanism in this setup. The SSO is handled by our
> authentication broker.

So you want use SSO on top of another SSO.

> For a user, the flow should be like this:
> - User wants access to 'very-important-server'

In AD you cannot have a 'very-important-server', you can only have a server.

> - Sign-on into our authentication broker
> - Enable temporary account in AD for 'very-important-server', with password
> supplied earlier
> - Login on 'very-important-server' using the temporary account
> - Do your thing on 'very-important-server'
> - At end of day, temporary account expires and is removed from AD

Why not: create AD user with a known password, set account to expire at 
given time, give user the password, restrict access to server via ACL's.

>
> The authentication broker records an audit trail, provides two-factor
> authentication and has sophisticated account management. This allows us to see
> who does what where and when and revoke access with a few clicks.

I think that you need to rethink your 'authentication broker' to get it 
to work with AD.

>
> Best regards,
> Emond Papegaaij