On 16/12/03 9:41 pm, David Syzdek <[EMAIL PROTECTED]> wrote:

> 
>> How would you handle authenticating to the other servers? Net::LDAP
>> deliberately does not cache authentication credentials, so it wouldn't be
> 
> Couldn't this be overcome by caching the credentials in a hash if
> following referrals was enabled.  To prevent Net::LDAP from caching
> credentials needlessly, following referrals could be disabled by default.

Net::LDAP should not be caching credentials. Any caching should be down to
the caller.

>> completely trivial - you almost certainly wouldn't want to offer credentials
>> valid for server A to server B for example. What if there are multiple
> 
> My experience with referrals is limited to iPlanet Messenger server and
> iPlanet Directory server.  However, iPlanet appears to require the same
> credentials on both the ldap server originally specified and the server
> referred to in the referral.  From what I have seen, only the LDAP
> administrator for a server can create an LDAP referral, so in theory the
> LDAP servers listed in the referrals should always be trusted LDAP servers.

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.

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.

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 :-)

>> referrals which could be followed - which choice should be taken?
> 
> According to section 4.1.11 of rfc2251, all URIs returned must be
> equally capable of performing the request.  I would choose the first URI
> that matchs the protocol that the original query/update was submitted
> with.  If the first URI fails, I would proceed to attempt each URI that
> matches the original protocol used.

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.

> Thanks
> David Syzdek
> 
> 

Cheers,

Chris

Reply via email to