Exit Print View

Oracle Secure Global Desktop Administration Guide for Version 4.6

Document Information

Preface

1.  Networking and Security

2.  User Authentication

Secure Global Desktop Authentication

User Identity

User Profile

System Authentication Mechanisms

Password Expiry

Security and Passwords

Active Directory Authentication

How Active Directory Authentication Works

User Identity and User Profile

Setting Up Active Directory Authentication

Preparing for Active Directory Authentication

Supported Versions of Active Directory

Domain Requirements

Network Requirements for Active Directory Authentication

Synchronizing System Clocks

SSL Connections to Active Directory

Configuring SGD for Kerberos Authentication

Kerberos Realms and KDCs

Active Directory Password Expiry

Network Protocols

KDC Timeout

How to Enable Active Directory Authentication

Anonymous User Authentication

How Anonymous User Authentication Works

User Identity and User Profile

Application Sessions and Password Cache Entries

How to Enable Anonymous User Authentication

LDAP Authentication

How LDAP Authentication Works

User Identity and User Profile

Setting Up LDAP Authentication

Preparing for LDAP Authentication

Supported LDAP Directories

Network Requirements for LDAP Authentication

LDAP Bind DN and Password Change

Authentication to Novell eDirectory

How to Enable LDAP Authentication

SecurID Authentication

How SecurID Authentication Works

User Identity and User Profile

Setting Up SecurID Authentication

Configuring SGD Servers as Agent Hosts

How to Configure an SGD Server as an Agent Host

How to Enable SecurID Authentication

Third-Party Authentication

How Third-Party Authentication Works

Search Local Repository

User Identity and User Profile

Search LDAP Repository

User Identity and User Profile

Use Default Third-Party Identity

User Identity and User Profile

Setting Up Third-Party Authentication

How to Enable Third-Party Authentication

SGD Administrators and Third-Party Authentication

Trusted Users and Third-Party Authentication

Information for Application Developers

How to Create a New Trusted User

UNIX System Authentication

How UNIX System Authentication Works

Search Unix User ID in Local Repository

User Identity and User Profile

Search Unix Group ID in Local Repository

User Identity and User Profile

Use Default User Profile

User Identity and User Profile

UNIX System Authentication and PAM

How to Enable UNIX System Authentication

Windows Domain Authentication

How Windows Domain Authentication Works

User Identity and User Profile

How to Enable Windows Domain Authentication

Passwords, Domains, and Domain Controllers

How to Specify a Domain Controller on a Different Subnet

Tuning Directory Services for Authentication

Filtering LDAP or Active Directory Logins

User Login Filter

Group Login Filter

How to Configure a User Login Filter

How to Configure the Group Login Filter

LDAP Discovery Timeout

Using Service Objects

How to Create an Active Directory Service Object

How to Create an LDAP Service Object

Password Expiry

LDAP Password Update Mode

Sites

Whitelists

Blacklists

Search Only the Global Catalog

Suffix Mappings

Domain Lists

Lookup Cache Timeout

LDAP Operation Timeout

Active Directory Authentication and LDAP Discovery

Troubleshooting Secure Global Desktop Authentication

Setting Log Filters for Authentication Problems

Denying Users Access to SGD After Failed Login Attempts

How to Enable the Login Failure Handler

How to Change the Number of Login Attempts

Users Cannot Log In to Any SGD Server

Using Shared Accounts for Guest Users

How to Share a User Profile Between Users

Solaris OS Users Cannot Log in When Security is Enabled

An Ambiguous User Name Dialog Is Displayed When a User Tries to Log in

3.  Publishing Applications to Users

4.  Configuring Applications

5.  Client Device Support

6.  SGD Client and Webtop

7.  SGD Servers, Arrays, and Load Balancing

A.  Global Settings and Caches

B.  Secure Global Desktop Server Settings

C.  User Profiles, Applications, and Application Servers

D.  Commands

E.  Login Scripts

F.  Third-Party Legal Notices

Glossary

Index

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

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:

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:

  1. Prepare for Active Directory authentication.

    SGD has specific requirements that must be configured before enabling Active Directory authentication, see 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 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 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:

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:

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:

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:

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

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

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

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:

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

  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

    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.

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