I don't want to import the groups from LDAP into Jira, while importing the users from LDAP in Jira.
I am not familiar to LDAP, but I want to import only users in Jira.
Is there anything that can be done at Jira level to restrict importing groups?
If you fill out your directory settings with the correct, but set the 'Group Object Filter" to an LDAP filter that will match nothing, you will not import any groups.
An example of a globally non-matching LDAP filter would be (1=2)
If you are using this technique, the other group LDAP settings become redundant, so you can set them as you please.
I don't know that there is a way to tell LDAP not to return the groups (in JIRA or otherwise), but you can tell JIRA not to use the groups to create JIRA groups. In my experience, JIRA will not automatically create JIRA groups to match LDAP groups if you use the setting "Read Only, with Local Groups".
I can't test that right now, I don't have my test server running. But I think that is the way it works. So if that is what you are trying to accomplish, then that should work for you.
You can specify what you want out of LDAP with extreme precision, certainly including whether you get users, groups, organizations, etc. Look up the LDAP search filter syntax. You will also need to know which LDAP schema is in use at the server, at least for users.
Related
If I have multiple Atlassian tools integrated with Crowd, i.e Jira, Confluence, Bamboo, etc., is it possible to grant a user access to Jira and not to Confluence or vice versa?
This can be done by the use of Groups. So, for example, you could have a jira-users group and a confluence-users group. Some users maybe members of both but other users may only be members of one and not the other.
The Managing Groups documentation for Crowd should help setting up the groups and adding users to them.
Specifying which Groups can access an Application details how to setup the restrictions you require per application.
Please note, that both these tasks require admin access to the Crowd Administration Console.
I have configured RTC with LDAP OpenDJ.
Now I am trying to import users but it is not giving any user list after search with * i.e. for all users.
However I am able to login to RTC using LDAP user itself.
I have given below filters in WAS LDAP user registry settings:
User filter: (&(uid=%v)(objectclass=inetOrgPerson))
Group filter:(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=posixGroup)))
User ID map: *:cn
Group ID map: *:cn
Group member ID map:
ibm-allGroups:member;ibm-allGroups:uniqueMember
With Base DN cn=JazzGroups,sc=ibm,dc=rtc,dc=com
Mapping in ccm_war,jts_war and rm_war is done,
I am able to map groups, users.
Is there any problem with OpenDJ?
Please help out in importing users.
I'm sorry I have no experience with RTC (not even sure what it stands out for) but OpenDJ is fully compliant with LDAPv3 and thus should work nicely with any client that has proper support of LDAP.
You might not be able to import users due to missing schema, lack of permissions for the user, or trying to add users with an already hashed password...
Please check OpenDJ access logs for details of failures. Usually the message in case of an error is pretty explicit.
I am able to import users now :-
I corrected few advanced properties Base DN, find user, etc in RTC admin GUI.
BTW thanks for your comment Ludovic Poitou.
I'm trying to connect artifactory (maven repository) to our open ldap.
I want to restrict access to users only in group 'developers'.
Sadly I'm far from being a ldap expert. That's the current problem here..
So if I don't do any filters on groups it's working.
Now I have setup a group developers, where the user 'adrian' is a uniqueMember of developers.
I hope my screenshots are a little help..
And here is the hierarchy:
And this is how the user 'adrian' is added to the group developers
So I tried already configuring the base path and filter like this:
search base: ou=group
filter: (uniqueMember=uid={0},ou=people,dc=firstbird,dc=eu)
I also left the search base completely blank..but that didn't help either.
You should not mix "User DN pattern" and "Search Filter" but rather use one of them. In your case you should use a search filter since the "User DN pattern" is used for "direct" user authentication.
You can use the following search filters:
(uniqueMember=uid={0},ou=people,dc=firstbird,dc=eu)
or
(&(uid={0})(uniqueMember=uid={0},ou=people,dc=firstbird,dc=eu))
The search base should be ou=people (an empty one will also work)
I need to create a Jira user/role for our support team to be able to login to JIRA and see what groups a user belongs to. They don't need to be able to edit or change anything, this should be read only, and ideally they would only access the user-browser. Jira 3.13.2 with Oracle DB.
Seeing who is in a group in JIRA is only allowed for members of jira-administrators. JIRA recommends using JIRA project roles rather than groups because they can be seen in more places and modified by project administrators.
If you really need this then I'd pursue custom development to change which groups are show for a user in their profile. It looks like the original three jira-* groups are shown to everyone but not groups that were added.
I'm working on a project where I've multiple ressources and multiple users, what I need to do is to associate different access rignts to every user depending on the ressource he wants to access to
The problem is that a simple LDAP server can't implement this kind of situation,
An idea is to use multiple LDAP servers, one for each ressource, then how could I manage them all?
Or is there another authentication process I can use in this case?
Spring Security has a special ACL module to handle such situations. The basic idea is that each domain object / ressource may have separate access control list. You need to fill this list with appropriate permissions and add corresponding checks in your code. You can have parent -> child relations between the objects to reduce number of permissions. Check it out.
If you have logic behind the access to the resources, you may want to use a rules authorization language such as XACML.
If the assignment of resources to users is arbitrary then the use of ACLs with Spring Security's ACL module is good enough.
The problem is that a simple LDAP server can't implement this kind of situation
Mine does. You use LDAP to define the roles associated with each user, then you use web.xml to associate the resources with the roles that are required to access them, then you configure/write your login module such that it looks up the roles of each user when you login. Container-managed security can do all that.