8
Windows Native Authentication

This chapter explains how to deploy OracleAS Single Sign-On for automatic sign-on, or Windows native authentication, from a Windows desktop. The terms automatic sign-on and Windows native authentication are interchangeable. For the remainder of the document, the latter term is used.

The chapter contains the following topics:

• Overview of Windows Native Authentication

• How Windows Native Authentication Works

• System Requirements

• Configuring Windows Native Authentication

• Fallback Authentication

• Login Scenarios

Overview of Windows Native Authentication

Windows native authentication is an authentication scheme for those who use Internet Explorer on Windows 2000. When this feature is enabled in OracleAS Single Sign-On, users log in to single sign-on partner applications automatically using Kerberos credentials obtained when the user logs in to a Windows 2000 computer.

Using the SPNEGO protocol, browsers that are Internet Explorer 5.0 and greater can automatically pass the user's Kerberos credentials to a Kerberos-enabled Web server when the server request these credentials. The Web server can then decrypt the credentials and authenticate the user.

Although SPNEGO supports both Kerberos version 5 and NTLM authentication schemes, OracleAS release 9.0.4 supports only Kerberos version 5 with SPNEGO.

Note: Although this document refers only to Windows 2000, Windows native authentication is also supported on the Windows XP platform.

How Windows Native Authentication Works

The following steps, illustrated in Figure 8-1, describe what happens when a user tries to access a single-sign-on-protected application:

1. The user logs in to a Kerberos realm, or domain, on a Windows 2000 computer.

2. The user attempts to access a single-sign-on partner application using Internet Explorer.

3. The application redirects the user to the single sign-on server for authentication. As part of this redirection, the following occurs:
   1. The browser obtains a Kerberos session ticket from the Key Distribution Center (KDC).

   2. The single sign-on server verifies the Kerberos session ticket and returns the user to the requested URL.

4. The application provides content to the user.

Figure 8-1 Flow for Windows Native Authentication

Text description of the illustration ssoag039.gif

The user logs out of this application and single sign-on applications accessed subsequently by logging out of the Windows computer.

System Requirements

Windows native authentication is intended for intranet Web applications. Your intranet deployment must have the following:

• Windows 2000 server with Microsoft Active Directory

• Kerberos service account established for single sign-on server

• OracleAS release 9.0.4 infrastructure installed

  Note: The configurations that follow assume that the OracleAS infrastructure is installed on UNIX, but it can be installed on Windows instead.

• Single sign-on middle tier configured to use a Kerberos realm

• Synchronization between Microsoft Active Directory and Oracle Internet Directory

• Oracle Internet Directory configured to use the Windows authentication plugin

Configuring Windows Native Authentication

Setting up Windows native authentication requires that Oracle Internet Directory, the single sign-on server, and the user's browser all be configured.

Perform these configuration tasks in the order listed:

• Verify That Microsoft Active Directory Is Set Up and Working

• Install Oracle Internet Directory and OracleAS Single Sign-On

• Synchronize Oracle Internet Directory with Microsoft Active Directory

• Configure Oracle Internet Directory to Use Windows Authentication Plugin

• Configure the Single Sign-On Server

• Configure the End User Browser

Verify That Microsoft Active Directory Is Set Up and Working

Consult documentation for the Windows 2000 server to ensure that Microsoft Active Directory is set up and working.

Install Oracle Internet Directory and OracleAS Single Sign-On

Install Oracle Internet Directory and OracleAS Single Sign-On. To determine which deployment configuration suits your installation, see Chapter 9, "Advanced Configurations". For installation instructions, see Oracle Application Server 10g Installation Guide.

Synchronize Oracle Internet Directory with Microsoft Active Directory

User entries in Oracle Internet Directory must be synchronized with user entries in Microsoft Active Directory. To learn how to synchronize Oracle Internet Directory with Microsoft Active Directory, see Oracle Internet Directory Administrator's Guide.

Configure Oracle Internet Directory to Use Windows Authentication Plugin

See Oracle Internet Directory Administrator's Guide.

Configure the Single Sign-On Server

Complete the following tasks to configure the single sign-on server.

