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