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

Third-Party Authentication

Third-party authentication enables users to log in to SGD if they have been authenticated by an external mechanism.

If you are using the SGD webtop, the only form of third-party authentication you can use is web server authentication. If you develop your own webtop applications using SGD web services, you can use any third-party authentication mechanism.

Third-party authentication is disabled by default.

This section includes the following topics:

How Third-Party Authentication Works

The user types in a user name and password directly to the external mechanism, typically using a web browser’s authentication dialog.

Third-party authentication is based on trust. SGD trusts that the third-party mechanism has authenticated the user correctly and so they are authenticated to SGD.

Next SGD performs a search to establish the user identity and user profile. The following search methods can be used:

If more than one search method is enabled, the methods are tried in the order they are listed above. The first matching user identity found is used. The search methods are described in the following sections.

If the searches do not produce a match, SGD cannot establish an identity for the user and the user cannot log in. If you are using the SGD webtop, the standard login page displays so that the user can log in using system authentication.

Search Local Repository

The Search Local Repository method searches the local repository for a user profile with a Name attribute that matches the user’s third-party user name. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute. If no user profile is found, the next search method is tried.

User Identity and User Profile

If a user profile is found, that object is used for the user identity and user profile. In the SGD datastore, the user identity is in the Local namespace. In the Administration Console, the text “(Local)” is displayed next to the user identity. On the command line, the user identity is located in .../_ens.

Search LDAP Repository

The Search LDAP Repository method searches an 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 found, the password typed by the user is checked against the LDAP object. If the authentication fails, the next authentication mechanism is tried.

If an LDAP object is not found, the next search method is tried.

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.

Next SGD searches for the user profile. When searching for the user profile, you can specify Use Default LDAP Profile or Use Closest Matching LDAP Profile. Use Default LDAP Profile is the default.

If Use Default LDAP Profile is selected, the profile object o=System Objects/cn=LDAP Profile is used for the user profile.

If Use Closest Matching LDAP Profile is selected, 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.

Use Default Third-Party Identity

The Use Default Third-Party Identity method does not perform a search.

User Identity and User Profile

The user identity is the third-party user name. In the SGD datastore, the user identity is in the Third–party namespace. In the Administration Console, the text “(3rd party)” is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/thirdparty.

The profile object System Objects/Third Party Profile is always used for the user profile.

Setting Up Third-Party Authentication

Setting up third–party authentication involves the following configuration steps:

  1. (Optional) Prepare to use LDAP directories.

    Third–party authentication can be configured to search an LDAP directory to establish users’ identities.

    Check that you are using a supported LDAP directory, see Supported LDAP Directories.

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

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

  2. Enable third–party authentication.

    See How to Enable Third-Party Authentication.

    By default, SGD Administrators cannot log in to SGD when third–party authentication is enabled, see SGD Administrators and Third-Party Authentication.

  3. Enable a third–party authentication mechanism.

    The most common authentication mechanism used with third–party authentication is web server authentication.

How to Enable Third-Party 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, select the Third-Party Authentication check box.
  3. On the Third-Party Authentication - User Identity and Profile step, select the check box for one or more search methods for finding the user identity.

    For details on how the search methods work, see How Third-Party Authentication Works.

    If the Search LDAP Repository check box is selected, select an option for finding the LDAP user profile.

  4. (Optional) On the LDAP Repository Details step, configure the LDAP directory details.

    The LDAP Repository Details step only displays if an LDAP search method is selected in Step 3.

    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 (;).

      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.

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

    If you enabled the LDAP search method, SGD creates a service object called generated. Service objects are used to manage directory services configuration, see Using Service Objects for more details.

SGD Administrators and Third-Party Authentication

By default, third-party authentication does not permit SGD Administrators to log in to SGD. This is a security measure. To change this behavior, use the following command:

$ tarantella config edit \
--tarantella-config-login-thirdparty-allowadmins 1

Trusted Users and Third-Party Authentication

Third-party authentication gives users access to SGD without having to authenticate to an SGD server. SGD is able to trust the third-party authentication mechanism because client applications, such as the webtop, and the SGD server have a shared secret which is the user name and password of a trusted user.

In a standard installation, there is just one trusted user. However, you might want to create additional trusted users in the following circumstances:

You create and maintain the “database” of trusted users on each SGD server in the array. The database is not shared between SGD servers. See How to Create a New Trusted User for details of how to add a trusted user. Note the following:

Information for Application Developers

If you are using SGD web services to develop your own applications, the ITarantellaExternalAuth web service is used for third-party authentication. This web service is protected with Basic web server authentication so that you can only access it using the credentials of a trusted user. This is configured as follows:

If you have developed your own client applications using the com.tarantella.tta.webservices.client.views package, you can store the trusted user credentials for the application in the same way as the webtop, see How to Create a New Trusted User. Otherwise, you need to develop your own methods for storing the credentials.

How to Create a New Trusted User

Before You Begin

Repeat the following procedure on each SGD server in the array.

  1. Log in as superuser (root) on the SGD host.
  2. Stop the SGD web server.
  3. Add the new trusted user to the database of trusted users on the SGD server.
    1. Think of a user name and password for the trusted user.
    2. Create the trusted user.

      Use the following command:

      # tarantella webserver add_trusted_user username

      When prompted, type the password.

    3. Check the user is created.

      Use the following command:

      # tarantella webserver list_trusted_users
    4. Check that the trusted user works.

      Go to the http://SGD-server/axis/services/document/externalauth URL. When prompted, log in as the trusted user.

  4. Add the new trusted user to the web services resources file for the webtop application.

    If you have relocated the webtop to a different host, perform this step on the remote host.

    1. Encode the user name and password of the trusted user.

      Use the following command:

      # /opt/tarantella/bin/jre/bin/java -classpath \
      /opt/tarantella/webserver/tomcat/tomcat-version/webapps/sgd/WEB-INF/lib/sgd-webservices.jar \
      com.tarantella.tta.webservices.client.views.SgdPasswd \
      --encode username:password
       
    2. Copy the encoded user name and password from the output.
    3. Change to the shared resources directory.
      # cd /opt/tarantella/webserver/tomcat/tomcat-version
      # cd shared/classes/com/tarantella/tta/webservices/client/views
    4. Edit the Resources.properties file.
    5. Replace the text after sgdaccess= with the encoded user name and password.
    6. Save the changes.
  5. Start the SGD web server.