18.3 Configuration of Integration with Microsoft Active Directory

18.3.2.1 About the Sample Synchronization Profiles

During installation, three sample Active Directory Connector synchronization profiles are provided. You can customize these samples to meet your deployment needs. The sample synchronization profiles are:

• ActiveImport—The profile for importing changes from Microsoft Active Directory to Oracle Internet Directory by using the DirSync approach

• ActiveChgImp—The profile for importing changes from Microsoft Active Directory to Oracle Internet Directory by using the USN-Changed approach

• ActiveExport—The profile for exporting changes from Oracle Internet Directory to Microsoft Active Directory

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

If these sample profiles meet your needs, then copy them and use the exact copies for running Active Directory Connector. If they do not meet your needs, then copy them and customize the copies.

To copy the sample profiles, use the createprofilelike (cpl) command of the Directory Integration and Provisioning Assistant, then enable the profile by following the instructions in Chapter 7, "Administration of Directory Synchronization". When you restart the Oracle directory integration and provisioning server, it uses the duplicate profile for synchronization, automatically refreshing its cache with any changed information.

Mapping Rules Mapping rules, an important part of the synchronization profile, determine the directory information to be synchronized and how it is to be transformed when synchronized. You can change mapping rules at run time to meet your requirements.

Each sample Active Directory synchronization profile includes default mapping rules. These rules contain a minimal set of default user and group attributes configured for out-of-the-box synchronization.

18.3.2.2 Creating Synchronization Profiles

To create new profiles, copy the sample profiles provided during installation and modify the copies.

To create and configure new profiles, use the Directory Integration and Provisioning Assistant. The Assistant can be invoked as a command-line tool or a graphical interface tool.

• To invoke the Assistant as a command-line tool enter dipassistant.

• To invoke the Assistant as a graphical interface tool, enter the following command:

  $ORACLE_HOME/bin/dipassistant -gui
  
  

  This displays the Oracle Directory Integration and Provisioning Server Administration tool, which provides a subset of the functionality provided through the command-line version of the tool.

18.3.2.3 Configuring the Connection Details for Microsoft Active Directory

You can configure the Active Directory Connector by using either the Oracle Directory Integration and Provisioning Server Administration tool or the express configuration option of the Directory Integration and Provisioning Assistant. Using either of these, you can specify the connection details as input to the script. This is the recommended method for configuring these details.

You can also create the profiles based on the template properties file provided during installation. If you are doing this, then you must specify the connection details in the odip.profile.condirurl, odip.profile.condiraccount, and odip.profile.condirpassword properties of the profile.

In addition to specifying the connection details, you must also ensure that the user account in Active Directory has the privileges to replicate directory changes for every domain of the forest monitored for changes. You can do this by one of the following methods:

• Grant to this account Domain Administrative permissions

• Make this account a member of the Domain Administrator's group

• Grant to this account Replicating Directory Changes permissions for every domain of the forest that is monitored for changes

To grant this permission to a non-administrative user, follow the instructions in the "More Information" section of the Microsoft Help and Support article "How to Grant the 'Replicating Directory Changes' Permission for the Microsoft Metadirectory Services ADMA Service Account" available at http://support.microsoft.com/.

18.3.2.4 Customizing Mapping Rules

Mapping rules govern the way data is transformed when a source directory and a destination directory are synchronized. Customize the default mapping rules found in the sample profiles when you need to do the following:

• Change distinguished name mappings. The distinguished name mappings establish how the Microsoft Active Directory DIT maps to the Oracle Internet Directory DIT.

• Change the attributes that need to be synchronized.

• Change the transformations (mapping rules) that occur during the synchronization.

You can perform any mapping if the resulting data in the destination directory conforms to the schema in that directory.

Distinguished Name Mapping You can change how the DIT in Active Directory maps to the one in Oracle Internet Directory.

Distinguished Name Rules
%USERBASE INSOURCE%:%USERBASE ATDEST%:

USERBASE refers to the container from which Microsoft Active Directory users and groups must be mapped. Usually, this is the users container under the root of the Microsoft Active Directory domain.

Distinguished Name Rules
cn=users,dc=us,dc=mycompany,dc=com:cn=users,dc=us,dc=mycompany,dc=com 

