On 14 Feb 2003, Andrew Bartlett <[EMAIL PROTECTED]> wrote: > > a) If we want the password-quality script to handle this, > > I think we'll all agree, storing clear text password is really > > not a good idea. Perhaps the interface should provide the new > > encrypted passwords to the external program -- if administrators > > don't have "easy access" to the encrypted password, some will > > probably endup use the cleartext one :( > > I think this complicates the issue - smbd would then be involved in key > management etc - and that just gets messy.
A generally useful interface needs to provide the cleartext password. (For example, as I mentioned earlier, our domain controller forbids passwords which have too many characters in common with an earlier password. I can't see this in the Domain Controller Security Policy, but perhaps it's a plug in or configured somewhere else.) Hopefully we can ship enough standard modules that people won't want to write random insecure implementations. But if they want to, they can. > We already use PAM, and we should use it for all the things it's > intended to do, but this is not something it was intended to do. I really disagree, I think this is exactly the sort of thing PAM is good for: providing a standard interface for doing authentication-related things, without needing to invent a new interface for each. PAM replaces a pile of little messy solutions and we should really not add a new custom protocol back in. Using PAM also allows the code to be reused for passwords changed through other mechanisms (web interfaces, ...) > (Because we are not asking it to store the password). I don't understand this one... Having PAM modules which check a proposed password change rather than storing it is absolutely fine -- look at the existing strength-checking systems. http://www.kernel.org/pub/linux/libs/pam/modules.html Basically PAM just provides a standard way of having a little conversation about a new password. > > Ain't people moving towards pdb LDAP backend using the included > > LDAP support in Samba instead of using PAM? > > LDAP and PAM solve different problems. PAM is the interface from the application to the security module; LDAP is the database. It could make sense to have a module which talks PAM to Samba and stores its data in LDAP. > > We could add an attribute "password quality runas root (true/false)" > > in smb.conf . Should we? Only add it if you can describe a case where running it as root wouldn't work. > > 5) "Protocol" > > > > Do we agree on the following for "version: 1\n"? I think you should use a PAM API rather than a subprocess. But if you insist on a subprocess, I think this is OK. > The script would only send a different value if it was found that MS was > using a different value. Allowing a hexadecimal number is both > perfectly practical, and solves this little issue. Yes, please just send the number. -- Martin
