You can use login filters to control which users can log in SGD and to specify which attributes are used to identify users. There are two filters, user login filter and group login filter.

You might want to configure a login filter in the following circumstances:

See also Section 2.8.2, “Using Directory Search Roots” for an alternative method of improving login times and restricting user logins.

You can use directory search roots to control which users can log in to SGD and to speed up directory searches when using LDAP or Active Directory authentication or when using Directory Services Integration to assign applications.

A directory search root specifies a part of the directory which is used to search for the user identity. To specify a search root, append the search root to the URL for the service object.

For example, to search for users in the Active Directory domain sales.example.com:

ad://example.com/dc=sales,dc=example,dc=com

Using the search root in this example, only users in the sales.example.com domain are able to log in to SGD.

For example, to search for users in the LDAP OU sales:

ldap://ldap.example.com/ou=sales,dc=example,dc=com

Using the search root in this example, only users in the sales OU are able to log in to SGD.

You can use multiple service objects to specify multiple search roots. With the URLs in the following example, only users in the domain sales.example.com and marketing.example.com are able to log in to SGD.

ad://example.com/dc=sales,dc=example,dc=com
ad://example.com/dc=marketing,dc=example,dc=com

The LDAP discovery timeout controls how long SGD waits for a directory server (LDAP or Active Directory) to respond to the initial contact request. The default is 20 seconds.

SGD makes two attempts to contact a directory server. If there is no response, SGD tries another directory server. If all directory servers time out, SGD might not be able to authenticate users or assign applications to them.

To change the timeout, use the following command:

$ tarantella config edit --tarantella-config-ldap-timeout secs

For Active Directory authentication, the LDAP discovery timeout must be longer than the KDC timeout. See Section 2.2.4.4, “KDC Timeout”. For example, if the KDC timeout is 10 seconds and the KDC retries is 3, make the LDAP discovery timeout 35 seconds (3 x 10 seconds + extra 5 seconds). Keep the KDC timeout and the LDAP discovery timeout in step. If you increase the KDC timeout, increase the LDAP discovery timeout.

A service object is a group of directory services configuration settings used for the following SGD authentication mechanisms:

You can enable Active Directory authentication or LDAP authentication. Both cannot be enabled at the same time.

If you enable any of these authentication mechanisms using the Authentication Wizard on the Global Settings → Secure Global Desktop Authentication tab in the SGD Administration Console, SGD automatically creates a service object called generated. If you enable any of these authentication methods on the command line, you must manually create at least one service object.

You can create and manage service objects on the Global Settings → Service Objects tab in the SGD Administration Console. The Service Objects List table shows the available service objects for the SGD array.

On the command line, you use the tarantella service command to create and manage service objects.

Note the following points about service objects:

In the Administration Console, you can configure only the commonly-used settings for service objects, such as the URL of the directory server, or the user name and password. See Section 2.8.4.1, “How to Create an Active Directory Service Object” and Section 2.8.4.2, “How to Create an LDAP Service Object” for more details.

There are also some advanced service object settings that can be configured only from the command line with the tarantella service new or the tarantella service edit commands.

For LDAP service object types, the following are the advanced configuration settings:

For AD service object types, the following are the advanced configuration settings:

The following information applies to LDAP and Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

SGD can handle the expiry of a user's password in the following ways:

The password expiry features are disabled by default.

For important information about authentication and password expiry, see Section 2.2.4.2, “Active Directory Password Expiry” and Section 2.4.3.3, “LDAP Bind DN and Password Change”.

Password expiry features are configured separately for each for service object. For example, to enable LDAP password expiry features for the mainldap service object, use the following command:

$ tarantella service edit --name mainldap --check-pwd-policy 1

With this configuration, users see a warning message on their webtop seven days before their password is due to expire. One day before their password is due to expire, SGD forces them to change their password. These are the defaults.

You can control when the password expiry features become active. In the following example, the password expiry features are enabled for the mainldap service object. SGD is configured to display a warning message 14 days (1209600 seconds) before password expiry, and users are forced to change their passwords 3 days (259200 seconds) before they expire:

$ tarantella service edit --name mainldap --check-pwd-policy 1 \
--pwd-expiry-warn-threshold 1209600 \
--pwd-expiry-fail-threshold 259200

The following information applies only to LDAP service object types. See Section 2.8.4, “Using Service Objects”.

By default, SGD performs password changes by performing a bind as the LDAP user. See Section 2.4.3.3, “LDAP Bind DN and Password Change” for more details.

The password update mode can be configured separately for each LDAP service object. For example, to use the administrator bind for the mainldap service object, use the following command:

$ tarantella service edit --name mainldap
--password-update-mode ldapadmin

The following information applies only to Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

A site object in Active Directory is an object that contains subnets.

If site awareness is enabled for a service object, SGD automatically attempts to discover site information by contacting the global catalog. Alternatively, you can configure your own site name for the service object.

