If an organization LDAP entry is not removed from the directory service, a new organization participant is created in Windchill database when the organization is selected from a search. This new organization object is not the same object that was deleted and all of the results of the earlier deletion still hold.

Windchill Participant Status

Windchill participants can have one of several status values. The possible status values for participants include the following:

Pending Users

A user who is known only through email is stored in Windchill as a pending user. Commonly, these users are added to a context team via email and there is no Windchill user with a matching email address. A pending user does not have an associated LDAP entry. Pending users appear in Windchill with a status of Pending and with only the available email address for the user name.

Pending users cannot log on to Windchill until they are activated.

Replicated Users

A replicated user is a user who was added to Windchill through the import of a Windchill replication package delivery. Basic attributes for the user are available, depending on what was sent from the source Windchill installation. Often these

attributes include the user name, full name, email address, and last name. Replicated users do not have an associated LDAP entry. A replicated user appears in Windchill with a status of Replicated .

When a replication package delivery is imported, Windchill attempts to match all imported users with current Windchill users. By default, user matching is attempted with the user’s distinguished name. If no match is found, matching is next attempted by user name. If there is still no match to a current Windchill user, a replicated user is created. You can configure your system to match users by attributes other than user name. For more information, see the Identifying Users in Context Replication and Activating Replicated Users section of the PTC Windchill Customization Guide.

A replicated user can be added to a context team via email. However, replicated users cannot log on to Windchill until they are activated.

Activating Pending and Replicated Users

Pending and replicated users are activated if a user is created in Windchill or loaded into Windchill with some of the same identifying attributes.

Activation occurs any time a new user is added to Windchill by one of the following means:

•Manually creating the user with the Participant Administration utility.

•A user with an entry in the corporate LDAP system logs on to Windchill for the first time or is discovered by Windchill during a particular action.

•User data is loaded into Windchill using a load file.

Pending users are activated if a user is created or loaded with the same email address.

Replicated users are activated if a user is created or loaded with the same user name or alternate user name as the replicated user. You can configure your system so that replicated users are activated if a user is created or loaded with the same email address as the replicated user rather than matching via user name.

When a pending or replicated user is activated, all places where the pending or replicated user was referenced are updated to reference the active Windchill user instead. For example, a part can be imported into Windchill with a reference to a replicated user as the creator of the part. If the replicated user is activated later, the reference to the user as the creator of the part is updated to the newly activated user.

Note

If the new user created via the Participant Administration utility, an LDAP user log on, or a load file has an alternate user name that matches a pending or replicated user, the pending or replicated user is activated and any attributes associated with the new user overwrite the attributes established for the pending or replicated user.

Participant (Users, Groups, and

Organizations) Identification

Participants are identified across Windchill systems through the use of the participant Unique Federation Identifiers (UFIDs). The syntax for UFIDs is as follows:

<distinguished_name>:<guid>@<domain>

where:

<distinguished_name> is the distinguished name of the participant (which is made up of directory attributes that include the user name and directory location).

<guid> is the globally unique identifier of the repository in which the participant was first created or discovered.

<domain> is the internet-style domain name of the repository in which the participant currently resides.

Together, <guid>@<domain> identifies the directory service in which the participant resides.

Best Practices for Assigning Domains to Participants

A domain is an administrative area that defines a set of administrative policies, such as access control, indexing, and notification. Objects associated with a domain are subject to its policies. When participant objects are created, they are associated with default domains as follows:

•Users who are affiliated with an organization (the organization attribute on their directory service entries is set) are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the site context User

domain. If the organization is associated with an organization context, then the domain is in the organization context; otherwise, the domain is in the site context.

•Users who are not affiliated with an organization (the organization attribute on their directory service entries is not set) are associated with the site context Unaffiliated domain. This domain is a child of the User domain. One exception to this rule is the Administrator user, which is associated with site context System domain.

•User personal cabinets are associated with the same domain as the user. The one exception to this rule is that the personal cabinet for the Administrator user is associated with the User domain in the site context.

•User-defined groups created in the site context are associated with the site context Unaffiliated domain. This domain is a child of the User domain.

•User-defined groups created in an organization context are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the site context User domain. The domain is in the organization context.

•Organizations are associated with the domain that was created for the organization when the organization object was created. This domain usually has the same name as the organization (or a shortened version of the organization name) and the domain is a child of the site context User domain. If the organization is associated with an organization context, then the domain is in the organization context; otherwise, the domain is in the site context.

Note

The default domain associations described in the previous list only apply if you have not set up JNDI adapters that configure participant domain assignments. The domain assignments in a JNDI adapter take precedence over the system defaults.

User objects and personal cabinets are created automatically when users are selected in a search or when users log in. These user objects and personal cabinets are always associated with the default domains described earlier. When you create a user through the Participant Administration utility, you can select the domains. But in most cases, you should use the defaults (which are used when you do not select a domain).

When creating group objects through the Participant Administration utility, using the default domain is usually a good choice. However, you may want to choose a different domain if you want policy rules from a domain other than the default to apply to the group object.