18 Integrating with Microsoft Active Directory

Step 1: Planning Your Integration

Plan your integration by reading Chapter 16, "Third-Party Directory Integration Concepts and Considerations", particularly "Microsoft Active Directory Integration Concepts". Be sure to create a new profile by copying the existing Active Directory template profile by following the instructions in "Creating Synchronization Profiles".

Step 2: Configuring the Realm

Configure the realm by following the instructions in "Configuring the Realm".

Step 3: Customizing the Search Filter to Retrieve Information from Microsoft Active Directory

By default, Microsoft Active Directory Connector retrieves changes to all objects in the container configured for synchronization. If you are interested in retrieving only a certain type of change, for example only changes to users and groups, then you should configure an LDAP search filter. This filter screens out changes that are not required when Microsoft Active Directory Connector queries Microsoft Active Directory. The filter is stored in the searchfilter attribute in the synchronization profile.

In the sample profiles activeChgImp and activeImport, only groups and users are retrieved from Microsoft Active Directory. Computers are not retrieved. The value of the searchfilter attribute is set as: searchfilter=(|(objectclass=group)(&(objectclass=user)(!(objectclass=computer))).

You can use Oracle Enterprise Manager Fusion Middleware Control to customize the search filter.

To customize the search filter by using the Oracle Enterprise Manager Fusion Middleware Control:

1. Open a Web browser and enter the Oracle Enterprise Manager Fusion Middleware Control URL for your environment. The format of the Oracle Enterprise Manager Fusion Middleware Control URL is: https://host:port/em.

2. Log in to Oracle Enterprise Manager Fusion Middleware Control.

3. In the navigation panel on the left, click or expand the Identity and Access entry and then select the DIP component that contains the search filter you want to customize.

4. Click the DIP Server menu, point to Administration, and then click Synchronization Profiles. The Manage Synchronization Profiles Page appears.

5. On the Manage Synchronization Server page, select an existing profile and click Edit. The Edit Synchronization Profile page appears, opened to the General tab.

6. On the Edit Synchronization Profile page, select the Filtering tab.

7. In the Mapping tab page, in the Destination Matching Filter (orclODIPConDirMatchingFilter) and the Source Matching Filter (orclODIPOIDMatchingFilter) fields, enter the appropriate values for the searchfilter attribute. Instructions for specifying the searchfilter attribute are provided in the section "Filtering Changes with an LDAP Search".

8. Choose OK.

To customize the search filter by using the manageSyncProfiles command:

1. Enter the following command to customize the Connected Directory Matching Filter (orclODIPConDirMatchingFilter) attribute:

   manageSyncProfiles update -h host -p port -D WLS_login_ID
   -pf synchronization_profile_name -params "odip.profile.condirfilter 
   searchfilter=(|(objectclass=group)(objectclass=organizationalunit)(&(objectclas
   s=user)(!(objectclass=computer))))"
   

2. Enter the following command to customize the OID Matching Filter (orclODIPOIDMatchingFilter) attribute:

   manageSyncProfiles update -h host -p port -D WLS_login_ID
   -pf synchronization_profile_name -params "odip.profile.oidfilter 
   orclObjectGUID"
   

Step 4: Customizing the ACLs

Customize ACLs as described in "Customizing Access Control Lists".

Step 5: Customizing Attribute Mappings

When integrating with Microsoft Active Directory, the following attribute-level mapping is mandatory for all objects:

ObjectGUID:  :  : :orclObjectGUID:
ObjectSID:  :  : :orclObjectSID:

SAMAccountName:1: :user:orclADSAMAccountName: :orclADUser
userPrincipalName: : :user:orclADUserPrincipalName::orclADUser:userPrincipalName

SAMAccountName:1: :group:orclADSAMAccountName: :orclADGroup

In the preceding examples, SAMAccountName and userPrincipalName from Microsoft Active Directory are mapped to orclADSAMAccountName and orclADUserPrincipalName in Oracle Internet Directory.

Customize the attribute mappings by following the instructions in "Customizing Mapping Rules".

Step 6: Synchronizing with Multiple Microsoft Active Directory Domains

When synchronizing with multiple Microsoft Active Directory domains, you need separate import and export synchronization profiles for each domain in most cases. However, the profiles for each domain should be very similar. The only exception involves using Global Catalog with import synchronization profiles. In this case, you only need to create a single import synchronization profile for the entire Microsoft Active Directory forest. For more information, see "Configuration Required for Importing from Microsoft Active Directory to Oracle Internet Directory".

The best approach to creating separate import and export synchronization profiles for multiple domains is as follows:

1. Customize the import and export synchronization profiles for a single domain, using the procedures described earlier in this section.

2. Once you have finished customizing the import and export synchronization profiles for the first domain, use the copy operation of the manageSyncProfiles command to duplicate profiles, as follows:

   manageSyncProfiles copy -h host -p port -D WLS_login_ID
   -pf Original_Profile_Name -newpf New_Profile_Name
   

3. Use the update operation of the manageSyncProfiles command to customize the profiles for each additional Microsoft Active Directory domain, as follows:

   manageSyncProfiles update -h host -p port -D WLS_login_ID
   -pf Profile_Name -params "prop1 val1 prop2 val2 ..."
   

4. If necessary, update the connection details for each domain by following the instructions listed in "Configuring Connection Details".

5. Update the last change number in the import and export synchronization profiles for each domain by running the following command:

   manageSyncProfiles updatechgnum -h host -p port -D WLS_login_ID
   -pf Profile_Name
   

6. Repeat Steps 2 through 5 for each Microsoft Active Directory domain with which you need to synchronize.

Step 7: Synchronizing Deletions from Microsoft Active Directory

To synchronize deletions in Microsoft Active Directory with Oracle Internet Directory, you must grant the necessary privilege to the Microsoft Active Directory user account that the Oracle directory integration server uses to perform synchronizations with Microsoft Active Directory. Microsoft Active Directory deletions can be synchronized with Oracle Internet Directory by querying for them in Microsoft Active Directory. The way to do this depends on whether you are using the DirSync approach or the USN-Changed approach.

For the DirSync approach, the Microsoft Active Directory user account that the Oracle Directory Integration Platform uses to access Microsoft Active Directory must have Domain Administrative permissions, belong to the Domain Administrators group, or be explicitly granted Replicating Directory Changes permissions.

For the USN-Changed approach, the Microsoft Active Directory user account that the Oracle Directory Integration Platform uses to access Microsoft Active Directory must have "List Content" and "Read Properties" permission to the cn=Deleted Objects container of a given domain. In order to set these permissions, you must use the dsacls.exe command that is available with recent versions of Microsoft Active Directory Lightweight Directory Service (AD LDS), which was previously known as Active Directory Application Mode or ADAM.

Regardless of whether you are using the DirSync approach or the USN-Changed approach to synchronize deletions in Microsoft Active Directory with Oracle Internet Directory, if you create a matching filter for the ActiveImport profile (for the DirSync approach) or the ActiveChgImp profile (for the USN-Changed profile) be sure to include only the following key Microsoft Active Directory attributes:

• ObjectGUID

• ObjectSID

• ObjectDistName

• USNChanged

In you specify any attributes in a matching filter other than the preceding key attributes, deletions in Microsoft Active Directory are not propagated to Oracle Internet Directory.

Step 8: Synchronizing in SSL Mode

Configure the Microsoft Active Directory connector for synchronization in SSL mode by following the instructions in "Configuring the Third-Party Directory Connector for Synchronization in SSL Mode".

Step 9: Synchronizing Passwords

To synchronize password changes from Oracle Internet Directory to Microsoft Active Directory:

1. Configure Oracle Internet Directory, Oracle Directory Integration Platform, and Microsoft Active Directory to run in SSL server authentication mode.

2. Enable password synchronization from Oracle Internet Directory to Microsoft Active Directory by following the instructions in "Enabling Password Synchronization from Oracle Internet Directory to a Third-Party Directory".

3. Configure the Microsoft Active Directory connector to synchronize passwords by installing and configuring the Oracle Password Filter for Microsoft Active Directory, as described in Chapter 19, "Deploying the Oracle Password Filter for Microsoft Active Directory".

Step 10: Configuring the Microsoft Active Directory External Authentication Plug-in

Configure the Microsoft Active Directory external authentication plug-in by following the instructions in "Configuring External Authentication Plug-ins".

Step 11: Performing Post-Configuration and Administrative Tasks

Read Chapter 23, "Managing Integration with a Third-Party Directory" for information on post-configuration and ongoing administration tasks.

What are the System Requirements for Windows Native Authentication?

Windows Native Authentication is intended for intranet Web applications. Your intranet deployment must include the following:

• Windows 2000 server with Microsoft Active Directory

• Kerberos service account established for OracleAS Single Sign-On Server

• Oracle Application Server 11g Release 1 (11.1.1) infrastructure installed

  Note:

  Although the sample configurations in this section are for UNIX/Linux, Oracle Fusion Middleware can also be installed on Microsoft Windows.

• OracleAS Single Sign-On Server middle tier configured to use a Kerberos realm

• Synchronization of Microsoft Active Directory with Oracle Internet Directory

• Oracle Internet Directory configured to use the Windows external authentication plug-in

Avoiding HTTP-401 Errors and Repeat Login Challenges for External Users

If only one Single Sign-On (SSO) server is configured, you cannot avoid the HTTP-401 response from the SSO server that is configured for Windows Native Authentication (WNA) for a website that can be accessed both internally by users who are Windows authenticated and also externally by users who are not in a Windows domain. If you are planning to use Windows Native Authentication, consider using a configuration comprised of two SSO servers, each with different IP addresses, to avoid HTTP-401 errors being sent to external users' browsers and being presented with multiple login challenges.

Configuring Windows Native Authentication with a Single Microsoft Active Directory Domain

To set up Windows Native Authentication, configure Oracle Internet Directory, the OracleAS Single Sign-On Server, and the user's browser by performing the following tasks in the order listed.

Task 1: Configure the OracleAS Single Sign-On Server

To configure the single sign-on server, complete the tasks described in these topics:

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

• Update the krb5.conf File

• Run the OracleAS Single Sign-On Server Configuration Assistant on each Oracle Application Server Single Sign-On Host

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

Create a service account for the OracleAS Single Sign-On Server in Microsoft Active Directory, then create a keytab file for the server, and map the service principal (the server) to the account name. The keytab file stores the server's secret key. This file enables the server to authenticate to the KDC. The service principal is the entity, in this case, the single sign-on server, to which the KDC grants session tickets.

1. Synchronize system clocks. The OracleAS Single Sign-On Server middle tier and the Windows 2000 server must match. If you omit this step, then authentication fails because there is a difference in the system time.Be sure the time, the date, and the time zones are synchronized.

2. Check the port number of the Kerberos server on the Microsoft Active Directory host. The port where the Kerberos server listens is selected 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 are:

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

3. 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, which refers to the physical host name of the Oracle Application Server Single Sign-On server, must appear after the IP address and before the short name. The following is an example of a correct entry:

   130.111.111.111 sso.MyCompany.com sso loghost
   

4. Perform the following tasks to create a user account and keytab file in Microsoft Active Directory that will be used by the logical Oracle Application Server Single Sign-On host:

   1. Log in to the Microsoft Active Directory Management tool on the Windows 2000 server, then choose Users, then New, then user.

      Enter the name of the OracleAS Single Sign-On Server host, omitting the domain name. For example, if the host name is sso.MyCompany.com, then enter sso. This is the account name in Microsoft Active Directory.

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

   2. Create a keytab file for the OracleAS Single Sign-On Server, and map the account name to the service principal name.You perform both tasks by running the following command on the Windows 2000 server:

      C:> Ktpass -princ HTTP/[email protected] -pass password -mapuser sso -out sso.keytab
      

      The -princ argument is the service principal. Specify the value for this argument by using the format HTTP/single_sign-on_host_name@KERBEROS_REALM_NAME. Note that HTTP and the Kerberos realm must be uppercase.

      Note that single_sign-on_host_name can be either the OracleAS Single Sign-On Server host itself or the name of a load balancer where multiple OracleAS Single Sign-On Server middle tiers are deployed. MyCompany.com is a fictitious Kerberos realm in Microsoft Active Directory. The user container is located within this realm. The -pass argument is the account password, the -mapuser argument is the account name of the OracleAS Single Sign-On Server middle tier, and the -out argument is the output file that stores the service key.

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

      Note:

      • If the Ktpass is not found on your computer, then download the Windows Resource Kit from Microsoft to obtain the utility.

      • The default encryption type for Microsoft Kerberos tickets is RC4-HMAC. Microsoft also supports DES-CBC and DES-CBC-MD5, two DES variants used in MIT-compliant implementations. Ktpass converts the key type of the KDC account from RC4_HMAC to DES.

5. For each Oracle Application Server Single Sign-On host, copy or FTP the keytab file, sso.keytab to the OracleAS Single Sign-On Server middle tier, placing it in $ORACLE_HOME/j2ee/OC4J_SECURITY/config. If you use FTP, be sure to transfer the file in binary mode.

   Be sure to give the Web server a unique identifier (UID) on the OracleAS Single Sign-On Server middle tier and to grant read permission for the file.

Update the krb5.conf File

You must update the krb5.conf file (krb5.ini on Windows) with the following information. If you do not update the krb5.conf file with the following information, the kinit test of the newly generated keytab file will fail, and the keytab file will fail when used for Windows Native Authentication in OracleAS Single Sign-On Server.

Update the krb5.conf file with the following information:

• The default realm of the Active Directory, for example: AD.UK.ORACLE.COM

• The hostname of the server where Active Directory resides, for example: active.uk.oracle.com

• The hostname of the server where OracleAS Single Sign-On Server resides, for example: sso.uk.oracle.com

For example, replace the marked-up text in the following text with the relevant default realm and KDC hostname, that is, the server where Active Directory resides:

[libdefaults]
        default_realm = AD.UK.ORACLE.COM 
                clockskew = 300
[realms]
                AD.UK.ORACLE.COM = {
                                 kdc = active.uk.oracle.com
                }
[domain_realm]
               .uk.oracle.com = AD.UK.ORACLE.COM 

Run the OracleAS Single Sign-On Server Configuration Assistant on each Oracle Application Server Single Sign-On Host Running the ossoca.jar tool at this point does the following:

• Configures the Oracle Application Server Single Sign-On server to use the Sun JAAS login module

• Configures the server as a secured application

To run the ossoca.jar tool on the OracleAS Single Sign-On Server middle tier:

1. Back up the following configuration files:

   • $ORACLE_HOME/sso/conf/policy.properties

   • $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn.xml

   • $ORACLE_HOME/opmn/conf/opmn.xml

   • $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn-data.xml

   • $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/WEB-INF/web.xml

   • $ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/orion-application.xml

2. Run the ossoca.jar tool:

   • UNIX/Linux:

     $ORACLE_HOME/sso/bin/ssoca
     wna -mode sso
     -oh $ORACLE_HOME
     -ad_realm AD_REALM
     -kdc_host_port kerberos_server_host:port
     -verbose
     

   • Windows:

     %ORACLE_HOME%\jdk\bin\java -jar %ORACLE_HOME%\sso\lib\ossoca.jar
     wna -mode sso
     -oh %ORACLE_HOME%
     -ad_realm AD_REALM
     -kdc_host_port kerberos_server_host:port
     -verbose
     

   AD_REALM is the Kerberos realm in Microsoft Active Directory. This is the user container. Note from the syntax that this value must be entered in uppercase. The default port number for the KDC is usually 88. To confirm this, see step 2 in the section Set Up a Kerberos Service Account for the OracleAS Single Sign-On Server.

3. Step 2 shuts down the OracleAS Single Sign-On Server. Restart it:

   $ORACLE_HOME/opmn/bin/opmnctl startall
   

Task 2: Configure Internet Explorer for Windows Native Authentication

Configure Internet Explorer to use Windows Native Authentication. How you do this depends on which version you have.

• Internet Explorer 5.0 and Later

• Internet Explorer 6.0 Only

Internet Explorer 5.0 and Later

To configure Internet Explorer 5.0 and later, perform the following steps:

1. From the menu bar, select Tools, then, from the Tools menu, select Internet Options.

2. In the Internet Options dialog box, select the Security tab.

3. On the Security tab page, select Local Intranet, then select Sites.

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

5. In the advanced version of the Local intranet dialog box, enter the URL of the OracleAS Single Sign-On Server middle tier. For example:

   http://sso.mydomain.com
   

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

7. In the Internet Options dialog box, select the Security tab; then choose Local intranet; then choose Custom Level.

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

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

10. From the menu bar, select Tools, then, from the Tools menu, select Internet Options.

11. In the Internet Options dialog box, select the Connections tab.

12. On the Connections tab page, choose LAN Settings.

13. Confirm that the correct address and port number for the proxy server are entered, then choose Advanced.

14. In the Proxy Settings dialog box, in the Exceptions section, enter the domain name for the OracleAS Single Sign-On Server (MyCompany.com in the example).

15. 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 Later"; then perform the following steps:

1. From the menu bar, select Tools, then, from the Tools menu, select Internet Options.

2. In the Internet Options dialog box, select the Advanced tab.

3. On the Advanced tab page, scroll down to the Security section.

4. Select Enable Integrated Windows Authentication (requires restart).

Task 3: Reconfigure Local Accounts

After configuring Windows Native Authentication, you must reconfigure accounts for the Oracle Internet Directory administrator (orcladmin) and other local Windows users whose accounts are in Oracle Internet Directory. If you omit this task, then these users will not be able to log in.

Use the Oracle Directory Services Manager interface 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 plug-in.

Configuring Windows Native Authentication with Multiple Microsoft Active Directory Domains or Forests

This section describes how to configure Windows Native Authentication with multiple Microsoft Active Directory domains or forests in the following types of deployments:

• Parent-child Microsoft Active Directory domains

• Microsoft Active Directory domains in the same forest with an established tree-root trust type

• Domains in different forests with an established forest trust type

  Note:

  Forest trust types are only supported in Windows Server 2003 and later versions of Windows operating systems.

To configure Windows Native Authentication with multiple Microsoft Active Directory domains or forests, perform the following tasks in the order listed:

Task 1: Verify that Trust is Established Between the Microsoft Active Directory Domains

Refer to your Microsoft Active Directory documentation for information on how to verify trust between multiple Microsoft Active Directory domains.

Task 2: Enabling Windows Native Authentication with Oracle Application Server Single Sign-On through a Load Balancer or Reverse Proxy

Configure the Oracle Application Server Single Sign-On server to run behind a load balance or through reverse proxy by following the instructions in the advanced deployment options chapter of the Oracle Fusion Middleware Administrator's Guide for Oracle Single Sign-On

Task 3: Configure the OracleAS Single Sign-On Server

Configure each Oracle Application Server Single Sign-On server by following the instructions in "Task 1: Configure the OracleAS Single Sign-On Server". Be sure to use the same Microsoft Active Directory realm and corresponding key distribution center (KDC) when configuring each physical Oracle Application Server Single Sign-On server instance. Also, be sure to use the load balance or reverse proxy name as the logical Oracle Application Server Single Sign-On host name.

Task 4: Configure Internet Explorer for Windows Native Authentication

Configure the Oracle Application Server Single Sign-On server by following the instructions in "Task 2: Configure Internet Explorer for Windows Native Authentication".

Implementing Fallback Authentication

The only browsers that support SPNEGO-Kerberos authentication are Internet Explorer 5.0 or later. OracleAS Single Sign-On Server 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 OracleAS Single Sign-On Server login form or the HTTP basic authentication dialog box. In either case, the user must provide a user name and password. The user name consists of the Kerberos realm name and the user ID. The default way to enter the user name is shown in the following example.

domain_name\user_id 

The following example, based on the example provided in "Set Up a Kerberos Service Account for the OracleAS Single Sign-On Server", illustrates how to enter the user name.

MyCompany.COM\jdoe

Note that the user name and password are case sensitive. Additionally, password policies for Microsoft Active Directory do not apply. You can configure a different synchronization profile by using the Oracle Directory Integration Platform. If you do, the login format just provided does not apply.

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

Understanding the Possible Login Scenarios

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