On 12/03/08 03:44, Darren J Moffat wrote: > I've read and understood this proposal and I'm happy it meets the > required functionality. > > It isn't exactly mirroring how NIS+ does password change; it uses a > daemon on the NIS+ root master that is contacted over the network > using the end users creds. However I think this is sufficient and the > risk of having an LDAP "admin" cred stored on each host is acceptable. > Particularly given that for those deployments where that is not > acceptable the site can choose to use pam_ldap instead. > > I'd suggest one tiny naming change. Instead of the using > adminDN/adminPassword I'd recommend a name much more specific so that > it encourages sites to create an LDAP principal specifically for this > use rather than using the directory manager (or other all powerful > account), say something like: shadowUpdateDN/shadowUpdatePassword.
Thanks for reviewing. I was debating this in my mind too but decided to use adminDN/adminPassword. My thought was that if we have to expend the use of this identity to limit the reading of the shadow information or to read/write other sensitive data that may come up in the future, we don't have to define yet another identity for it. Please let me know if you still think shadowUpdateDN/shadowUpdatePassword is better, I would be happy to change it. -- Michen
