Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When checking memberof, apply the group filter after getting all groups #683

Merged
merged 4 commits into from
Nov 16, 2021

Conversation

jvillafanez
Copy link
Member

For nested groups, this was a problem because the group filter could
remove the nested group, so we couldn't check the memberof attribute of
the nested group and we couldn't go upwards in the group tree.

GroupA contains GroupB, and GroupB contains User1. If the group filter
contains just GroupA (not GroupB), checking the "memberof" of User1
would return no group. This PR fixes this by returning GroupA, which is
part of the group filter (if the "nested groups" checkbox is active)


Related to https://github.com/owncloud/enterprise/issues/4754

Steps to reproduce

  1. In the AD create GroupA; inside GroupA create GroupB; inside GroupB create some users
  2. Ensure the AD has additional users and groups
  3. Configure the user_ldap app to connect to the AD
    1. User filter is something like (&(|(objectclass=user))(|(|(memberof:1.2.840.113556.1.4.1941:=CN=GroupA,CN=Users,DC=forest,DC=dungeon,DC=prv)(primaryGroupID=2048)))) Basically, only members of the GroupA will be allowed. Note the 1.2.840.113556.1.4.1941 for the recursive search in AD.
    2. Login filter is the same, with the samaccountname as uid: (&(&(|(objectclass=user))(|(|(memberof:1.2.840.113556.1.4.1941:=CN=GroupA,CN=Users,DC=forest,DC=dungeon,DC=prv)(primaryGroupID=2048))))(samaccoutname=%uid))
    3. Group filter just takes into account the GroupA: (&(|(objectclass=group))(|(|(cn=GroupA))))
    4. Group-member association in the advanced tab must be "member (AD)"
    5. Nested groups checkbox must be enabled
    6. The rest of the option could be the default ones.
  4. Go to the users page

Previous behavior

  • Users inside the GroupB don't appear as member of GroupA. The'll likely appear without any group membership if they don't belong to any other group.
  • Clicking in the GroupA (which should appear in the left sidebar) doesn't show any user

PR's behavior

  • Users inside GroupB appear ONLY as member of groupA. Note that GroupB isn't part of the "accepted" groups in the group filter, so this is ok.
  • Clicking inside the GroupA shows all the users that are inside that group and any other group that is inside GroupA, such as GroupB. The users are shown only as members of the GroupA, not GroupB.

@jvillafanez
Copy link
Member Author

Tested with OC 10.6 and 10.8, works in both cases. Note that the patch can't be applied cleanly in any user_ldap's released version.

@phil-davis
Copy link
Contributor

@jvillafanez PR #684 has been merged. You can rebase this PR.

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline webUIProvisioning-master-chrome-mysql8.0-php7.4 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3486/56/1

Copy link
Contributor

@mrow4a mrow4a left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh makes sense, probably was overlooked / not tested. will approve after integration test passing

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline webUIProvisioning-master-chrome-mysql8.0-php7.4 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3489/56/1

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline webUIProvisioning-master-chrome-mysql8.0-php7.3 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3493/55/1

@jvillafanez
Copy link
Member Author

@janackermann @JammingBen it seems we broke something with the group UI and it's breaking these tests. If it's intentional we need to adjust or drop the failing tests

master
Screenshot from 2021-09-28 09-55-00

10.8.0
Screenshot from 2021-09-28 10-19-04

@AlexAndBear
Copy link

AlexAndBear commented Sep 28, 2021

@jvillafanez Is everything else working correctly?
At first, it was not intended that those groups won't be shown, but why the heck, we want to show x groups while creating a user, if they are not assignable?

So I think this is an advancement, IF everything else is working

@phil-davis
Copy link
Contributor

Note: I am making a core PR to @skipOnOcV10.8.0 etc a lot of core test scenarios that had core master changes recently and are known to not pass any more against "latest" core 10.8.0. That will fix all failures that are in pipelines that run against core "latest". After removing this "noise", I will see what else is failing...

