It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×4,713
×4,316
×88
×22

question asked: Apr 28 '15, 4:13 p.m.
question was seen: 5,012 times
last updated: Apr 30 '15, 11:40 p.m.

Related questions

LDAP - Grant All Domain Users JazzUsers access?!

1
1
Dave Evans (148●1●28●46) | asked Apr 28 '15, 4:13 p.m.
edited Apr 28 '15, 4:14 p.m.
Let's say I have a network where I would like everyone in "Domain Users" (using Microsoft Active Directory) to have the JazzUsers repository permissions. Has anyone come up with a nice way to accomplish this? It appears Jazz doesn't support nesting if the groups are inside different OUs, and I would like to not have JazzAdmins, JazzProjectAdmins, etc. inside the same OU as "Domain Users".
Comments
Donald Nong commented Apr 28 '15, 8:25 p.m.

Your post is a bit confusing. 

Are you saying that there are multiple groups with the exact name "Domain Users" under different OUs, and you want to just map "Domain Users" to the "JazzUsers" role? Then, what about the super- and sub-groups of the "Domain Users" group?
You can map completely separate and different groups to various Jazz roles and I don't understand why you have the concern of "inside the same OU".
And lastly, are you using WAS or Tomcat? The way to set this up is quite different.

Peter Morgenthaler commented Apr 28 '15, 8:59 p.m. | edited Apr 28 '15, 9:00 p.m.

This is a feature I have been looking for ages. Assuming it is the same problem.. We would like to create a group call OurJazzUsers which has one member from the AD which is Domain Users. It appears the Jazz can not recognise that ALL AD users belong to Domain Users. If there is a way to get JTS to recognise this that would be great.

Jazz Group Membership should have nothing to do with WAS/Tomcat as I believe it is done by the JTS LDAP query.

Donald Nong commented Apr 28 '15, 9:42 p.m.

I'm not an AD admin or expert. Since CLM supports LDAP, not AD (with its distinctive features and etc), can you explain the use case in LDAP terms? In other words, we will use the term DN, OU and etc. 

Peter Morgenthaler commented Apr 28 '15, 10:07 p.m.

Currently in the JTS you setup LDAP groups with a member attribute storing the CN "members". When the JTS starts it checks the current user to see if the CN of the current user is a member of the group. In AD there are built in groups such as CN=Domain Users. This built in group does NOT have an attribute called member but rather is a built in function/query that says all users in the domain automatically belong to this group. Because the JTS is looking to match the CN to the users CN it does not know how to handle these built in query groups. This is probably a unique feature of AD but is extremely useful so we don't need to maintain groups with over 4000 members in it. The only work around is to run scripts every day to query all users, get the user and add them as a member to an existing group. Hope that helps explain the problem

Dave Evans commented Apr 29 '15, 11:06 a.m.

I see, I guess I didn't think about Domain Users not being a 'real' group in the user's memberof property. This explanation is helpful, thanks. We have been doing it like you said: automating the duplication of the Domain Users built-in group. I was hopeful someone had come up with a workaround. Thanks for the help!

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Donald Nong (14.5k●6●14) | answered Apr 29 '15, 3:23 a.m.
This may not be an answer to the original post, but rather to the use case that Peter explained. The LDAP group mapping is done in two places - application server (WAS or Tomcat) and JTS. The application server handles authentication and authorization, and JTS handles synchronization of the users between LDAP and JTS, and the search function.
When we talk about assigning "JazzUsers" role to all users, there is actually an easy way to do it, as long as you are using WebSphere - in WAS admin console, when you configure "Security role to user/group mapping", usually we use the option "Map Groups ...", but you can use the option "Map Special Subjects" and choose "All Authenticated in Application's Realm", or even "Everyone". What it means is that as long as a user can log on, s/he will have the "JazzUsers" role. How do you configure so many users so that they can authenticate is a different story though.
As you can see in the screen shot, you can map a user directly without worrying about which group this user belongs to.
Comments
Dave Evans commented Apr 29 '15, 10:49 a.m.

