Shibboleth IdP v3.2.1 & LDAP+AD Authentication

[Daniel Fisher]

On Wed, Jun 22, 2016 at 6:10 PM, IAM David Bantz <dabantz at alaska.edu> wrote:

> 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
> https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AggregateDNResolver.1),
> 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.
>

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.


> 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.
>

Incorrect, see my previous comments. If you are synchronizing passwords,
the AggregateDnResolver can be configured to work in your environment.


> 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.
>
>
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.

--Daniel Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160623/5e795d1b/attachment-0001.html>