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.

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.

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

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

Chris




From:   <markus....@mc.ingenico.com>
To:     Christopher Lamb/Switzerland/IBM@IBMCH, <aboko...@redhat.com>,
            <mko...@redhat.com>
Cc:     <freeipa-users@redhat.com>
Date:   06.07.2015 08:00
Subject:        AW: AW: [Freeipa-users] FreeIPA mail object to use in 3rd party
            tool



Hi Chris,

thanks for your help. Now we are able to login and have our mails
delivered. Do you maybe know which configuration objects needs to be used
in Jira to be able to use the FreeIPA groups? We have configured all
necessary Jira Groups in FreeIPA but it doesn´t work as it should.

-----Ursprüngliche Nachricht-----
Von: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Gesendet: Mittwoch, 1. Juli 2015 09:31
An: Moj, Markus; aboko...@redhat.com; mko...@redhat.com
Cc: freeipa-users@redhat.com
Betreff: Re: AW: [Freeipa-users] FreeIPA mail object to use in 3rd party
tool

Hi Markus

It is a pleasure. It was serendipity that we were working on the same
problem at the same time. Your thread prompted me to take a different look
at the question and find a viable solution. Let us know if it works for
you.

What intrigues me is: with my solution we had to change from an anonymous
bind to a simple bind via user / pw to get one extra attribute: mail.  This
raises the question: Is there some way to configure IPA to determine which
user attributes are returned to anonymous binds?

Cheers

Chris



From:            <markus....@mc.ingenico.com>
To:              Christopher Lamb/Switzerland/IBM@IBMCH, <aboko...@redhat.com>,
            <mko...@redhat.com>
Cc:              <freeipa-users@redhat.com>
Date:            01.07.2015 07:54
Subject:                 AW: [Freeipa-users] FreeIPA mail object to use in 3rd
party
            tool



Hi Christopher,

thanks very much for your help, I appreciate it. I will reconfigure our
Jira and see how it works out.


-----Ursprüngliche Nachricht-----
Von: Christopher Lamb [mailto:christopher.l...@ch.ibm.com]
Gesendet: Montag, 29. Juni 2015 16:08
An: Alexander Bokovoy; Moj, Markus; Martin Kosek
Cc: freeipa-users@redhat.com
Betreff: Re: [Freeipa-users] FreeIPA mail object to use in 3rd party tool

Hi

As of a few minutes ago, we can now replicate FreeIPA users to JIRA,
including the vital mail attribute!

Note there are probably other solutions that work as well, but this is the
one that works for us.

Key points:
a) Integration Style: "Internal Directory with LDAP Authentication" -->
only those users that attempt to login are replicated, useful if your JIRA
users are a subset of your FreeIPA users.
b) LDAP Type = Generic LDAP --> JIRA does not yet have native FreeIPA
Support.
c) bind = via user / password --> we first tried anonymous bind (w/o user).
While this replicated users and logins worked, the all important mail
attribute was not replicated.
d) as the password of the bind user is stored in plaintext in the jira db,
make sure this is a limited user (member of the default ipa-users group is
sufficient). e.g. don't use the Directory Manager user!
e) ldap.user.filter=(objectclass=inetorgperson) ensures that replies DO NOT
come from the compat tree (no mail attribute). We want replies from
cn=users,cn=accounts, which does have the mail attribute

