3 Windows Native Authentication

To complete the integration of Microsoft Active Directory with Oracle Collaboration Suite, you must deploy OracleAS Single Sign-On for automatic sign-on, also known as Windows native authentication. The terms automatic sign-on and Windows native authentication are synonymous. For the remainder of the document, the latter term is used.

The following topics guide you through the process of deploying Windows native authentication from a Windows desktop:

• 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 3-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 3-1 Flow for Windows Native Authentication

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

• Verify That Synchronization and the Authentication Plugin Are Working

• Configure the Single Sign-On Server

• Configure the End User Browser

• Reconfigure Local Accounts

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" in the Oracle Application Server Single Sign-On Administrator's Guide 10g (9.0.4). 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 the Oracle Internet Directory Administrator's Guide.

Configure Oracle Internet Directory to Use Windows Authentication Plugin

See the Oracle Internet Directory Administrator's Guide.

Verify That Synchronization and the Authentication Plugin Are Working

Verify that you have synchronized user entries between the two directories; then verify that the Windows authentication plugin is working. You perform this step by trying to log in to the single sign-on server:

1. Go to the login page:

   http://host:port/pls/orasso
   
   

2. Enter your user name in this format:

   user_name@active_directory_domain
   
   

   then enter your password.

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 the krb5.conf file/etc/krb5/krb5.conf (system_drive:\krb5\krb5 on Windows) 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. The file is found at /etc/krb5 on UNIX systems and at system_drive:\krb5 on Windows systems.

   
   

   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. On Windows systems, the services file is found at system_drive:\WINNT\system32\drivers\etc. The service name is Kerberos. Typically the port is set to 88/udp and 88/tcp on the Windows 2000 server. When added correctly to the 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 hosts file, located in the same directory as the services 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/[e-mail] -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 four command line parameters for JVM:

   -Djavax.security.auth.useSubjectCredsOnly=false
   -Doracle.security.jazn.config=$ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn.xml
   -Djava.security.krb5.realm=default_realm_in_Active_Directory 
   -Djava.security.krb5.kdc=Active_Directory_host_name
   
   

   These parameters should be added to the OC4J_SECURITY process configuration section of opmn.xml. Add them as values to both the "start-parameters" and "stop-parameters" category id tags.

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

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

   Comment the following line if it is not commented already:

   <jazn provider="LDAP" location="ldap://myoid.us.oracle.com:389" />
   
   

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. You may use the sample file in $ORACLE_HOME/sso/conf instead.

   <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="[e-mail]"/>
     </jazn>
     .
     .
     .
   </orion-application>
   

   
   

   Note: If your directory has just one realm, you may omit the default-realm parameter. If the directory has more than one realm, enter only the realm name, not the realm DN. If, for example, your realm has a DN of dc=uk,dc=oracle,dc=com, the realm name is uk.

   
   

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 of the Oracle Application Server Single Sign-On Administrator's Guide 10g (9.0.4).

Configure the End User Browser

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

• Internet Explorer 5.0 and Greater

• Internet Explorer 6.0 Only

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

Reconfigure Local Accounts

Now that you have successfully configured Windows native authentication, you must reconfigure accounts for orcladmin and other local Windows users. These are users whose accounts are in Oracle Internet Directory. If you omit this task, these users will not be able to log in.

Use the administration console for Oracle Internet Directory to perform these steps:

1. Add the orclADUser class to the local user entry in Oracle Internet Directory.

2. Add the login ID of the local user to the orclSAMAccountName attribute in the user's entry. For example, the login ID of the orcladmin account is orcladmin.

3. Add the local user to the exceptionEntry property of the external authentication plugin.

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, you are presented with the single sign-on login form or the HTTP basic authentication dialog box. In either case, you 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 3-1 shows under what circumstances automatic sign-on and fallback authentication are invoked.

Table 3-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