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:
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.
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 involves the following configuration steps:
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”.
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”.
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”.
You prepare for Active Directory authentication as follows:
Ensure you are using a supported version of Active Directory, see Section 2.2.3.1, “Supported Versions of Active Directory”.
Ensure your Active Directory domains are configured correctly, see Section 2.2.3.2, “Domain Requirements”.
Ensure your SGD servers can connect to Active Directory, see Section 2.2.3.3, “Network Requirements for Active Directory Authentication”.
Synchronize the system clocks, see Section 2.2.3.4, “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 Section 2.2.3.5, “SSL Connections to Active Directory”.
The supported versions of Active Directory are listed in the Oracle Secure Global Desktop Platform Support and Release Notes for Release 4.7 available at http://www.oracle.com/technetwork/documentation/sgd-193668.html.
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.
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.
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.
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:
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”.
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 Section 7.5.2.2, “How to Install a Client Certificate for an SGD Server”.
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:
Kerberos realms and KDCs. The KDCs SGD uses to authenticate users, see Section 2.2.4.1, “Kerberos Realms and KDCs”
Password expiry. Whether or not SGD prompts a user for a new password if their password has expired, see Section 2.2.4.2, “Active Directory Password Expiry”.
Network protocol. Whether SGD uses the UDP or TCP protocol for Kerberos authentication, see Section 2.2.4.3, “Network Protocols”
KDC timeout. What happens if there is a failure to contact a KDC, see Section 2.2.4.4, “KDC Timeout”
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
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
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.
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
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.
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.
For Repository Type, select the Active Directory option.
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.
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.
(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
.
(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
Section 2.8.4, “Using Service Objects” for more details.