• Set Up a Kerberos Service Account for the Single Sign-On Server

• Configure the Single Sign-On Server to Use the Sun JAAS Login Module

• Configure the Single Sign-On Server as a Secured Application

Set Up a Kerberos Service Account for the Single Sign-On Server

Configure a kerberos realm on the single sign-on middle tier; then create a service account for the single sign-on server in Microsoft Active Directory. Finally, create a keytab file for the single sign-on server, mapping the service principal to the account name.

1. Configure /etc/krb5/krb5.conf on the middle tier. You do this by updating the file to look like the following example:

   [libdefaults]
   default_realm = ADUSERS.ACME.COM
   [realms]
   ADUSERS.ACME.COM = {
      kdc = kdc.acme.com
      }
   [domain_realm]
   .acme.com = ADUSERS.ACME.COM
   
   

   where ADUSERS.ACME.COM is the default realm of Microsoft Active Directory, kdc.acme.com is the host name of the KDC, and .acme.com is the DNS domain name of the UNIX computer. Be sure to replace the example values given with values suitable for your installation. These values appear in boldface in the example.

   Note: The realm name in krb5.conf is case sensitive and should match the realm name in Microsoft Active Directory. The realm name is usually uppercase.

2. Synchronize system clocks between the single sign-on middle tier and the Windows 2000 server. If you omit this step, authentication fails because of clock skew errors.

3. Check the port number of the Kerberos server on the single sign-on computer. The port where the Kerberos server listens is picked from /etc/services by default. The service name is Kerberos. Typically this port is set to 88/udp and 88/tcp on the Windows 2000 server. When added correctly to the /etc/services file, the entries for these port numbers look like this:

   kerberos5        88/udp          kdc             # Kerberos key server
   kerberos5        88/tcp          kdc             # Kerberos key server
   
   

4. In the /etc/hosts file, check the entry for the single sign-on middle tier. The fully qualified host name of the single sign-on computer must appear after the IP address and before the short name. Here is an example of a correct entry:

   130.111.111.111 sso.acme.com sso loghost
   
   

5. Log in to the Active Directory Management tool on the Windows 2000 server; then click Users -> New -> user.

   Enter the name of the single sign-on host, omitting the domain name. If, for example, the host name is sso.acme.com, you enter only sso. This is the account name in Active Directory.

   Note the password that you assigned to the account. You will need it later. Do not choose User must change password at next logon.

6. Create a keytab file for the single sign-on server, mapping the account name to the service principal name. You perform both tasks by issuing the following command on the Windows 2000 server:

   C:> Ktpass -princ HTTP/sso.acme.com@ADUSERS.ACME.COM -pass password -mapuser 
   sso -out sso.keytab
   
   

   where -princ is the service principal. This value must be specified using the format HTTP/single_sign-on_host_name@KERBEROS_REALM_NAME. Note that HTTP and the Kerberos realm must be uppercase.

   -pass is the account password that you obtained in step 4. -mapuser is the account name of the single sign-on middle tier. You created this account in step 4. -out is the output file that stores the service key.

   Again, be sure to replace the example values given with values suitable for your installation. These values appear in boldface in the example.

   Note: If ktpass is not found on your computer, download the Windows resource kit to obtain the utility.

7. Copy or FTP the keytab file, sso.keytab, created in step 4, to the single sign-on middle tier, placing it in $ORACLE_HOME/j2ee/OC4J_SECURITY/config.

   Be sure to give the Web server uid on the single sign-on middle tier read permission for the file.

Configure the Single Sign-On Server to Use the Sun JAAS Login Module

1. Modify $ORACLE_HOME/opmn/conf/opmn.xml to include the following command line parameters for JVM:

   -Djavax.security.auth.useSubjectCredsOnly=false
   
   -Doracle.security.jazn.config=$ORACLE_HOME/j2ee/OC4J_
   SECURITY/config/jazn.xml
   
   

   These configurations should be added to the OC4J_SECURITY process configuration section of opmn.xml. Here is an example configuration for the OC4J_SECURITY process in the file.

   <process-type id="OC4J_SECURITY" module-id="OC4J">
   .
   .
   .
   <data id="java-options" value="-server -Djava.security.policy=$ORACLE_
   HOME/j2ee/OC4J_SECURITY/config/java2.policy -Djava.awt.headless=true 
   -Xmx512m -Djavax.security.auth.useSubjectCredsOnly=false 
   -Doracle.security.jazn.config=$ORACLE_HOME/j2ee/OC4J_
   SECURITY/config/jazn.xml"/>
   .
   .
   .
   </process-type>
   
   

