Often, companies use their existing corporate directories, like Microsoft Active Directory (AD), to serve as the authentication source for Windchill user accounts. By using pre-existing user accounts from a source outside Windchill, maintaining separate user accounts, password policy, etc in Windchill can be avoided. See PTC Tech Support article CS29445 for more information about configuring AD with Windchill for authentication and directory information.
Windchill authentication is processed by Apache. The Apache authentication configuration can be set so that through the ldap protocol, directory sources can be used to authenticate against. It's possible to authenticate against a list of multiple external sources.
Due to company mergers, we use WindchillDS along with three separate AD domains as Windchill authentication sources. A problem arises when a user exists with the same username in two different directories. Typically, sAMAccountName is mapped from AD to the Windchill user name, but other AD properties such as userPrincipalName can also be used. UserPrincipalName requires users to add the domain to their username when logging in, e.g. user@example.com, where user is the sAMAccountName and example.com is the domain. This guarantees uniqueness across domains. However, it could be possible to avoid requiring users to include the domain with their username by reorganizing the order in which the authentication sources are queried.
The order in which the sources are queried is specified in the app-Windchill-Auth.conf file which is compiled from the <Apache>\conf\extra\app-Windchill-AuthProvider.xml template file. Normally, an administrator edits the xml file and then compiles it using an ant command. The conf file is not normally edited directly. The order of the sources listed in the xml file can be rearranged during propagation due to the alphanumeric sorting scheme used. To precisely control the order, a number can be added before the name in the xml file.
Example app-Windchill-AuthProvider.xml file:
<provider>
<name>01-Windchill-AdministrativeLdap</name
<ldapUrl>ldap://<fully.qualified.hostname>:1389/ou=people,cn=AdministrativeLdap,cn=Windchill_10.2,o=ptc</ldapUrl>
<bindDn>cn=Manager</bindDn>
<bindPwd><Manager's Password></bindPwd>
</provider>
<provider>
<name>02-Windchill-com.mycompany.domain.name</name>
<ldapUrl>ldap://adserver.mycompany.com:389/OU=Users,DC=mycompany,DC=com?sAMAccountName?sub?(&(objectClass=*)
(! (UserAccountControl:1.2.840.113556.1.4.803:=2)))</ldapUrl>
<bindDn>LookupUser@name.domain.mycompany.com</bindDn>
<bindPwd><pass></bindPwd>
</provider>
<provider>
<name>03-Windchill-EnterpriseLdap</name
<ldapUrl>ldap://<fully.qualified.hostname>:3268/ou=people,cn=EnterpriseLdap,cn=Windchill_10.2,o=ptc</ldapUrl>
<bindDn>cn=Manager</bindDn>
<bindPwd><Manager's password></bindPwd>
</provider>
When it is propagated, the providers are sorted according to the numbers and therefore not changed. This was the key to minimizing the problems I had integrating multiple AD domains. See CS121536 for more info. If a user with the same username exists in two ldap provider directories listed in the conf file, the password tied to the provider that comes first in the list must be used. The credentials required come from the first occurrence of a username match.
By manipulating this order, I was able to place the WindchillDS source first, followed by the primary AD domain and then other AD domains avoiding most username collision problems. Over time we have reduced the number of AD domains used in the company and now have a process to avoid username duplication, but the flexibility provided in the authentication configuration allowed me to work with multiple AD domains without significantly changing existing user accounts.