cn=groups,dc=us,dc=mycompany,dc=com: cn=users,dc=us,dc=mycompany,dc=com

Attribute-Level Mapping Attribute-level mapping specifies:

• The attributes in source directory that are to be synchronized

• The corresponding attributes in the target directory with which they are to be synchronized

• Any transformation of attribute values that is to occur as the data is synchronized from one directory to the other

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: :user:orclADSAMAccountName: :orclADGroup

Here, SAMAccountName and userPrincipalName from Microsoft Active Directory are mapped to orclADSAMAccountName and orclADUserPrincipalName in Oracle Internet Directory.

Adding another attribute to be synchronized requires adding another rule, as previously indicated earlier. Similarly, if an attribute no longer needs to be synchronized, then the corresponding rule needs to be removed or put in a comment.

How to Customize the Mapping Rules To customize the mapping rules:

1. Make a duplicate of the sample mapping rules file based on your deployment scenario—for example, whether you are using the DirSync approach or the USN-Changed approach, or whether or not you are doing one-to-one mapping.

2. Edit the sample mapping rules file to make the previously discussed modifications. The sample mapping rules files are stored in the directory $ORACLE_HOME/ldap/odi/conf with the extension of map.master for the various profiles. You can find instructions for editing mapping rules in "Configuring Mapping Rules".

3. After the changes are made, enter the following command:

   $ORACLE_HOME/bin/dipassistant modifyprofile -profile profile_name 
   -host oid_host -port oid_port -dn DN -passwd password
   odip.profile.mapfile=path_name
   
   

   For example:

   $ORACLE_HOME/bin/dipassistant modifyprofile -profile my_profile 
   -host my_host -port 3060 -dn cn=orcladmin -passwd welcome1
   odip.profile.mapfile=my_profile.map
   
   

   
   

   See Also: The dipassistant section in the Oracle Directory Integration and Provisioning tools chapter of the Oracle Identity Management User Reference

   
   

18.3.2.5 Customizing the LDAP Schema

Customizing the LDAP schema is required if:

• A directory deployment contains schema extensions such as custom object classes and attributes

• The custom attributes must be synchronized from one directory server to the other

To customize the LDAP schema, you must:

• Identify the schema extensions on the source directory

• Create those extensions on the target directory before starting the data migration and the synchronization.

  
  

  Note: In addition to creating schema extensions, you must also add the attribute to be synchronized with the corresponding object classes to the mapping rules.

  
  
  
  

  See Also: The chapter on administering the schema in Oracle Internet Directory Administrator's Guide for instructions on customizing the schema in Oracle Internet Directory Microsoft documentation available at http://msdn.microsoft.com/ for instructions on customizing the schema in Microsoft Active Directory

  
  

18.3.2.6 Customizing the Search Filter to Get Information from Microsoft Active Directory

By default, 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 Active Directory Connector queries 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 either Oracle Directory Integration and Provisioning Server Administration tool or Directory Integration and Provisioning Assistant to update the searchfilter attribute.

To customize the search filter by using the Directory Integration and Provisioning Assistant:

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

   $ORACLE_HOME/bin/dipassistant modifyprofile -D bindDn -w password -profile
   profName odip.profile.condirfilter=searchfilter=(|(objectclass=group)
   (objectclass=organizationalunit)(&(objectclass=user)(!(objectclass=computer)))) 
   
   

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

   $ORACLE_HOME/bin/dipassistant modifyprofile -D bindDn -w password 
   -profile profName odip.profile.oidfilter=orclObjectGUID 
   
   

To customize the search filter by using the Oracle Directory Integration and Provisioning Server Administration tool:

1. Launch the Oracle Directory Integration and Provisioning Server Administration tool by entering:

   $ORACLE_HOME/bin/dipassistant -gui
   
   
   

2. In the navigator pane, expand directory_integration_and_provisioning_server, then expand Integration Profile Configuration.

3. Select the configuration set, and, in the right pane, select the profile you want to customize. The Integration Profile window appears.

4. In the Integration Profile window, select the Mapping tab. The fields in this tab page are described in "Mapping".

5. In the Mapping tab page, in the Connected Directory Matching Filter (orclODIPConDirMatchingFilter) and the OID 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".

