Here are two solutions to this issue.
A. Add a property to Active Directory that matches the Windchill Organization. Then point to it thru the JNDI Adapter.
{JNDI Adapter}.windchill.mapping.user.usersOrganizationName={Active Directory property name}
For example:
com.ptc.ActiveDirectory.windchill.mapping.user.usersOrganizationName=windchillOrganization
This results in a single adapter, but each Windchill user must have their Windchill Organization defined in Active Directory (AD), without typos or specifying the wrong Org name, before they start using Windchill.
Also, AD Administrators may not be willing to add another property to all defined user accounts for a handful of Windchill users.
B. Hard code the Windchill Organization in the JNDI Adapter.
{JNDI Adapter}.windchill.mapping.user.usersOrganizationName={static Windchill Organization Name}
For example:
com.ptc.ActiveDirectory.windchill.mapping.user.usersOrganizationName=MyDefaultOrg
Anyone visible thru this JNDI Adapter will belong to the Windchill Organization named "MyDefaultOrg".
That means each Windchill Organization hosting participants will require a separately defined JNDI Adapter with a unique usersOrganizationName value.
The JNDI Adapters may be identical except they would use separate user filter groups to define owning Windchill Organization.
{JNDI Adapter #}.windchill.mapping.user.filter=(& (objectClass=*)(! ({Disabled User Account}))(memberOf={Filter Group DN}))
For example:
com.ptc.ActiveDirectory1.windchill.mapping.user.filter=(& (objectClass=*)(! (userAccountControl:1.2.840.113556.1.4.803:=2))(memberOf=CN=Org1_WindchillFilterGroup,OU=groups,DC=company,DC=com))
Notes:
- Windchill user unique identifiers (e.g. sAMAccountName or userPrincipalName) must be unique across all defined JNDI Adapters. So, be careful to ensure no single user defined with the same unique identifier belongs to more than one filter group in AD. If this is the case, the user won't be visible/usable in Windchill and some participant functions (e.g. Participant Search) may throw errors.
- To use filter groups, the filter groups must exist with users assigned to them AND the user entries must have the memberOf attribute defined showing the DN of the filter group they belong to. This is because Windchill is searching the LDAP for users with the memberOf property. It is not searching for the group and then looking for the associated members. So, the filter doesn't work when AD doesn't have the membersOf property defined, or at least not defined consistently, on user accounts. Technically, the filter can use any attribute defined on the user object (e.g. user object class, enabled status, location, department, etc.), but we always use group membership because it is the most flexible.
- Wrong owning Organization can be corrected in Active Directory, but Windchill won't recognize the change. A System Administrator can force an update to correct the owning Organization and associated domains (CS35455).
java wt.inf.container.OrganizationSync --users {space separated list of usernames}
Filter groups as described above require an AD Administrator, or someone with write permissions to AD, to maintain the filter group(s). It was explained to me that some clever AD/Windchill Administrators have setup [email] distribution groups, used the distribution group membership as the filter, and granted Windchill System/Business Administrators edit permissions to the distribution groups. This puts user management fully in the control of Windchill Administrators and off the plate of AD Administrators. I haven't done this one yet, but would love to hear the implementation details from someone with first-hand experience.
