C H A P T E R 3 |
This chapter describes how you use organizational hierarchies to manage SGD users and give them access to applications.
SGD is built on the principles of directory services. Users, applications, and application servers are represented by objects in a directory. The objects are arranged into an organizational hierarchy representing your organization.
An organizational hierarchy starts with a top-level directory object, usually an organization object. Other directory objects, such as an organizational unit (OU), are containers that can be used to divide the organizational hierarchy. You can create group objects. Group objects are not containers. Groups have members that are objects located in other parts of the organizational hierarchy.
SGD also includes a number of different object types for representing users, applications, and application servers.
Each object has a number of configuration settings, known as attributes. For example, an application object has an Icon attribute that is the name of an icon to display to users.
SGD objects, and the attributes used for each object, are based on the commonly‐used LDAP version 3 schema. These objects have been extended, using the standard method of doing so, to support SGD functionality. For more information on the LDAP schema, see RFC 2256.
SGD uses a local repository to store all the objects in your organizational hierarchy. Each object is distinguished from other objects in the same container by using an attribute name as a prefix, for example ou=Sales. This attribute is known as the naming attribute or the relative distinguished name (RDN). Two objects in the same container cannot have the same RDN. The complete name of the object that includes all the RDNs from the top of the hierarchy is the distinguished name (DN), for example o=Indigo Insurance/ou=Sales. The DN is the name that uniquely identifies an object. The following table shows some example objects, their RDN, and their DN.
Object Type | Relative Distinguished Name | Distinguished Name |
---|---|---|
Organization | o=Indigo Insurance | o=Indigo Insurance |
OU | ou=Sales | o=Indigo Insurance/ou=Sales |
User profile | cn=Violet Carson | o=Indigo Insurance/ou=Sales/cn=Violet Carson |
User profile | cn=Elizabeth Blue | o=Indigo Insurance/ou=Sales/cn=Elizabeth Blue |
The relationships between objects are significant. For example, to deploy an application to users, you associate user profile objects with an application object. SGD calls these relationships assignments. Assignments are described in more detail in Publishing Applications.
For more information about hierarchies and objects, see the following sections:
SGD uses four organizational hierarchies: one each for users, applications, and application servers, and a System Objects hierarchy that contains objects for use by SGD. In the Administration Console, you use the following tabs to manage these organizational hierarchies:
The following sections describe these tabs, the objects that they can contain, and how they are used. The System Objects organization is also described.
On the command line, you manage your organizational hierarchies with the tarantella object command. You can also use this command to populate an organizational hierarchy using a batch script. See Populating the SGD Organizational Hierarchy Using a Batch Script.
In the Administration Console, the User Profiles tab is where you create and configure objects for managing SGD users. You use the objects on this tab to control users’ SGD-related settings, and the applications that they can access through SGD.
By default, this tab contains two objects, an organization object called o=organization and a domain component object called dc=com. These are the top‐level objects in the organizational hierarchy. You can rename or delete these objects, or create new top-level objects. You create all the objects you need for managing users within these top-level objects.
The following are the SGD object types that are available on the User Profiles tab:
In the Administration Console, the Applications tab is where you create and configure objects that represent the applications and documents that users can access through SGD. These objects are always created within the applications organization. On the command line, this organization is called o=applications.
The following are the SGD object types that are available on the Applications tab:
In the Administration Console, the Application Servers tab is where you create and configure objects for managing the application servers that run the applications displayed through SGD. These objects are always created in the application servers organization. On the command line, this organization is called o=appservers.
The following are the SGD object types that are available on the Application Servers tab:
The System Objects organization contains objects that are essential for the running and maintenance of SGD. On the command line, the System Objects organization is displayed as o=Tarantella System Objects.
The System Objects organization contains the Global Administrators role object. This object determines who is an SGD Administrator, and who can use the SGD graphical administration tools. See SGD Administrators.
The System Objects organization also contains profile objects. These are default user profile objects for use with the various authentication mechanisms supported by SGD. For example, the profile object System Objects/LDAP Profile is the default user profile if you are using LDAP or Active Directory authentication.
You can edit objects in the System Objects organization, but you cannot create, move, rename, or delete objects.
This section describes the available SGD object types and how they are used.
The following are the object types that are used to organize users, applications, and application servers:
The following are the object types used to represent users, applications, and application servers.
Directory objects that are organization objects are used for the things that apply to your organization as a whole. Organization objects are always at the top of the organizational hierarchy and can contain OU, Active Directory container, or user profile objects.
On the command line, you create an organization object with the tarantella object new_org command.
Directory (light) objects that are domain component objects are used to replicate a directory structure, usually a Microsoft Active Directory structure, within the SGD organizational hierarchy. Domain component objects are similar to organization objects, but do not include additional SGD-specific attributes or allow you to assign applications. This is why they are called directory (light) objects.
Domain component objects can only appear at the top of the organizational hierarchy, or within another domain component object. Domain component objects can contain OU, domain component, Active Directory container, or user profile objects.
On the command line, you create a domain component object with the tarantella object new_dc command.
Directory objects that are OU objects are used to divide your users, applications, and application servers into different departments, sites, or teams.
An OU can be contained in an organization or a domain component object.
On the command line, you create a directory object with the tarantella object new_orgunit command.
Active Directory container objects are used to replicate your Microsoft Active Directory structure within the SGD organizational hierarchy.
Active Directory container objects are similar to OUs, but do not include additional SGD-specific attributes or allow you to assign applications. This is why they are called directory (light) objects.
An Active Directory container object can be contained in an organization, an OU, or a domain component object.
On the command line, you create an Active Directory container object with the tarantella object new_container command.
Active Directory container objects have a cn= naming attribute.
User profile objects are used to represent a user in your organization, and give that user access to applications. They also define the SGD settings associated with a user.
How SGD associates a user profile object with a user depends on the authentication mechanisms in use. For some authentication mechanisms, you might not have to create user profile objects at all. See Secure Global Desktop Authentication for details.
On the command line, you create a user profile object with the tarantella object new_person command.
User profile objects can have a cn= (common name), a uid= (user identification), or a mail= (mail address) naming attribute.
Group objects are used to associate groups of applications with an object on the User Profiles tab or groups of application servers with an object on the Applications tab.
Group objects are not the same as directory objects. Applications or application servers can only belong to one directory, but can be a member of many different groups.
Members of a group can be applications, application servers, or other groups. Groups can moved or renamed without affecting group membership.
Groups of application server objects can be used to associate similar application servers for load balancing. See Load Balancing for details.
On the command line, you create a group object with the tarantella object new_group command.
Windows application objects are used to give Microsoft Windows graphical applications to users. See Windows Applications for more details.
On the command line, you create a Windows application object with the tarantella object new_windowsapp command.
X application objects are used to give X11 graphical applications to users. See X Applications for more details.
On the command line, you create an X application object with the tarantella object new_xapp command.
Character application objects are used to give VT420, Wyse 60, or SCO Console character applications to users. See Character Applications for more details.
On the command line, you create a character application object with the tarantella object new_charapp command.
Document objects are used to give documents to users. A document object can refer to any Uniform Resource Locator (URL).
On the command line, you create a document object with the tarantella object new_doc command.
3270 application objects are used to give 3270 (mainframe) applications to users.
On the command line, you create a 3270 application object with the tarantella object new_3270app command.
5250 application objects are used to give 5250 (AS/400) applications to users.
On the command line, you create a 5250 application object with the tarantella object new_5250app command.
Application server objects are used to represent an application server that is used to run applications through SGD.
Application servers are used with load balancing. If you assign two or more application server objects to an application object, SGD chooses which application server to use, based on the load across the application servers. See Load Balancing for details.
On the command line, you create an application server object with the tarantella object new_host command. Application server objects have a cn= naming attribute.
You have complete control over the objects that you create to model your organizational hierarchy. However it is important to design and test your organizational hierarchy before implementing it. The following factors affect your design:
Authentication mechanism. The most important influence on the design of organizational hierarchy is the Secure Global Desktop authentication mechanisms you use. For example, if you use UNIX system authentication, you can structure the hierarchy however you like. However, with LDAP authentication, you might need to mirror part of your LDAP directory structure. See Secure Global Desktop Authentication for details.
Organization chart. Sometimes it is a good approach to use OUs to represent the departments or offices in your organization. However, if your organization is restructured, you might have to reorganize your hierarchy.
Inheritance. The settings for user profile objects and OU objects can be inherited from the object’s parent in the organizational hierarchy. For example if everyone in a department needs an application, assign the application to the OU that represents the department. Every user belonging to that OU gets the applications assigned to the OU. Inheritance works best if you are not using LDAP assignments.
User profile objects. User profile objects can be configured to give users access to particular applications and customized settings. Depending on the authentication mechanisms you enable, a default user profile is often used and this might be sufficient for your needs. This is particularly true if you use LDAP assignments to assign applications to users.
Naming convention. Use a naming convention for each application or document object type. The name of the application or document object is displayed to users. For user profile objects, it is best to use the person’s full name, for example “Indigo Jones”.
When you create an object in the Administration Console, you can use any characters you want for the name of the object, apart from backslash (\) or plus (+).
On the command line, if you use a forward slash in an object name, you must backslash protect, or escape, it. This is because SGD interprets the forward slash as a part of the organizational hierarchy. For example, if you try to create an object with the relative name cn=a/b beneath o=organization, SGD tries to create an object called b within o=organization/cn=a. This fails because o=organization/cn=a does not exist. To create an object with this name, type cn=a\/b.
On the command line, if the name of an object includes spaces, make sure you enclose the name in quotes, for example ".../_ens/o=Indigo Insurance".
How you name an object on the command line varies, depending on which part of the SGD datastore the object is from.
For example, an object in the local repository might have this name:
.../_ens/o=Indigo Insurance/ou=Marketing/cn=Cust-o-Dat
For objects in the local repository, the .../_ens part of the name is optional. You can also type the following:
o=Indigo Insurance/ou=Marketing/cn=Cust-o-Dat
An object stored on an LDAP directory server might have this name:
.../_service/sco/tta/ldapcache/cn=Cust-o-Dat,ou=Marketing,o=Indigo Insurance
A server on the network might have this name:
.../_dns/verona.indigo-insurance.com
With the tarantella object command, any name in the local repository is treated as case insensitive. When you create or rename an object, the case used is preserved. However, other commands, such as the tarantella webtopsession and tarantella emulatorsession commands, are case sensitive.
If you want to populate your organizational hierarchy with a large number of objects, using the Administration Console to do this is not very efficient. The solution is to use the batch scripting functionality of the tarantella object command.
Once you have designed the structure of your SGD organizational hierarchy, you create a file for each type of object you want. Each file contains one line per object, with the correct syntax for creating the object from the appropriate tarantella object command. For example, to create five OUs you might have a file called orgunits.txt containing the following:
--name "o=Indigo Insurance/ou=IT" \ --name "o=Indigo Insurance/ou=Sales" \ --name "o=Indigo Insurance/ou=Marketing" \ --name "o=Indigo Insurance/ou=Finance" \ --name "o=Indigo Insurance/ou=Finance/ou=Administration" |
Do not include the actual tarantella object command name, for example object new_orgunit, as part of each line.
Application objects, including their groups and OUs, must be created in the o=applications organization.
Application server objects, including their groups and OUs, must be created in the o=appservers organization.
Every application server must have an application server object.
Once all your files are complete, use the tarantella object script command to process them all at once, for example:
#!/bin/sh tarantella object script << EOF new_orgunit --file orgunits.txt new_group --file groups.txt new_host --file hosts.txt new_person --file people.txt new_xapp --file xapps.txt new_windowsapp --file windowsapps.txt new_charapp --file charapps.txt EOF |
The tarantella object script command runs each command in order. Each command reads and processes the specified file.
You can use any tarantella object subcommand with the tarantella object script command. You do not have to read in object details from other files.
Many other commands, for example the tarantella passcache command, accept --file arguments so you can perform multiple related actions at once.
When a user is authenticated with either LDAP authentication, Active Directory authentication, or third-party authentication using the LDAP search, SGD establishes the user profile for a user by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:
A user profile with the same name as the LDAP person object.
For example, if the LDAP person object is cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com, SGD searches the local repository for dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP person object but with the name cn=LDAP Profile.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
If there is no match, the profile object System Objects/LDAP Profile is used for the user profile.
Typically LDAP and Active Directory users use the default LDAP profile, and applications and documents are assigned to them using LDAP assignments. See LDAP Assignments. However, user profile objects can also be used to control a user’s SGD-specific settings, such as the ability to use copy and paste or to edit client profiles. If you want to customize an LDAP or Active Directory user’s SGD settings, you might have to mirror some of your LDAP organization in the local repository.
When you mirror your LDAP organization, remember the following:
Do not mirror your entire LDAP organization in the local repository. Only create as much of the structure as you need.
Inherit as much as possible from other objects in the organizational hierarchy.
Do not create user profile objects for all users. Only create user profile objects for users that must have individual settings. Creating cn=LDAP Profile objects is sufficient in most cases.
When you configure LDAP authentication, or third-party authentication using the LDAP search, you specify one or more LDAP URLs. LDAP URLs can contain a search root. If you specify a search root on your LDAP URLs, that search root is used as the starting point for the objects you need to mirror in the local repository.
When working with LDAP mirroring in the Administration Console, it is useful to display the naming attribute for the objects you work with. By default the Administration Console does not display naming attributes. You enable the display of naming attributes in the Preferences for the Administration Console.
When working with user profiles in the Administration Console, select Local + LDAP from the Repository list on the User Profiles tab. LDAP objects that are mirrored in the local repository are indicated by the following icon:
The following is an example of how to mirror your LDAP organization to give users different SGD settings.
Indigo Insurance has five departments: IT, Sales, Marketing, Finance, and Administration. The Finance and Marketing departments need different SGD settings to the other departments. Sid Cerise in the Finance department needs different SGD settings to the other users in the Finance department.
The objects you create depend on the type of LDAP directory server used, as described in the following sections.
For Sun Java System Directory Server, the following are the LDAP names of the objects you need to mirror in the local repository and the object types use:
Note - In the Administration Console, create Directory objects. The naming attribute is set automatically. |
FIGURE 3-1 shows the mirrored objects in the Administration Console.
With this structure in place, create the following user profile objects in the local repository:
Note - In the Administration Console, remember to select uid as the naming attribute for the user profile object o=indigo-insurance.com/ou=Finance/uid=Sid Cerise. |
With this organizational hierarchy, users receive settings as follows:
Sid Cerise receives the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:
Users in the Finance department receive the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:
Users in the Marketing department receive the settings defined for the following user profile object, including any settings inherited from parent objects in the organizational hierarchy:
All other users receive the settings defined for the default LDAP user profile, System Objects/cn=LDAP Profile
For Microsoft Active Directory, the following are the LDAP names of the objects you need to mirror in the local repository and the object types to use:
Note - In the Administration Console, you create domain components and Active Directory containers by creating Directory (Light) objects, and then selecting the correct naming attribute. |
FIGURE 3-2 shows the mirrored objects in the Administration Console.
With this structure in place, create the following user profile objects in the local repository:
With this organizational hierarchy, users receive settings as follows:
Sid Cerise receives the settings defined for the following user profile object:
Users in the Finance department receive the settings defined for the following user profile object:
Users in the Marketing department receive the settings defined for the following user profile object:
All other users receive the settings defined for the default LDAP user profile, System Objects/cn=LDAP Profile
Note - It is not possible to inherit SGD settings from domain component and Active Directory container objects. |
In SGD, administration privileges are managed using the Global Administrators role object in the System Objects organization.
The Global Administrators role object has a list of members, and a list of assigned applications. All SGD Administrators are defined as members of the Global Administrators role object. The list of assigned applications is used to assign administration tools to SGD Administrators. SGD Administrators are assigned these applications in addition to any other applications assigned to them.
Only SGD Administrators can configure SGD using the SGD graphical administration tools, Administration Console and Profile Editor. To use the SGD command-line tools, the following conditions apply:
Commands that control the SGD server and SGD Web Server can be run only by superuser (root).
Commands for creating and managing arrays of SGD servers can only be run by SGD Administrators.
All other commands can be run by any user in the ttaserv group.
Use the usermod -G command to make a user a member of the ttaserv group. The ttaserv group does not have to be the users primary or effective group.
You can use the SGD Administration Console or the tarantella role command to add or remove SGD Administrators.
If no user profile objects are defined as members of the Global Administrators role object, the UNIX or Linux system root user has administration privileges.
Note - If you want SGD Administrators to authenticate using an LDAP directory or Active Directory authentication, you must create user profiles for them. See LDAP Mirroring for details. |
Add a user profile object to the Members tab.
Locate the user profile object.
Use the Search field or the navigation tree to find the object you want.
Select the check box next to a user profile object.
To add several SGD Administrators, select more than one user profile object.
The Members tab is displayed, showing the selected user profile object.
Tip - You can also use the tarantella role add_member --role global --member pobj command. |
Remove a user profile object from the Members tab.
In the Editable Members table, select the check box next to a user profile object.
To remove several SGD Administrators, select more than one user profile object.
Tip - You can also use the tarantella role remove_member --role global --member pobj command. |
Creating objects to represent the applications, application servers, and users in your organization does not, by itself, give users to access applications through SGD. Applications must be published. You publish applications by creating relationships between the objects in the organizational hierarchy. SGD calls these relationships assignments. You publish applications as follows:
Assign applications to application servers. This configures the application servers that can run the application.
Assign applications to users. This configures the users that see the application on their webtop.
Assignments can be either of the following types:
Local assignments. These are relationships between objects that are in the SGD repository. See Local Assignments.
LDAP assignments. These are relationships between objects in the SGD repository and objects in an LDAP directory. See LDAP Assignments.
Assigning applications to application servers is done by using local assignments.
Assigning applications to users is done by using local assignments, LDAP assignments, or a combination of both.
The Administration Console provides several ways for reviewing assignments, see Reviewing Assignments.
Local assignments are relationships between objects in the local repository.
In the Administration Console, you assign applications on the Applications tab as follows:
Use the Hosting Application Servers tab to assign applications, or groups of applications, to application servers.
See How to Assign Application Servers to Applications.
Tip - You can also assign applications from the Hosted Applications tab for group and application server objects. |
Use the Assigned User Profiles tab to assign applications to users.
See How to Assign Applications to Users.
Tip - You can also assign applications from the Assigned Applications tab for directory and user profile objects. |
SGD uses inheritance to make local assignments easier to manage and more efficient. OU and user profile objects can inherit the assignments and settings of their parent objects in the organizational hierarchy. Inheritance is enabled by default. To use inheritance, create user profile objects within OU objects, and then assign applications to the OUs.
The Administration Console provides several ways for reviewing assignments, see Reviewing Assignments.
In the Administration Console, go to the Applications tab and select an application object or a group object.
If you select a group of applications, you can assign application servers to all the applications in the group.
Locate application server or group objects.
Use the Search field or the navigation tree to find the objects you want.
Select the check box next to the application server or group objects and click Add
If you select more than one application server, or a group of application servers, SGD load balances between application servers. See Load Balancing.
If you select a group of application servers, you select all the application servers in the group.
The Effective Application Servers table is updated with the selected application servers.
In the Administration Console, go to the Applications tab and select an application object or a group object.
If you select a group of applications, you can assign all the applications in the group to users.
Locate user profile or directory objects.
Use the Search field or the navigation tree to find the objects you want.
You can assign an application to user profile or directory objects.
If you assign an application to a directory object, all the user profiles contained in that directory object automatically receive the application. This is called inheritance. Assigning an application to directory objects is more efficient.
Select the check box next to the user profile or directory objects and click Add.
The Effective User Profiles table is updated with the selected users.
LDAP assignments make use of SGD’s Directory Services Integration feature. With Directory Services Integration, you use an LDAP directory instead of the local repository for holding user information. This means you do not need to create any user profile objects in the local repository.
You can only use Directory Services Integration for users who have their user identity established by searching an LDAP directory. This means users must be authenticated by one of the following authentication mechanisms:
Active Directory authentication, see Active Directory Authentication
LDAP authentication, see LDAP Authentication
Third-party or web server authentication using the LDAP repository search, see Third-Party and Web Server Authentication
LDAP assignments are relationships between objects in the SGD repository and objects in an LDAP directory. With LDAP assignments, instead of assigning applications to users, you assign users to applications. In the Administration Console, you do this on the Assigned User Profiles tab for application, document, and group objects. You can assign users as follows:
LDAP users. You select individual users in an LDAP directory.
See How to Assign Applications to LDAP Users for details.
LDAP groups. You select groups in an LDAP directory and SGD assigns the users in the group to the application.
See How to Assign Applications to Members of LDAP Groups for details.
You might have to perform additional configuration to use LDAP group searches successfully. See Tuning LDAP Group Searches for details.
LDAP searches. You configure an LDAP search filter or URL and SGD assigns the matching users to the application.
See How to Assign Applications Using LDAP Searches for details.
When working with LDAP assignments in the Administration Console, it is useful to display the naming attribute for the objects you work with. By default the Administration Console does not display naming attributes. You enable the display of naming attributes in the Preferences for the Administration Console.
If you want more control over the SGD-specific settings for LDAP users, such as the ability to use copy and paste, or to edit client profiles, see LDAP Mirroring.
The Administration Console shows you which users are configured to receive an application using LDAP assignments, see Reviewing Assignments.
See Troubleshooting LDAP Assignments for tips on working with LDAP assignments.
In the SGD Administration Console, go to the Applications tab.
Select an application or group object and go the Assigned User Profiles tab.
Use the Search field or the navigation tree to find the object you want.
If you select a group object, LDAP users receive all the applications in the group.
Locate the LDAP users you want to assign to the object.
Use the Search field or the navigation tree to find users in the LDAP directory.
Select the check box next to the LDAP users and click the Add button.
If you assign several LDAP users to an object, it is more efficient to use an LDAP search.
Tip - On the command line, you can use the --ldapusers option to assign LDAP users. |
The Add User Assignment window closes and the Editable Assignments table is updated with the LDAP users.
Select an application, document, or group object and go to the Assigned User Profiles tab.
Use the Search field or the navigation tree to find the object you want.
If you select a group object, all members of the LDAP group receive all the applications in the group.
Locate the LDAP groups you want to assign to the object.
Use the Search field or the navigation tree to find groups in the LDAP directory.
Select the check box next to the LDAP groups and click the Add button.
If you assign several groups to an object, it is more efficient to use LDAP searches instead.
Tip - On the command line, you can use the --ldapgroups option to assign the members of LDAP groups. |
The Add User Assignment window closes and the Editable Assignments table is updated with the LDAP groups.
Select an application, document, or group object and go to the Assigned User Profiles tab.
In the LDAP Searches section configure the LDAP search.
Select the Simple Search option and use the LDAP query builder to construct the LDAP search.
Select the Advanced Search option and enter the LDAP search string in the LDAP URL or Filter field.
See Using LDAP Searches for details.
Click the Preview button to check whether the configured search returns the expected results.
Tip - On the command line, you can use the --ldapsearch option to configure LDAP searches. |
LDAP searches can be either of the following:
An RFC 2254 search filter, see http://www.faqs.org/rfcs/rfc2254.html
An RFC 1959 LDAP URL, see http://www.faqs.org/rfcs/rfc1959.html
The Administration Console provides a Simple Search and an Advanced Search for configuring LDAP searches.
As you configure LDAP searches, use the Preview button to check that the search returns the expected results.
The Simple Search enables you to construct an LDAP search using the following commonly-used LDAP and Active Directory attribute.
Attribute Name | Description |
---|---|
c | The countryName attribute containing a two-letter ISO 3166 country code. |
cn | The commonName attribute containing the name of the object. For person objects, this is usually the person’s full name. |
departmentNumber | The attribute containing the code for a department. The code can be numeric or alphanumeric. |
l | The localityName attribute containing the name of a locality such as a city or country. |
memberOf | The commonly-used attribute for managing users in Active Directory. Contains a list of groups to which the user belongs. |
ou | The organizationalUnitName attribute containing the name of an Organizational Unit. |
sn | The surname attribute containing the family name of a person. |
You can also select a search root. The search root you specify is used instead of the search root configured for the SGD authentication mechanism. If you specify a search root, the search is formatted as an LDAP URL. If you do not specify a search root, the search is formatted as an LDAP filter.
When you save a Simple Search, the search string is displayed in the Advanced Search field.
The Advanced Search field enables you to enter your own LDAP search filter or URL, or to paste in a search from another tool.
If you enter an LDAP URL, use the format ldap:///search. If you include the host, port, and return attribute specification in the URL they are ignored.
You can use the Simple Search to construct a basic search and save it. This loads the simple search into the Advanced Search field. Then select the Advanced Search option to fine tune the search.
The Administration Console enables you to review assignments as follows:
Assigned User Profiles tab for application, document, group, and OU objects – The Effective User Profiles table shows you the users that are assigned the application
Assigned Applications tab for user profile, OU, and organization objects – The Effective Applications table shows you the users that are assigned the application
Hosting Application Servers tab on application and group objects – The Effective Application Servers table shows you the application servers that can run an application
The Hosted Applications tab on application server and group objects – The Effective Applications table shows you the applications that can run on the application servers
The Members tab on group objects – The Effective Members table shows you the members of the group
By default, LDAP assignments are not displayed. To display LDAP assignments, click the Load LDAP link in the effective assignment tables.
The effective assignment tables enable you to trace the origin of assignments, where the assignment is the result of inheritance, group membership, or an LDAP search.
You can tune the LDAP group searches to return the users you require for LDAP assignments by configuring how SGD identifies the users in a group and whether SGD can search nested groups or sub-groups.
By default, the LDAP group search searches a single depth of LDAP groups. If your organization uses nested groups or sub-groups, you can increase the depth of the search. Increasing the depth might have a negative effect on performance. See How to Increase the LDAP Group Search Depth.
SGD checks the reverse attributes on the LDAP user object for group membership before searching for users on group objects. Reverse attributes are attributes that list the groups to which the user belongs. By default, SGD searches for groups in the isMemberOf, nsroledn, memberOf attributes on user objects. If your LDAP directory uses other reverse attributes to list group membership, you can configure SGD to use those attributes. See How to Configure LDAP Group Reverse Attributes.
When SGD searches for members of LDAP groups, it searches for users in the uniquemember, member, and uniqueMember attributes on group objects. If your LDAP directory uses other attributes to specify group membership, you can configure SGD to use those attributes. See How to Configure LDAP Group Membership Attributes.
If the group membership attributes do not provide enough information to allow SGD to uniquely identify users, for example because the attributes contain only the user’s relative distinguished name, then the group search fails. SGD enables you to specify one or more short name attributes that can be used to identify users. SGD considers a user to be a member of a group if the value of their short name attribute also appears in one of the group membership attributes for the group. For short name attributes to work, they must contain unique values. See How to Configure LDAP Group Short Name Attributes.
Repeat the following procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
Repeat the following procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
Repeat the following procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
Repeat the following procedure on each SGD server in the array.
Ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.
The Administration Console has some configuration settings that affect the display of LDAP data, for example the attributes that are used to identify users. If you find that LDAP operations in the Administration Console do not work as you expect, you might have to adjust the settings. See Administration Console Configuration Settings for details.
To help diagnose problems with LDAP assignments, set a server/webtop log filter to obtain more information. For information about setting log filters, see Using Log Filters to Troubleshoot Problems With an SGD Server.
You can configure an LDAP timeout in the event that the LDAP searches of an LDAP directory fail. See LDAP Timeout.
SGD caches the data it collects from an LDAP directory. If you find that SGD is not detecting changes, you can flush the cached data manually. See LDAP Cache.
If LDAP group searches are not returning the expected results, see Tuning LDAP Group Searches.
Copyright © 2008, Sun Microsystems, Inc. All rights reserved.