Secure Global Desktop 4.40 Administration Guide > Users and Authentication > Active Directory Authentication

Active Directory Authentication

Active Directory authentication allows users to log in to SGD if they have an account in an Active Directory domain. Active Directory authentication offers users a faster, more secure, and more scalable authentication mechanism than LDAP authentication. By using the Kerberos authentication protocol, SGD can securely authenticate any user against any domain in a forest.

Active Directory authentication is disabled by default.

This page includes the following topics:

How Active Directory Authentication Works
Enabling Active Directory Authentication
The LDAP Cache
LDAP Timeouts

How Active Directory Authentication Works

At the SGD login screen, the user types a user principal name and password. A user principal name is a user name and a domain name joined by the "@" sign, for example indigo@indigo-insurance.com.

SGD uses the Kerberos protocol to check the user principal name and password against a Key Distribution Center (KDC) for a domain.

If the authentication fails, the next authentication mechanism is tried.

If the Kerberos authentication succeeds, SGD establishes the user's identity by performing an LDAP search of Active Directory. Next, SGD searches for the user profile (see the following section). If the Login attribute of the user profile is not enabled, the user cannot log in and no further authentication mechanisms are tried. If the Login attribute of the user profile is enabled, the user is logged in.

User Identity and User Profile

The user identity is the LDAP identity. In the SGD Administration Console, the user identity is displayed as LDAP-ID (LDAP). On the command line, the user identity is displayed as .../_service/sco/tta/ldapcache/LDAP-ID.

SGD establishes the user profile by searching the local repository, allowing for differences between the LDAP and SGD naming systems. SGD searches for the following until a match is found:

A user profile with the same name as the LDAP person object.
For example, if the LDAP person object is cn=Emma Rald,cn=Sales,dc=Indigo Insurance,dc=com, SGD searches the local repository for dc=com/dc=Indigo Insurance/cn=Sales/cn=Emma Rald.
A user profile in the same organizational unit as the LDAP person object but with the name cn=LDAP Profile.
For example, dc=com/dc=Indigo Insurance/cn=Sales/cn=LDAP Profile.
A user profile in any parent organizational unit with the name cn=LDAP Profile.
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.

You can use Active Directory authentication with Directory Services Integration. The applications assigned to Active Directory users come from a combination of the user profile and from LDAP searches.

Application Sessions and Password Cache Entries

Application sessions and password cache entries belong to the LDAP person object.

Enabling Active Directory Authentication

You enable Active Directory authentication as follows:

Ensure Kerberos authentication is enabled in Active Directory.
Kerberos authentication must be enabled in Active Directory. It is by default.
Ensure each Active Directory domain has a global catalog server.
Configure a domain controller in each domain as a global catalog server.
Configure SGD for Kerberos authentication.
See How to Configure SGD for Kerberos Authentication.
Configure Active Directory authentication.
See How to Configure Active Directory Authentication.

How to Configure SGD for Kerberos Authentication

The following procedure configures an SGD server so that users can be authenticated with the Kerberos protocol.

Repeat this procedure on each SGD server in the array.

Become superuser (root).
Stop the SGD server.
Synchronize the time between the SGD server and KDC servers. See Synchronizing Time.
Create or edit the Kerberos configuration file. See Kerberos Configuration.
Start the SGD server.

Synchronizing Time

To use Kerberos authentication, the clocks on the KDCs and the SGD servers in the array must be synchronized so that the time is within the maximum tolerance for computer clock synchronization defined for the Kerberos security policy and the Default domain security policy on the Microsoft Windows server. This is called clock skew. If the clock skew is exceeded, the Kerberos authentication fails.

Because time synchronization is important, use Network Time Protocol (NTP) software to synchronize clocks. Alternatively, use the rdate command.

Kerberos Configuration

A Kerberos configuration file must be present on each SGD server in the array. The Kerberos configuration file used by an SGD server is either of the following:

The system default Kerberos configuration file. This is usually the following:
- /etc/krb5/krb5.conf on Solaris OS platforms.
- /etc/krb5.conf on Linux platforms.
The SGD Kerberos configuration file. This is the /opt/tarantella/bin/jre/lib/security/krb5.conf file.
You must manually create this file or copy an existing configuration file. If this configuration file exists, it is used instead of the system default configuration file.

A Kerberos configuration file contains many options for controlling Kerberos authentication. Consult your system documentation for more details. The following configuration options are the minimum requirements for SGD:

Kerberos realms and KDCs - the KDCs SGD uses to authenticate users.
Password expiry - whether or not SGD prompts a user for a new password if their password has expired.
Network protocol - whether SGD uses the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) for Kerberos authentication.
KDC timeout - what happens if there is a failure in the authentication process.

These configuration options are described in the following sections.

If you make changes to your Kerberos configuration, SGD does not detect the changes until you restart the SGD server. Alternatively, you can use the following command to refresh the Kerberos configuration without restarting the SGD server:

$ tarantella cache --flush krb5config

Configuring Kerberos Realms and KDCs

As a minimum, the Kerberos configuration file must contain the following sections:

[libdefaults] - this sets defaults for Kerberos authentication. You must set the default_realm and default_checksum.
[realms] - this sets the KDCs for each Kerberos realm. A realm can have more than one KDC. The entry for each KDC has the form hostname:port. The port can omitted if the default port 88 is used.
[domain_realm] - this maps Active Directory domains to Kerberos realms.

The following is an example Kerberos configuration file:

[libdefaults]
default_realm = INDIGO-INSURANCE.COM
default_checksum = rsa-md5

