-
Suggestion
-
Resolution: Unresolved
-
None
-
None
FreeIPA 3.x is a very powerful replacement for MS AD. As it turns out, it also contains a full RBAC system that has host-based differentiation capabilities.
Imagine: Individual permissions allow very granular mapping to actual functions in the Atlassian stack. Traditional Atlassian roles such as jira-administrator allow a smooth migration path for existing users. Privileges are created to map these permissions to roles. Add hosts to the mix, and roles can be differentiated by server such that the jira-administrator role can be the same everywhere, but with only certain users available to exercise a role per host.
FreeIPA does all this out of the box.
Crowd is great, but FreeIPA has slowly improved to where Crowd was originally going to go. FreeIPA is incredibly detailed, maybe too detailed for the beginner user. As it's turned out, they compliment each other quite remarkably! Supporting both Crowd and FreeIPA will make the Atlassian stack incredibly valuable.
![[Atlassian Documentation] Page](https://confluence.atlassian.com/images/icons/favicon.png "[Atlassian Documentation] Page"){kind=icon}
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page"){kind=icon}
[CWD-4134] Support FreeIPA Roles/Permissions/Privileges
I am trying to migrate from OpenLDAP to FreeIPA. I am not able to have JIRA communicate w/ FreeIPA. I get connection error 49.
// code placeholder
Connection test failed. Response from the server: [LDAP: error code 49 - Invalid Credentials]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials] For more information regarding LDAP error codes see Troubleshooting LDAP Error Codes.
I agree, native support for FreeIPA would be super, and sensible as FreeIPA is an obvious LDAP solution for anyone running Enterprise Linux (RHEL, OEL, CENTOS et al).
It is however possible to integrate FreeIPA to JIRA (and probably to other Atlassian products). However it took us several attempts, and some head-scratching to get a working solution. As always the devil is in the details, but it is easy once you know how.
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 (and without working e-mail notification Jira is as useful as a chocolate tee-pot.)
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. (FreeIPA can provide users from 2 trees, the "compat" tree and the native users accounts tree).
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 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
Jerald Sussman
added a comment - +1 
I've also had issues with this but eventually configured it trough trial and error in the Crowd UI. I have posted my settings here.