| Exit Print View | |
Oracle Secure Global Desktop Administration Guide for Version 4.6 |
|
|
|
|
3. Publishing Applications to Users
Designing the Organizational Hierarchy
Naming Objects in the Organizational Hierarchy
Populating the SGD Organizational Hierarchy Using a Batch Script
Managing the Directory Services Cache
Troubleshooting LDAP Assignments
7. SGD Servers, Arrays, and Load Balancing
B. Secure Global Desktop Server Settings
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=example/ou=Sales. The DN is the name that uniquely identifies an object.SGD object names are written like file system paths (slash-separated and top-down). The following table shows some example objects, their RDN, and their DN.
|
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 SGD authentication mechanisms. 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.
Organization objects have an o= naming attribute.
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.
Domain component objects have a dc= naming attribute.
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.
Directory objects have an ou= naming attribute.
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.
Group objects have a cn= naming attribute.
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.
Windows application objects have a cn= naming attribute.
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.
X application objects have a cn= naming attribute.
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.
Character application objects have a cn= naming attribute.
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.
Document objects have a cn= naming attribute.
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.
3270 application objects have a cn= naming attribute.
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.
5250 Application objects have a cn= naming attribute.
Dynamic application objects are used with dynamic launch to enable users to select
an application to run. See Dynamic Launch for details.
On the command line, you create a dynamic application object with the tarantella object new_dynamicapp command. Dynamic application objects have a cn= naming attribute.
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.
Dynamic application server objects are used with dynamic launch to enable users to
select the application server that runs the application. See Dynamic Launch for details.
On the command line, you create a dynamic application server object with the tarantella object new_host --dynamic command. Dynamic 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".
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.
Remember the following:
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 must have an application object.
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 user’s LDAP object.
For example, if the LDAP object is cn=Emma Rald,cn=Sales,dc=example,dc=com, SGD searches the local repository for dc=com/dc=example/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP object but with the name cn=LDAP Profile.
For example, dc=com/dc=example/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
For example, dc=com/dc=example/cn=LDAP Profile.
If there is no match, the profile object o=System Objects/cn=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 structure in the local repository.
When you mirror your LDAP structure, remember the following:
Do not mirror your entire LDAP structure 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.
You can configure service objects that specify a base DN (a search root)
as part of the LDAP URL, see Using Service Objects. The base DN can
be used as the starting point when mirroring your LDAP structure. SGD only permits
an organization object (o=) or domain component (dc=) object as the top-level object. If
your LDAP structure uses other objects, such as country (c=) or location (l=)
objects, you must ensure the base DN for the service object enables you
to mirror from an organization or domain component object. SGD also constrains the
objects you can use as directory containers. For example, you cannot nest an organization
object inside an organization object. This means you might have to create service
objects with different base DNs in order to mirror everything you need.
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 Oracle Directory Server Enterprise Edition (formerly 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:
o=indigo-insurance.com
Use an organization object.
ou=Finance,o=indigo-insurance.com
Use an OU object.
ou=Marketing,o=indigo-insurance.com
Use an OU object.
Note - In the Administration Console, create Directory objects. The naming attribute is set automatically.
Example Mirrored LDAP Objects for Oracle Directory Server shows the mirrored objects in the Administration Console.
With this structure in place, create the following user profile objects in the local repository:
o=indigo-insurance.com/ou=Finance/cn=LDAP Profile
o=indigo-insurance.com/ou=Marketing/cn=LDAP Profile
o=indigo-insurance.com/ou=Finance/uid=Sid Cerise
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:
o=indigo-insurance.com/ou=Finance/uid=Sid Cerise
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:
o=indigo-insurance.com/ou=Finance/cn=LDAP Profile
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:
o=indigo-insurance.com/ou=Marketing/cn=LDAP Profile
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:
dc=indigo-insurance,dc=com
Use a domain component object.
cn=Finance,dc=indigo-insurance,dc=com
Use an Active Directory container object.
cn=Marketing,dc=indigo-insurance,dc=com
Use an Active Directory container object.
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.
Example Mirrored LDAP Objects for Microsoft Active Directory shows the mirrored objects in the Administration Console.
With this structure in place, create the following user profile objects in the local repository:
dc=com/dc=indigo-insurance/cn=Finance/cn=LDAP Profile
dc=com/dc=indigo-insurance/cn=Marketing/cn=LDAP Profile
dc=com/dc=indigo-insurance/cn=Finance/cn=Sid Cerise
With this organizational hierarchy, users receive settings as follows:
Sid Cerise receives the settings defined for the following user profile object:
o=indigo-insurance.com/cn=Finance/cn=Sid Cerise
Users in the Finance department receive the settings defined for the following user profile object:
o=indigo-insurance.com/ou=Finance/cn=LDAP Profile.
Users in the Marketing department receive the settings defined for the following user profile object:
o=indigo-insurance.com/ou=Marketing/cn=LDAP Profile.
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.
In the Administration Console, go to the User Profiles tab.
Select the Global Administrators role object.
Add a user profile object to the Members tab.
In the Editable Members table, click Add.
The Add User Assignment window is displayed.
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.
Click Add Assignment.
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.
In the Administration Console, go to the User Profiles tab.
Select the Global Administrators role object.
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.
Click Delete.
A warning message is displayed.
Click OK.
The Members tab is displayed.
Tip - You can also use the tarantella role remove_member --role global --member pobj command.
|
|
