matomo-org
Support nested groups for LDAP
I would love to see that - or at least there should be the option to use the Extension:(memberOf:1.2.840.113556.1.4.1941:=cn=group,cn=users,DC=x)
I tried to set it up but unfortunately it doesn't seem to be used.
bump just encountered the issue, it's blocking us from using Matomo at the moment.
@all I have added this task "For Priortisation", meanwhile @Mndarin can you provide more context to this, so that we better understand the issue and it will help us in priortising it.
Create a LDAP group "A". Create a LDAP group "B". Set user "X" as member to "A". Set group "A" as member to "B".
Configure the plugin to use group "B" as required for access.
User "X" cannot login because the nested groups are not resolved by the plugin.
Note that there could be more levels of nesting than just 2 groups.
We're considering implementing this. I have a Q: from a LDAP perspective, should Nested Groups always be resolved? (or are there cases you'd want to disable that and then we also need a setting for this - but ideally we don't need a new setting)
should Nested Groups always be resolved?
I could not think of any reason why one would not want to.
We're considering implementing this. I have a Q: from a LDAP perspective, should Nested Groups always be resolved? (or are there cases you'd want to disable that and then we also need a setting for this - but ideally we don't need a new setting)
The rationale for making recursion optional is for cases of large/poorly structured directories where it could cause slow-downs. (Not a case I've ever faced personally).
@dougti we should have an option to disable this I think @mattab what are your thoughts on this?
No option needed @AltamashShaikh we can implement the nested resolution logic to all :+1:
Are you guys sure, you want to implement the recursion yourself? This can get VERY bad and slow on big forests.
Normally the "1.2.840.113556.1.4.1941" search options is there for exactly this. Here is a simple User-Lookup which we use in sonarqube for example:
ldap.user.request=(&(objectClass=user)(sAMAccountName={login})(memberOf:1.2.840.113556.1.4.1941:=CN=complete cn of group))
As you can see there's a placeholder for finding the user. The trick here is not to get the users of the group and than match the user but instead offload the check for a given user directly to ldap / AD
@pfeigl The LDAP_MATCHING_RULE_IN_CHAIN is great but I'm not sure it can currently be used with how LoginLdap is configured. Have you tested this with LoginLdap?
Often enabling recursion is behind a configuration flag.
Having it togglable might be the right way.
Btw I finally managed to get it working with the current state of the implementation. The trick was not to use Ldap SearchFilter but only go with memberOf settings and more specifically set this as the memberOf Field:
memberOf:1.2.840.113556.1.4.1941:
Than just put the correct group in the group field and you should be good to go.
See the following screenshot:
With this combination, the search query is actually setup correctly internally.
@pfeigl with the above setting, nested groups are working perfectly for you?
Yes, it worked just as expected
(We are only doing login integration, no mass sync. This would probably not work this way)
@pfeigl Tested and if memberOf:1.2.840.113556.1.4.1941: is set only the matching users are synced with ./console loginldap:synchronize-users and its better to use memberOf:1.2.840.113556.1.4.1941: to resolve nested groups
@Mndarin @lgromb Does setting LDAP memberOf Field as memberOf:1.2.840.113556.1.4.1941: and saving and testing wokrs for you ?
@all We created a new FAQ to resolve nested groups using memberOf:1.2.840.113556.1.4.1941:, it will be great if anyone can review it