On 12/03/08 10:53, Darren J Moffat wrote: > 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".
Yes. That's a good idea. We will do that. And actually we plan to update the idsconfig(1M) utility to allow users to create such an identity with only the necessary permission for reading/writing shadow information. Thanks again, Michen