6. Choose OK.

18.3.2.7 Synchronizing Deletions from Microsoft Active Directory

Active Directory deletions can be synchronized with Oracle Internet Directory by querying for them in 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 Active Directory user account that the Oracle directory integration and provisioning server uses to access 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 Active Directory user account that the Oracle directory integration and provisioning server uses to access 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 Active Directory Application Mode (ADAM). You can download the most recent version of ADAM at http://www.microsoft.com/downloads/.

Regardless of whether you are using the DirSync approach or the USN-Changed approach to synchronize deletions in 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 Active Directory attributes:

• Object-GUID

• Object-SID

• Object-Dist-Name

• USN

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

18.3.2.8 Synchronizing Passwords

You can synchronize Oracle Internet Directory passwords with Active Directory. You can also make passwords stored in Microsoft Active Directory available in Oracle Internet Directory. Password synchronization is possible only when the directories run in SSL mode 2, that is, server-only authentication.

Synchronizing Passwords from Oracle Internet Directory to Microsoft Active Directory Before Active Directory Connector can synchronize passwords in this direction, do the following:

• Add a mapping rule that enables password synchronization. For example:

  Userpassword: : :inetorgperson:unicodepwd: :user
  
  

• Enable the password policy and reversible password encryption in the Oracle directory server. To do this, assign a value of 1 to the orclPwdPolicyEnable and orclpwdEncryptionEnable attributes in the entry cn=PwdPolicyEntry,cn=common,cn=products,cn=oraclecontext,DN_of_realm. You can do this by using either Oracle Directory Manager or ldapmodify.

Synchronizing from Microsoft Active Directory to Oracle Internet Directory  Because passwords in Microsoft Active Directory cannot be accessed by LDAP clients, you cannot synchronize Oracle Internet Directory passwords with Microsoft Active Directory in Oracle Application Server. However, if a deployment requires passwords to be available in Oracle Internet Directory, then Oracle recommends the following two methods:

• Build a custom plug-in for Active Directory that captures a password change and synchronizes it with Oracle Internet Directory. For more information:

  • See the chapter about the Oracle Internet Directory plug-in framework in Oracle Internet Directory Administrator's Guide

  • Visit the Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/

• Manage Active Directory passwords from the Oracle environment. With this method, passwords are available in both Oracle Internet Directory and Microsoft Active Directory. The Active Directory Connector can synchronize the two directories.

18.3.3.1 Customizing ACLs for Import Profiles

The import profile is the identity used by the Oracle directory integration and provisioning server to access Oracle Internet Directory. ACLs must enable the import profile to add, modify, and delete objects in either the users and groups containers or the subtree where entries are accessed. By default, import profiles are part of the Realm Administrators group (cn=RealmAdministrators, cn=groups,cn=OracleContext,realm_DN) in the default realm. This group grants privileges to perform all operations on any entry under the DN of the default realm.

You should not need to customize the ACLs for import synchronization with the default realm that is installed with Oracle Internet Directory Release 10g Release 2 (10.1.2). If you are upgrading from an earlier version of Oracle Internet Directory, or if the synchronization is with a nondefault Oracle Internet Directory realm, then be sure that the necessary privileges in the proper subtree or containers are granted to the import profiles handling the synchronization.

For an ACL template in LDIF format, see the file $ORACLE_HOME/ldap/schema/oid/oidRealmAdminACL.sbs. If you have not changed the ACLs on the default realm, then this template file can be applied directly after instantiating the substitution variables, replacing %s_SubscriberDN% with the default realm DN in Oracle Internet Directory and replacing %s_OracleContextDN% with cn=OracleContext,default_realm_DN respectively. For example, if realmacl.ldif is the instantiated file, then you can upload it by using the following ldapmodify command:

$ORACLE_HOME/bin/ldapmodify -h <OID host> -p <OID port> 
-D "DN of privileged OID user" -w "password of privileged OID user" 
-v -f realmacl.ldif

18.3.3.2 Customizing ACLs for Export Profiles

To enable the Oracle directory integration and provisioning server to access Active Directory, you must create an identity in Active Directory. This identity is configured in each export profile.

