On Mon, 06 Jul 2015, Christopher Lamb wrote:
Hi MarkusThe short answer is no. The longer answer is: We replicated only users, and manage groups within JIRA. The delegated LDAP approach ("Connecting to an Internal Directory with LDAP Authentication") allows you to either synchronise groups and group membership from FreeIPA to Jira, or to automatically add FreeIPA users to Jira groups. We chose the second approach: All users are automatically added to the jira-users and jira-developers groups on first log in. This suits our purposes, as basically all our JIra users should have the same rights, other than admins. Note also that the delegated LDAP approach does not allow you to configure the LDAP properties JIRA accesses groups and membership, but the full synchronised approach does. On our first attempt to integrate FreeIPA and JIRA we tried to replicate both users and group, but only succeeded in replicating users, not the groups (or to be precise, group-membership). A bit of googling showed that others had problems with the groups bit. My initial guess is that, just like the mail attribute, very likely the compat tree is getting in the way of group membership.
compat tree presents group membership information using RFC 2307, this is, after all, a *compatibility* tree and RFC 2307 what legacy clients use.
Using Apache Directory Studio to see how group membership is modelled in the compat and accounts trees I see the following. cn=compat, cn=groups, cn=admins, memberUid --> set of users belonging to the group admins cn=compat, cn=users, uid=bilbo No attibute showing which groups this user belongs to.
memberUid is what RFC 2307 wants.
cn=accounts, cn=groups, cn=ipausers, member --> set of users belonging to the group ipausers cn=accounts, cn=users, uid=bilbo, memberOf --> list of groups user bilbo is a member of
member and memberOf are what RFC 4519 wants.
Here are some ldapsearch queries to simulate what JIRA might be doing to retrieve group membership —reply from accounts tree only ldapserach -x -D "uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com" -W -h localhost -p 389 -b "dc=my,dc=silly,dc=example,dc=com" "(&(objectClass=groupofnames)(cn=admins))" member —reply from both compat tree and accounts tree. (reply from compat tree is empty, reply from accounts tree has values) ldapserach -x -D "uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com" -W -h localhost -p 389 -b "dc=my,dc=silly,dc=example,dc=com" "(cn=admins)" member —reply from compat tree only ldapserach -x -D "uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com" -W -h localhost -p 389 -b "dc=my,dc=silly,dc=example,dc=com" "(cn=admins)" memberUid
You configure JIRA to always ask for memberUid, but then you wouldn't get mail attribute from the compat tree as it is not part of RFC 2307 payload. You can try setting up a separate compat tree which provides member/memberOf (e.g. RFC 4519) based output for both IPA and AD users but currently there is internal assumption to expect memberUid when parsing requests for group memberships of AD users -- after all the plugin was expected to handle RFC 2307 only. It would probably make sense to add ability to return RFC 4519 compatible output over some subtree with slapi-nis plugin and then hook together AD-related details there as well, querying them from SSSD over infopipe interface -- at least I've seen enough requests for such specialized tree to consider a combined 'modern' RFC 4519 subtree. If this sounds useful for you, feel free to file a ticket for that. If you have subscription with Red Hat, it would probably be good to file a request via normal support channel too so that demand is actually measurable. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