If SGD has site information, it queries only the Active Directory servers appropriate for the site.

See Section 2.8.15, “Active Directory Authentication and LDAP Discovery” for more details about how sites are used.

Sites can be configured separately for each service object. For example, to enable site awareness for the east service object, use the following command:

$ tarantella service edit --name east --site-aware 1
 

For example, to configure a site name of boston for the east service object, use the following command:

$ tarantella service edit --name east --site-aware 1 --site-name boston

The following information applies only to Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

A whitelist is a list of global catalog servers that are always used for LDAP queries. Only those servers that are included in the whitelist can used for LDAP queries.

The order of the servers in the whitelist is important. If SGD cannot contact the first server in the list, it tries the next one.

See Section 2.8.15, “Active Directory Authentication and LDAP Discovery” for more details about how whitelists are used.

Whitelists can be configured separately for each service object. For example, to configure a whitelist for the east service object, use the following command:

$ tarantella service edit --name east --white-list \
"good1.east.example.com" "good2.east.example.com"

The following information applies only to Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

A blacklist is a list of Active Directory servers that are never used for LDAP queries, for example because a server is temporarily unavailable. Blacklists override any other configuration such as sites or whitelists.

Blacklists can be configured separately for each service object. For example, to configure a blacklist for the east service object, use the following command:

$ tarantella service edit --name east --black-list \
"bad1.east.example.com" "bad2.east.example.com"

The following information applies only to Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

When searching for user information from Active Directory, SGD uses the domain controller for the user's domain by default.

While the domain controller contains the most complete and reliable source for user information, it can result in longer timeouts and delays because SGD has to manage connections to both the domain controller and the global catalog. Instead SGD can be configured to search for user information only from the global catalog.

See Section 2.8.15, “Active Directory Authentication and LDAP Discovery” for more details about how this option is used.

Whether to search only the global catalog can be configured separately for each for service object. For example, to enable searching only the global catalog for the east service object, use the following command:

$ tarantella service edit --name east --ad-alwaysusegc 1

After running this command, you must flush the cache of LDAP data. Run the following command as superuser (root) on every SGD server in the array:

# tarantella cache --flush all

The following information applies to Active Directory service objects and LDAP service objects that connect to Active Directory. See Section 2.8.4, “Using Service Objects”.

Suffix mappings enable you to remap the domain typed by a user to an authentication domain.

Suffix mappings can be configured separately for each service object. For example, to configure a suffix mapping for the east service object, use the following command:

$ tarantella service edit --name east --suffix-mappings \
"test.east.example.com=east.example.com"

Each suffix mapping has the format suffix=domain. If there is more than one mapping, separate each mapping with a space.

The following information applies only to Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

When SGD starts, it connects to the configured Active Directory forests and then only connects to individual domains as they are needed. In some situations, there can be delays for users when they log in while SGD establishes a connection to the domain. Performance can be improved by providing SGD with a list of domains to connect to when SGD starts.

Domain lists can be configured separately for each for service object. For example, to configure a domain list for the east service object, use the following command:

$ tarantella service edit --name east --domain-list \
"boston.east.example.com" "cambridge.east.example.com"

If there is more than one domain, separate each domain name with a space.

Domain lists do not restrict the Active Directory domains used for authentication.

The following information applies to LDAP and Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

The lookup cache timeout controls for how long SGD keeps LDAP user data after a user logs in. The default is 1200 seconds (20 minutes).

You might want to increase this timeout if the LDAP data does not change very often.

The lookup cache timeout can be configured separately for each for service object. For example, to configure the lookup cache timeout for the east service object, use the following command:

$ tarantella service edit --name east --lookupcache-timeout secs

The following information applies to LDAP and Active Directory service object types. See Section 2.8.4, “Using Service Objects”.

You can configure an LDAP timeout in the event that the LDAP searches of an LDAP directory or Active Directory server takes too long. The LDAP timeout controls how long SGD waits for the directory server to respond to LDAP operations, such as requests for data. The default is 20 seconds.

SGD makes two attempts to contact the directory server. If there is no response, SGD tries another directory server in the list. For Active Directory service objects, see Section 2.8.15, “Active Directory Authentication and LDAP Discovery” for details of the servers SGD contacts. For LDAP service objects, the list of LDAP servers comes from the URLs configured for the service object.

If all directory servers time out, SGD might not be able to authenticate users, or assign applications using LDAP.

The LDAP operation timeout can be configured separately for each for service object. For example, to configure the timeout for the east service object, use the following command:

$ tarantella service edit --name east --operation-timeout secs

With Active Directory authentication, once a user has been authenticated using Kerberos, SGD performs an LDAP search of Active Directory to establish the user identity and other user information. By default, SGD performs the following steps to discover the LDAP information:

The configuration of the service object can have a significant effect on the discovery of LDAP information, see Section 2.8.4, “Using Service Objects” for more details. The following table summarizes the effect of service objects on the steps performed by SGD.