18.3.3.3 ACLs for Other Oracle Components

Default ACLs enable you to create, modify, and delete users and groups, but only in the users and groups containers under the default realm. To synchronize objects in other containers, you must customize the ACLs.

There are sample ACL files that you can use to customize ACLs for Oracle Components. These sample files are installed in the directory $ORACLE_HOME/ldap/schema/oid/. They are:

• oidUserAdminACL.sbs—Grants necessary rights to the subtree for Oracle components to manage and access users

• oidGroupAdminACL.sbs—Grants necessary rights to the subtree for Oracle components to manage and access groups.

• oidUserAndGroupAdminACL.sbs—Grants the privileges for Oracle components to manage and access users and groups in the subtree.

You can customize your ACL policy to grant privileges on a container-by-container basis with the required rights.

18.3.6.1 Preparing for Synchronization

To prepare for synchronization between Oracle Internet Directory and Microsoft Active Directory:

1. Plan your deployment by reading the following:

   • Chapter 17, "Considerations for Integrating with Third-Party Directories"

   • "Concepts and Architecture of Microsoft Active Directory Integration"

2. Use Oracle Enterprise Manager 10g Application Server Control Console to verify that Oracle Internet Directory is running.

   
   

   See Also: Oracle Internet Directory Administrator's Guide for information on how to work with the Oracle Enterprise Manager 10g Application Server Control Console Your Microsoft Active Directory documentation for instructions on how to verify that Microsoft Active Directory is running

   
   

3. Create a user account in Microsoft Active Directory with sufficient privileges to perform both import and export operations. Oracle Directory Integration and Provisioning will use this account to log in to Microsoft Active Directory.

   • For Import Operations from Microsoft Active Directory: Grant the user account read access privileges to the subtree root. The user account must be able to read all objects under the source container (subtree root) in Active Directory that are to be synchronized with the Oracle directory integration and provisioning server. To verify whether an Active Directory user account has the necessary privileges to all Active Directory objects to be synchronized with Oracle Internet Directory, use the command-line ldapsearch utility to perform a subtree search, as follows:

     $ORACLE_HOME/bin/ldapsearch -h <AD host> -p <AD port> -b "DN of subtree" 
     -s sub -D "DN of privileged AD user" -w "password for privileged AD user" 
     "objectclass=*" 
     
     

     The return results from the ldapsearch utility should include all objects of interest, including all attributes and values that will be synchronized.

     To synchronize deletions of users in Active Directory with Oracle Internet Directory, you must grant the user account the necessary privileges by following the instructions in "Synchronizing Deletions from Microsoft Active Directory".

   • For Export Operations to Microsoft Active Directory: Grant the user account the following privileges to the subtree root that is the parent of all the containers to which the Oracle directory integration and provisioning server will export users:

     • Write

     • Create all child objects

     • Delete all child objects

   
   

   See Also: Your Microsoft Active Directory documentation for information how to grant privileges to user accounts

   
   

18.3.6.2 Creating Synchronization Profiles with Express Configuration

This section describes how to create and customize synchronization profiles with express configuration. It contains these topics:

• Understanding Express Configuration

• Running Express Configuration

• Additional Synchronization Considerations

18.3.6.3 Customizing Attribute Mapping

Once you have established a working synchronization between Oracle Internet Directory and Microsoft Active Directory, you can customize the attribute mapping rules for your synchronization profiles to meet the needs of your deployment. To customize the attribute mapping rules for your synchronization profiles:

1. When you use express configuration to create import and export synchronization profiles, mapping files are created for each profile in the $ORACLE_HOME/ldap/conf directory. The mapping files are named profile_nameImport.map and profile_nameExport.map. For example, if you enter "abc" when express configuration prompts you for the name of your profile, your import mapping files will be named abcImport.map and abcExport.map. Modify the mapping rules in your mapping files as needed by following the instructions described in "Customizing Mapping Rules".

2. Wait until the scheduling interval has elapsed, and then check the synchronized users and groups to ensure that the attribute mapping rules meet your requirements.

3. Repeat Step 1 through Step 2 until the synchronized users and groups contain the attributes you need.

   
   

   Tip: You may find it helpful to add test users and groups to Oracle Internet Directory or Microsoft Active Directory when customizing attribute mapping rules.

   
   

