CAS LDAP not liking nested AD groups

[Zach Tackett]

So we need to allow users to login to our LDAP/CAS 5.0 server from their respective AD groups, there is a root group called "IDM", and within it are groups called IDM-BANNER, IDM-FINAID,

I have tried the following:

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM,dc=marshall,dc=edu

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM,ou=IDM-FINAID,dc=marshall,dc=edu

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM-FINAID,dc=marshall,dc=edu

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM,ou=IDM-BANNER,dc=marshall,dc=edu

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM-BANNER,dc=marshall,dc=edu

None of which are working. Can OU's be grouped/nested within the listing, does CAS/LDAP not like the nested AD groups?

[Zach Tackett]

We have several AD groups within the root IDM group, is there a way to wildcard those nested groups (IDM-BANNER, IDM-FINAID) and have them authenticate or will indexes need to be created for each nested group?

[Tepe, Dirk]

It's hard to identify a specific cause without more information, but there are some things to pursue. First, what exact version of CAS are you using?

You say groups but your example shows OUs (organizational units). They are very different things. That's going to lead to some confusion.

Your example uses 'ldap[1]'. Should that be 'ldap[0]' or do you really have another ldap configuration in addition to this one? (those arrays are 0 based)

I suspect the dnFormat will not be your best choice. That would require having a single predictable format, which does not seem to be the case for you. You will likely be more successful using a bind/query/bind approach where CAS first binds as a known user, uses a filter to find the entry for the provided user and then attempts a bind as that retrieved DN with the provided password. Use the bindDn and bindCredential from here:

https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#ldap-connection-settings

With the baseDn and searchFilter from here:

https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#ldap-authenticationsearch-settings

If you really want to stick with the single bind attempt using a fixed DN string, you may be able to use AD's support for the 'user@domain' style DNs. You could try something like '%s...@marshall.edu'. But I think the bind/query/bind is much better.

-dirk

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/a502221e-e62a-4292-828b-e9da684cc3d4%40apereo.org.

[Zach Tackett]

 Sorry, I am not very well versed in AD. Simply going off of what another coworker was trying to explain. There is already an ldap[0] config setup and working. This one needs to be setup for the OU IDM, inside that OU there are quite a few OU's that need to have access. It works if I do

cas.authn.ldap[1].dnFormat=cn=%s,ou=IDM, ou=IDM-BANNER,dc=marshall,dc=edu

But I do not want to have to do that for each one, is there a way to allow anyone within the IDM OU access?

[Tepe, Dirk]

When you say "need to have access", it sounds like you are trying to combine authentication and authorization. Is the existing ldap configuration also using the same AD? Is there a reason these users cannot be authenticated that way? Then authorization is a separate action.

You can use the searchFilter to refine the users allowed to authenticate. That's just a normal LDAP filter so you should be able to use any other attribute in addition to cn. For example:

cas.authn.ldap[0].searchFilter=(&(cn={user})(otherAttribute=LetMeIn))

That would give you control over what accounts CAS will match the username against.

As an Identity Provider, CAS is not necessarily responsible for authorizing into other applications. The IdP authenticates the user, possibly with multiple factors and provides agreed upon attributes to the service provider. The service provider then makes the authorization decision. CAS does allow you to per service access strategies, which might also be useful in this case:

https://apereo.github.io/cas/5.3.x/installation/Configuring-Service-Access-Strategy.html

Maybe a little more context of your situation would help us provide better suggestions.

-dirk

--

- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/ee6c8d13-ec29-4795-8f72-ba7abecffd4c%40apereo.org.