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

Emond Papegaaij emond.papegaaij at topicus.nl
Tue Nov 25 06:47:00 MST 2014


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.
 
> 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

> 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. For a user, the flow should be like this:
- User wants access to 'very-important-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

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.

Best regards,
Emond Papegaaij


More information about the samba mailing list