18.3.6.4 Final Configuration Requirements

This section describes the final configuration requirements for the import and export synchronization profiles created with express configuration. It contains these topics:

• Customizing DN Mapping Rules

• Synchronizing Multiple Domains

• Performing Initial Bootstrapping

• Granting Privileges to Non-Default Realms

18.3.6.5 Configuring Synchronization Profiles for SSL

Your last step in customizing the import and export synchronization profiles should be to enable SSL. By default, SSL is not enabled for the import and export synchronization profiles created with express configuration. This section describes how to enable SSL for Active Directory synchronizations.

1. Follow the instructions in "Configuring the Active Directory Connector for Synchronization in SSL Mode".

2. Once SSL is enabled for Active Directory and Oracle Internet Directory, you can modify the Active Directory connection information, including the host name and profile, using the Directory Integration and Provisioning Assistant's modifyprofile command, as follows:

   $ORACLE_HOME/bin/dipassistant modifyprofile <-h hostName> <-p port> 
   -profile profilename odip.profile.condirurl= ad_host_name:636:1
   
   

3. Restart the Oracle directory integration and provisioning server by following the instructions "Starting, Stopping, and Restarting the Oracle Directory Integration and Provisioning Server".

4. Add a test user and verify that it synchronizes successfully. If the test user does not synchronize successfully, then troubleshoot your SSL configuration.

18.3.6.6 Additional Considerations

Read the following topics for additional configuration requirements:

• "Configuring the Realm"

• "Configuring the Active Directory External Authentication Plug-in"

• "Configuring Windows Native Authentication"

• "ACLs for Other Oracle Components"

18.3.7.1 Installing Active Directory External Authentication Plug-ins

To install the plug-in:

1. Execute the oidspadi.sh script by entering:

   cd $ORACLE_HOME/ldap/admin
   sh oidspadi.sh
   

   
   

   Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities: Cygwin 1.3.2.2-1 or later. Visit http://sources.redhat.com/ MKS Toolkit 6.1. Visit http://www.datafocus.com/

   
   

   If you are using the Windows operating system, then execute oidspadi.sh after you have installed the UNIX emulation utility by entering:

   sh oidspadi.sh
   
   

2. Enter the Microsoft Active Directory host name. This is the Microsoft Active Directory with which you are going to synchronize. This value is required.

3. Specify whether to use an SSL connection to Microsoft Active Directory. If you choose to use SSL, then you need to enter the following:

   • The Microsoft Active Directory SSL connection port number

   • The location of the Oracle wallet. This wallet needs to have the valid certificate from the Microsoft Active Directory that you are trying to connect to.

   • The Oracle wallet password.

     When specifying the wallet location on the Microsoft Windows operating system, add an additional backslashes (\). For example, if the wallet location is D: storage\wallet, then enter D:\\storage\\wallet.

4. Enter the connect string for the database designated for Oracle Internet Directory.

5. Enter the ODS password for Oracle Internet Directory

6. Enter the directory server host name. This value is required.

7. Enter directory server port number. The default port is 389.

8. Enter the password of the Oracle administrator (orcladmin). This value is required.

9. (Optional) Enter the distinguished name of the container to which the plug-in needs to be applied. Every entry in this container will be authenticated against Active Directory. Note that this need not necessarily be the User Search Base supplied by using the Oracle Internet Directory Self-Service Console. All the users under this search base are authenticated externally to the Active Directory. If more than one container is specified, then separate the DNs with semi-colons (;).

10. Enter the Plug-in Request Group DN. For security reasons, the plug-in can be invoked only by users belonging to this group. For example, suppose that the Oracle Application Server Single Sign-On administrators are in the group cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext. If you enter this DN as the value for the Plug-in Request Group DN, then only requests fromOracle Application Server Single Sign-On administrators can trigger the external authentication plug-in. You can enter multiple DN values. Use a semicolon (;) to separate them. This value is not required, but, for security purposes, it should be specified.

