16 Integration with the Microsoft Active Directory Environment

About Realms in Oracle Internet Directory

In Oracle Internet Directory, an identity management realm defines an enterprise scope over which certain identity management policies are defined and enforced by the deployment. It comprises:

• A well-scoped collection of enterprise identities—for example, all employees in the US domain.

• A collection of identity management policies associated with these identities. An example of an identity management policy would be to require that all user passwords have at least one alphanumeric character.

• A collection of groups, that is, aggregations of identities that simplify setting the identity management policies

Multiple Realms

You can define multiple identity management realms within the same Oracle Identity Management infrastructure. This enables you to isolate user populations and enforce a different identity management policy,—for example, password policy, naming policy, self-modification policy—in each realm. This is useful in a hosted deployment of Oracle Application Server.

Each identity management realm is uniquely named to distinguish it from other realms. It also has a realm-specific administrator with complete administrative control over the realm.

The Default Realm

For all Oracle components to function, an identity management realm is required. One particular realm, created during installation of Oracle Internet Directory, is called the default identity management realm. It is where Oracle components expect to find users, groups, and associated policies whenever the name of a realm is not specified. This default realm facilitates proper organization of information and enforces proper access controls in the directory.

There can be only one default identity management realm in the directory. If a deployment requires multiple identity management realms, then one of them must be chosen as the default.

Figure 16-2 illustrates the default identity management realm.

Figure 16-2 The Default Identity Management Realm

Description of the illustration oimig001.gif

As Figure 16-2 shows, the default identity management realm is part of a global DIT. The node just below the root DSE is dc=com, followed by dc=MyCompany, then dc=us. These four nodes represent the overall DIT structure. The node dc=us is the root of the default identity management realm. It has two subtrees for containing user and group information: cn=Users and cn=Groups. For illustration purposes, the cn=Users node contains two leaves: uid=user1 and uid=user2. Similarly, the cn=Groups node contains cn=group1 and cn=group2.

Access Control Policies in the Realm

You must configure appropriate ACLs in Oracle Internet Directory to enable Oracle Directory Integration and Provisioning to:

• Enable the import profile to add, modify and delete objects in the users and groups containers. By default, import profiles are part of the Realm Administrators group, which can perform all operations on any entry under the realm DN. If you have customized ACLs in the realm, then be sure that the import profiles have the appropriate privileges to perform these operations on the subtree to be synchronized or on either the user container, the group container, or both depending on where the synchronization takes place.

• Enable Oracle components to manage the users and groups in the realm. By default, Oracle components can manage users and groups in the users and groups containers respectively. If you have updated your usersearchbase and groupsearchbase in the realm, then set up appropriate ACLs on the users container and groups container.

Planning the Deployment

When planning the DIT, the most important decisions to make before synchronization are:

• Which directory is to be the central one

• What objects to synchronize, for example:

  • The portion of the DIT that you want to synchronize. You can synchronize the entire DIT or just a portion of it.

  • For each entry, the specific contents that you want to synchronize. You can synchronize the entire content of the entry or just a portion of it.

• Where to synchronize. You have two options:

  • You can synchronize so that the relative position of each entry in the DIT is the same in the source and destination directories. This configuration, called one-to-one distinguished name mapping, is the most commonly used configuration. Because the source DN is the same as the destination DN, this configuration provides better performance than when the two DNs are different.

  • You can synchronize so that the relative position in the DIT of each entry in the destination directory is different from that in the source directory. In this configuration, the Oracle directory integration and provisioning server must change the DN values of all entries being mapped, including their references in group entries. This requires more intensive computation.

    If you synchronize in this way, you need to use the dnconvert mapping rule as described in "Supported Attribute Mapping Rules and Examples".

Example: Integration with a Single Microsoft Active Directory Domain Controller

Figure 16-3 shows an example of one-to-one mapping between the two directories.

Figure 16-3 Default DIT Structures in Oracle Internet Directory and Active Directory When Both Directory Hosts Are Under the Domain us.MyCompany.com

Description of the illustration oimig003.gif

In the one-to-one mapping illustrated in Figure 16-3:

• Both Active Directory and Oracle Internet Directory hosts have the same topology.

