Problem integrating CAS with OpenLDAP (Mapping Rules issue)

[Eduardo Navas]

I have a problem with the integration between CAS and OpenLDAP.

The authentication works fine but the problem I have it when I try to do the assignment of roles to LDAP groups (Mapping Rules

I Create a group called 49 in the OpenLDAP and I add a test user. then create a roll in the CAM to assign the test group to VLAN 49.

I performed test creating mapping rules with these attributes and the result was negative

Uid
memberUid
gidNumber

Anyone know which is the attribute that I read in the OpenLDAP?

In  another implementation thaht I perform with LDAP on Windows was very  simple because only create the groups in the LDAP and then put in the CAM will  verify the memberOf attribute and everything worked perfect.

I appreciate your help

Thank you in advance

Eduardo Navas

[Federico Lovison]

Hi Eduardo,

Here the problem seems to be related to the LDAP structure rather than the fact that you're using OpenLDAP.

In the AD structure indeed you have both the user record referring to the group DN on the "memberOf" attribute, as well as the group record referring to the members' DNs on the "member" attribute.

You need to perform mapping based on attribute(s) available on the user object, not the group one; that's indeed the case for the "memberOf" example you  mentioned.

So, you either need to add also an attribute on the user referring to the group(s) it belongs to, or you should perform the mapping using a different attribute.

If you're not sure about what are the available attributes I would strongly recommend to use an LDAP browser so to better learn the LDAP structure.

This is just a hint, as LDAP is actually pretty flexible so there's not a unique solution to this problem.. but keeping in mind to check against the user attributes should help.

Good luck! :-)

Regards,

Federico

--

If this answers your question please mark the question as "answered" and rate it, so other users can easily find it.

[Eduardo Navas]

Hi Federico

I perform  the search with the LDAP-Browser in the OpenLDAP  but I did not find any  attribute that made mention to the group...

I found in the group´s the "memberUid" attribute that refers to each of the users who are members of the group.

I  understand that the CAM performs the search on the attributes of the  user, but there is some possibility that the CAM verify attributes of a group and see the users are there?

Thanks in advance

Eduardo

[Federico Lovison]

Hi Eduardo,

The LDAP config for the CAM allows you to specify only the search filter for the user object.. so you can solve this only by adding the necessary info on the LDAP account.

If you cannot really add the group reference in an attribute to your LDAP users accounts, then I'm afraid you should look for a different solution.

Although this is just aimed to be a hint... as it would be a bit long to explain all the steps, a possible alternative solution would be to configure a RADIUS authentication provider on the NAC Manager and point this to an ACS 5.x.

Then, you can point ACS 5.x to the OpenLDAP server; indeed, ACS 5.x allows you to search for the user reference (either the username or the user DN) in an attribute of the group object...

I cannot think of other solutions for the moment, even though you may check with the LDAP admins (if it's not yourself :-) ) on whether it's actually a big deal to add this additional attribute to your users, similar to what AD does by default.

Regards,

Federico

[Eduardo Navas]

Hello Federico

Thanks for all your help.

After you send me your answer I finaly solved the problem this way:

I found an attribute called "entryDN" that show where the user is created in the LDAP tree.

Then I gave instructions to staff that operates the OpenLDAP to organize users into groups (Users Vlans) and then I make the mappings rules for each  user roll and this solved the problem.

I attached a print screen of NAC

Thanks again for your help and your time

Best regards

Eduardo Navas

[Federico Lovison]

Hi Eduardo,

I'm glad to hear that this issue is now solved!

Regards,

Federico