Configure directory services

• Workspace Control will use your environment's name resolution mechanism to resolve the selected Fully Qualified Domain Names to the correct paths.
• When configuring a Security Context:
  • the account must be in the same domain as the directory service you are configuring.
  • the account requires sufficient rights to query the domain in Active Directory or in Microsoft Windows Domain.

These credentials will only be used when viewing data in the Management Console.

• If your environment does not include trusted domains, not allowing query from external domains will make sessions start up faster.
• With a Mount Point, objects in the tree above the mount point cannot be used in the Management Console unless another directory service starts in the same tree at a higher point.
• Group Nesting determines whether Access Control based on a parent group also applies to members of a subgroup. For example, suppose that Access Control for an application depends on membership of the group "AppUsers", and that this group contains the subgroup "AppAdmins".
  • Without support for group nesting, users must be member of the group "AppUsers" to get the application. Users who are only member of the subgroup "AppAdmins" do not get the application.
  • With support for group nesting, users who are only member of the group "AppAdmins" also get the application.
• You can select the method of resolving users and groups:

Account names is preferable if user and group names do not change often. Renamed users and groups lose their current access because Workspace Control cannot find a match for their name. This method is recommended if Building Blocks are used to transfer objects from test to production environments, since names then are the same, but SIDs are not.

Account SIDs is preferable if user and group names change frequently. If a user or group is renamed, the account name changes but its SID does not. With Access Control based on SID, renamed users and groups keep their existing access and the Console reflects their new names.

When importing a Building Block, this can be done based on either Account names or Account SIDs. Based on this option the import process will automatically either resolve SIDs based on configured account names or resolve account names based on configured SIDs. The default setting is Account names. Unattended Building Block import will always use Account names.

• Select the method for Get group membership using (for Microsoft Active Directory and Windows Domain):
  • Domain controller - Select this method to have the Workspace Composer query the domain controller to get group membership for the current user. With this method, in a user session, changes in group membership are detected during a workspace refresh. To get the group membership faster, choose the method Local tokens (faster).
  • Local tokens (faster) - Select this method to have the Workspace Composer resolve the user's group membership from its logon token. This option is especially interesting for multi-domain environments, in which resolving cross domain group membership does not work properly or causes performance degradation. With this method, in a user session, a user needs to log off and logon again to detect changes in group membership. To detect changes during a workspace refresh, choose the method Domain controller.
    This option should only be used in environments that have a Global Catalog server.
  • Local tokens, until administrative refresh - Select this method to combine the benefits of both methods Local tokens (faster) and Domain controller to get group membership for the current user. Local tokens are used until the first administrative refresh. From then on, until the session is logged off, the domain controller is queried to get the group membership for the current user. In multi-domain environments, all domains must be configured with this method.
    For more details about administrative refreshes, see Administrative Workspace Refresh.

It is advised to select the same method for all defined directory services in the Workspace Control Console.

• In some situations, the order in which Directory Services are processed may be important. When a user starts a session, Workspace Control starts at the top of the list of Directory Services configured in the Console. The first configured Directory Service that matches the user's logon domain becomes the primary directory service for the session.
  The following order is usually advisable:
  • all Active Directory Services
  • all Microsoft Windows Domain Directory Services
  • the Local Computer Directory Service

In complex environments, you may need to experiment with this order.