Complex Configurations

Once you've set up and verified that basic Windows Desktop SSO Authentication works, you can deploy the module in more complex configurations:

• Chaining Multiple Authentication Modules

• To Use the Windows Desktop SSO Authentication Module with a Load Balancer

• Using the Windows Desktop SSO Authentication Module with Multiple Kerberos Domain Controllers

Chaining Multiple Authentication Modules

You can use the administration console to chain multiple authentication modules to work together as single a authentication service . When multiple authentication modules are chained together, the end-user must authenticate at least one of authentication modules in defined in the authentication group. Or the user may be required to authenticate to all of the modules, depending upon on how authentication chaining is configured.

The following instructions demonstrate chaining the DataStore Authentication module and Windows Desktop SSO Authentication module to work together as an authentication service. Using this configuration, an end-user can access OpenSSO Enterprise using the authentication service name. Example: http://openSSO.example.com/amserver/UI/Login?service=WinSSOService.

To Configure Authentication Chaining

1. Log in to the OpenSSO Enterprise admnistration console as amadmin.

2. Go to Access Control > Default Realm > Authentication.

3. Define a new instance of the Windows Desktop SSO Authentication module.

4. Go to Access Control? > Default Realm > Authentication.

5. Define new instance of Authentication Chaining.

   1. Click the New button for Authentication Chaining.

      Provide a name for this chain, and then click OK. Example name: WinSSOService.

   2. Click Add, and then choose the first authentication module to be executed in this chain.

      In this example, Windows Desktop SSO is the first module to be executed.

   3. For Criteria, choose Sufficient.

   4. Click Add, and then choose the next authentication module in the chain to be executed.

      In this example, Data Store is the next module to be executed.

   5. For Criteria, choose Sufficient.

6. Go to Access Control > Default Realm> Authentication, and save this new chaining configuration.

To Test Authentication Chaining

1. Log in to a Windows XP Domain Controller and start any browser that is enabled for the SPNEGO protocol.

2. Go to the OpenSSO Enterprise URL configured with the authentication service name.

   Example : http://am.demo.identity.com/amserver/UI/Login?service=WinSSOService.

   If a user can log into Windows XP Domain Controller successfully, the browser sends a Kerberos ticket to the OpenSSO Enterprise server, and the user is successfully authenticated using the Windows Desktop SSO Authentication module. .

   If the user cannot authenticate to the first authentication module, then OpenSSO Enterprise prompts for user name and password and tries to authenticate using the Data Store Authentication module. If authentication fails, then the administrator should troubleshoot the authentication failure. For a short list of solutions for the most common error messages related to Windows Desktop SSO Authentication, see Troubleshooting Windows Desktop SSO Authentication Issues.

To Use the Windows Desktop SSO Authentication Module with a Load Balancer

All OpenSSO Enterprise authentication modules, including the Windows Desktop SSO Authentication module, can be accessed through a load balancer. The Windows Desktop SSO Authentication module requires some special configuration.

1. Create an Active Directory domain account in Windows 2003 or in the Kerberos service principal.

2. When you generate the keytab file for he Windows Desktop SSO Authentication, you have to specify the load balancer FQDN.

   Example: HTTP://opensso-lb.example.com. If you don't specify the fully-qualified domain name, authentication will fail.

3. Copy the keytab file to all OpenSSO Enterprise servers, and put place in under the same directory in each server.

   Example location: /etc/ SUNWam/config.

4. Create a new Windows Desktop SSO Authentication module and Configure it with the newly copied keytab file.

5. Restart all the OpenSSO Enterprise servers and test the new module through the load balancer.

Using the Windows Desktop SSO Authentication Module with Multiple Kerberos Domain Controllers

You can configure the Windows Desktop SSO authentication module to work with multiple Kerberos Domain Controllers. This is useful for deploying a failover Kerberos server.

When you configure the Windows Desktop SSO authentication module with a keytab file from one of the trusted domain controllers, any user belonging to any of the trusted domains can authenticate through the Windows Desktop SSO authentication module. Administrators can configure and manage trust relationships in environments containing multiple Active Directories.

To make the Windows domain controller a part of the trusted nodes, and to make the Windows domain controller work with the Windows Desktop SSO authentication module, the following conditions must be met:

• You must use Windows 2003 or a later version.

• The domain controller functional level must be set at Windows Server 2003.

• Trust must be configured.

Trust configuration is beyond the scope of this document. The following links provide useful related information:

• Configuring KDC Servers in System Administration Guide: Security Services

• Configuring Cross-Realm Authentication in System Administration Guide: Security Services

The following procedures will help you navigate to the configuration areas of the Windows domain controller:

• To Locate the Trust Configuration Window

• To Promote the Domain Controller Functional Level

To Locate the Trust Configuration Window

1. From the Windows Start menu, choose Administrative Tools > Active Directory Domains and Trusts.

2. In the Active Directory Domains and Trusts window, right-click the domain name and click Properties.

3. Click the Trusts tab.

4. Click New.

   

To Promote the Domain Controller Functional Level

1. From the Windows Start menu, go to Administrative Tools > Active Directory Domains and Trusts.

2. In the Active Directory Domains and Trusts window, right-click the domain name, and choose the Raise Domain Functional Level menu.

3. Choose windows Server 2003 as the new functional level.