On 17/12/03 12:20 am, David Syzdek <[EMAIL PROTECTED]> wrote: > > > 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
Yes. > a function such as $ldap->modify()? If this what you mean, would > optionally passing the credentials in the function call be acceptable: Well, you don't know which server the modify will get sent to, so no. If you don't care who gets your credentials, then yes. >> 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. Absolutely you *could*, and you could replicate the entries being bound with to each server, but in the general case you cannot do this. >> 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 A -> B, but it doesn't change your argument much :-) > 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. I don't think that's terribly realistic, except in limited circumstances. >> 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. That's *really* crude :-( It sounds more like a scheme to avoid searching for too long instead of a security mechanism. Of course, referrals are a crude mechanism for interconnecting directories as well. Here's an example. You've got two companies which are trading partners and who have thus interconnected their directories using referrals. Your company has multiple servers "connected" via referrals; the other company also trades with your competitor and has referrals to them. You almost certainly do not want to replicate copies of your entries with their credentials (userPassword, whatever) to your trading partner. You don't want to try to authenticate to your trading partner. You have to trust more than 1 referral hop to get around your directory. You do not want to trust more than 1 referral hop because your competitors are 2 hops away :-) Cheers, Chris
