Hide Forgot
Description of problem: When we configure CFME with AD/LDAP authentication we are unable to authenticate with the users member of Domain Users, and also not able to authenticate with Users on Different OU. The Base DN is set to to the top of the domain tree DC=ad,DC=example,DC=com # Error for audit.log unable to match user's group membership to an EVM role # Version-Release number of selected component (if applicable): 5.6.x How reproducible: Case 1: Steps to Reproduce: 1. Configure CFME with AD authentication as LDAP 2. set Base DN: DC=ad,DC=example,DC=com 3. add add group to CFME by looking up AD user member of Domain Users. if the user is member of multiple groups we can add the group the user long to it, and we can auth fine, as long the group is not Domains Users group. Case 2: 1. Configure CFME with AD authentication as LDAP 2. set Base DN: OU=DEV,DC=ad,DC=example,DC=com 3. add add group to CFME by looking up AD user member of Domain Users if the user is member of multiple groups we can add the group the user long to it, and we can auth fine, as long the group is not Domains Users group. Actual results: Expected results: CFME should search AD tree, and the user should be able to login based on the group membership added the CFME Roles Additional info:
Amogh, can you reproduce this?
Case 1: For the groups that are working are they at the same level or above in the tree as Users container? Meaning: Domain Users is below users in the tree by default, cn=Domain Users, cn=Users, DC=ad, DC=example, DC=com. cn=Working Group, DC=ad, DC=example, DC=com. <--- equal in the tree to cn=Users Case 2. Where in the tree hierarchy is OU=DEV,DC=ad,DC=example,DC=com? I suspect it's equal to cn=Users, DC=ad, DC=example, DC=com. If that's the case I would expect the scenario to fail as you can't query cn=Domain Users, cn=Users, DC=ad, DC=example, DC=com when your bind DN is OU=DEV,DC=ad,DC=example,DC=com. You would have to set your bind DN above or equal to cn=Users, DC=ad, DC=example, DC=com in which case it will fail as in case 1.
Case 1: The working groups are inside the Users container. Case 2: OU=DEV,DC=ad,DC=example,DC=com si equal to cn=Users, DC=ad, DC=example, DC=com in the hierarchy The case 2 we used as workaround because I cannot get any users from Domain Users group to auth. In case 1 we bind to the top level domain, and I should be able to query the users in Domain Users group. In fact CloudForms won't display Domain Users group when I lookup LDAP user If I add the user to any other group I can see the other group but not domain users group.
Case 2: You need to bind above cn=Users, DC=ad, DC=example, DC=com and OU=DEV,DC=ad,DC=example,DC=com as they are peers. This is not a bug but works as designed in LDAP. Essentially cn=Users, DC=ad, DC=example, DC=com is above where you are binding to, and you don't have rights to query it. Case 2 is a configuration issue. Unfortunately binding above it means binding to DC=ad, DC=example, DC=com which will generate a similar problem as Case 1.
Matt, The problem is not with binding the problem I cannot see the Domain Users group in CloudForms. I try it cn=Users, DC=ad, DC=example, DC=com but I cannot see Domain user group in CloudForms. if you think its not a bug you can close it.
I need to still investigate Case 1. Case 2. Is not a bug it's a configuration issue, you should not expect Case 2 to work with a bind DN that's a peer of the container that holds your groups. Your bind DN needs to be higher in the tree.
Case 1. In talking with Developers this is not supported. In a Non-Built-In AD group membership is based on the memberOf attribute, which is what CFME queries on for group membership. In a built-in group, membership is defined by the member attribute. You should see this fail for all AD Built-In groups.