2. Modify $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn.xml to point to an XML provider.

   <jazn provider="XML" location="./jazn-data.xml" />
   
   

3. Add the entry that follows to $ORACLE_HOME/j2ee/OC4JSECURITY/ config/jazn-data.xml. This step configures the single sign-on server to use Krb5LoginModule, the Sun JAAS login module.

   In the XML entry, KeyTab designates the location of the keytab file. principal is the service principal name for the single sign-on server. For consistency, the example keytab file and principle have been retained in the entry. Be sure to replace the values that appear in boldface with actual values.

   You can either cut and paste the entry provided here or copy and paste the sample file, $ORACLE_HOME/sso/conf/wna-jazn-data.xml.

   <jazn_data>
     <jazn-loginconfig>
     .
     .
     .
       <application>
         <name>com.sun.security.jgss.accept</name>
         <login-modules>
         <login-module>
           <class>com.sun.security.auth.module.Krb5LoginModule</class>
           <control-flag>required</control-flag>
           <options>
             <option>
               <name>debug</name>
               <value>false</value>
             </option>
             <option>
               <name>addAllRoles</name>
               <value>true</value>
             </option>
             <option>
               <name>useKeyTab</name>
               <value>true</value>
             </option>
             <option>
               <name>keyTab</name>
               <value>Oracle_home/j2ee/OC4J_SECURITY/config/sso.keytab</value>
             </option>
             <option>
               <name>principal</name>
               <value>HTTP/sso.acme.com</value>
             </option>
             <option>
               <name>doNotPrompt</name>
               <value>true</value>
             </option>
             <option>
               <name>storeKey</name>
               <value>true</value>
             </option>
           </options>
         </login-module>
         </login-modules>
       </application>
       .
       .
       .
     </jazn-loginconfig>
   </jazn-data>
   

Configure the Single Sign-On Server as a Secured Application

1. Add the entry that follows to $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/WEB-INF/web.xml.

   Cut and paste the entry provided here or copy and paste the sample file located at $ORACLE_HOME/sso/conf/wna-web.xml.

   <web-app>
   .
   .
   .
     <security-role>
       <role-name>{{PUBLIC}}</role-name>
     </security-role>
     <security-constraint>
       <web-resource-collection>
         <web-resource-name>SSO</web-resource-name>
         <url-pattern>auth</url-pattern>
       </web-resource-collection>
       <!-- authorization -->
       <auth-constraint>
         <role-name>{{PUBLIC}}</role-name>
       </auth-constraint>
     </security-constraint>
     <!-- authentication -->
     <login-config>
       <auth-method>BASIC</auth-method>
     </login-config>
     .
     .
     .
   </web-app>
   
   

2. Configure a Kerberos service name for the single sign-on server in $ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/ orion-application.xml. You do this by adding the entry that follows. Be sure to replace the values that appear in boldface with actual values.

   <orion-application>
   .
   .
   .
     <security-role-mapping name="{{PUBLIC}}">
       <group name="{{PUBLIC}}" />
     </security-role-mapping>
     <jazn provider="LDAP" location="ldap://directory_server.domain:port"    
     default-realm="default_realm_in_Oracle_Internet_Directory">
     <jazn-web-app auth-method="WINDOWS_KERBEROS_AUTH"/>
     <property name="kerberos-servicename" value="HTTP@sso.acme.com"/>
     </jazn>
     .
     .
     .
   </orion-application>
   
   

3. Configure the single sign-on server to use the Kerberos authentication plugin. In $ORACLE_HOME/sso/conf/policy.properties, designate the Kerberos plugin as the default authentication plugin.

   Edit the MediumSecurity_AuthPlugin parameter to look like this:

   MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOKerbeAuth
   
   

4. Restart the single sign-on middle tier. For instructions, see "Stopping and Starting the Single Sign-On Middle Tier" in Chapter 2.

Configure the End User Browser

Configure Internet Explorer to use Windows native authentication. Depending upon your browser, configuration is a three-part process:

• Internet Explorer 5.0 and Greater

• Internet Explorer 6.0 Only

• Login Scenarios

Internet Explorer 5.0 and Greater

1. Click the following in succession:
   • Tools

   • Internet Options

   • Security

   • Local intranet

   • Sites

2. In the Local intranet dialog box, choose Include all sites that bypass the proxy server; then click Advanced.

3. In the advanced version of the Local intranet dialog box, enter the URL of the single sign-on middle tier. Here is an example:

   http://sso.mydomain.com
   
   

4. Click OK to exit the Local intranet dialog boxes.

5. In the Internet Options dialog box, click the Security tab; then click Local intranet; then Custom Level.

6. In the Security Settings dialog box, scroll down to the User Authentication section and then choose Automatic logon only in Intranet zone.

7. Click OK to exit the Security Settings dialog box.

8. Click the following in succession:
   • Tools

   • Internet Options

   • Connections

9. On the Connections tab, click LAN Settings.

10. Check that you have the correct address and port number for the proxy server; then click Advanced.

11. In the Proxy Settings dialog box, in the Exceptions section, make sure that you have entered the domain name for the single sign-on server (acme.com in the example).

12. Click OK to exit the Proxy Settings dialog box.

Internet Explorer 6.0 Only

If you are using Internet Explorer 6.0, perform steps 1 through 12 in "Internet Explorer 5.0 and Greater"; then add the following steps:

1. Click the following in succession:
   • Tools

   • Internet Options

   • Advanced

2. On the Advanced tab, scroll down to the Security section.

3. Choose Enable Integrated Windows Authentication (requires restart).

Fallback Authentication

Only browsers that are Internet Explorer 5.0 or greater support SPNEGO-Kerberos authentication. OracleAS Single Sign-On provides fallback authentication support for unsupported browsers such as Netscape Communicator. Depending upon the type of browser and how it is configured, the user is presented with the single sign-on login form or the HTTP basic authentication dialog box. In either case, he or she must provide a user name and password. The user name consists of the Kerberos realm name and the user ID. It must be entered this way:

domain_name\user_id 

For example:

acme\jdoe

Note that the user name and password are case sensitive. Note, too, that password policies for Microsoft Active Directory do not apply.

Fallback authentication is performed against Microsoft Active Directory, using an external authentication plugin for Oracle Internet Directory.

Notes: HTTP basic authentication does not support logout. To clear their credentials from the browser cache, users must close all opened browsers. Alternatively, they can log out of the Windows computer. In cases where basic authentication is invoked, users must set their language preference manually in Internet Explorer. This is accomplished by navigating to Tools -> Internet Options -> Languages and then adding the desired language.

Login Scenarios

Users may encounter a number of different login behaviors within Internet Explorer depending upon which version they are using. Table 8-1 shows under what circumstances automatic sign-on and fallback authentication are invoked.

Table 8-1 Single Sign-On Login Options in Windows Internet Explorer

Browser Version	Desktop Platform	Desktop Authentication Type	Integrated Authentication in Internet Explorer Browser	Single Sign-On Login Type
>= 5.0.1	Windows 2000/XP	Kerberos version 5	On	Automatic sign-on
>= 5.0.1 and < 6.0	Windows 2000/XP	Kerberos version 5	Off	Single sign-on
>= 6.0	Windows 2000/XP	Kerberos version 5 or NTLM	Off	HTTP basic authentication
>= 5.0.1 and < 6.0	Windows NT/2000/XP	NTLM	On or off	Single sign-on
>= 6.0	NT/2000/XP	NTLM	On	Single sign-on
>= 5.0.1	Windows 95, ME, Windows NT 4.0	N/A	N/A	Single sign-on
< 5.0.1	N/A	N/A	N/A	Single sign-on
All other browsers	All other platforms	N/A	N/A	Single sign-on