AD and Windchill DS

[davehaigh]

In the business admin guide, it says the following:

"In the out-of-the-box configuration, there are two LDAP directory services: the Administrative LDAP service and the Enterprise LDAP service. End users can reside in either service; although typically, the Administrative LDAP service should be used for administrative users and enterprise LDAP service should be used for all end users who are not administrators."

Do you have your system setup like this? Any lessons I ought to know?

David Haigh
Phone: 925-424-3931
Fax: 925-423-7496
Lawrence Livermore National Lab
7000 East Ave, L-362
Livermore, CA 94550

[MikeLockwood]

We have about 1800 user accounts (only about 800 are currently active). Curiously, about 90 of them are in the Administrative branch.

We've put in multiple tech support calls over time asking a) how did this happen b) how can we move them to the Enterprise branch. Answers: We don't know how they got there; you're stuck with it for life.

The only symptom we currently see is that when selecting users for membership in team templates, one has to select ALL instead of the default Enterprise branch. But, we fear that at some point there will be more bad things that result.

We still don't know how these users got this way, or how to prevent it in the future.

[MichaelStertz]

Our normal users are set up to be in the enterprise LDAP branch as we have the webserver configured to authenticate those users via Active Directory. Non-standard and administrative users are in the administrative branch which means that they are authenticated against the Windchill LDAP.

[atwood]

In Reply to Mike Lockwood:

We have about 1800 user accounts (only about 800 are currently active). Curiously, about 90 of them are in the Administrative branch.

We've put in multiple tech support calls over time asking a) how did this happen b) how can we move them to the Enterprise branch. Answers: We don't know how they got there; you're stuck with it for life.

The only symptom we currently see is that when selecting users for membership in team templates, one has to select ALL instead of the default Enterprise branch. But, we fear that at some point there will be more bad things that result.

We still don't know how these users got this way, or how to prevent it in the future.

IIRC, the create user function in Principal Administrator couldfill in some values for you depending which user you have already looked at. So if you were looking/modifying a user on the Admin branch, and then created a new user immediately afterwards without paying attention, that user would end up in the Admin branch. Its also possible a bulk load of users did not specify the branch.

It is possible to relocate the users, but you have to do it manually: move them in the ldap itself, then adjust the remoteobjectinfo reference in Oracle to have the correct path. You could alsouse the Disconnected Principal tool for step 2, butif you're relocating several dozen usersits easier to script the changes instead.

Tim Atwood

PTC Enterprise Deployment Center

[LiuLiang]

We have JNDI adapter created and configured for Active Directory Authentication. Users have also been removed in Windchill DS control panel, however manually associate all disconnected principals to their AD entries in Principal Administrator Maintanence GUI one by one is very time consuming for over 1000+ existing users. Anyone knows of any automatic tools or scripts thatcan perform retargetingexisting users to their AD in batch?Is RemoteObjectInfo column in RemoteObjectInfo table in Windchill database the only place needs to be updated so that the pointer referecences AD one and not DS one?

[patrick.chin1]

Read up on multiple forest,

If you want external users to sign in, I recommend multiple forest. This is much easier to manage users with the same name. Thus, your unique userid is mapped to AD principle name instead of SAMAccountname. You'll have to sign on with your SAMAccountName@domain.com which should be your email address. In most cases, a single forest has unique SAMAccountName. But with multiple forest, you will have conflicts.

In the AD, try to have the AD administrator populate all the properties of the user, title, phone, etc. which can be mapped back into Windchill which then can populate the content via customizations.

In the Windchill DS, we have test users specifically for Windchill which the Windchill Admins have control of their passwords and access. It is a good idea to create a test user for each group/role so you can log into Windchill as that test user to ensure proper functionality with access.

Good luck,

Patrick

[patrick.chin1]

We also manually migrated Windchill users who originally existed in Windchill DS users to AD by:

• deleting then in the Windchill DS which resulted in them being disconnected


• then repaired them by pointing to a Active Directory user.

If you delete any disconnected principles who owned workspaces, their workspaces are no longer accessible.