[realms]
INDIGO-INSURANCE.COM = {
  kdc = melbourne.indigo-insurance.com
  }
EAST.INDIGO-INSURANCE.COM = {
  kdc = ad01.east.indigo-insurance.com
  kdc = ad02.east.indigo-insurance.com
  }
WEST.INDIGO-INSURANCE.COM = {
  kdc = ad01.west.indigo-insurance.com
  kdc = ad02.west.indigo-insurance.com
  }
  
[domain_realm]
  indigo-insurance.com = INDIGO-INSURANCE.COM
  .east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM
  east.indigo-insurance.com = EAST.INDIGO-INSURANCE.COM
  .west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM
  west.indigo-insurance.com = WEST.INDIGO-INSURANCE.COM

Password expiry

SGD can be configured to prompt a user for a new password if their Active Directory password has expired. To do this, the details of the server that handles the password change for each Kerberos realm must be added to the Kerberos configuration file, as follows:

kpasswd_server = host:port
admin_server = host:port
kpasswd_protocol = SET_CHANGE

The kpasswd_server and admin_server lines identify the Kerberos administration server (host) that handles the password change. If kpasswd_server is omitted, the admin_server is used instead. The port can omitted if the default port 464 is used.

The following is an example of password expiry configuration for a realm:

EAST.INDIGO-INSURANCE.COM = {
  kdc = ad01.east.indigo-insurance.com
  kdc = ad02.east.indigo-insurance.com
  admin_server = ad01.east.indigo-insurance.com
  kpasswd_protocol = SET_CHANGE
  }

Network Protocols

When sending messages to the KDC or the Kerberos administration server, SGD uses either the UDP or TCP protocols. The protocol used is determined by the following line in the [libdefaults] section of the Kerberos configuration file:

udp_preference_limit = bytes

This line sets the maximum size in bytes for packets that can be sent using UDP. If the message is larger than this size, TCP is used. If the KDC or administration server indicates that the package is too big, TCP is used instead. To always use TCP, set the udp_preference_limit as follows:

udp_preference_limit = 1

KDC timeout

If the Kerberos authentication process fails, you can configure a KDC timeout that controls how long SGD waits for a reply from a KDC and how many times it tries to contact each KDC.

To set the KDC timeout, add the following lines to the [libdefaults] section of the Kerberos configuration file:

kdc_timeout = time
max_retries = number

The kdc_timeout sets the maximum number milliseconds to wait for a reply from a KDC. The max_retries is the maximum number of times each KDC is tried. The KDCs for each realm are tried in the order they are listed in the [realms] section of the Kerberos configuration file.

It is best to keep the KDC timeout and the LDAP discovery timeout in step. If you increase the KDC timeout, increase the LDAP discovery timeout.

If SGD cannot contact any KDCs for the user's realm, the authentication phase fails.

How to Configure Active Directory Authentication

In the SGD Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.
On the Global Settings » Secure Global Desktop Authentication tab, click the Change Secure Global Desktop Authentication button.
On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.
On the System Authentication - Repositories step, select the LDAP/Active Directory check box.
On the LDAP Repository Details step, configure the Active Directory domain details.
1. For Repository Type, select the Active Directory option.
2. In the URLs field, type the name of an Active Directory domain, for example ad://east.indigo-insurance.com.
  The URL must start with ad://. Only type one URL.
  
  SGD uses the domain name to perform a Domain Name System (DNS) lookup to obtain a list of global catalog servers. The global catalog is used to determine which Active Directory servers SGD can search to determine the user's identity and user profile.
3. Configure whether SGD connects to Active Directory using a secure or a standard connection.
  To use secure connections, select the Use Certificates check box and install the client certificates for each SGD server in the array.
  
  To use standard connections, type the user name and password of a user that has privileges to search Active Directory in the User Name and Password fields. The user name must be the user principal name, for example sgd-ldap@indigo-insurance.com. You might want to create a special user reserved for Active Directory authentication.
4. In the Base Domain field, type a partial domain name.
  The base domain is used when users only supply a partial domain when they log in. For example, if the base domain is set to indigo-insurance.com and a user logs in with the user name rouge@west, SGD tries to authenticate the user as rouge@west.indigo-insurance.com.
5. In the default Domain field, type a domain name to use as a default.
  The default domain is used when users do not supply a domain when they log in. For example, if the default domain is set to east.indigo-insurance.com and a user logs in with the user name rouge, the SGD tries to authenticate the user as rouge@east.indigo-insurance.com.
On the Review Selections step, check the authentication configuration and click Finish.

The LDAP Cache

SGD caches the LDAP data it collects from Active 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 Directory Services Integration.
`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 Directory Services Integration.
`all`	Flushes all LDAP data.

LDAP Timeouts

You can configure two LDAP timeouts in the event that the LDAP searches of an Active Directory server fail.

The LDAP discovery timeout controls how long SGD waits for an Active Directory server to respond to the initial contact request. The default is 30 seconds. To change this timeout, run the following command:

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

The LDAP timeout controls how long SGD waits for an Active 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

With both timeouts, SGD makes two attempts to contact the Active Directory server. If there is no response, SGD tries another Active Directory server. The list of Active Directory servers for a domain is obtained from the global catalog. If all Active Directory servers time out, SGD might not be able to use directory services integration.

Configure the LDAP discovery timeout to be longer than the 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.

Related Topics
Using Directory Services Integration LDAP Authentication Secure Global Desktop and User Authentication