That is actually a really helpful suggestion, so thanks!

The remaining question is... is there any way to get JTS to automatically import all users from the realm?

We are currently doing it as Peter suggested: running scripts daily which add all new users to the JazzUsers group. As we expand to additional networks, we were attempting to arrive at a better solution than duplicating the built-in "Domain Users" group in Microsoft AD.

Donald Nong commented Apr 30 '15, 7:10 a.m.

When you said the "realm", did you mean the WAS federated user repository? If so, then no, as JTS has to talk to a real LDAP server. If you have multiple LDAP/AD servers, then you can only import/sync from only one of the servers - the one currently configured in JTS. This is one of the caveats mentioned in this article.

If you just want to import/sync users from multiple OUs from a single AD server, using "Domain Users" as a rule, then you can do it this way:
1. Set the base user DN as the top level common OU (even just the DC root).
2. Add (primaryGroupID=513) as part of the search filter - this basically means the user's primary group is "Domain Users". You may have to add it everywhere you can specify a user search filter.
Reference here:

Peter Morgenthaler commented Apr 30 '15, 10:05 a.m.

Hi Donald,

I have made the change to WAS adding in All Authenticated in Applications Realm however users are presented with a 403 Forbidden page because the JTS is not recognising them as a member of the JazzUsers group. The username and password is being processed no problems by WAS from what I can tell it is just not recognising the user as a JazzUser as setup in the teamserver.properties files. This problem goes away if I an another group where the member is explicity added which brings me back to the original questions/comment about recognising All Domain users as a group.

Your comment above about adding primayGroupID-513.. Where would I add this in?

thanks

Peter

Donald Nong commented Apr 30 '15, 11:40 p.m. | edited Apr 30 '15, 11:40 p.m.

Peter, 


If the user is truly authenticated, the "JazzUsers" role should be assigned by WAS with the correct configuration. As mentioned in an earlier comment, JTS relies on the application server to tell what repository role the user has, and it does not do this by itself. Just imagine if you use multiple LDAP servers, or the WAS file-based user repository, how can JTS find out the repository role? Apparently it cannot query multiple LDAP servers or the file-based user repository, and it will just accept what the application server provides.
In WAS, depending on how you configure the LDAP server, the search filter can be found in different places. If using a federated repository, it is Global security > Federated repositories > LDAP2 > Federated repositories entity types to LDAP object classes mapping > PersonAccount - Search filter
(&(objectClass=user)(primaryGroupID=513))

If using standard LDAP, it is Global security > Standalone LDAP registry > Advanced Lightweight Directory Access Protocol (LDAP) user registry settings - User filter
 (&(uid=%v)(objectclass=person)(primaryGroupID=513))
To make it even simpler, I do not map any users or groups except for the "All Authenticated" special subject to the "JazzUsers" role for JTS in the WAS admin console. Combined with a base user DN "DC=JAZZ,DC=NET", I have no problem with assigning the "JazzUsers" role to a user "CN=Donald Nong,OU=Sydney,DC=JAZZ,DC=NET" (notice that the user is not under the built-in "CN=Users,DC=JAZZ,DC=NET").

In the JTS advanced properties (which is also stored in teamserver.properties), you can set "Find Users by Name Query" to "(&(cn=?1*)(primaryGroupID=513))", with a proper base user DN. This query will be used when you "import users". You can also set "User Search Object class filter" to "(&(objectClass=user)(primaryGroupID=513))" to limit what will be returned in an LDAP search (note that with the such configuration, users with a primary group other than "Domain Users" will not be returned).

It will be quite useful if you can capture network trace between JTS/WAS and the LDAP/AD server, as you will see how these filters will be used to construct the LDAP search. Of course it may not be practical or allowed in a corporate environment.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.