On Mon, 06 Jul 2015, Christopher Lamb wrote:
Hi Markus

The 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

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)"
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

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to