Chris Ridd wrote:
Net::LDAP should not be caching credentials. Any caching should be down to the caller.
By caller do you mean the the script or module that is actually calling a function such as $ldap->modify()? If this what you mean, would optionally passing the credentials in the function call be acceptable:
$mesg = $ldap->modify(
'replace' => {
'sn' => 'Syzdek'
},
'binddn' => 'uid=syzdek,ou=People,o=isp',
'password' => 'lamepass'
);This way the credentials are not being cached within Net::LDAP and passing the credentials back to the module would be upto the script developer. If the credentials were not resupplied, the referrals could be attempted using anonymous binds. The anonymous binds most likely would not work for modifies and adds, however it would possibly be able to return additional information when using $ldap->search();
No. If you bind as manager to server A and get a referral to server B, you almost certainly shouldn't try to bind as server A's manager. They may not be administered by people in the same part of the organization.
I agree, using the manager to follow a referral would be a bad idea. However you could set up a bind dn common to both LDAP servers for use when following referrals.
Server B may not have the same entries as server A, so it may not even be possible to bind as the same user on B as A.
If you are referring from server B to server A there is probably already some type of coordination occuring between the two LDAP administrators. It would be up to the script developer to work with the LDAP administrators to ensure that a common bind dn exists on both servers.
Experience of more distributed directory services bears this out - you may trust another server, but do you trust that server to trust another server trusting another server (etc)? No, you don't. (Well, you'd be crazy if you did :-)
Again I agree. iPlanet's ldapmodify allows you to specify the max number of referrals to follow. The same could be true for the referral functionality for Net::LDAP.
>
They're certainly ordered, so that makes some sense. However you might have more knowledge about how near certain servers are so you can't just blindly try the list in order.
A list of preferred list of LDAP servers could be provided by the script developer if they needed to specify which LDAP servers to try first.
