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

Setting Up Active Directory Authentication

Preparing for Active Directory Authentication

Configuring SGD for Kerberos Authentication

How to Enable Active Directory Authentication

Anonymous User Authentication

How Anonymous User Authentication Works

How to Enable Anonymous User Authentication

LDAP Authentication

How LDAP Authentication Works

Setting Up LDAP Authentication

Preparing for LDAP Authentication

How to Enable LDAP Authentication

SecurID Authentication

How SecurID Authentication Works

Setting Up SecurID Authentication

Configuring SGD Servers as Agent Hosts

How to Enable SecurID Authentication

Third-Party Authentication

How Third-Party Authentication Works

Setting Up Third-Party Authentication

How to Enable Third-Party Authentication

SGD Administrators and Third-Party Authentication

Trusted Users and Third-Party Authentication

UNIX System Authentication

How UNIX System Authentication Works

UNIX System Authentication and PAM

How to Enable UNIX System Authentication

Windows Domain Authentication

How Windows Domain Authentication Works

How to Enable Windows Domain Authentication

Passwords, Domains, and Domain Controllers

Tuning Directory Services for Authentication

Filtering LDAP or Active Directory Logins

LDAP Discovery Timeout

Using Service Objects

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

Users Cannot Log In to Any SGD Server

Using Shared Accounts for Guest 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

LDAP Authentication

LDAP authentication enables users to log in to SGD if they have an entry in an LDAP directory.

This authentication mechanism is disabled by default.

This section includes the following topics:

How LDAP Authentication Works

At the SGD login screen, the user types a user name and password. The user name can be any of the following:

SGD searches the LDAP directory for an LDAP object with an attribute that matches the user name typed by the user. By default, SGD searches the following attributes:

If an LDAP object is not found, the next authentication mechanism is tried.

If an LDAP object is found, SGD performs a bind using the name of the LDAP object and the password typed by the user. If the bind fails, the next authentication mechanism is tried.

If the authentication succeeds, SGD searches the local repository 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 user’s LDAP object. 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 LDAP authentication with Directory Services Integration. The applications assigned to LDAP 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 LDAP Authentication

Setting up LDAP authentication involves the following configuration steps:

  1. Prepare for LDAP authentication.

    Additional configuration might be required to use SGD with your LDAP directory, see Preparing for LDAP Authentication.

  2. Enable LDAP authentication.

    Configure SGD to use LDAP authentication and specify the LDAP directory details, see How to Enable LDAP Authentication.

    For organizations with complex LDAP deployments, use service objects to manage and tune your LDAP configuration. See Using Service Objects.

Preparing for LDAP Authentication

You prepare for LDAP authentication as follows:

Supported LDAP Directories

The supported LDAP directories 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.

Network Requirements for LDAP Authentication

Before you enable LDAP authentication, make sure all the SGD servers in the array can contact each LDAP directory server used for authentication.

The standard port used for connections to LDAP directory servers is TCP port 389 for standard connections and port TCP 636 for secure (ldaps://) connections. If your directory servers use different ports, you can specify the port when you enable LDAP authentication. You must make sure SGD can make LDAP connections using these ports.

To be able to use secure (ldaps://) connections, SGD must be able to validate the SSL certificate presented by an LDAP directory server. You might have to import the CA certificates for your LDAP directory servers into the SGD CA certificate truststore. See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.

LDAP Bind DN and Password Change

By default, SGD uses two LDAP bind DNs, an administrator bind DN and a user bind DN.

The administrator bind DN is the user name and password configured for LDAP authentication. The administrator bind DN is used only for querying the directory server and so this user must have privileges to search the directory. You might want to create a special LDAP user for use with SGD. The administrator bind can be an anonymous bind. Active Directory does not support anonymous binds.

The user bind DN is the user name and password provided when a user logs in. By default, the user bind DN is used for authentication and password change operations.

Once a user’s password expires, they cannot log in to SGD and SGD cannot force them to change their password. SGD can be configured to warn users that their password is about to expire, and to force them to change their password before it expires, see Password Expiry. For SGD to be able to do this, the following must be true:

If your directory server does not meet these requirements, and you want SGD to handle password change, you must configure SGD to use the administrator bind DN for password change operations. See LDAP Password Update Mode.


Note - On some LDAP directories, password change operations performed using the administrator bind DN are treated as a password reset rather than a change operation.


For Oracle Directory Server Enterprise Edition, if you configure SGD to use the administrator bind DN for password updates, additional configuration might be needed for SGD to handle password change, as follows:

For Active Directory, password expiry including forcing the user to change their password at next logon, can only be handled if there is a secure connection (ldaps://) between the SGD server and the Active Directory server.

By default, Novell eDirectory requires that all simple LDAP binds that contain a password must use an SSL connection. To use eDirectory with SGD, do either of the following:

Authentication to Novell eDirectory

Users might not be able to authenticate Novell eDirectory because the user login filter for LDAP authentication filters for the cn attribute and this attribute is a restricted attribute in eDirectory.

To enable users to log in to SGD, do either of the following:

How to Enable LDAP Authentication

  1. In the SGD 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 LDAP directory details.

    1. For Repository Type, select the LDAP option.

      Select this option even if you are using a Microsoft Active Directory server for LDAP authentication. The Active Directory option enables Active Directory authentication, see Active Directory Authentication.

    2. In the URLs field, type the URL of one or more LDAP directory servers.

      For example, ldap://melbourne.example.com.

      If you type more than one URL, separate each URL with a semicolon (;).

      If there is than one URL, SGD uses the URLs in the order they are listed. If the first LDAP directory server in the list is unavailable, the next one is tried.

      To use secure connections to LDAP directory servers, use an ldaps:// URL.

      The URLS must all be of the same type, either ldap:// or ldaps://. You cannot use a mixture of ldap:// and ldaps:// URLs.

      If the LDAP directory uses a non-standard port, specify the port number as part of the URL, for example ldap://melbourne.example.com:5678. Otherwise the port number can be omitted.

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

    3. Type the details of an LDAP user in the User Name and Password fields.

      The user name must be the DN of the user, for example cn=sgd-user,cn=Users,dc=example,dc=com. This is the administrator bind DN, see LDAP Bind DN and Password Change for more details.

      As you can only enter one user name and password, this user must be able to search all LDAP directory servers listed in the URL field.

      If the directory server supports anonymous binds, you can omit the user name and password. You must be able to perform LDAP queries for user data to use anonymous binds.

      The URLS configured for an LDAP service object must all be of the same type, either ldap:// or ldaps://. You cannot use a mixture of ldap:// and ldaps:// URLs.

  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.