• Users are synchronized only from Active Directory to Oracle Internet Directory. All users to be synchronized are stored in one container in Active Directory, in this case users.us.MyCompany.com.

• The same DIT structure is maintained in both Active Directory and Oracle Internet Directory. All users appear in the same users subtree identified by the value cn=users,dc=us,dc=MyCompany,dc=com.

In the example shown in , only the users subtree must be synchronized from Active Directory to Oracle Internet Directory using one-to-one domain mappings.

Example: Integration with Multiple Microsoft Active Directory Domain Controllers

A deployment of Microsoft Active Directory with multiple domains can have either a single DIT or a combination of two or more DITs. In Microsoft Active Directory, a group of DITs is called a forest.

One-to-One Mapping of Multiple Microsoft Active Directory Domains

Figure 16-4 shows how multiple domains in Microsoft Active Directory are mapped to a DIT in Oracle Internet Directory.

Figure 16-4 Example of a Mapping Between Oracle Internet Directory and Multiple Domains in Microsoft Active Directory

Description of the illustration oimig002.gif

In Figure 16-4, the Microsoft Active Directory environment has a parent and two children. Each domain has a domain controller associated with it. The Active Directory domain controller supporting the node us.mycompany.com is the Global Catalog server.

The first child domain a.us.MyCompany.com maps to dc=a,dc=us,dc=MyCompany,dc=com in Oracle Internet Directory. The second child domain b.us.MyCompany.com maps to dc=b,dc=us,dc=MyCompany,dc=com in Oracle Internet Directory. The common domain component in Active Directory environment us.MyCompany.com maps to the default identity management realm in Oracle Internet Directory, in this case dc=us,MyCompany,dc=com.

Mapping of a Microsoft Active Directory Forest

Figure 16-5 shows how a forest in Microsoft Active Directory is reflected in Oracle Internet Directory.

Figure 16-5 Mapping Between Oracle Internet Directory and a Forest in Microsoft Active Directory

Description of the illustration oimig004.gif

In this directory, two domain trees constitute a forest. These trees are in a trust relationship, that is, users in one domain are authenticated by the domain controller in the other domain. This forest in Microsoft Active Directory maps to an identically structured subtree in Oracle Internet Directory.

Foreign Security Principals

A Microsoft Active Directory user or computer account represents a physical entity such as a computer or person. User accounts and computer accounts, as well as groups, are called security principals. Security principals are directory objects that are automatically assigned security identifiers. Objects with security identifiers can log on to the network and access domain resources. A user or computer account is used to:

• Authenticate the identity of the user or computer

• Authorize or deny access to domain resources

• Administer other security principals

• Audit actions performed using the user or computer account

For example, the user and computer accounts that are members of the Enterprise Administrators group are automatically granted permission to log on at all of the domain controllers in the forest.

User and computer accounts are added, disabled, reset, and deleted by using Microsoft Active Directory Users and Computers.

In a trust relationship in Active Directory, users in one domain are authenticated by a domain controller in another domain. The trust relationship can be transitive or nontransitive.

• In a transitive trust relationship, the trust relationship extended to one domain is automatically extended to all other domains that trust that domain. For example, suppose you have three domains: A, B, and C in which both B and C are in a direct trust relationship with A. In this scenario, both B and C also trust each other. This is because, although they are not in a direct trust relationship with each other, they are in a direct trust relationship with A.

• In a nontransitive trust relationship, the trust is bound by the two domains in the trust relationship; it does not flow to any other domains in the forest.

When a trust is established between a Windows 2000 domain in a particular forest and a Windows 2000 domain outside of that forest, security principals from the external domain can be granted access to resources in the forest. A security principal from an external domain is called a foreign security principal and is represented in Active Directory as a "foreign security principal" object. These foreign security principals can become members of domain local groups, which can have members from domains outside of the forest.

Foreign security principals are used when there is a nontransitive trust between two domains in a Microsoft Active Directory environment.

