Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform
11g Release 1 (11.1.1)
E10031-02
  Go To Table Of Contents
Contents		 Go To Index
Index
Previous
Previous 		 Next
Next		  

18 Integrating with Microsoft Active Directory

This chapter outlines the procedures for integrating Oracle Identity Management with Microsoft Active Directory in a production environment. It contains these topics:


Note:

This chapter assumes familiarity with the chapter on Oracle Internet Directory concepts and architecture in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. It also assumes familiarity with the earlier chapters in this book, especially:

If you are configuring a demonstration of integration with Microsoft Active Directory, then see the Oracle By Example series for Oracle Identity Management Release 11g Release 1 (11.1.1), available on Oracle Technology Network at http://www.oracle.com/technology/

Verifying Synchronization Requirements for Microsoft Active Directory

Before configuring basic or advanced synchronization with Microsoft Active Directory, ensure that your environment meets the necessary synchronization requirements by following the instructions in "Verifying Synchronization Requirements".

Configuring Basic Synchronization with Microsoft Active Directory

You can use Oracle Enterprise Manager Fusion Middleware Control or the manageSyncProfiles command to configure synchronization profiles for Microsoft Active Directory. Refer to Chapter 7, "Managing Directory Synchronization Profiles" for more information.

Configuring Advanced Integration with Microsoft Active Directory

When you install Oracle Directory Integration Platform, sample import and export synchronization profiles are automatically created for each of the supported third-party directories. The sample synchronization profiles created for Microsoft Active Directory are:


Notes:

  • Whether you use ActiveImport or ActiveChgImp depends on the method you chose for tracking changes, either DirSync or USN-Changed.

  • If you establish integration between Active Directory and Oracle Internet Directory for both exporting and importing users, then you must customize the ActiveExport search filter to prevent Oracle Directory Integration Platform from exporting or importing users twice. The following is an example of a customized ActiveExport search filter that may be used when both export and import operations are enabled for the same Active Directory instance:

    odip.profile.condirfilter ="searchfilter=(|(objectclass= group)(objectclass= organizationalunit)(&(objectclass=user) (!(objectclass=computer))))"


See Also:

"Step 3: Customizing the Search Filter to Retrieve Information from Microsoft Active Directory" for information on customizing the search filter

You can also use the expressSyncSetup command or Oracle Enterprise Manager Fusion Middleware Control to create additional synchronization profiles. The import and export synchronization profiles created during the install process or with expressSyncSetup are only intended as a starting point for you to use when deploying your integration of Oracle Internet Directory and Microsoft Active Directory. Because the default synchronization profiles are created using predefined assumptions, you must further customize them for your environment by performing the following steps in the order listed:

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"

Note:

All attributes specified in the searchfilter attribute should be configured as indexed attributes in Microsoft Active Directory.


See Also:

The appendix about the LDAP filter definition in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for instructions on configuring an LDAP search filter

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:

Example 18-1 Attribute-Level Mapping for the User Object in Microsoft Active Directory

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

Example 18-2 Attribute-Level Mapping for the Group Object in Microsoft Active Directory

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


Note:

Be sure to perform attribute and DN mapping before attempting to synchronize with multiple domains.

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.


See Also:

Article ID 303972 at http://support.microsoft.com for information on how to grant 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.


See Also:

  • Article ID 230113 at http://support.microsoft.com for more information on deleting items from Microsoft Active Directory

  • The attribute reference chapter in Oracle Fusion Middleware User Reference for Oracle Identity Management for a listing of the standard LDAP attributes that Oracle Internet Directory supports

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.

Using DirSync Change Tracking for Import Operations

By default, the import synchronization profile created with expressSyncSetup uses the USN-Changed approach for tracking changes. If you want to use the DirSync change tracking approach, be sure to perform the steps in this section before beginning synchronization.


Note:

You may want to back up your current import synchronization profile before performing the following procedures. You can create a backup copy of a profile by using the copy operation of the manageSyncProfiles command.

