PSARC/2008/745 nss_ldap shadowAccount support

[Darren J Moffat]

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