Secure Global Desktop 4.40 Administration Guide > Organizing Your Resources > Using Directory Services Integration
SGD Directory Services Integration (DSI) allows you to use an LDAP directory instead of the local repository for holding user information. With DSI, you do not need to create any user profile objects in the local repository. Instead of assigning applications to a user, you assign the user to the applications.
This page includes the following topics:
To enable DSI:
DSI is supported on the following LDAP version 3 directory servers:
DSI might work on other LDAP directory servers, but it is not supported.
You can only use DSI for users who have their identity established by a search of an LDAP directory. This means users must be authenticated by one of the following authentication mechanisms:
See Configuring Applications, Documents and Groups for DSI for details.
If you want more control over the SGD-specific settings for users, such as the ability to use copy and paste, or to edit client profiles, you might want to configure user profiles for DSI.
With DSI, instead of assigning applications to users, you assign users to applications. In the SGD Administration Console, you do this on the Assigned User Profiles tab for application, document and group objects. You can assign users as follows:
Note Using DSI 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.
You assign LDAP users to an application, a group of applications, or a document, as follows:
The Add User Assignment window displays.
Use the navigation tree or the search to find users in the LDAP directory.
The Add User Assignment window closes and the Editable Assignments table is updated with the LDAP user(s).
Alternatively, use the following command:
$ tarantella object edit --name obj \ --ldapusers user-dn ...
The user-dn is one or more distinguished names (DNs) of users in an LDAP directory,
for example uid=Sid Cerise,ou=Finance,o=indigo-insurance.com
.
Note If you assign several individual users to an object, it is more efficient to use LDAP searches instead.
You assign LDAP groups to an application, a group of applications, or a document, as follows:
The Add User Assignment window displays.
Use the navigation tree or the search to find groups in the LDAP directory.
The Add User Assignment window closes and the Editable Assignments table is updated with the LDAP group(s).
Alternatively, use the following command:
$ tarantella object edit --name obj \ --ldapgroups group-dn ...
The group-dn is one or more distinguished names (DNs) of groups in an LDAP directory,
for example cn=managers,ou=Finance,o=indigo-insurance.com cn=managers,ou=Marketing,o=indigo-insurance.com
.
Note If you assign several groups to an object, it is more efficient to use LDAP searches instead.
LDAP searches can be RFC 2254 search filters or RFC 1959 LDAP URLs.
You configure the LDAP searches for an application, a group of applications, or a document, as follows:
Do either of the following:
Alternatively, use the following command:
$ tarantella object edit --name obj \ --ldapsearch search_string ...
The following example is an LDAP filter that assigns any manager in the Sales department and anyone who has Violet Carson as their manager.
--ldapsearch "(&(job=manager)(dept=Sales))" "(manager=Violet Carson)"
The following example is an LDAP URL that assigns any manager in the Sales department of indigo-insurance.com.
--ldapsearch "ldap:///ou=Sales,dc=indigo-insurance,dc=com??sub?job=manager"
The LDAP query builder for the Simple Search allows you to construct an LDAP search using commonly-used LDAP and Active Directory attributes. You can also select a search root to specify the part of the LDAP directory you want to search 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. As you build the query, use the Preview button to see a list of the users that are returned by the search. This allows you to check that the search returns the users you expect. When you click the Save button, the search string is displayed in the Advanced Search field.
The following are the available Simple Search 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 strictly numeric or it can be 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. It 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. |
The Advanced Search field allows 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.
Use the Preview button to see a list of the users that are returned by the search.
Note If you fine tune a Simple Search in the Advanced Search field, you might not be able to edit the search again as a Simple Search if you edit it in a way that is not compatible with a simple search. If this happens, you must clear the Advanced Search field and Save the change. The re-build the Simple Search.
In the SGD Administration Console, the Effective User Profiles table on the Assigned User Profiles tab shows the the user profiles that are assigned to the application, document, or group object. By default, the LDAP assignments do not display. To display the LDAP assignments, click the Load LDAP links in the table. The LDAP assignments part of the table shows a list of all the LDAP users assigned to the object and the assignment type. The assignment type can be any of the following:
Assignment Type | Description |
---|---|
Direct | The user is assigned as the result of an LDAP user or LDAP group search. |
Indirect | The user is assigned as the result of an LDAP search filter or URL. |
Multiple | The used is assigned as the result of both Direct and Indirect searches. |
By clicking the See Details link in the Effective Assignments table, you can see the origin of the user assignment.
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 the 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:
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
.
cn=LDAP Profile
.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile
.
cn=LDAP Profile
.
For example, dc=com/dc=Indigo Insurance/cn=LDAP Profile
.
If there is no match, the profile object System Objects/LDAP Profile
is used for the user profile.
User profiles can be used to control a user's SGD-specific settings,
for example the ability to use copy and paste or to edit client profiles, as well as the applications they can run.
By default, all LDAP users have the same SGD-specific settings, the settings configured for the
System Objects/LDAP Profile
user profile. In order to customize a user's
SGD settings, you might have to mirror some of your LDAP organization in the local repository.
Note If you want Secure Global Desktop Administrators to authenticate using an LDAP directory, you must create user profiles them.
When you mirror your organizational hierarchy, remember the following:
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.
Note When working with user profiles in the SGD Administration Console, select Local + LDAP from the Repository list on the User Profiles tab. LDAP objects that are mirrored in the local repository display this symbol in the tree view. You might also find it useful to display the naming attributes of the objects you create. You enable the display of the naming attributes in the preferences for the SGD Administration Console.
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 to use:
o=indigo-insurance.com
- use an organization (Directory) objectou=Finance,o=indigo-insurance.com
- use an organizational unit (Directory) objectou=Marketing,o=indigo-insurance.com
- use an organizational unit (Directory) objectThe following screenshot shows the mirrored objects in the SGD Administration Console.
With this structure in place, create the following user profiles in the local repository:
o=indigo-insurance.com/ou=Finance/cn=LDAP Profile
- a user profile object representing the users in Financeo=indigo-insurance.com/ou=Marketing/cn=LDAP Profile
- a user profile object representing the users in Marketingo=indigo-insurance.com/ou=Finance/uid=Sid Cerise
- a user profile object representing Sid CeriseNote Remember to select uid as the naming attribute for the o=indigo-insurance.com/ou=Finance/uid=Sid Cerise
object.
With this organizational hierarchy, users receive settings as follows:
o=indigo-insurance.com/ou=Finance/uid=Sid Cerise
user profile,
including any settings inherited from parent objects in the organizational hierarchy.o=indigo-insurance.com/ou=Finance/cn=LDAP Profile
user profile,
including any settings inherited from parent objects in the organizational hierarchy.o=indigo-insurance.com/ou=Marketing/cn=LDAP Profile
user profile,
including any settings inherited from parent objects in the organizational hierarchy.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 (Directory Light) objectcn=Finance,dc=indigo-insurance,dc=com
- use an Active Directory container (Directory Light) objectcn=Marketing,dc=indigo-insurance,dc=com
- an Active Directory container (Directory Light) objectNote To create domain components and Active Directory containers, create Directory Light objects and select the correct naming attribute.
The following screenshot shows the mirrored objects in the SGD Administration Console.
With this structure in place, create the following user profiles in the local repository:
dc=com/dc=indigo-insurance/cn=Finance/cn=LDAP Profile
- a user profile representing the users in Financedc=com/dc=indigo-insurance/cn=Marketing/cn=LDAP Profile
- a user profile representing the users in Marketingdc=com/dc=indigo-insurance/cn=Finance/cn=Sid Cerise
- a user profile representing Sid CeriseWith this organizational hierarchy, users receive settings as follows:
o=indigo-insurance.com/cn=Finance/cn=Sid Cerise
user profile.o=indigo-insurance.com/ou=Finance/cn=LDAP Profile
user profile.o=indigo-insurance.com/ou=Marketing/cn=LDAP Profile
user profile.System Objects/cn=LDAP Profile
.Note It is not possible to inherit SGD settings from domain component and Active Directory container objects.
You can tune the LDAP group searches to return the users you require for DSI by configuring how SGD identifies the users in a group and whether SGD can search nested groups (sub-groups).
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. You do this as follows:
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.
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 (RDN), then the group search fails. SGD allows you to specify one or more short name attributes which 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. You configure short name attributes as follows:
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.
By default, the LDAP group search searches a single depth of LDAP groups. If your organization uses nested groups (sub-groups), you can increase the depth of the search. Increasing the depth might have a negative effect on performance. You do this as follows:
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.
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 with the following command:
tarantella cache --flush ldapgroups | ldapconn | ldapconn-lookups | all
Note This command only flushes the cache on the SGD server on which the command is run.
Option | Description |
---|---|
ldapgroups |
Flushes the cache of all LDAP group data, used for DSI. |
ldapconn |
Flushes the cache of all the IP address, domain and attribute data. |
ldapconn-lookups |
Flushes the cache of all LDAP search data, used for DSI. |
all |
Flushes all LDAP data. |
You can configure an LDAP timeout in the event that the LDAP searches of an LDAP directory server fail. The LDAP timeout controls how long SGD waits for an LDAP directory server to respond to LDAP operations, such as requests for data. The default is 30 seconds. To change this timeout, run the following command:
$ tarantella config edit --tarantella-config-ldap-timeout secs
SGD makes two attempts to contact the LDAP directory server. If there is no response, SGD tries another LDAP directory server. If all LDAP directory servers time out, SGD might not be able to use DSI assignments.
The SGD 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 SGD Administration Console do not work as you expect, you might have to adjust the settings. See SGD Administration Console Configuration Settings for details.
Copyright © 1997-2007 Sun Microsystems, Inc. All rights reserved.