2.2. Active Directory Authentication

Active Directory authentication enables users to log in to SGD if they have an account in an Active Directory forest. 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 section includes the following topics:

2.2.1. How Active Directory Authentication Works

At the SGD login screen, the user types a user name and password, usually a user name and a domain name joined by the @ sign, for example indigo@example.com.

SGD uses the Kerberos protocol to check the user 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 Section 2.2.1.1, “User Identity and User Profile” for details. 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.

2.2.1.1. User Identity and User Profile

The user identity is the DN of the LDAP user. In the SGD datastore, the user identity is in the LDAP namespace. In the Administration Console, the text "(LDAP)" is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/ldapcache.

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 user's LDAP object.

    For example, if the user's 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 user's 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.

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 LDAP searches. See Chapter 3, Publishing Applications to Users for details of how applications are assigned to users.

2.2.2. Setting Up Active Directory Authentication

Setting up Active Directory authentication involves the following configuration steps:

  1. Prepare for Active Directory authentication.

    SGD has specific requirements that must be configured before enabling Active Directory authentication, see Section 2.2.3, “Preparing for Active Directory Authentication”.

  2. Configure SGD for Kerberos authentication.

    Configure SGD with the details of the KDCs to use for Kerberos authentication, see Section 2.2.4, “Configuring SGD for Kerberos Authentication”.

  3. Enable Active Directory authentication.

    Configure SGD to use Active Directory authentication and specify the Active Directory domain details, see Section 2.2.5, “How to Enable Active Directory Authentication”.

    For organizations with complex Active Directory deployments, use service objects to manage and tune your Active Directory configuration. See Section 2.8.4, “Using Service Objects”.

2.2.3. Preparing for Active Directory Authentication

You prepare for Active Directory authentication as follows:

2.2.3.1. Supported Versions of Active Directory

The supported versions of Active Directory are listed in the Oracle Secure Global Desktop Platform Support and Release Notes.

2.2.3.2. Domain Requirements

Kerberos authentication must be enabled in Active Directory. It is by default.

Ensure each Active Directory forest has a global catalog server.

When you enable Active Directory authentication, you provide a user name and password. The user must have privileges to search Active Directory for user information. You might want to create a special user reserved for Active Directory authentication.

2.2.3.3. Network Requirements for Active Directory Authentication

Before you enable Active Directory authentication, make sure all the SGD servers in the array can connect to Active Directory.

SGD must be able to make connections to Active Directory on the following ports:

  • Port 53 for DNS lookups on Active Directory

  • Ports 88 and 464 for Kerberos authentication to a KDC

  • TCP port 389 for the secure LDAP connection to a domain controller

  • TCP port 3268 for the secure LDAP connection to a global catalog server

Ports 88 and 464 are the standard ports for Kerberos authentication. These ports are configurable. Port 464 is only required for password change operations. Ports 88 and 464 can use either the TCP or UDP protocol depending on the packet size and your Kerberos configuration, see Section 2.2.4.3, “Network Protocols” for details.

If you are using SSL connections without client certificates, SGD must be able to make connections to Active Directory on the following additional ports:

  • TCP port 636 for the secure LDAP connection to a domain controller

  • TCP port 3269 for the secure LDAP connection to a global catalog server

See Section 2.2.3.5, “SSL Connections to Active Directory” for more details.

SGD performs several DNS lookups to discover LDAP information, see Section 2.8.15, “Active Directory Authentication and LDAP Discovery” for details. For these lookups to work, it is essential that your DNS is configured correctly to enable the required information to be returned from Active Directory.

2.2.3.4. Synchronizing System Clocks

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 Active Directory server. This is called clock skew. If the clock skew tolerance 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.

2.2.3.5. SSL Connections to Active Directory

To use SSL for connections to Active Directory, the Active Directory server must be configured to support LDAP signing. Consult your system documentation for details of how to support LDAP signing. Microsoft Knowledge Base article 935834 has details of how to support LDAP signing for Windows Server 2008.

SGD must be able to validate the SSL certificate presented by an Active Directory server. You might have to import the Certificate Authority (CA) or root certificate for your Active Directory servers into the CA certificates truststore on your SGD servers. See Section 7.5.1, “The CA Certificate Truststore” for details of how to check for supported CAs and how to import CA certificates.

By default, SGD authenticates to Active Directory with a user name and password. For additional security, SGD can be configured to present a client certificate instead. If you do this, each SGD server in the array must have a valid client certificate that has been signed using Active Directory Certificate Services. Active Directory must be configured to support the use of client certificates.

The process for creating a client certificate is as follows:

  1. Create a certificate signing request (CSR) for the client certificate for an SGD server.

    See Section 7.5.2.1, “How to Create a Client Certificate CSR for an SGD Server”.

  2. Create the client certificate using Active Directory Certificate Services.

    Consult your system documentation for details of how to create client certificates using Active Directory Certificate Services.

    Submit the CSR as a Base-64-encoded certificate request (Advanced Certificate Request).

    If you need to select a certificate template for the certificate, the default Administrator or User template is sufficient. The template you select must enable the certificate to be used for user or client authentication.

    Ensure you download the client certificate in Base 64 encoded format. If the certificate is signed by an Intermediate CA, download the certificate and chain.

  3. Install the client certificate for an SGD server.

    See Section 7.5.2.2, “How to Install a Client Certificate for an SGD Server”.