11. (Optional) Enter the value of the entry that is to be excluded from authentication to Microsoft Active Directory. This value is the exception to Step 9. You need to enter the value in the standard ldapsearch filter format. For example, if you specify the value (&(objectclass=inetorgperson)(cn=orcladmin)), then any entry under the user container specified in Step 9 that has the cn=orcladmin and objectclass=inetorgperson attribute values will not be authenticated to Microsoft Active Directory.

12. (Optional) Specify the backup Microsoft Active Directory domain controller details.

18.3.7.2 Installing Active Directory External Authentication Plug-ins for Multiple Domains

You should use a single instance of Global Catalog to configure multiple Active Directory domains for external authentication in Oracle Internet Directory. However, if you cannot configure a single instance of Global Catalog for multiple Active Directory domains in your deployment environment, then install multiple Active Directory external authentication plug-ins for each domain as follows.

1. Copy and edit the Active Directory external authentication plug-in SQL package:

   1. Copy the $ORACLE_HOME/ldap/admin/oidspada.pls file to oidspada2.pls, or another unique file name that represents an additional Active Directory domain.

   2. Edit oidspada2.pls (or whatever file name you chose) and replace all five occurrences of "OIDADPSWD" with "OIDADPSW2".

   3. Save and close oidspada2.pls.

2. Copy and edit the Active Directory external authentication plug-in installation script:

   1. Copy the $ORACLE_HOME/ldap/admin/oidspadi.sh file to oidspadi2.sh, or another unique file name that represents an additional Active Directory domain.

   2. Edit oidspadi2.sh (or whatever file name you chose) and make the following edits.

   3. Go to line 361 and replace "oidspada.pls" with "oidspad2.pls".

   4. Go to line 380 and replace "cn=adwhencompare" with "cn=adwhencompare2".

   5. Go to line 383 and replace "OIDADPSWD" with "OIDADPSW2".

   6. Go to line 390 and replace "adwhencompare" with "adwhencompare2".

   7. Go to line 396 and replace "cn=adwhenbind" with "cn=adwhenbind2".

   8. Go to line 399 and replace "OIDADPSWD" with "OIDADPSW2".

   9. Go to line 406 and replace "adwhenbind" with "adwhenbind2".

   10. Save and close oidspadi2.sh.

3. Execute the oidspadi2.sh script by following the instructions in "Installing Active Directory External Authentication Plug-ins".

4. Executing the oidspadi2.sh script creates two configuration entries: cn=adwhencompare2,cn=plugin,cn=subconfigsubentry and cn=adwhenbind2,cn=plugin,cn=subconfigsubentry. Use ldapmodify to disable or delete these entries.

5. Repeat the preceding steps for any additional domains, but be sure to use unique file names when you copy oidspada.pls and oidspadi.sh.

18.3.7.3 Enabling the Active Directory External Authentication Plug-ins

By default, the Active Directory external authentication plug-ins are enabled. However, you may need to enable them at some point.

To enable Active Directory external authentication plug-ins:

1. Create an LDIF file with the following entries:

   dn: cn=adwhencompare,cn=plugin,cn=subconfigsubentry
   changetype: modify
   replace: orclpluginenable
   orclpluginenable: 1
   
   dn: cn=adwhenbind,cn=plugin,cn=subconfigsubentry
   changetype: modify
   replace: orclpluginenable
   orclpluginenable: 1
   
   

2. Load the LDIF file with the ldapmodify command as follows:

   ldapmodify -h host -p port  -D cn=orcladmin -w password -f fileName
   

18.3.7.4 Testing the Active Directory External Authentication Plug-ins

To test the Active Directory external authentication plug-ins:

1. Use your browser to visit http://host of OracleAS Single Sign-On:port number of OracleAS Single Sign-On/pls/orasso.

2. Log in by using a pre-defined user in Microsoft Active Directory: user identifier@domain.

18.3.8.1 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 10g Release 2 (10.1.2) infrastructure installed

  
  

  Note: Although the sample configurations in this section are for UNIX, Oracle Application Server can also be installed on Microsoft Windows.

  
  

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

• Synchronization of Active Directory with Oracle Internet Directory

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

18.3.8.2 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: Verify That Microsoft Active Directory Is Set Up and Working

To ensure that Microsoft Active Directory is properly configured and running, consult the Windows 2000/2003 server documentation.

