Open spirritus opened 7 years ago
That is correct. This is a feature treated differently by different LDAP servers, if supported at all. There is currently no support implemented in Gitblit to deal with such a set up.
Wow, that was fast ... :-) ok maybe in the future. There seems to be an issue with ldap searches however.
The nesting situation can be somewhat mitigatet by adapting the groupMemberPattern to: realm.ldap.groupMemberPattern = (&(objectClass=group)(|(member=${dn})(member=${memberOf})))
This should find all groups which have the user as direct member and additionally all groups which have the users groups as member. This filter is not designed to find groups in a chain - but you get at least one level of nesting. Assume: GroupA has member GroupB has member GroupC has member UserZ. GroupA should never be found, GroupB and GroupC should.
Above search should return GroupC (because: member=${dn}) AND GroupB (because: member=${memberOf}) however only GroupC is found. (Maybe this an issue with multiple return values, e.g. multiple memberOf fields, for a replacement in ${someVariableFromTheUser}??)
It is possible to match users in a chain. It is a feature of AD.
The following value in gitblit.properties works for me:
realm.ldap.groupMemberPattern = (&(objectClass=group)(member:1.2.840.113556.1.4.1941:=${dn}))
See: https://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx
Hi there,
gitblit is a wonderfull peace of software. However, either there seems to be a small issue with the groupMemberPattern or i am an idiot - equally possible :-) Suppose this: GroupB is a member of GroupA. UserZ belongs to GroupB. By nesting this means UserZ is also member of GroupA. However gitblit only sees GroupB. Furthermore, if a group has only other groups as members and therefor no users gitblit does not seem to "see" them. (Gitbltit 1.8 with AD as LDAP)
If you need more details i am happy to provide. Cheers Jens