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

Windows Domain Authentication

Windows domain authentication enables users to log in to SGD if they belong to a specified Windows domain.

Windows domain authentication is disabled by default.

This section includes the following topics:

How Windows Domain 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 local repository for a user profile with a Name attribute that matches the user name typed by the user. If there is no match, the search is repeated on the Login Name attribute, and finally on the Email Address attribute.

If a user profile is found, the Login Name attribute of the user profile is treated as the Windows domain user name. If no user profile is found, the name the user typed is used as the Windows domain user name. SGD then checks the Windows domain user name and the password typed by the user against the domain controller.

If the authentication fails, the next authentication mechanism is tried.

If the authentication succeeds and the Login attribute for the user profile is not enabled, the user is not logged in and no further authentication mechanisms are tried.

If the authentication succeeds and either the Login attribute for the user profile is enabled or no matching user profile is found, the user is logged in.

User Identity and User Profile

If a user profile was found in the local repository, 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.

If no user profile was found in the local repository, the user identity is the Windows domain user name. In the SGD datastore, the user identity is in the NT namespace. In the Administration Console, the text “(NT)” is displayed next to the user identity. On the command line, the user identity is located in .../_service/sco/tta/ntauth. The profile object System Objects/NT User Profile is used for the user profile.

How to Enable Windows Domain 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 Windows Domain Controller check box.

  4. On the Windows Domain Authentication - Domain Controller step, type the name of a domain controller in the Windows Domain field.

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

Passwords, Domains, and Domain Controllers

Windows domain authentication supports 8-bit case-sensitive passwords. The user name can contain any characters.

If you need to authenticate users from more than one domain, you must have one domain that is trusted by all the other domains. You must use the trusted domain as the Windows domain controller when you configure Windows domain authentication.

When a user from another domain logs in to SGD, they must use the format domain\username for their user name. If they do not use this format, SGD tries to authenticate the user using the authentication domain and fails.


Note - The Domain Name (--ntdomain) attribute for user profiles plays no part in the SGD login.


If an SGD server is on a different subnet to the domain controller, you must hard code the domain controller information, see How to Specify a Domain Controller on a Different Subnet.

How to Specify a Domain Controller on a Different Subnet

Before You Begin

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

  1. Log in a superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Configure the domain controller

    Use the following commands:

    # tarantella config edit \
    --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig \
    authnbt=NTNAME
    # tarantella config edit \
    --com.sco.tta.server.login.ntauth.NTAuthService.properties-authConfig-append \
    authserver=my.domain.name

    where NTNAME is the NetBIOS name of the domain controller and my.domain.name is the DNS name or IP address of the domain controller.

  4. Start the SGD server.