Michen.Chang at Sun.COM wrote: > 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.
I thought about that too. > Please > let me know if you still think shadowUpdateDN/shadowUpdatePassword is > better, I would be happy to change it. What about we go for a compromise and leave the names as you specified them and make it clear in the documentation that this isn't necessarily (and actually not recommended to be) the a directory server "super user" with all access but instead a special account that can only write to those "fields". -- Darren J Moffat
