C H A P T E R  3

Publishing Applications to Users

This chapter describes how you use organizational hierarchies to manage Sun Secure Global Desktop Software (SGD) users and give them access to applications.

This chapter includes the following topics:


Organizations and Objects

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.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.


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:

Organizational Hierarchies

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.

The User Profiles Tab

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:

The Applications 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:

The Application Servers 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

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.

SGD Object Types

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 Object: Organization

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) Object: Domain Component

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 Object: Organizational Unit

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.

Directory (Light) Object: Active Directory Container

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 Object

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 Object

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 Object

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 Object

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 Object

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 Object

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 Object

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 Object

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.

Application Server Object

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.

Designing the Organizational Hierarchy

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:

Naming Objects in the Organizational Hierarchy

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.

Populating the SGD Organizational Hierarchy Using a Batch Script

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:

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.

LDAP Mirroring

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:

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:

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:

Screen capture of the mirrored LDAP object
symbol

The following is an example of how to mirror your LDAP organization to give users different SGD settings.

An Example of LDAP Mirroring

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.

Sun Java System Directory Server

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:

  • 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.



FIGURE 3-1 shows the mirrored objects in the Administration Console.

FIGURE 3-1   Example Mirrored LDAP Objects for Sun Java System Directory Server

Screen capture showing mirrored LDAP objects
in the Administration Console when using Sun Java System Directory
Server


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

Microsoft Active Directory

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.



FIGURE 3-2 shows the mirrored objects in the Administration Console.

FIGURE 3-2   Example Mirrored LDAP Objects for Microsoft Active Directory

Screen capture showing mirrored LDAP objects
in the Administration Console when using Microsoft Active Directory


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.



SGD Administrators

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:

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.



procedure icon  How To Add an SGD Administrator

  1. In the Administration Console, go to the User Profiles tab.

  2. Select the Global Administrators role object.

    1. In the navigation tree, click System Objects.

      The System Objects table is displayed.

    2. In the System Objects table, click the Global Administrators role object.

      The Members tab is displayed.

  3. Add a user profile object to the Members tab.

    1. In the Editable Members table, click Add.

      The Add User Assignment window is displayed.

    2. Locate the user profile object.

      Use the Search field or the navigation tree to find the object you want.

    3. Select the check box next to a user profile object.

      To add several SGD Administrators, select more than one user profile object.

    4. 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.



procedure icon  How To Remove an SGD Administrator

  1. In the Administration Console, go to the User Profiles tab.

  2. Select the Global Administrators role object.

    1. In the navigation tree, click System Objects.

      The System Objects table is displayed.

    2. In the System Objects table, click the Global Administrators role object.

      The Members tab is displayed.

  3. Remove a user profile object from the Members tab.

    1. 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.

    2. Click Delete.

      A warning message is displayed.

    3. Click OK.

      The Members tab is displayed.



    Tip - You can also use the tarantella role remove_member --role global --member pobj command.




Publishing Applications

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:

Assignments can be either of the following types:

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

Local assignments are relationships between objects in the local repository.

In the Administration Console, you assign applications on the Applications tab as follows:

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.

procedure icon  How to Assign Application Servers to Applications

  1. 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.

    The General tab is displayed.

  2. Go to the Hosting Application Servers tab.

  3. In the Editable Assignments table, click Add.

    The Add Application Server Assignment window displays.

  4. Locate application server or group objects.

    Use the Search field or the navigation tree to find the objects you want.

  5. 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.

procedure icon  How to Assign Applications to Users

  1. 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.

    The General tab is displayed.

  2. Click the Assigned User Profiles Tab.

  3. In the Editable Assignments table, click Add.

    The Add User Assignment window displays.

  4. 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.

  5. 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

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:

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:



caution icon

Caution - Using LDAP assignments requires many round-trips to an LDAP directory server. This can generate a lot of network traffic and degrade performance. Using LDAP searches is more efficient and flexible than using LDAP users and groups. Use LDAP users and groups sparingly.



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.

procedure icon  How to Assign Applications to LDAP Users

  1. In the SGD Administration Console, go to the Applications tab.

  2. 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.

  3. In the Editable Assignments table, click the Add button.

    The Add User Assignment window is displayed.

  4. From the Repository list, select Local + LDAP.

  5. 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.

  6. 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.

procedure icon  How to Assign Applications to Members of LDAP Groups

  1. In the Administration Console, go to the Applications tab.

  2. 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.

  3. In the Editable Assignments table, click the Add button.

    The Add User Assignment window is displayed.

  4. From the Repository list, select Local + LDAP.

  5. 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.

  6. 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.