Task 2: 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 the chapter about advanced configurations in Oracle Application Server Single Sign-On Administrator's Guide. For installation instructions, see the installation documentation for your operating system.

Task 3: Synchronize Oracle Internet Directory with Microsoft Active Directory

User entries in Oracle Internet Directory must be synchronized with user entries in Microsoft Active Directory.

Task 4: Configure the Active Directory External Authentication Plug-in for each Domain

This task is necessary to allow users to access Oracle Application Server Single Sign-On applications with browsers other than Internet Explorer 5.0 or later.

1. Install the Active Directory external authentication plug-in by following the instructions in "Configuring the Active Directory External Authentication Plug-in".

2. Verify that the Active Directory external authentication plug-in is working by following the instructions in "Testing the Active Directory External Authentication Plug-ins".

Task 5: Configure the OracleAS Single Sign-On Server

To configure the single sign-on server, complete the tasks described in the following topics.

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

• Run the OracleAS Single Sign-On 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 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 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 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 Active Directory that will be used by the logical Oracle Application Server Single Sign-On host:

   1. Log in to the 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 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 host itself or the name of a load balancer where multiple OracleAS Single Sign-On 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 that you obtained in Step 4. The -mapuser argument is the account name of the OracleAS Single Sign-On middle tier. You created this account in step 4. 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 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, created in step 5, to the OracleAS Single Sign-On 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 unique identifier (UID) on the OracleAS Single Sign-On middle tier read permission for the file.

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

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

• It configures the server as a secured application.

To run the ossoca.jar tool on the OracleAS Single Sign-On 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/applications-deployments/sso/orion-application.xml

2. Run the ossoca.jar tool:

   • UNIX:

     $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 6: 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 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 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 7: 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 Manager 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.

18.3.8.3 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: Verify That Microsoft Active Directory Is Set Up and Working

To ensure that Microsoft Active Directory is properly configured and running, consult the Windows 2000/2003 server documentation.

Task 3: 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 the chapter about advanced configurations in Oracle Application Server Single Sign-On Administrator's Guide. For installation instructions, see the installation documentation for your operating system.

Task 4: Synchronize Oracle Internet Directory with each Microsoft Active Directory Domain

Create separate synchronization profiles for each Microsoft Active Directory by following the instructions described in "Configuring Synchronization Profiles".

Task 5: Configure the Active Directory External Authentication Plug-in for each Domain

This task is necessary to allow users to access Oracle Application Server Single Sign-On applications with browsers other than Internet Explorer 5.0 or later.

1. Install the Active Directory external authentication plug-in for each domain by following the instructions in "Installing Active Directory External Authentication Plug-ins for Multiple Domains".

2. Perform the following steps for each domain to verify that the Active Directory external authentication plug-in for each domain is working:

   1. Enter an ldapbind command to verify that a user entry was successfully imported from Active Directory into Oracle Internet Directory.

   2. Enter an ldapcompare command to find whether userPassword attribute for the user entry exists in Oracle Internet Directory.

Task 6: 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 Application Server Single Sign-On Administrator's Guide.

Task 7: Configure the OracleAS Single Sign-On Server

Configure each Oracle Application Server Single Sign-On server by following the instructions in "Task 5: Configure the OracleAS Single Sign-On Server". Be sure to use the same 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 8: Configure Internet Explorer for Windows Native Authentication

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

18.3.8.4 Implementing Fallback Authentication

Only browsers that are Internet Explorer 5.0 or later 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 OracleAS Single Sign-On 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 and provisioning server. 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.

18.3.8.5 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-5 shows under what circumstances automatic sign-on and fallback authentication are invoked.

18.3.9.1 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-5, 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 Directory Integration and Provisioning Assistant as follows:

   $ORACLE_HOME/bin/dipassistant modifyprofile 
   -profile profile_name_for_domain_A_or_B 
   -host host_name 
   -port port_name 
   -dn bind_DN 
   -passwd password_of_bind_DN
   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 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 389, 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 -bootstrap option of the Directory Integration and Provisioning Assistant to bootstrap the data from Microsoft Active Directory to Oracle Internet Directory.

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-5, 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-5, 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 Directory Integration and Provisioning Assistant.