Below is the config direct from the Jira database (of course we made the
config changes via the Jira admin GUI, which has a nifty Test function.

mysql> select attribute_name, attribute_value from
mysql> cwd_directory_attribute
where directory_id = 10001;
+--------------------------------------------+---------------------------------------------------------------------+


| attribute_name                             | attribute_value
|
+--------------------------------------------+---------------------------------------------------------------------+


| autoAddGroups                              | jira-users
|
| crowd.delegated.directory.auto.create.user | true
|
| crowd.delegated.directory.auto.update.user | true
|
| crowd.delegated.directory.importGroups     | false
|
| crowd.delegated.directory.type             |
com.atlassian.crowd.directory.GenericLDAP                           |
| ldap.basedn                                |
dc=my,dc=silly,dc=example,dc=com                                    |
| ldap.external.id                           | uid
|
| ldap.group.description                     | description
|
| ldap.group.dn                              |
|
| ldap.group.filter                          |
(objectclass=groupOfUniqueNames)                                    |
| ldap.group.name                            | cn
|
| ldap.group.objectclass                     | groupOfUniqueNames
|
| ldap.group.usernames                       | uniqueMember
|
| ldap.nestedgroups.disabled                 | true
|
| ldap.pagedresults                          | false
|
| ldap.pagedresults.size                     | 1000
|
| ldap.password                              | xxxxxxxxx
|
| ldap.referral                              | false
|
| ldap.url                                   |
ldap://xxx-ldap.my.silly.example.com:389                            |
| ldap.user.displayname                      | displayName
|
| ldap.user.dn                               | cn=accounts
|
| ldap.user.email                            | mail
|
| ldap.user.filter                           | (objectclass=inetorgperson)
|
| ldap.user.firstname                        | givenName
|
| ldap.user.group                            | memberOf
|
| ldap.user.lastname                         | sn
|
| ldap.user.objectclass                      | inetorgperson
|
| ldap.user.username                         | uid
|
| ldap.user.username.rdn                     | cn
|
| ldap.userdn                                |
uid=yyyy,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com      |
| ldap.usermembership.use                    | false
|
| ldap.usermembership.use.for.groups         | false
|
+--------------------------------------------+---------------------------------------------------------------------+



@Martin K
In an earlier thread on FreeIPA / JIRA integration you asked for
contributions to a "How to Article". I think the solution above could be
the basis of such an article.

Cheers

Chris




From:                             Christopher Lamb/Switzerland/IBM@IBMCH
To:                               Alexander Bokovoy <aboko...@redhat.com>,
            markus....@mc.ingenico.com
Cc:                               freeipa-users@redhat.com
Date:                             29.06.2015 11:27
Subject:                                  Re: [Freeipa-users] FreeIPA mail 
object to
use in 3rd
party
            tool
Sent by:                                  freeipa-users-boun...@redhat.com



Hi all

I am fighting this exact problem too.

We had setup Jira, integrated to FreeIPA with the option "Internal
Directory with LDAP Authentication", using anonymous bind.

This integration path means that when a FreeIPA user attempts to logon to
Jira with his FreeIPA Credentials, his user is replicated from FreeIPA to
the Jira user directory.

https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal
+Directory+with+LDAP+Authentication

While this allows FreeIPA users to successfully log in to Jira, the user
was replicated without email, which renders Jira as useful as a chocolate
teepot.

Alexanders's reply prompted me to "go back to basics". So I fired up Apache
Directory Studio, and the command line to do some ldapsearchs, to see what
was returned. This should then guide me how to configure the JIRA / FreeIPA
integration.


Query 1: Anonymous bind, filter is uid = bilbo

[root@xxx-ldap ~]# ldapsearch -x -h localhost -p 389 -b
"dc=my,dc=silly,dc=example,dc=com" "(uid=bilbo)"
# extended LDIF
#
# LDAPv3
# base <dc=my,dc=silly,dc=example,dc=com> with scope subtree # filter:
(uid=bilbo) # requesting: ALL #

# bilbo, users, compat, my.ch.example.com
dn: uid=bilbo,cn=users,cn=compat,dc=my,dc=silly,dc=example,dc=com
cn: bilbo bagins
objectClass: posixAccount
objectClass: top
gidNumber: 1175800010
gecos: bilbo bagins
uidNumber: 1175800010
loginShell: /bin/sh
homeDirectory: /home/bilbo
uid: bilbo

# bilbo, users, accounts, my.ch.example.com
dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com
displayName: bilbo bagins
cn: bilbo bagins
objectClass: ipaobject
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: sambaSAMAccount
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
initials: bb
gecos: bilbo bagins
homeDirectory: /home/bilbo
uid: bilbo
givenName: bilbo
sn: bagins
uidNumber: 1175800010
gidNumber: 1175800010

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

This returns 2 replies, inc one from the compat tree, as suggested by
Alexander. Note however, neither reply has the mail attribute!

//////////////////////////////////////////////////////////////////////////////////////////////////////////////




Query 2: Anonymous bind,  filtered on objectClass = inetorgperson AND uid =
bilbo (This is probably close to the JiRA query, which includes
inetorgperson)

[root@xxx-ldap ~]# ldapsearch -x -h localhost -p 389 -b
"dc=my,dc=silly,dc=example,dc=com"
"(&(objectClass=inetorgperson)(uid=bilbo))"
# extended LDIF
#
# LDAPv3
# base <dc=my,dc=silly,dc=example,dc=com> with scope subtree # filter:
(&(objectClass=inetorgperson)(uid=bilbo))
# requesting: ALL
#

# bilbo, users, accounts, my.ch.example.com
dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com
displayName: bilbo bagins
cn: bilbo bagins
objectClass: ipaobject
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: sambaSAMAccount
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
initials: bb
gecos: bilbo bagins
homeDirectory: /home/bilbo
uid: bilbo
givenName: bilbo
sn: bagins
uidNumber: 1175800010
gidNumber: 1175800010

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This now returns 1 record, from users, accounts, but still no mail
attribute

//////////////////////////////////////////////////////////////////////////////////////////////////////////////




Ah! me thinks - what about a search with user and password? Does this get
us something different?

Query 3: same as query 2, but no longer anonymous:

[root@xxx-ldap ~]# ldapsearch -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=inetorgperson)(uid=bilbo))"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=my,dc=silly,dc=example,dc=com> with scope subtree # filter:
(&(objectClass=inetorgperson)(uid=bilbo))
# requesting: ALL
#

# bilbo, users, accounts, my.ch.example.com
dn: uid=bilbo,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com
displayName: bilbo bagins
cn: bilbo bagins
objectClass: ipaobject
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: sambaSAMAccount
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
initials: bb
gecos: bilbo bagins
homeDirectory: /home/bilbo
uid: bilbo
mail: l...@ch.example.com
krbPrincipalName: bi...@my.silly.example.com
givenName: bilbo
sn: bagins
ipaUniqueID: 3bf7e2e0-0955-11e5-b065-080027f52872
uidNumber: 1175800010
gidNumber: 1175800010
krbPasswordExpiration: 20150831183039Z
krbLastPwdChange: 20150602183039Z
memberOf:
cn=ipausers,cn=groups,cn=accounts,dc=my,dc=silly,dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

That is much more like it:  Performing the query with an ldap user and
password gives me many more attributes, including the desired mail
attribute.

Next I will configure JIRA to bind to FreeIPA with a FreeIPA user (non-
anonymous bind), and report back ... (unless there is a way to configure
which attributes are available to anonymous binds ...)

Cheers

Chris



From:                                                              Alexander 
Bokovoy
<aboko...@redhat.com>
To:
markus....@mc.ingenico.com
Cc:                                                                
freeipa-users@redhat.com
Date:                                                              28.06.2015 
15:26
Subject:                                                                   Re:
[Freeipa-users] FreeIPA mail object to
use in 3rd
party
            tool
Sent by:
freeipa-users-boun...@redhat.com



On Thu, 18 Jun 2015, markus....@mc.ingenico.com wrote:
>Hi @all,
>
>
>
>I am new to freeIPA operating and are facing an issue with mail object
>in freeIPA. We are running Jira from Atlassian and are trying to
>authenticate against freeIPA. The authentication process is running but
>mail object is not provided by freeIPA to Jira to inform users about
>new events / trackers or whatsoever. If a test object is displayed with
>ldapsearch mail attribute is available and set but is not useable by
>Jira.
>
>How is it possibilt to inherit mail accounts in Jira to be able to
>authenticate and use FreeIPA as IDM for Jira as well as for Liunx
>systems.
This sounds like you are using $SUFFIX (e.g. dc=example,dc=com) as your
basedn when configuring Jira. If that's the case, then Jira gets results
from both cn=accounts,$SUFFIX and cn=compat,$SUFFIX if compat tree is
enabled. In the compat tree you have RFC2307 schema which doesn't include
mail attribute and slapi-nis always answers first over LDAP queries that
apply to cn=compat,$SUFFIX so you are ending up with two LDAP entries
returned for each individual IPA users, one from the compat tree without
mail attribute, another one is the original entry from
cn=users,cn=accounts,$SUFFIX.

Jira most likely expects a single entry response and if gets more, only
evaluates the first entry -- the one that is returned by the compat tree
and which doesn't have mail attribute.

You can solve this issue by bounding your query to cn=accounts,$SUFFIX to
only return primary IPA user/group entries.

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




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









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

Reply via email to