<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Thank you Daniel. This is helpful to me.<br><br><div>David.Bantz<span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.231373); -webkit-composition-frame-color: rgba(77, 128, 180, 0.231373); ">@<a href="http://alaska.edu">Alaska.edu</a></span><div><span class="Apple-style-span" style="-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span></div></div></div><div><br>On Jun 22, 2016, at 20:44, Daniel Fisher <<a href="mailto:dfisher@vt.edu">dfisher@vt.edu</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 22, 2016 at 6:10 PM, IAM David Bantz <span dir="ltr"><<a href="mailto:dabantz@alaska.edu" target="_blank">dabantz@alaska.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">This is sufficiently counter-intuitive to me that I want to make sure I understand correctly. If two directory sources are used, and multiple DN resolvers and authentication handlers defined (per <a href="https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AggregateDNResolver.1" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AggregateDNResolver.1</a>), then if there are in fact DNs found in both directories (the user has accounts in LDAP and AD) this will cause the aggregate DN resolver to fail, and hence the user's attempt to authenticate fail.</div></div></div></blockquote><div><br></div><div>Correct, that is the default behavior. However, you can set allowMultipleDns=true and authentication will be attempted against one of the directories. If you care which one, you'll need to use an ordered map in the configuration.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">In other words, with multiple directories (it seems fairly common, for example, to deploy MS AD and some more generic LDAP directory) the assumption behind this behavior is that the population of the directories is disjoint; thus having records with the same username in both directories is an error condition such that authN cannot succeed for such a user.<br></div></div></div></blockquote><div><br></div><div>Incorrect, see my previous comments. If you are synchronizing passwords, the AggregateDnResolver can be configured to work in your environment.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">99% of our users have records with same username and synchronized passwords in both MS AD (for Domain use and Windows-centric apps) and Oracle LDAP for eduPerson and multiple other attributes and self-service updates.  If I've got the behavior above nearly right, seems we'll have to stick with JAAS with multiple ldap's each "sufficient" for authN, foregoing features and efficiency of ldaptive.</div><span class=""><div class="gmail_quote"><br></div></span></div></div></blockquote><div><br></div><div>Don't let better be the enemy of good enough. If your configuration meets your needs and you're getting acceptable performance, stick with JAAS.<br></div><div><br></div><div>--Daniel Fisher</div><div><br></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>-- </span><br><span>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></span></div></blockquote></body></html>