@jvillafanez
Copy link
Member Author

At first, it was not intended that those groups won't be shown, but why the heck, we want to show x groups while creating a user, if they are not assignable?

You're right. Makes sense to me.
Let's wait for the changes in the tests of core.

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline webUIProvisioningS-master-chrome-mysql8.0-php7.3 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3497/69/1

@phil-davis
Copy link
Contributor

Some core skips that I missed yesterday are coming in core PR owncloud/core#39305

@phil-davis
Copy link
Contributor

PR #686 has been merged - CI is green now. This PR and any others should be rebased.

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline apiUserLDAP-latest-postgres9.4-php7.3 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3506/38/1

@jvillafanez
Copy link
Member Author

Type error: Too few arguments to function LoggingContext::assertLogFileContainsAtLeastOneEntryMatchingTable(), 2 passed in /var/www/owncloud/testrunner/tests/acceptance/features/bootstrap/LoggingContext.php on line 214 and exactly 3 expected (Behat\Testwork\Call\Exception\FatalThrowableError)

@phil-davis this seems to be a problem in the core tests.

@ownclouders
Copy link
Contributor

💥 Acceptance tests pipeline core-apiAll-21-20-master-mysql8.0-php7.3 failed. The build has been cancelled.

https://drone.owncloud.com/owncloud/user_ldap/3513/90/1

@AlexAndBear
Copy link

This branch is out-of-date with the base branch
@jvillafanez can you take care ?

lib/Group_LDAP.php Outdated Show resolved Hide resolved
For nested groups, this was a problem because the group filter could
remove the nested group, so we couldn't check the memberof attribute of
the nested group and we couldn't go upwards in the group tree.

GroupA contains GroupB, and GroupB contains User1. If the group filter
contains just GroupA (not GroupB), checking the "memberof" of User1
would return no group. This PR fixes this by returning GroupA, which is
part of the group filter (if the "nested groups" checkbox is active)
@sonarcloud
Copy link

sonarcloud bot commented Nov 15, 2021

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

100.0% 100.0% Coverage
0.0% 0.0% Duplication

@jvillafanez jvillafanez merged commit 2ccc261 into master Nov 16, 2021
@delete-merged-branch delete-merged-branch bot deleted the fix_nested_group_with_filter branch November 16, 2021 08:44
This was referenced Nov 22, 2021
@jnweiger
Copy link
Contributor

Confirmed fixed in 10.9.0 RC2

But it works in more cases than specifed above:

  • Also works, when checkbox [ ] nested groups is not checked.
  • Also works with algorithm memberOf, which is explained to not work with nested groups.

image

Note:
The ldap queries must be written as ...(memberof:1.2.840.113556.1.4.1941:=CN=GroupA,...
The syntax propsed by the query generator ...(memberof=CN=GroupA,... only finds direct members of GroupA

@jvillafanez
Copy link
Member Author

jvillafanez commented Dec 16, 2021

To clarify a bit, this PR just fixes the linked issue, whose steps to reproduce are described at the beginning. It doesn't have anything to do with the group membership algorithm because they were introduced later.

There might be some interactions between the algorithm and the checkbox that we should investigate.

@mmattel
Copy link
Contributor

mmattel commented Dec 16, 2021

@jvillafanez @jnweiger is the way how the query string is used docs relevant?
Imho it looks like, but I am not sure. This may be not relevant for this PR but in general.

@jvillafanez
Copy link
Member Author

I don't think it's doc relevant by itself. I mean, it fixes an issue with recursive group membership in AD, but you should know about recursive group membership in the first place.

If we don't have docs about recursive group membership, we could decide whether we should document something or not, but I think it's out of the scope of this ticket. In addition, this is mainly for AD (I'm not sure how many providers support this feature, but I don't think is too common)

@mmattel
Copy link
Contributor

mmattel commented Dec 16, 2021

we don't have docs about recursive group membership,

As far I know, we dont have that, therefore I think it is a good idea to have a docs ticket to keep track on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants