246 lines
10 KiB
Markdown
246 lines
10 KiB
Markdown
---
|
|
page-title: "HowTos/LDAP authentication for Atlassian JIRA using FreeIPA - FreeIPA"
|
|
url: https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA
|
|
date: "2023-03-06 15:19:17"
|
|
---
|
|
[Template:Draft](https://www.freeipa.org/index.php?title=Template:Draft&action=edit&redlink=1 "Template:Draft (page does not exist)") Draft / Work in Progress on formatting
|
|
|
|
- [1 Introduction](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Introduction)
|
|
- [2 Integration Path](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Integration_Path)
|
|
- [3 Toolset](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Toolset)
|
|
- [4 Key Challenges](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Key_Challenges)
|
|
- [4.1 LDAP Adapter Type](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#LDAP_Adapter_Type)
|
|
- [4.1.1 Other Candidate Adapters](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Other_Candidate_Adapters)
|
|
- [4.2 RFC Schemas + FreeIPA Trees](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#RFC_Schemas_.2B_FreeIPA_Trees)
|
|
- [4.3 E-Mail Attribute and Bind Type](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#E-Mail_Attribute_and_Bind_Type)
|
|
- [4.4 Replicating Users and Groups](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Replicating_Users_and_Groups)
|
|
- [4.4.1 Users](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Users)
|
|
- [4.4.2 Groups](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#Groups)
|
|
- [5 The Final Configuration](https://www.freeipa.org/page/HowTos/LDAP_authentication_for_Atlassian_JIRA_using_FreeIPA#The_Final_Configuration)
|
|
|
|
## Introduction
|
|
|
|
This page describes how to integrate JIRA to a FreeIPA LDAP server. Very likely the same approach can be taken to integrate other Atlassian products such as Confluence to FreeIPA.
|
|
|
|
JIRA offers a number of different ways to integrate to LDAP. Unfortunately FreeIPA integration is not natively supported, but once you know how, it is not that difficult. There are probably other solutions that work as well, but this is the one that worked for us.
|
|
|
|
At the time of integration we were running FreeIPA Server 4.1.0 and JIRA 6.4.7
|
|
|
|
See:
|
|
|
|
[https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory](https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory) [https://confluence.atlassian.com/display/DEV/How+to+write+LDAP+search+filters](https://confluence.atlassian.com/display/DEV/How+to+write+LDAP+search+filters)
|
|
|
|
## Integration Path
|
|
|
|
JIRA can be integrated to an LDAP by a number of different paths including full bi-directional sync.
|
|
|
|
We chose **Internal Directory with LDAP Authentication**, which means that FreeIPA users and groups are copied to the JIRA internal directory when a FreeIPA user logs in to JIRA. i.e.
|
|
|
|
- FreeIPA is used for authentication
|
|
- FreeIPA users, and optionally groups + group membership are replicated one-way to JIRA on user login.
|
|
|
|
|
|
In particular this means that only a subset of the FreeIPA users will be replicated to JIRA - only those that actually log in to JIRA.
|
|
|
|
See [https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal+Directory+with+LDAP+Authentication](https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal+Directory+with+LDAP+Authentication)
|
|
|
|
Much of the config described below could probably be used for the other integration paths.
|
|
|
|
## Toolset
|
|
|
|
We used the following tools to gain insight into the structure of the FreeIPA LDAP directory, and to understand and simulate the queries that JIRA (might) be making against FreeIPA
|
|
|
|
- **Apache Directory Studio:** This or any similar visual LDAP browser is invaluable to getting into the guts of an LDAP, seeing what is where, which attributes are available (and even making changes in extremis). See [https://directory.apache.org/studio/](https://directory.apache.org/studio/)
|
|
|
|
- **ldapsearch:** This command line tool is your friend! Use it to simulate queries that JIRA might be making, fine tune filters, and see what FreeIPA returns. This approach helped us to see that we were initially getting results from both the compat and accounts trees - which confused JIRA, and then how to prevent this.
|
|
|
|
- **FreeIPA and JIRA logs:** What queries is JIRA actually making? Although you can guesstimate based on your config, it is great to see the actual queries.
|
|
- FreeIPA Server: /var/log/dirsrv/slapd-\*/access
|
|
- JIRA: See [https://confluence.atlassian.com/display/JIRA/Logging+and+Profiling](https://confluence.atlassian.com/display/JIRA/Logging+and+Profiling) We added the package com.atlassian.crowd.directory.SpringLDAPConnector, and got partial results.
|
|
|
|
## Key Challenges
|
|
|
|
### LDAP Adapter Type
|
|
|
|
While JIRA offers a wide range of LDAP Adapters, it does not (yet) offer a FreeIPA Adapter out of the box. We chose the Generic LDAP adapter, and were able to configure this for FreeIPA.
|
|
|
|
#### Other Candidate Adapters
|
|
|
|
- **FedoraDS:** We did NOT use the FedoraDS adapter (even though FedoraDS is an ancestor of FreeIPA), as this uses the compat tree due to the (objectclass=posixAccount) filter. However other freeIPA users have reported success with this adapter: [https://www.redhat.com/archives/freeipa-users/2015-June/msg00200.html](https://www.redhat.com/archives/freeipa-users/2015-June/msg00200.html)
|
|
- **Other Adapters:** It is possible that other adapters can also be persuaded to work, with more or less additional configuration.
|
|
|
|
### RFC Schemas + FreeIPA Trees
|
|
|
|
There are several different LDAP RFC Schemas. FreeIPA uses the RFC 2307bis schema (with users stored under cn=accounts, cn=users), but also offers publishes an alternative "compat" tree cn=users,cn=compat,dc=example,dc=com with users in a RFC 2307 schema.
|
|
|
|
The chosen adapter, and the configuration applied to it, plays an important role here in determining which of the trees returns data. Here using ldapsearch was invaluable. For example it proved that in one of our first attempt we were getting returns from both trees, and that JIRA was using only the first return.
|
|
|
|
Making the query with the correct filter gave us data from the desired tree (cn=accounts, cn=users). The ldap.user.filter (objectclass=inetorgperson) ensures that replies DO NOT come from the compat tree (which among other things does not have the mail attribute).
|
|
|
|
See [https://www.freeipa.org/page/Directory\_Server](https://www.freeipa.org/page/Directory_Server) and [https://www.redhat.com/archives/freeipa-users/2015-June/msg00547.html](https://www.redhat.com/archives/freeipa-users/2015-June/msg00547.html)
|
|
|
|
### E-Mail Attribute and Bind Type
|
|
|
|
We managed to get users synced from FreeIPA, and able to authenticate and thus log in to JIRA fairly easily. However the email field was empty, which means that JIRA mail notification didn't work, rendering JIRA about as useful as a chocolate teapot. While the email field could be updated in the JIRA user management, it always emptied every time the user logged back on.
|
|
|
|
Once again ldapsearch proved what was going on: We had configured the LDAP Adapter without a user: i.e. anonymous bind. Performing the same query via simple bind: i.e. with an LDAP user, returned additional attributes, including the all important mail attribute. We therefore reconfigured the LDAP Adapter to use a FreeIPA user and password, and bingo! JIRA received the mail attribute!
|
|
|
|
As the password of the bind user is stored in plaintext in the jira database, make sure the user configured is a limited user (member of the default ipa-users group is sufficient). e.g. don't use the Directory Manager user!
|
|
|
|
### Replicating Users and Groups
|
|
|
|
#### Users
|
|
|
|
It is possible to replicate only the users to JIRA, with groups managed locally (you can configure default groups to which user are added automatically). We did this as a first step.To get this to work change:
|
|
|
|
- **User Schema Settings / Additional User DN** to cn=accounts
|
|
- **User Schema Settings / User Unique ID Attribute** from entryUUID to uid
|
|
|
|
#### Groups
|
|
|
|
Additionally groups, and group memberships can be replicated to JIRA. To get this to work change:
|
|
|
|
- **Group Schema Settings / Additional Group DN** to cn=accounts
|
|
- **Group Schema Settings / Group Object Class** from groupOfUniqueNames to groupOfNames
|
|
- **Group Schema Settings / Group Object Filter** from (objectclass=groupOfUniqueNames) to (objectclass=groupOfNames)
|
|
- **Member Schema Settings / Group Members Attribute** from uniqueMember to Member
|
|
|
|
## The Final Configuration
|
|
|
|
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).
|
|
|
|
Note: you will need to change some values to reflect your domain, hostname etc
|
|
|
|
mysql> select attribute\_name, attribute\_value from cwd\_directory\_attribute where directory\_id = xxxx;
|
|
|
|
**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
|
|
|
|
true
|
|
|
|
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
|
|
|
|
cn=accounts
|
|
|
|
ldap.group.filter
|
|
|
|
(objectclass=groupOfNames)
|
|
|
|
ldap.group.name
|
|
|
|
cn
|
|
|
|
ldap.group.objectclass
|
|
|
|
groupOfNames
|
|
|
|
ldap.group.usernames
|
|
|
|
Member
|
|
|
|
ldap.nestedgroups.disabled
|
|
|
|
true
|
|
|
|
ldap.pagedresults
|
|
|
|
false
|
|
|
|
ldap.pagedresults.size
|
|
|
|
1000
|
|
|
|
ldap.password
|
|
|
|
*<password of the bind user>*
|
|
|
|
ldap.referral
|
|
|
|
false
|
|
|
|
ldap.url
|
|
|
|
ldap:/*/<hostname of your FreeIPA Server>*.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
|
|
|
|
uid
|
|
|
|
ldap.userdn
|
|
|
|
uid=*<uid of the bind user>*,cn=users,cn=accounts,dc=my,dc=silly,dc=example,dc=com
|
|
|
|
ldap.usermembership.use
|
|
|
|
false
|
|
|
|
ldap.usermembership.use.for.groups
|
|
|
|
false |