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

Troubleshooting Secure Global Desktop Authentication

Use the information in this section to troubleshoot problems when users log in to SGD. This section includes the following topics:

Setting Log Filters for Authentication Problems

To help diagnose problems with Secure Global Desktop authentication, use one or more of the log filters shown in the following table to obtain more information.

Log Filter
Purpose
server/directoryservices/*
Information about authentication mechanisms that use directory services.

Applies to Active Directory, LDAP, and third-party authentication.

server/login/*
Information about what happens when users attempt to log in.

Applies to all authentication mechanisms.

server/securid/*
Information about connections to RSA Authentication Manager.

Applies to SecurID authentication.

For information about setting log filters, see Using Log Filters to Troubleshoot Problems With an SGD Server.

Denying Users Access to SGD After Failed Login Attempts

SGD Administrators can enable a login failure handler so that users are denied access to SGD after three failed login attempts. See How to Enable the Login Failure Handler. This additional security measure only works if users have their own user profile objects in the local repository. It does not work for the default profile objects in the System Objects organization. See for details

The number of login attempts is configurable, see How to Change the Number of Login Attempts. By default users get three attempts. The number of login attempts is local to each SGD server and is not copied across the array. Only when the login limit is reached on a server, is the user denied access across the array. For example, a user could try to log in on each SGD server two times, but only when they fail for the third time on a server are they denied access to the other members of the array.

If a user is denied access, they are only denied access to SGD. They are not denied access to the host on which SGD is installed

When a user is denied access, SGD deselects the Login check box on the General tab (--enabled false) for the user profile object in the Administration Console. To give a user access again, you must select the check box (--enabled true).

For security reasons, users are not given any indication that their account is disabled. They see the same message as if they had typed an incorrect password.

How to Enable the Login Failure Handler

You can only enable the login failure handler from the command line.

How to Change the Number of Login Attempts

Before You Begin

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

  1. Log in to the primary SGD server as superuser (root).
  2. Stop the primary SGD server.
  3. Set the number of login attempts.

    Use the following command:

    # tarantella config edit \
    --com.sco.tta.server.login.LoginFailureHandler.properties-attemptsallowed num
  4. Start the primary SGD server.
  5. Do a warm restart of all secondary SGD servers.

    Use the following command:

    # tarantella restart sgd --warm

Users Cannot Log In to Any SGD Server

If all users, including the UNIX system root user, cannot log in to any SGD server, this might be caused by either of the following:

To check whether all authentication mechanisms are disabled, use the following command:

$ tarantella config list | grep login

If all authentication mechanisms are disabled, enable the UNIX system authentication mechanism from the command line, as follows:

$ tarantella config edit --login-ens 1

Once the UNIX system authentication mechanism is enabled, you can log in to the Administration Console with the user name “Administrator” and the UNIX system root user’s password. You can then reconfigure authentication.

To check whether user logins are disabled for an SGD server, use the following command:

$ tarantella config list --server serv... --server-login

If user logins to all SGD servers are disabled, use the following command to enable user logins:

$ tarantella config edit --array --server-login 1

Using Shared Accounts for Guest Users

SGD enables more than one user to log in using the same user name and password, for example to share an account for guest users.


Note - Anonymous users are always treated as using a shared account, see Anonymous User Authentication.


Users that share a user profile object share the same application server passwords. Guest users cannot add or change entries in the password cache. This means that, unless an SGD Administrator has cached application server passwords for them, guest users are prompted for a password every time they start an application. Use the Administration Console or the tarantella passcache command to manage application server passwords for guest users.

How to Share a User Profile Between Users

  1. In the Administration Console, go to the User Profiles tab.
  2. Select the user profile that is to be shared.

    The General tab is displayed.

  3. For Login, select the Multiple check box.
  4. Click Save.

Solaris OS Users Cannot Log in When Security is Enabled

If users with Solaris OS client devices find that they cannot log in to an SGD server when SGD security services are enabled, check that the /dev/random device is present on the client device.

SGD security services require the /dev/random device. If it is missing, install the Solaris OS patch that contains this device.

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

The Ambiguous User Name dialog is displayed only for users who share person object attributes and also have the same password.

For example, there are two users with the name John Smith (cn=John Smith) and they have chosen the same password. Their email addresses and user names are different. If they log in with the name John Smith, SGD displays the Ambiguous User Name dialog which asks them to provide either an email address or a user name. The dialog displays because the credentials they supply match more than one user. If they log in using an email address or a user name, they are logged in.

The Ambiguous User Name dialog is displayed only if you are using LDAP authentication or UNIX system authentication that searches for the user ID in the local repository.

The solution is to ensure that users have unique passwords. Alternatively, configure the user profiles to have unique attributes. SGD uses the Name (--name), Login Name (--user) and Email Address (--email) to identify and disambiguate users.