To modify the import synchronization profile to use the DirSync change tracking approach:

  1. You can use the activeimp.cfg.master file, located in your $ORACLE_HOME/ldap/odi/conf directory, to change the import synchronization profile from the USN-Changed approach to DirSync. Use the following command to update the profile:

    manageSyncProfiles update -h host -p port -D WLS_login_ID -pf Profile_Name 
-params "odip.profile.configfile $ORACLE_HOME/ldap/odi/conf/activeimp.cfg.master"

  2. Update the last change number by running the following command:

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

Configuring Windows Native Authentication

This section describes the system requirements and tasks for configuring Windows Native Authentication. It contains these topics:

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.


See Also:

Refer to Note 417620.1 in My Oracle Support (formerly MetaLink) for more information. You can access My Oracle Support at: http://metalink.oracle.com/

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

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/sso.MyCompany.com@MyCompany.com -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:


Note:

The krb5.conf file is case sensitive.		 

[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

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:


See:

The Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information about using Oracle Directory Services Manager to configure Oracle Internet Directory.

  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.


Note:

With multiple Microsoft Active Directory forests, the Oracle Application Server Single Sign-On server's logical host name must belong to one of the Microsoft Active Directory domains. For example, assume you have two Microsoft Active Directory forests and each forest contains a single domain. The domain in the first forest is named engineering.mycompany.com and the domain in the second forest is named finance.mycompany.com. The Oracle Application Server Single Sign-On server's logical host name must reside in either the engineering.mycompany.com or the finance.mycompany.com domain.

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.


Note:

  • HTTP basic authentication does not support logout. To clear credentials from the browser cache, users must close all open browser windows. 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. Select Internet Options from the Tools menu, select Languages, and then enter the desired language.

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.

Table 18-1 Single Sign-On Login Options in Internet Explorer

Browser Version Desktop Platform Desktop Authentication Type Integrated Authentication in Internet Explorer Browser OracleAS Single Sign-On Server Login Type

5.0.1 or later

Windows 2000/XP

Kerberos V5

On

Automatic sign-on

5.0.1 or later but earlier than 6.0

Windows 2000/XP

Kerberos V5

Off

Single sign-on

6.0 or later

Windows 2000/XP

Kerberos V5

or NTLM

Off

HTTP basic authentication

5.0.1 or later but earlier than 6.0

Windows NT/2000/XP

NTLM

On or off

Single sign-on

6.0 or later

NT/2000/XP

NTLM

On

Single sign-on

5.0.1 or later

Windows 95, ME, Windows NT 4.0

Not applicable

Not applicable

Single sign-on

Earlier than 5.0.1

N/A

Not applicable

Not applicable

Single sign-on

All other browsers

All other platforms

Not applicable

Not applicable

Single sign-on

Configuring Synchronization of Oracle Internet Directory Foreign Security Principal References with Microsoft Active Directory

This section explains how to synchronize Oracle Internet Directory foreign security principal references with Microsoft Active Directory.

Although Microsoft Active Directory stores information for group members in a trusted domain as foreign security principal references, Oracle Internet Directory stores the DNs of these members as they appear in Oracle Internet Directory. This results in a mismatch between an entry and its value as a member of a group. The relationship between a user and a group cannot be directly established in Oracle Internet Directory.

To establish the relationship between users and groups, the member DNs that refer to the foreign security principals must be replaced by the DNs of the entries during the synchronization of such groups. This is called resolving foreign key references.


Note:

Synchronization of foreign security principal references is supported only on Windows 2003.

Example 18-3 How Foreign Key References Are Resolved

The example in this section illustrates how foreign key references are resolved.Assume that there are three domains: A, B and C.

Domain A has a one-way non-transitive trust to Domain B. It can have foreign security principal references for users and groups from Domain B.
Domain A has a one-way non-transitive trust to Domain C. It can have foreign security principal references for users and groups from Domain C.
Domain B has a one-way non-transitive trust to Domain C. It can have foreign security principal references for users and groups from Domain C.

In this example, the one-way non-transitive trusts are from Domain A to Domain B, from Domain A to Domain C, and from Domain B to Domain C.

Tasks to Resolve Foreign Key References

This section explains the steps for resolving foreign key references.

Task 1: Update Agent Configuration Information For each profile that can have foreign security principal references, perform the following steps. The sample configuration files referred further are available in $ORACLE_HOME/ldap/odi/samples directory.

  1. Copy the activeimp.cfg.fsp file. The following is an example of the activeimp.cfg.fsp file:

    [INTERFACEDETAILS]
   Package: gsi
   Reader: ActiveReader
[TRUSTEDPROFILES]
   prof1 : <Name of the profile1>
   prof2 : <Name of the profile2>
[FSPMAXSIZE]
   val=10000

    The preceding example assumes you are using the DirSync change tracking approach. If you are using the USN-Changed approach for tracking changes, assign a value of ActiveChgReader to the Reader parameter.

  2. In the activeimp.cfg.fsp file, under the [TRUSTEDPROFILES] tag, specify the profile names of the other domains that have foreign security principal references in this domain.

    Referring to Example 18-3, agent configuration information for Domain A contains the following:

    [INTERFACEDETAILS]
   Package: gsi
   Reader: ActiveReader
[TRUSTEDPROFILES]
   prof1: profile_name_for_domain_B
   prof2: profile_name_for_domain_C

    Agent configuration information for domain B contains the following:

    [INTERFACEDETAILS]
   Package: gsi
   Reader: ActiveReader
[TRUSTEDPROFILES]
   prof1: profile_name_for_domain_C

    Agent configuration information for domain C has no changes because domain C has no foreign key references.

  3. Under the [FSPMAXSIZE] tag, specify the foreign security principal cache size. This can be the average number of foreign security principals you can have. A sample value of 1000 is specified in the activeimp.cfg.fsp file.

  4. Load the new agent configuration information file by using the update operation of the manageSyncProfiles command as follows:

    manageSyncProfiles update -h host -p port -D WLS_login_ID
-pf profile_name_for_domain_A_or_B -params "odip.profile.configfile activeimp.cfg.fsp"

  5. Repeat this task for every profile of interest.

Task 2: Modify the Input Data Before Bootstrapping to Resolve the Foreign Security Principal References To do this, perform the following steps:

  1. Get the LDIF dump from the Microsoft Active Directory with appropriate filtering so that the resultant LDIF file contains only the required objects, for example users and groups.


    Note:

    The command to dump entries from Microsoft Active Directory to Oracle Internet Directory is ldifde. This command can be run only from a Microsoft Windows environment.

  2. Resolve the foreign security principal references by entering the following command:

    $ORACLE_HOME/ldap/odi/admin/fsptodn 
host=oid_host port=oid_port
dn= OID_privileged_DN (that is, superuser or dipadmin user)pwd=OID_password
profile=profile_name_for_domain_A_or_B
infile=input_filenameo_of_the_LDIF_dump_from_Active_Directory
outfile=output_filename
[sslauth=0|1]

    By default, host is set to local_host, port is set to 3060, and sslauth is set to 0.


    Note:

    You can verify the successful execution of the command by verifying that the output file contains no references to cn=foreignsecurityprincipals in the member attribute. This command performs no attribute-level mapping other than resolving foreign security principal references.

  3. Use the syncProfileBootstrap command to bootstrap the data from Microsoft Active Directory to Oracle Internet Directory.


See Also:

"Bootstrapping Data Between Directories"

Task 3: Update the Mapping Rules to Resolve the Foreign Security Principals During Synchronization After bootstrapping, modifications to groups must be reflected in Oracle Internet Directory with the correct group membership values. The fsptodn mapping rule enables you to do this when you synchronize. Modify this mapping rule in every profile that needs foreign security principal resolution. Referring to Example 18-3, the mapping rules must be modified for Domains A and B.

If you do not have DN mapping, then change your mapping rule for the member attribute to the following:

member: : :group:uniquemember: :groupofUniqueNames: fsptodn(member)

If you have DN mapping, then change the mapping rules as follows:

  1. Add the DN mapping rules corresponding to each of the trusted domains. This is used to resolve the correct domain mapping. Referring to Example 18-3, the domainrules in the mapping file for Domain A should have content similar to the following:

    DOMAINRULES
<Src Domain A >:<Dst domain A1 in OID>
<Src Domain B >:< Dst domain B1 in OID>
<Src Domain C>:<Dst domain C1 in OID>

  2. Change your mapping rule for the member attribute to:

    member:::group:uniquemember::groupofUniqueNames:dnconvert(fsptodn(member))

  3. Upload the mapping file for the different profiles using the update operation of the manageSyncProfiles command, as follows:

    manageSyncProfiles update -h host -p port -D WLS_login_ID
-pf Profile_Name -file File_Name

Switching to a Different Microsoft Active Directory Domain Controller in the Same Domain

This section explains how to change the Microsoft Active Directory domain controller to which changes are exported. There are two methods, one for the USN-Changed approach and the other for the DirSync approach.

How to Change the Microsoft Active Directory Domain Controller by Using the USN-Changed Approach

If you are using the USN-Changed approach, then perform the following:

  1. Disable the current running profile. Modify the Microsoft Active Directory host connection information, that is, host, port, user, password, to point to the new host. Usually, the host name is the only item that you need to update.

  2. Obtain the current value of the highestCommittedUSN by searching the new domain controller's root DSE for the current highest USNChanged value (attribute value of the highestCommittedUSN attribute of the root DSE):

    ldapsearch -h host -p port -b "" -s base -D binddn -q \
"objectclass=*" highestCommittedUSN

    Note:

    You will be prompted for the password.

  3. Use Oracle Directory Integration Platform to run a full synchronization from Microsoft Active Directory.

    1. Run ldifde, the command to dump entries from Microsoft Active Directory to Oracle Internet Directory, using the intended LDAP search scope and search filter. Normally, the search filter should be the same as that specified in the running profile. For example, the following search filter is set in the sample properties file. Note that ldifde can be run only from a Microsoft Windows environment.

      searchfilter=(&(|(objectclass=user)(objectclass=organizationalunit))(!(objectclass=group)))

      Essentially, run ldifde with a search scope and search filter that retrieve all Oracle Internet Directory objects (entries) that were configured to be synchronized with Microsoft Active Directory by the running profile.

    2. Run Oracle Directory Integration Platform to upload the LDIF file generated in Step a using the same profile.

  4. After the full synchronization is completed, update the lastchangenumber attribute with the highestCommittedUSN value obtained in Step 2.

  5. Resume the normal synchronization, that is, incremental synchronization from Microsoft Active Directory using USNChanged attribute.

How to Change the Microsoft Active Directory Domain Controller by Using the DirSync Approach

If you are using the DirSync approach, perform the following steps:

  1. Stop the current profile that is running.

  2. Use the copy operation of the manageSyncProfiles command to create a new profile exactly the same as the profile already being used. In the newly created profile, modify the Microsoft Active Directory host connection information, that is, host, port, user, password, to point to the new host. Usually, the host name is the only item you need to update.

  3. Resume normal synchronization with the modified profile. Note that all the domain controllers must be in the same Microsoft Active Directory domain.

Configuring the Microsoft Active Directory Connector for Microsoft Active Directory Lightweight Directory Service

The Microsoft Active Directory connector can be used for synchronizing the entries between Microsoft Active Directory Lightweight Directory Service (AD LDS), which was previously known as Active Directory Application Mode or ADAM, and Oracle Internet Directory.

Configuring the Microsoft Active Directory Connector for Microsoft Exchange Server

The Microsoft Active Directory Connector can be used for provisioning users in Microsoft Exchange. This is applicable in deployments having Microsoft Active Directory Server 2000 or later as their identity store.

You can configure the Microsoft Active Directory connector for Microsoft Exchange Server use either of the following approaches:

To further customize your integration with Microsoft Exchange, follow the instructions in "Configuring Advanced Integration with Microsoft Active Directory".


See Also:

Oracle Application Server MS Office Developer's Guide

  Previous
Previous 		 Next
Next
  Go To Table Of Contents
Contents		 Go To Index
Index