[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