Windchill Security - Joined Active Directory Groups

[TomU]

Curious if anyone is leveraging Active Directory groups for access control in Windchill. I am evaluating it right now and one of the hangups I'm running into is the inability to set permissions based on the combined membership of two different groups.

For example, let's say I have two groups in Active Directory:

• Windchill_Users
• Product_ABC_Users

The first group contains everyone in the company that is allowed to access Windchill. The second group contains everyone one in the company who is allowed access to one particular product. (Could be department, division, product team, whatever.) This group has MANY more people in it - many who should never appear in Windchill.

In a perfect world, I would like to define access based on a join of these two groups.

• If a user exists in both groups then they are allowed access.
• If a user only exists in Windchill_Users, they can log in but they won't be able to access Product_ABC.
• If a user only exists in Product_ABC_Users, but not in Windchill_Users, then they can't log in at all (or even be listed in Windchill).

From my testing so far, I can prevent users from logging in via complex Apache filters, but ALL members of the Product_ABC_Users group are showing up in Windchill even though both the Info*Engine and Apache user filters are set to only allow users in the Windchill_Users group.

I really would like to avoid recreating a bunch of context specific groups in Windchill and then manually having to maintain membership on them individually. Having the ability to check membership in multiple groups at the same time would really simplify things. Has anyone figured out a way to accomplish something like this?

Thanks!

[Arpit-Singh]

Hi Tom,

Firstly, i would be curious to know how is your filter's set in Apache and InfoEngine.

Ideally if you can prevent them from login, you should be able to apply the same rule in JNDI, so that windchill wont even see them. For your requirement set up a user filter that allows all users from Windchill_Users to login.

Dont setup any group filters. so all the groups will come in Windchill.

If the above is done correctly, You can just allow access in the Product_ABC for Users from group Product_ABC_Users and that should do it all.

Theoritically it should work.

[TomU]

The issue isn't so much about preventing logins, instead it's more about controlling who's listed in Windchill teams.

Apache is going to limit logins to only users in the Windchill_Users group. Simple enough.

Inside Windchill I'm using other Active Directory groups to drive security (like Product_ABC_Users). There are many more users in this group than in the Windchill_Users group. This means all the users listed in the Product_ABC_Users group are being listed as members of Product_ABC when many of them don't even have login permissions to Windchill. I would like to filter the Product_ABC users to only the subset that are also a part of Windchill_Users.

The JNDI user filter does not appear to have any impact on members of existing groups.

Make sense?

[Arpit-Singh]

I think yes in this configuration above, the users who are not in the Windchill_Users will have login permission, but they would not be able to login as the Login is only for the users in the Windchill_Users group.

This cant be prevented, as per the Group structure you have.

[TomU]

The more I look into this, the more I think what I need are "dynamic groups". Extra groups created in WindchillDS that are derived from the membership of other Active Directory groups.

GroupA = (&(memberOf=GroupB)(memberOf=GroupC)

Probably the simplest approach is to write some custom script that will query Active Directory and then put the result into WindchillDS.

[Arpit-Singh]

Yes you are correct about it. And Custom script is a good way to start, it will save most of your manual efforts.

Wish you a Merry Christmas !!

[TomU]

Just want to clarify something for anyone who's following this topic. The user filter DOES limit logins to the group (or groups) listed in the user filter. If other Active Directory groups are used for assigning permissions, just because additional people may be listed, if they are not part of the user filter they won't be able to login. This does not require any special filtering in Apache.

-------------------------------------------------------------------

Cross-posting the following from PTC User

-------------------------------------------------------------------

1. Product/Library Permissions

When Windchill is configured to use Active Directory groups, if a group is added to a Product or Library role Windchill will automatically step through each group and subgroup when checking permissions. The test:

Active Directory Configuration:

Group1

__ User1

__ Group2

____ User2

____ Group3

______ User3

______ Group4

________ User4

Golf_Cart Product Team

__ Members

____ Group1

I then logged on to Windchill and had full access to the Golf_Cart product as “User4” even though only “Group1” was listed as part of the team. Picking on the information link for Group1 would display the membership for Group1 as Group2 and User1. Following the link for Group2 would show the membership of Group2 as Group3 and User2. It was possible to continue to drill all the way down.

Conclusion: Windchill DOES step through nested groups and all members of the nested groups are given the same permissions as members in the root of the group.

2. User Account Access (the main issue originally being discussed)

It IS possible to get Windchill to return all users from Active Directory nested groups by adding a user filter with a bitwise matching rule.

(http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx)

For example, this filter will allow Participant Administration to find all users inside of “Group1” and all nested sub-groups, regardless of how deep:

<adapter name>.windchill.mapping.user.filter= memberOf:1.2.840.113556.1.4.1941:=CN=Group1,CN=Users,DC=<domain>,DC=COM

I tested this 4 levels deep and it successfully returned all four users.

Group1

__ User1

__ Group2

____ User2

____ Group3

______ User3

______ Group4

________ User4

Disclaimers, Caveats, and Other Stuff.

• Do your own testing on a development system before you implement any of this in a production environment.
• All testing was done using Windchill PDMLink 10.2 M020.
• I did verify that the group permissions behavior for teams works correctly without the user filter in section two enabled. From the testing I’ve done, nested groups for permissions works fine out of the box.
• If Active Directory groups are used directly in Windchill, ALL members of that group (and effectively all subgroups) will be listed as part of the team membership, even if they should have been excluded by the user filter. This does not mean they can actually log in, but just that they are listed and visible in the team membership.
• To state this a different way, if a user cannot be seen as a user in Participant Administration, they will not be able to log in, regardless of whether or not they may be present in some other group. (This is good!)