2.2.4. Configuring SGD for Kerberos Authentication

To use Active Directory authentication, every SGD server in the array must be configured for Kerberos authentication.

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 one the following files:

    • /etc/krb5/krb5.conf on Oracle Solaris 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. You might need to configure the following:

Caution

Pay particular attention to the format of the krb5.conf file. Incorrectly formatted files can cause problems, especially with password expiry operations.

Whenever you make changes to your Kerberos configuration file, SGD does not detect the changes until you restart the SGD server. Alternatively, you can use the following commands to refresh the Kerberos configuration and connection information without restarting the SGD server:

$ tarantella cache --flush krb5config
$ tarantella cache --flush ldapconn

2.2.4.1. 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. If a default realm is not specified, users might not be able to change an expired password.

  • [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 host:port. The port can be omitted if the default port 88 is used.

  • [domain_realm]. This maps network domains to Kerberos realms.

The following is an example Kerberos configuration file:

[libdefaults]
default_realm = EXAMPLE.COM
 
[realms]
EXAMPLE.COM = {
  kdc = kdc.example.com
}
EAST.EXAMPLE.COM = {
  kdc = ad01.east.example.com
  kdc = ad02.east.example.com
}
WEST.EXAMPLE.COM = {
  kdc = ad01.west.example.com
  kdc = ad02.west.example.com
}
 
[domain_realm]
example.com = EXAMPLE.COM
.east.example.com = EAST.EXAMPLE.COM
east.example.com = EAST.EXAMPLE.COM
.west.example.com = WEST.EXAMPLE.COM
 west.example.com = WEST.EXAMPLE.COM

2.2.4.2. Active Directory Password Expiry

SGD can be configured to prompt a user for a new password if their Active Directory password has expired. If a default realm is not specified in the krb5.conf file, users are unable to change an expired password.

To configure password expiry, 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 that handles the password change. If kpasswd_server is omitted, the admin_server is used instead. The port can be omitted if the default port 464 is used.

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

EAST.EXAMPLE.COM = {
 kdc = ad01.east.example.com
 kdc = ad02.east.example.com
 admin_server = ad01.east.example.com
 kpasswd_protocol = SET_CHANGE
 }

SGD can be configured to warn users that their password is about to expire and force them to change their password, see Section 2.8.5, “Password Expiry”. SGD can only do this if it can read the domain controller's Maximum Password Age setting and the user's Password Last Set attribute. If you configure SGD to search only the global catalog, this attribute is not available. See Section 2.8.10, “Search Only the Global Catalog” for more details.

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

2.2.4.4. KDC Timeout

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 of 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. See Section 2.8.3, “LDAP Discovery Timeout”.

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

2.2.5. How to Enable Active Directory Authentication

  1. In the Administration Console, display the Secure Global Desktop Authentication Configuration Wizard.

    Go to the Global Settings → Secure Global Desktop Authentication tab and click the Change Secure Global Desktop Authentication button.

  2. On the Third-Party/System Authentication step, ensure the System Authentication check box is selected.

  3. On the System Authentication - Repositories step, select the LDAP/Active Directory check box.

  4. On the LDAP Repository Details step, configure the Active Directory forest details.

    1. For Repository Type, select the Active Directory option.

    2. In the URLs field, type the URL of an Active Directory forest.

      For example, ad://example.com.

      The URL must start with ad://. Only type one URL.

      You can specify a DN to use as the search base, for example ad://example.com/dc=sales,dc=example,dc=com. This specifies the part of the directory used to search for the user identity.

    3. Configure secure connections to Active Directory.

      • To use only the Kerberos protocol for secure connections – Select the Kerberos option for Connection Security, and type a user name and password in the User Name and Password fields. This option is selected by default.

      • To use Kerberos and SSL for secure connections – Select the SSL option for Connection Security, and type a user name and password in the User Name and Password fields.

      • To use Kerberos, SSL, and client certificates for secure connections – Select the SSL option for Connection Security, and select the Use Certificates check box.

      See Section 2.2.3.5, “SSL Connections to Active Directory” for details of the additional configuration required to use SSL connections.

      If you type a user name, the user name has the form user@example.com. If you omit the domain name from the user name, SGD uses the information in the URL, Active Directory Base Domain, and Active Directory Default Domain fields to obtain a domain. The user must have privileges to search Active Directory for user information.

    4. (Optional) In the Active Directory 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 example.com and a user logs in with the user name rouge@west, SGD authenticates the user as rouge@west.example.com.

    5. (Optional) In the Active Directory 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.example.com and a user logs in with the user name rouge, SGD authenticates the user as rouge@east.example.com.

  5. On the Review Selections step, check the authentication configuration and click Finish.

    When you click Finish, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Section 2.8.4, “Using Service Objects” for more details.