Password dilemmas.

Samuel James Johnston samj at cse.unsw.EDU.AU
Wed Feb 25 00:41:34 GMT 1998


You have raised an important issue here. Certainly the UNIX community is
not going to be overly excited at the prospect of even having to alter the
format of the /etc/passwd file, let alone completely creating a new 'samba
proprietry' one. Of course if we were MS...

The issues as I see them are:

* Everything in the windows NT client must be stock standard
* The UNIX server should be as close to stock standard as possible (this
means we can't really modify the authentication procedures, etc.)
* The password should be able to be changed using the standard password
change dialog in NT and a modified /bin/passwd file in UNIX.
* The solution cannot rely on PAMs, etc. which may be specific to certain
operating systems. (ie it must be portable between different versions of
* The file which contains the LM and MD4 hashes must be kept secure, as
these are both reversible (almost) and are password equivalents.

Any which way we look at it, the UNIX and the NT hashes must be generated
whenever the password is changed. Thus we need to have the cleartext
password. This has proven a problem in NTland because the authentication
is done using the hashes (challenge/response etc.), and thus the PDC does
not get to see the cleartext password. In the land of UNIX, the only two
processes which handle the cleartext password regularly are login and

One thing which hasn't been mentioned is the NT password filtering system
(passfilt.dll). This feature hasn't had much publicity, but there's a KB
article on it at MS. A simple passfilt.dll was released with SP2, as far
as I know. Basically it is a dll which sits on the PDC and checks the
password for validity, in terms of length, mix of characters, maybe a
dictionary check, etc. Of course to check the password, you need to have
the password. Thus even if the standard method of changing the password is
for the client to provide a hash which is fed directly into the SAM, there
m for the PDC to request a cleartext password. I haven't had a chance to
look into this in depth, so if anyone has more of an idea about it...

OK so we've got the cleartext password in UNIX now, either via the
standard dialog, or through /bin/passwd. Creating the hashes isn't too
difficult, but where does one put them. Probably the most convenient
option is to stash it in a text file (like everything else), pretty much
identical to the smbpasswd file, if not exactly the same. This will need
to be locked away somewhere, much the same as a shadow password file. We
would probably want to consider not having an entry for root, rather
having both a root and an administrator account (root for UNIX, with no LM
and MD4 hashes, and administrator for NT). This will mean we can sleep at
night in the knowledge that the root password is safe (even if everyone
elses aren't quite as secure).

The other option suggested for the storage was to have a samd, which
would look after the hashes in some encrypted format, and would check that
the user requesting a hash is authorised to do so. This is adding
complexity somewhat, and is looking like a bit of a 'samba proprietry'
solution, which is not really a good thing. Do we have that big a problem
with a text file protected by file system security to justify implementing
a new protocol?

The other options Paul came up with... for example having users connect to
a web page using SSL... are also good ideas, except that anything
non-standard may mean that some sites choose not to adopt samba.

I'd be interested to hear if anyone has any comments about any of this,
particularly with regards the innards of the NT passowrd change system.


Sam Johnston
Computing Support Officer, UNSW

On Wed, 25 Feb 1998, Samba Bugs wrote:

> Paul,
> Your analysis of the issues is clear and seemingly comprehensive, as per
> your usual style.
> One issue you did not address is the inherent dynamics of change.
> What has inertia? What could gain support of the Unix/Linux community and
> what effort would that take?
> Also, what is your estimate of the time frame before an acceptable
> solution may be available?
> My personal preference is to make the password synchronisation Unix
> centric, thus PAM could be a suitable vehicle even given maintenance of
> both /etc/passwd and /etc/smbpasswd files. I am confident that the
> Unix community will be __unwilling__ to consider a change away from
> /etc/passwd (and it's friends).
> While in London, I spoke with Luke about this and the possibily of a samd
> (SAM Daemon) that maintains a Unix equivalent of the NT SAM and SECURITY
> database files in a suitably secure format. I suspect this is still a good
> option to protect the database from prying eyes. The samd could have an
> API that Samba could call into.
> This does not address your concern of the mechanics of implementing a
> synchronised password change from a Windows client system. The key to
> success of Samba has been the fact that it does NOT require ANY
> third-party add-on software for the MS Windows client. I can not help but
> fear the worst should we now change that by requiring a "Samba
> proprietary" password change/authentication system for client platforms.
> Sorry if I seem a wet blanket here, that is not my intention.
> Your efforts are appreciated very much.
> Cheers,
> John H Terpstra

More information about the samba-ntdom mailing list