[Freeipa-users] FreeIPA mail object to use in 3rd party tool

[Alexander Bokovoy]

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