Password dilemmas.

[Paul Ashton]

At 11:47 25/02/98 +1100, Samuel James Johnston wrote:
>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
>/bin/passwd.

It's not a problem in NT, it is a problem with Unix. With NT, as I said
in my synchronisation article, the password is passed in the clear to
the DC. If the user changes their password on Unix we need to intercept
it with a client change or new PAM.

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

That uses the "Notification Package" mechanism I mentioned in my article.
The password is supplied to the server using the RPCs I mentioned. If the
NT machine is a domain member you only have to install the notification
package on the PDC (or do the equivalent with Samba).


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

Why not store in the standard smbpasswd file?

Paul