IDPv3.1.2 LDAP connector: using two distinct LDAP servers?

[Raymond Gardner]

This poses a problem for me.  I do not have a generic bind account to use for configuring a bindDn property or a bindCredential property as is expected with the BindConnectionInitializer.
The user provides these binding values during login.  How is one expected to configure this?

Will an anonymous search work?  Then, the authHandler will do the actual bind?


From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Daniel Fisher
Sent: Tuesday, July 05, 2016 12:38 PM
To: Shib Users
Subject: Re: IDPv3.1.2 LDAP connector: using two distinct LDAP servers?

On Tue, Jul 5, 2016 at 1:12 PM, Brady, Jason W <jbrady at sbccd.cc.ca.us<mailto:jbrady at sbccd.cc.ca.us>> wrote:
Maybe this has to do with using the FormatDnResolver with the AggregateDnResolver and not using PooledSearchDnResolver for both. It looks like FormatDnResolver always succeeds so the AggregateDnResolver$AuthenticationHandler will always try and authenticate them. Effectively, all accounts exist to the FormatDnResolver, even when they don’t exist in the directory.

That's correct. The FormatDnResolver will always succeed and because it succeeds the fastest, it's authentication handler will always be the one invoked. Use a SearchDnResolver so your directories can be logically separated.

--Daniel Fisher


****************************************************************
This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT America makes no warranty that this email is error or virus free. Thank you.
****************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160705/a0b54156/attachment.html>