| Summary: | Unable to login with AD users when the user is member Domain Users | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Saif Ali <saali> |
| Component: | Appliance | Assignee: | Gregg Tanzillo <gtanzill> |
| Status: | CLOSED NOTABUG | QA Contact: | Matt Pusateri <mpusater> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.6.0 | CC: | abellott, amavinag, dajohnso, greartes, gtanzill, hkataria, jhardy, jvlcek, mpovolny, niroy, obarenbo, saali |
| Target Milestone: | GA | ||
| Target Release: | cfme-future | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | ldap:auth | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-03-17 13:59:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Saif Ali
2016-10-31 22:33:50 UTC
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. |