procedure icon  How to Assign Applications Using LDAP Searches

  1. In the Administration Console, go to the Applications tab.

  2. Select an application, document, or group object and go to the Assigned User Profiles tab.

  3. In the LDAP Searches section configure the LDAP search.

    Do either of the following:

    • 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.

    Use 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.



  4. Click Save.

Using LDAP Searches

LDAP searches can be either of the following:

The Administration Console provides a Simple Search and an Advanced Search for configuring LDAP searches.



Note - The Administration Console does not automatically escape the special characters specified in RFC2254. To use a special character in the Administration Console, you must manually type the escape sequence. For example, to search for a user with the common name “John Doe (123456)”, type the following cn=John Doe\0x28123456\0x29 in the search field.



SGD supports the use of extensible matching search filters as specified in RFC2254. This enables you to look up information from components that make up an object’s DN. For example, to assign an application to a user that is contained within any OU called managers (ou=managers), you can use a (&(ou:dn:=managers)) search filter.

As you configure LDAP searches, use the Preview button to check that the search returns the expected results.

Using the Simple Search

The Simple Search enables you to construct an LDAP search using the following commonly-used LDAP and Active Directory attributes.


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.
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.

Using the Advanced Search

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.



Note - If you fine tune a Simple Search in the Advanced Search field and edit it in a way that is not compatible with a Simple Search, you might not be able to edit the search again as a Simple Search. If this happens, you must clear the Advanced Search field and save the change. Then rebuild the Simple Search.



Reviewing Assignments

The Administration Console enables you to review assignments as follows:

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.

Tuning LDAP Group Searches

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.

procedure icon  How to Increase the LDAP Group Search Depth

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.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Increase the depth of group searches.

    Use the following command:


    # tarantella config edit \
    --com.sco.jndi.toolkit.utils.LDAPUserCollection.properties-maximumGroupDepth \
    depth
    

    The default depth is 0. Increase the value of depth to match the depth of the nested groups.

  4. Start the SGD server.

procedure icon  How to Configure LDAP Group Reverse 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.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Specify additional attributes as reverse attributes

    Use the following command:


    # tarantella config edit \
    --com.sco.jndi.toolkit.utils.LDAPUserCollection.properties-reverseAttributes-append \
    attribute ...
    

    You can list more than one attribute. Each attribute must be separated by a space.

  4. Start the SGD server.

procedure icon  How to Configure LDAP Group Membership 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.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Specify additional attributes as group membership attributes

    Use the following command:


    # tarantella config edit \
    --com.sco.jndi.toolkit.utils.LDAPUserCollection.properties-directAttributes-append \
    attribute ...
    

    You can list more than one attribute. Each attribute must be separated by a space.

  4. Start the SGD server.

procedure icon  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.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Specify the short name attributes.

    Use the following command:


    # tarantella config edit \
    --com.sco.jndi.toolkit.utils.LDAPUserCollection.properties-userShortAttributes-append \
    attribute ...
    

    You can list more than one attribute. Each attribute must be separated by a space.

  4. Start the SGD server.

LDAP Person Object Search Filter

When using LDAP assignments, SGD searches for person objects in the LDAP directory using the following search filter:

(|(objectclass=user)(objectclass=person)(uid=*))

If this search filter does not identify the person objects in your LDAP directory, it is possible for users to log in to SGD and receive a blank webtop. For example, this might happen if the LDAP person objects have an inetOrgPerson object class and no uid attribute.

If this happens, you can configure the LDAP person object search filter so that is does identify the person objects in your LDAP directory, see How to Change the LDAP Person Object Search Filter.

procedure icon  How to Change the LDAP Person Object Search Filter

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 running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Edit the person.properties file.

    The file is in /opt/tarantella/var/serverresources/tfn/tta/jserver directory.

  4. Edit the java.naming.person.userfilter property.

    For example, to add the inetOrgPerson object class to the filter, change the filter to the following:

    (|(objectclass=user)(objectclass=person)(objectclass=inetOrgPerson)(uid=*))



    caution icon

    Caution - You must keep the default SGD search filter.



  5. Save the changes.

  6. Start the SGD server.

Troubleshooting LDAP Assignments

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 the following log filters

server/webtop/*:ldapwebtop%%PID%%.log
server/webtop/*:ldapwebtop%%PID%%.jsl

See Using Log Filters to Troubleshoot Problems With an SGD Server for more information on configuring and using log filters.

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.

If a user is able to log in to SGD, but they receive a blank webtop, see LDAP Person Object Search Filter.