In a nontransitive trust relationship in a Microsoft Active Directory environment, when one domain recognizes a foreign security principal from the other domain, it represents that entity similar to a DN entry. In that entry, the RDN component is set to the SID of the original entry in the trusted domain. In the case of groups, the DNs of the foreign security principals are represented as member values, not as the DNs of the original entries in the trusted domain. This can create a problem when foreign security principals are synchronized with Oracle Internet Directory.

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.

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.

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

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 Directory Integration and Provisioning Assistant (dipassistant) Syntax"

   
   

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

  
  

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.

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 information on how to grant Replicating Directory Changes permissions, see Article ID 303972 at http://support.microsoft.com.

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

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, as described in "Starting the Oracle Directory Integration and Provisioning Server by Using the OID Control Utility".

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.

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

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.

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.

Preparing for Synchronization

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

1. Plan your deployment by reading the following:

   • Chapter 15, "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

   
   

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

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.

   
   

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

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.

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"

Installing Active Directory External Authentication Plug-ins

To install the plug-in:

1. Execute the script oidspadi.sh 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.

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
   

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.

System Requirements

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

Configuration Tasks

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 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 Oracle Internet Directory to Use the Active Directory External Authentication Plug-in

See Configuring the Active Directory External Authentication Plug-in.

Task 5: Verify That Synchronization and the Active Directory External Authentication Plug-in Are Working

Log in to the OracleAS Single Sign-On server to verify that you have synchronized user entries between the two directories and that the Active Directory external authentication plug-in is working.

1. Go to the login page:

   http://host:port/pls/orasso
   
   

2. Enter your user name in the following format:

   user_name@active_directory_domain
   
   

3. Enter your password.

Task 6: 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

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 OracleAS Single Sign-On computer. 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 of the single sign-on computer 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. 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.

5. 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 when you run the tool as explained in Step 5.

   
   

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

 Running the ossoca.jar tool at this point does the following:

• It configures the 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
     -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 7: Configure the End User Browser

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 8: 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.

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.

Login Scenarios

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

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

Bootstrapping Data Between Directories

Bootstrapping is sometimes called data migration. To bootstrap data, do the following once the Active Directory Connector and plug-in configurations are complete:

1. Identify the data you want to migrate. You can choose to migrate all data in the directory or only a subset of data.

2. Make sure the synchronization is not enabled yet.

3. Bootstrap from one directory to another by using the Directory Integration and Provisioning Assistant with the -bootstrap option. Bootstrapping is described in Chapter 8, " Bootstrapping of a Directory in Oracle Directory Integration and Provisioning".

   Once bootstrapping is accomplished, the profile status attributes are appropriately updated in the synchronization profile by the Directory Integration and Provisioning Assistant.

4. If you used LDIF file-based bootstrapping, then initialize the lastchangekey value with the Directory Integration and Provisioning Assistant as follows:

   $ORACLE_HOME/bin/dipassistant modifyprofile -updlcn
   
   

   This lastchangekey attribute should be set to the value of the last change number in the source directory before you started the bootstrap.

   In order to update the last change number, the value assigned to the odip.profile.condirurl property in the import synchronization profile must be for a non-SSL connection. If you have already configured the import synchronization profile for SSL, then before attempting to update the last change number, you must temporarily change the value assigned to the odip.profile.condirurl property so it points to a non-SSL port.

5. If two-way synchronization is required, then enable the export profile and make sure the change logging option is enabled for the Oracle directory server. Change logging is controlled by the -l option while starting Oracle Internet Directory. By default, it is set to TRUE, meaning that change logging is enabled. If it is set to FALSE, then use the OID Control Utility to shut down the Oracle directory server, and then to start the server again with the change log enabled.

Managing the Active Directory External Authentication Plug-in

This section explains how to delete, disable, and re-enable the Active Directory external authentication plug-in.

ldapdelete -h host -p port -D cn=orcladmin -w password
"cn=adwhencompare,cn=plugin,cn=subconfigsubentry"

ldapdelete -h host -p port -D cn=orcladmin -w password
"cn=adwhenbind,cn=plugin,cn=subconfigsubentry"

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

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 Active Directory Domain Controller by Using the USN-Changed Approach

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

1. Stop 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 userDN -w password "objectclass=*" highestCommittedUSN
   
   

3. Use Oracle Directory Integration and Provisioning 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 ldapsearch 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 in Release 10.1.2: 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 and Provisioning 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 Active Directory Domain Controller by Using the DirSync Approach

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

1. Stop the current profile that is running.

2. Use the Directory Integration and Provisioning Assistant createlike option 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 all the domain controllers must be in the same Active Directory domain.