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:

How Active Directory Authentication Works
Setting Up Active Directory Authentication
Preparing for Active Directory Authentication
Configuring SGD for Kerberos Authentication
How to Enable Active Directory Authentication

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

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

Setting Up Active Directory Authentication

Setting up Active Directory authentication involves the following configuration steps:

Prepare for Active Directory authentication.

SGD has specific requirements that must be configured before enabling Active Directory authentication, see Preparing for Active Directory Authentication.
Configure SGD for Kerberos authentication.

Configure SGD with the details of the KDCs to use for Kerberos authentication, see Configuring SGD for Kerberos Authentication.
Enable Active Directory authentication.

Configure SGD to use Active Directory authentication and specify the Active Directory domain details, see 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 Using Service Objects.

Preparing for Active Directory Authentication

You prepare for Active Directory authentication as follows:

Ensure you are using a supported version of Active Directory, see Supported Versions of Active Directory.
Ensure your Active Directory domains are configured correctly, see Domain Requirements.
Ensure your SGD servers can connect to Active Directory, see Network Requirements for Active Directory Authentication.
Synchronize the system clocks, see Synchronizing System Clocks.
(Optional) Prepare for SSL connections.

SGD connections to Active Directory are always secure. SGD supports two methods for authenticating connections to Active Directory, Kerberos and SSL. Kerberos is the method used by default. To use SSL, additional configuration is required, see SSL Connections to Active Directory.

Supported Versions of Active Directory

The supported versions of Active Directory are listed in the Oracle Secure Global Desktop 4.6 Platform Support and Release Notes available at http://docs.sun.com/app/docs/doc/821-1928.

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.

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 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 SSL Connections to Active Directory for more details.

SGD performs several DNS lookups to discover LDAP information, see 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.

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.

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 KB 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 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:

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

See How to Create a Client Certificate CSR for an SGD Server.
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.
Install the client certificate for an SGD server.

See How to Install a Client Certificate for an SGD Server.

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 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. You might need to configure the following:

Kerberos realms and KDCs. The KDCs SGD uses to authenticate users, see Kerberos Realms and KDCs
Password expiry. Whether or not SGD prompts a user for a new password if their password has expired, see Active Directory Password Expiry.
Network protocol. Whether SGD uses the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) for Kerberos authentication, see Network Protocols
KDC timeout. What happens if there is a failure to contact a KDC, see KDC Timeout

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

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

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 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 Search Only the Global Catalog for more details.

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

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 LDAP Discovery Timeout.

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

How to Enable Active Directory Authentication

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.
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 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
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 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.
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 Using Service Objects for more details.

Exit Print View
Oracle Secure Global Desktop Administration Guide for Version 4.6

Oracle Secure Global Desktop Administration Guide for Version 4.6