| Oracle® Collaboration Suite Integration with Microsoft Active Directory Release 2 (9.0.4) for Solaris Part Number B15610-01 |
|
|
View PDF |
| Oracle® Collaboration Suite Integration with Microsoft Active Directory Release 2 (9.0.4) for Solaris Part Number B15610-01 |
|
|
View PDF |
Oracle provides centralized security administration for all Oracle components by tightly integrating them with Oracle Identity Management. Similarly, Microsoft provides centralized security administration in Windows 2000 and Microsoft Windows NT by tightly integrating all Microsoft applications with Microsoft Active Directory.
This chapter, written for environments with both Oracle and Microsoft technology stacks, explains how Oracle Identity Management can integrate with Microsoft Windows environments. It contains these topics:
Overview of Integration with the Microsoft Windows Environments
Configuring The Active Directory External Authentication Plug-in
Installing and Configuring Windows NT External Authentication and Auto-Provisioning Plug-ins
Sample LDIF Files Required for Integration with Microsoft Windows
|
See Also: "Oracle Internet Directory Frequently Asked Questions" on the Oracle Technology Network at |
This section discusses the various aspects of the Windows integration environment as well as the Oracle components and tools involved. It contains these topics:
Components for Integrating with the Microsoft Windows Environment
Configuration Information Set During Installation of the Active Directory Connector
Information Required in a Multiple-Domain Microsoft Active Directory Environment
Directory Information Tree Setup for Integration with Microsoft Active Directory
Table 2-1 describes each Oracle component used in integrating Oracle Internet Directory with Microsoft Active Directory.
Table 2-1 Components for Integrating with Microsoft Active Directory
Microsoft Active Directory provides various ways of tracking changes to its directory contents. Two of these approaches are:
The DirSync control-based approach
The USNChanged-based approach
In each approach, the directory from which changes are derived is polled at scheduled intervals by the Active Directory connector.
Each approach has advantages and disadvantages. Table 2-2 compares and contrasts the two approaches.
Table 2-2 Comparing and Contrasting the DirSync Approach with the USNChanged Approach
| Consideration | DirSync Approach | USNChanged Approach |
|---|---|---|
| Change key | Presents changes to the ObjectGUID-the unique identifier of the entry |
Presents changes to the distinguished name. The ObjectGUID is used to keep track of modifications of the RDN. |
| Changes to multivalued attributes | Reflects incremental changes made to multivalued attributes as a complete replacement of the attribute value. This might cause unnecessary traffic on the network. | Reflects incremental changes made to multivalued attributes as a complete replacement of the attribute value. This might cause a lot of unnecessary traffic on the network. |
| Error handling | If synchronization aborts, starts the next cycle from the current place. This requires keeping count of the number of changes applied during any synchronization operation. Otherwise, some changes are applied again. | Does not require synchronization to be atomic. If synchronization of a particular entry fails, then the next synchronization cycle can start from the current or next entry. |
| Information in the search results | Provides search results consisting of only the changed attributes and the new values. Application of these changes to Oracle Internet Directory is very easy. | Provides search results consisting of the complete changed entry. All the attribute values are compared to the old values stored in Oracle Internet Directory and applied, only if it has changed. This can be time consuming. |
| Information in the search results | Provides search results consisting of only the changed attributes and the new values. Application of these changes to Oracle Internet Directory is very easy. | Provides search results consisting of the complete changed entry. All the attribute values are compared to the old values stored in Oracle Internet Directory and applied, only if it has changed. This can be time consuming. |
| Monitoring of applied changes | When queried for changes in the directory, presents incremental changes based on a cookie value that identifies the state of the directory. Because the cookie is a binary value, changes over a period of time cannot be selectively ignored. | The changes are queried in the directory based on the USNChanged attribute, which is an Integer. It is very easy to modify the value if required. |
| Privileges required for the synchronizing user | Requires the user to have the SE_SYNC_AGENT_NAME privilege, which enables reading all objects and attributes in Microsoft Active Directory regardless of the access protections on the objects and attributes. |
No special privileges required. The user must have privileges to read and write in the specific container. |
| Support of multiple domains | Requires separately connecting to the different domain controllers to read changes made to the entries in different domains. | Enables the user to read changes made to the multiple domains by connecting to the Global Catalog Server. |
| Synchronization from a replicated directory in case of failover | Can be continued as it is. The synchronization key is the same when connecting to a replicated environment. | Requires the change number to be updated before starting synchronization with the failover directory. |
| Synchronization scope | Reads all the changes made in the directory, filters out the changes made to the required entries, and propagates to Oracle Internet Directory. | Makes it possible to look for changes in any specific subtree. |
| Two-way Synchronization | For two-way synchronization, requires configuring an import profile and an export profile for each of the domain controllers. | For two way synchronization, requires one profile for importing changes from all the domain controllers, and individual profiles to export changes to each of the domain controllers. |
| Usability in an environment with multiple Microsoft Active Directory servers behind a load balancer | Connect to a specific Microsoft Active Directory node, preferably a Global Catalog Server. | Connect to a specific Microsoft Active Directory node. |
During installation, default synchronization profiles, mapping rules, and access controls are preconfigured. You can customize them to meet the needs of your deployment.
Most of the information for enabling synchronization is preconfigured in Oracle Internet Directory during installation and stored in a directory entry called Synchronization Profile. This information is used by the Oracle directory integration and provisioning server during synchronization and by the Directory Integration and Provisioning Assistant during bootstrapping.
You can change this information at runtime to meet your requirements. The next time the directory integration and provisioning server uses the profile for synchronization, it automatically refreshes its cache with the changed information. This saves you from restarting this server every time you change configuration information.
During installation, three default Active Directory synchronization profiles are created in Oracle Internet Directory. You can use them for running the Active Directory connector if they are adequate for your needs. Otherwise, use them as templates, customizing them to meet the needs of your deployment. They 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 USNChanged approach
ActiveExport-The profile for exporting changes from Oracle Internet Directory to Microsoft Active Directory.
Mapping rules, an important part of the synchronization profile, determine what directory information is to be synchronized from one directory to another and how it is to be synchronized. You can change mapping rules at runtime to meet your requirements.
Each default Active Directory synchronization profile includes default mapping rules. These rules contain a minimal set of default user and group attributes configured for synchronization out of the box. These default attributes are described in Table 2-3, which lists them using their respective names in Microsoft Active Directory and Oracle Internet Directory.
Table 2-3 Default User and Group Attributes
| Name in Microsoft Active Directory | Name in Oracle Internet Directory | Description |
|---|---|---|
| Default User Attributes | ||
cn |
cn |
User name |
SAMAccountName |
user:orclADSAMAccountName |
Contains Microsoft Active Directory login ID. Used by Oracle Application Server Single Sign-On Service for Windows native Authentication. |
UserprinicipalName |
uid |
Used by Oracle Application Server Single Sign-On Service for single sign-on |
UserprinicipalName |
orclADUserprinicipalName |
Used by Oracle Application Server Single Sign-On Service for single sign-on in case uid can not be used |
ObjectGUID |
orclADObjectGUID |
Used by Active Directory Connector as Synchronization key |
ObjectSID |
orclsADObjectSID |
Not used currently |
| Default Group Attributes | ||
cn |
cn |
User name |
SAMAccountName |
user:orclADSAMAccountName |
Contains Microsoft Active Directory login ID |
Managedby |
Owner |
Represents who owns the group entry |
Member |
uniquememeber |
Represents DNs of member users in the groups |
In addition to the default attributes in Table 2-3, the ou (organizational unit) attribute is also preconfigured for synchronization. It is represented by ou both in Microsoft Active Directory and Oracle Internet Directory.
To enable users to access only data they are authorized to use, proper access controls are required in Oracle Internet Directory. More specifically, access controls are required to:
Enable only the authorized accounts to create data in Oracle Internet Directory when synchronizing it from Microsoft Active Directory
Allow only the user and group objects to be created in the proper containers
Two default access control policies are preconfigured during installation. They ensure that only authorized users can create entries in Oracle Internet Directory. The first policy disallows creation of any objects except users under the users subtree, which is the default container for all users to be synchronized. The second policy disallows creation of any objects except groups under the groups subtree, which is the default container for all groups to be synchronized.
|
See Also: "Directory Information Tree Setup for Integration with Microsoft Active Directory" for more details on the user and group subtrees |
After installation of Oracle Internet Directory, you need to configure only minimal additional information in the synchronization profile to enable synchronization between the two directories. In a simple deployment, you can easily configure this information by using the script adprofilecfg.sh. Other tools for configuring the information are:
Oracle Internet Directory Self-Service Console, described in Chapter 31, "Oracle Internet Directory Self-Service Console" of the Oracle Internet Directory Administrator's Guide
Directory Integration and Provisioning Assistant, described in "Directory Integration and Provisioning Assistant"
Oracle Directory Manager, described in Chapter 4, "Directory Administration Tools" of the Oracle Internet Directory Administrator's Guide
|
See Also: "Configuring the Active Directory Connector" for a detailed description of the information you need to configure to enable the synchronization |
Configuration information required in multiple-domain Microsoft Active Directory environments for synchronizing Microsoft Directory to Oracle Internet Directory depends on whether the Global Catalog is configured. If it is available, then the Active Directory connector can synchronize from the Global Catalog. In this case, you must configure only one synchronization profile. If the Global Catalog is not available, then the Active Directory connector must go to each Microsoft Active Directory server to synchronize from Microsoft Active Directory. In this case, you must configure as many export profiles as there are number of Microsoft Active Directory domains.
Configuration information required in multiple-domain Microsoft Active Directory environments for synchronizing from Oracle Internet Directory to Microsoft Active Directory does not depend on the Global Catalog. The Active Directory connector always goes to each Active Directory to synchronize from Oracle Internet Directory to Microsoft Active Directory. You must configure as many export profiles as there are Microsoft Active Directory domains.
|
See Also: "Configuring the Active Directory Connector" and "Configuring the Active Directory Connector" for instructions on configuring synchronization in environments with multiple Microsoft Active Directory domains |
Information in an LDAP directory is organized in a Directory Information Tree (DIT). In this tree, each node is called a directory entry that is identified by a unique value, called a distinguished name (DN).
A part of a tree that serves as a container for other entries is called a subtree. A node of a tree that contains no other entries is called a leaf.
Users and groups are represented as entries and can be either leaf or non-leaf nodes.
To facilitate proper organization of information and to enforce proper access controls in the directory, a top-level DIT structure is configured in the directory during installation. For example, the domain of Oracle Internet Directory is us.MyCompany.com, and a pre-configured default realm value is chosen during installation, then, after installation, the Oracle Internet Directory Configuration Assistant configures a default DIT. This default DIT, shown in Figure 2-1, contains two special entries: users and groups. These two entries are the roots of the two subtrees containing users and groups.
The most important decisions to be made before synchronization are:
What information to synchronize
You can synchronize either the entire DIT or part of it.
Where to synchronize
The Active Directory connector enables you to choose from two possible configurations:
Synchronizing so that the relative position of each entry in the DIT is the same in both the source and destination directories. This configuration, called one-to-one domain mapping, is the most commonly used configuration. It is also the recommended configuration.
Synchronizing so that the relative position of each entry in the DIT is different in the destination directory from that in the source directory. In this configuration, whenever information is synchronized, you must change the DN values of all entries being mapped, including their references in group entries. Doing this can be very expensive.
Figure 2-1 shows an example of one-to-one mapping between the DITs in two directories.
Figure 2-1 Default DIT Structures in Oracle Internet Directory and Microsoft Active Directory when Both Directory Hosts are Under the Domain us.MyCompany.com
In the deployment illustrated in Figure 2-1:
Both Microsoft Active Directory and Oracle Internet Directory hosts are in the same domain, namely, us.MyCompany.com.
Users are synchronized only from Microsoft Active Directory to Oracle Internet Directory. All users to be synchronized are stored in one container in Microsoft Active Directory, namely, users.us.MyCompany.com.
The same DIT structure is maintained in both Microsoft Active Directory and Oracle Internet Directory. All the users appear in the same users subtree identified by the value users.us.MyCompany.com.
In such a deployment, only the users subtree must be synchronized from Microsoft Active Directory to Oracle Internet Directory using one-to-one domain mappings.
To configure the DIT:
Set a mapping rule in the Active Directory synchronization profile used for import operations. In this example, the mapping rule is:
Domain Rule Cn=users, dc=us, cd=MyCompany, dc=comusers.us.MyCompany.com: users.us.MyCompany.com
This mapping rule indicates that only the users container must be synchronized by using one-to-one domain mappings.
The DNs of the user entries in both Microsoft Active Directory and Oracle Internet Directory are identical.
If you choose to synchronize multiple subtrees, then you must configure multiple domain rules.
Set up the default realm, usersearchbase, and groupsearchbase values in Oracle Internet Directory. These values indicate to the various Oracle components where to look for users and groups in Oracle Internet Directory. During installation, be sure to set them correctly. Otherwise, even if the synchronization seems to function properly, components still may not be able to access users and groups in Oracle Internet Directory.
The default realm is set up during installation However, if the default realm value is incorrectly specified during installation, then do the following:
If Oracle Application Server has been installed but not yet deployed, then it is easier to re-install everything with the correct default realm value.
If Oracle Application Server applications have already been deployed, then you must change the default realm.
The usersearchbase and groupsearchbase values refer to the roots of the subtrees in Oracle Internet Directory under which Oracle components look for users and groups. These values are set to default values during installation. However, in deployments requiring integration with Microsoft Active Directory, these values must be reset to the appropriate values, depending on the DIT structure in Active Directory.
For example, in the above example, the value of usersearchbase should be set to at least cn=users,dc=us,dc=MyCompany,dc=com or one of its parents. Similarly, the groupsearchbase can be set to cn=groups,dc=us, dc=MyCompany,dc=com, assuming that there is a subtree named groups in the DIT.
The usersearchbase and groupsearchbase values are set as part of Windows integration setup discussed in "Configuring the Active Directory Connector".
Microsoft Active Directory deployment with multiple domains can have one single DIT or a forest of trees. In this typical scenario, Microsoft Active Directory has multiple domain controllers. A deployment with multiple domain controllers can have one single DIT or a forest of trees. The mapping between the DIT on Oracle Internet Directory and the DIT on Microsoft Active Directory for the single tree and the forest configurations are shown in Figure 2-2 and Figure 2-3, respectively.
Figure 2-2 shows an example of how multiple domains in Microsoft Active Directory are mapped to a DIT in Oracle Internet Directory.
Figure 2-2 Integration of Oracle Internet Directorywith Multiple Domains in Microsoft Active Directory
In Figure 2-2, the Microsoft Active Directory environment has a parent and two child domains. Each domain has a domain controller associated with it. The Microsoft Active Directory supporting the node us.mycompany.com is the Global Catalog Server.
The first child domain-namely, a.us.MyCompany.com—maps to dc=a,dc=us,dc=MyCompany,dc=com in Oracle Internet Directory. The second child domain—namely, b.us.MyCompany.com, maps to dc=b,dc=us,dc=MyCompany,dc=com in Oracle Internet Directory. The common domain component in Microsoft Active Directory environment—namely, us.MyCompany.com—maps to the default identity management realm in Oracle Internet Directory—namely, dc=us,MyCompany,dc=com.
Figure 2-3 shows how a forest in Microsoft Active Directory is reflected in Oracle Internet Directory.
Figure 2-3 Mapping Between Oracle Internet Directory and a Forest in Microsoft Active Directory
In Figure 2-3, Microsoft Active Directory is the enterprise directory. In this directory, two domain trees constitute a forest, and this forest maps to an identically structured subtree in Oracle Internet Directory.
To lists and describes the tools you use to set up and manage integration with Microsoft Active Directory.
Table 2-4 Tools for Setting Up and Managing Integration with Microsoft Active Directory
| Tool | Description |
|---|---|
adprofilecfg.sh |
A shell script that provides an easy way of setting configuration information related to the Windows environment, such as the Microsoft Active Directory host and port information. This tool is useful only in simple scenarios and can be used only to configure information in default profiles. Note that this tool sets the information in all the three default profiles. When you run this tool, it creates the three default profiles, described earlier, from master default profiles and then modifies them with the information it takes as input from the user. Various setup tasks in the next section refer to this tool. This tool resides in $ORACLE_HOME/ldap/odi/admin. |
| Directory Integration and Provisioning Assistant | A command-line tool primarily for initial migration of data. It also enables you to manage synchronization profiles. You can use it to create new default profiles and set various attributes in those profiles. Various setup tasks in next section are refer to this tool.
See Also: Oracle Internet Directory Administrator's Guide, Appendix A, "Syntax for LDIF and Command-Line Tools" for more details about using the Directory Integration and Provisioning Assistant |
| Oracle Internet Directory Self-Service Console | A Web-based GUI tool for use by administrators and end users. In a Windows integration setup, is primarily used to configure information to manage realms and the user group search bases. It is also used to create and manage users and groups.
See Also: Oracle Internet Directory Administrator's Guide, Chapter 31, "Oracle Internet Directory Self-Service Console" for instructions about using this tool to manage realms and user and group search bases |
| Oracle Directory Manager | A standalone Java- based GUI tool for managing all data in Oracle Internet Directory. You can use it to:
See Also: Oracle Internet Directory Administrator's Guide, Chapter 4, "Directory Administration Tools" for more details |
| Command-line tools | Such tools as ldapmodify and ldapsearch for managing synchronization profiles and troubleshooting. Various set up tasks in next section refer to these tools, too. Once you know the various setup requirements for Windows integration, these tools are very handy for quick customization.
See Also: Oracle Internet Directory Administrator's Guide, Appendix A, "Syntax for LDIF and Command-Line Tools" |
There are two common ways of deploying integration with a Microsoft Windows environment. In the first, Oracle Internet Directory is the central enterprise directory and source of truth for user and group data for the Microsoft Windows 2000 and Windows NT environments. In the second, Microsoft Active Directory is the central enterprise directory and source of truth for user and group data for Oracle components.
This section contains these topics:
Deployments with Oracle Internet Directory
Deployments with Microsoft Active Directory as the Central Directory
Table 2-5 describes the typical requirements in this deployment.
Table 2-5 Typical Requirements with Oracle Internet Directory as the Central Directory
| Requirement | Oracle Internet Directory as Central |
|---|---|
| Initial bootstrapping | The Directory Integration and Provisioning Assistant populates Microsoft Active Directory with users and groups stored in Oracle Internet Directory.
If there are multiple Microsoft Active Directory servers, then the Directory Integration and Provisioning Assistant must be run as many times as there are Microsoft Active Directory servers. Each time you do this, you choose the specific data set required by the target Microsoft Active Directory server. |
| Synchronization | User and group information is managed in Oracle Internet Directory. Changes to that information are synchronized with Microsoft Active Directory by the Oracle directory integration and provisioning server.
The less likely synchronization from Microsoft Active Directory into Oracle Internet Directory can be achieved by configuring an import profile. |
| Passwords and password verifiers | Passwords are managed in Oracle Internet Directory by using such Oracle tools as the Oracle Internet Directory Self-Service Console. Password changes are synchronized with Microsoft Active Directory by the Oracle directory integration and provisioning server. However, before this server can synchronize the password changes, the password synchronization must be configured in the mapping rules. If the Oracle environment requires a password verifier, the latter is automatically generated when a new user entry is created or when a password is modified. |
| Oracle Application Server Single Sign-On |
Once the OracleAS Single Sign-On server is configured, users log into the Oracle environment through it.
When called upon by the OracleAS Single Sign-On server to authenticate a user, the Oracle directory server uses credentials available locally. No external authentication is involved. Users must log in only once to access various applications in the Oracle environment. |
| Windows native authentication (autologin) | This can be enabled for Windows-based users by configuring the OracleAS Single Sign-On server in the autologin mode.
When Windows native authentication is configured, Windows users, once they login into the Windows desktop, need not log into the Oracle environment again. |
| Active Directory external authentication plug-in | Because user credentials are managed locally in Oracle Internet Directory, the Active Directory external authentication plug-in is not required. |
New users or groups created in Oracle Internet Directory, are automatically provisioned into the Microsoft Windows environment by the Oracle directory integration and provisioning server. Before this provisioning can take place, a one-way synchronization must be configured between Oracle Internet Directory and Microsoft Active Directory.
If multiple Microsoft Active Directory servers are involved, then the Oracle directory integration and provisioning server provisions users and groups in the respective Microsoft Active Directory servers. Before this provisioning can take place, a one-way synchronization must be configured between Oracle Internet Directory and Microsoft Active Directory.
Table 2-6 describes the typical requirements in this deployment.
Table 2-6 Typical Requirements with Microsoft Active Directory as the Central Directory
| Requirement | Microsoft Active Directory as Central |
|---|---|
| Initial bootstrapping | The Directory Integration and Provisioning Assistant populates Oracle Internet Directory with users and groups stored in Microsoft Active Directory.
If there are multiple Microsoft Active Directory servers, then the Directory Integration and Provisioning Assistant must be run as many times as there are Microsoft Active Directory servers. You can choose to manage user information, including password credentials, only in Microsoft Active Directory. In such deployments, to enable single sign-on in the Oracle environment, the Oracle directory integration and provisioning server can synchronize a minimal set of attributes of the user entry into Oracle Internet Directory. Passwords are not migrated. |
| Synchronization | The source of truth for user and group information is Microsoft Active Directory, and that information is managed there. Changes to user and group information are also synchronized by the Oracle directory integration and provisioning server from Microsoft Active Directory servers into Oracle Internet Directory.
The less likely synchronization from Oracle Internet Directory to Microsoft Active Directory is achieved by configuring an export profile. |
| Passwords and password verifiers | It is assumed that passwords are managed in Microsoft Active Directory by using Microsoft Windows tools. The Oracle directory integration and provisioning server does not synchronize password changes into Oracle Internet Directory.
In this deployment, it is not possible to generate password verifiers that the Oracle environment may require. To make a password verifier available in the Oracle environment, a user enables it to be generated by setting the password in the Oracle environment. However, in this case the Oracle directory server generates a password verifier when a password changes. It does not store the password in the |
| Oracle Application Server Single Sign-On |
Once the OracleAS Single Sign-On server is configured, users log into the Oracle environment through it. To access various components in the Oracle environment, they must log in only once.
Users with credentials only in Microsoft Active Directory are authenticated by the Oracle directory server invoking the external authentication plug-in. Users with credentials in Oracle Internet Directory are authenticated locally by the Oracle directory server. |
| Windows native authentication (autologin) | Same as in Oracle Internet Directory-centered deployment. However, for a user to use autologin, the user must exist in the Microsoft Active Directory.
If Oracle Internet Directory contains some local users, then single sign-on does not function for them if Windows native authentication is enabled. Such users require that the attributes |
| Active Directory external authentication plug-in | Because user credentials are managed in Microsoft Active Directory, this plug-in is required.
When called upon by the OracleAS Single Sign-On server to authenticate a user, the Oracle directory server discovers that the credentials are not available in Oracle Internet Directory. It then invokes the external authentication plug-in. The plug-in performs the authentication of the user against the user credentials stored in Microsoft Active Directory. |
New users or groups created in Microsoft Active Directory are automatically provisioned into Oracle Internet Directory by the Oracle directory integration and provisioning server. Before the provisioning can take place, a one-way synchronization between Microsoft Active Directory and Oracle Internet Directory must be established.
If multiple Microsoft Active Directory servers are involved, then the Oracle directory integration and provisioning server provisions users and groups from the respective Microsoft Active Directory servers into Oracle Internet Directory. Before the provisioning can take place, a one-way synchronization between Oracle Internet Directory and each Microsoft Active Directory server must be established.
Passwords are not migrated.
To successfully set up the integration of Oracle Identity Management with Microsoft Active Directory, do the following:
Determine the kind of synchronization required. You base this determination on:
Whether Oracle Internet Directory or Microsoft Active Directory is to be the source of truth for user and group information
Whether one-way or two-way synchronization is required
Whether single or multiple Microsoft Active Directory domains are to be integrated
In case of multiple domains, whether the Global Catalog is configured in the Microsoft Active Directory environment.
Determine whether the Active Directory external authentication plug-in is required. If it is, then follow the steps in "Configuring the Active Directory Connector".
If you are synchronizing from Microsoft Active Directory to Oracle Internet Directory, and need to track changes in Microsoft Active Directory, then determine the tracking approach by using Table 2-2. The synchronization scenarios described later in "Configuring the Active Directory Connector" are based on the USNChanged approach. However, to use the DirSync approach, the synchronization scenarios requires a minor change that is documented in the scenarios.
If the synchronization scenarios described in section "Configuring the Active Directory Connector" do not meet your requirements, then see "Customizing the Active Directory Connector".
Once you are ready for synchronization, but before you start it, decide whether you need initial migration of data from Microsoft Active Directory to Oracle Internet Directory or from Oracle Internet Directory to Microsoft Active Directory. If you do, then follow the steps in the "Migrating Data Between Directories".
|
See Also: "Configuring the Active Directory Connector" for instructions for setting up various synchronization scenarios |
This section explains how to configure integration with Microsoft Active Directory in various scenarios.
This section contains these topics:
Summary of Active Directory Connector Configuration Scenarios
About the Information You Must Add to the Active Directory Connector
Synchronization Between a Single-Domain Microsoft Active Directory and Oracle Internet Directory
Synchronization Between a Multiple-Domain Microsoft Active Directory and Oracle Internet Directory
The scenarios described in this section share these assumptions:
The default set of attributes installed with Oracle Internet Directory are sufficient for synchronization
Only user and group objects must be synchronized
Migration of users and groups from Microsoft Active Directory is not required
Table 2-7 Scenarios with Single-Domain Microsoft Active Directory Environments
| Scenario# | Synchronization Configuration |
|---|---|
| Scenario1 | Users and groups from Microsoft Active Directory to Oracle Internet Directory |
| Scenario2 | Users and groups from Oracle Internet Directory to Microsoft Active Directory |
| Scenario3 | Two-way synchronization of users and groups between Oracle Internet Directory and Microsoft Active Directory |
Table 2-8 Scenarios with Multiple-Domain Microsoft Active Directory Environments
| Scenario# | Synchronization Configuration |
|---|---|
| Scenario4 | Users and groups from Global Catalog Server to Oracle Internet Directory |
| Scenario5 | Users and groups from Microsoft Active Directory to Oracle Internet Directory without a Global Catalog Server |
| Scenario6 | Users and Groups from Oracle Internet Directory to Microsoft Active Directory |
Each scenario in this section uses an example. These examples rest on the following assumptions:
The synchronization of users and groups between Oracle Internet Directory and Microsoft Active Directory always use one-to-one domain mapping—that is, the DN of the user and group entries are the same in both directories.
Oracle Internet Directory is installed on a host iasdemo.us.mycompany.com. This means that the default realm of Oracle Internet Directory is dc=us,dc=mycompany,dc=com.
The Oracle directory server is running on port 389.
The password for the directory administrator, as chosen during installation of Oracle Internet Directory, was welcome1.
Other tools, namely, the Directory Integration and Provisioning Assistant and adprofilecfg.sh prompt you for a password. The password you should supply is welcome1.
The adprofilecfg.sh prompts you for a super user DN. The value you should supply is dn=orcladmin.
In a single-domain Microsoft Active Directory environment, the host name is addemo.us.mycompany.com. This means that the domain of the Microsoft Active Directory host is the same as the default realm of Oracle Internet Directory as set during installation, namely, dc=us,dc=mycompany,dc=com.
If this is not true, then, during installation of Oracle Internet Directory, the default realm value must be set to correspond to the Microsoft Active Directory domain. In this example, that domain is dc=us,dc=mycompany,dc=com.
If you have already installed Oracle Internet Directory and the default realm does not correspond to the domain of the Microsoft Active Directory host, then Oracle Corporation recommends that you re-install the Oracle Identity Management. As you do this, set the proper value of default realm, otherwise the setup scenarios described in this section fail.
In this section, the examples of multiple-domain Microsoft Active Directory environments use two domains having the host names ad1demo.a.us.mycompany.com and ad2demo.b.us.mycompany.com. This means that the domains of Microsoft Active Directory hosts are respectively dc=a,dc=us,dc=mycompany,dc=com and dc=b,dc=us,dc=mycompany,dc=com.
Further, during installation of Oracle Internet Directory, the default realm value must be set to the parent of the Microsoft Active Directory server domains. In this example, the default realm value is dc=us,dc=mycompany,dc=com. If this is not true, then Oracle Corporation recommends that you re-install Oracle Identity Management. As you do this, set the proper value of default realm, otherwise the setup scenarios described in this section fail.
The scenario described later uses the USNChanged approach for tracking changes in Active Directory. However, if the user wishes to use the DirSync approach, replace the profile ActiveChgImp with the profile activeImport Tasks 1-5 required in this setup.
Every user created from Oracle Internet Directory requires an object class orclADUser to be added the entry, which has a mandatory attribute of orclSAMAccountName. Note that, orclSAMAccountName cannot have any special characters in it. If you are creating users from Oracle Internet Directory Self-Service Console, then you need to modify the user creation property through the Console to include the orclADUser object class and orclSAMAccountName. Further, the value of the attribute orclSAMAccountName could be given as ActiveDirectorydomain$userid.
Most of the configuration information required for enabling synchronization is preconfigured in Oracle Internet Directory during installation. Beyond that preconfigured information, you need to add a minimal amount of information to the Active Directory connector.
The information you must add to the Active Directory connector pertains to the Microsoft Active Directory environment. This information includes:
Microsoft Active Directory URL (host:port)
Microsoft Active Directory user account and password to be used by the Active Directory connector
Microsoft Active Directory domain containing the users and groups to be synchronized
To add this information, you can use either command-line tools or Oracle Directory Manager.
Moreover, if the default realm is changed, then you must re-create the ACLs to enable only the owners of various synchronization profiles to create, modify, and delete entries under the user and group containers. Although default ACLs are created during installation, most often they must be modified to meet the security needs of the deployment. The section "Scenario 1: One-Way Synchronization from Microsoft Active Directory to Oracle Internet Directory" advises you as to when you need to change an ACL.
|
See Also: Oracle Internet Directory Administrator's Guide, Chapter 3, "Preliminary Tasks and Information" for more information about customizing the default access control configuration |
The scenarios described in the next sections use the adprofilecfg.sh tool to configure Microsoft Active Directory-related information into the default profiles. This tool creates three default profiles from master default profiles and then modifies them with the information it receives from the user. If you have already customized one of the default profiles, then the adprofilecfg.sh tool overwrites it. In this case, rename your default profile as described in the next section, "Tasks Common to Various Scenarios".
This section discusses tasks that, in most scenarios, you must perform only once for a given installation. For example, suppose that you are following both Scenario 1 and Scenario 2 described later in this chapter. If, you perform these tasks to set up Scenario 1, then you do not need to perform them again to set up Scenario 2.
To do this, enter the following command against the Microsoft Active Directory server:
ldapsearch -p port -h host -D user account -w password -b "" -s base "objectclass=*" defaultnamingcontext
For example:
ldapsearch -p 389 -h adtest.us.MyCompany.com -D Administrator@us.MyCompany.com -w welcome1 -b "" -s base "objectclass=*" defaultnamingcontext
This should return the domain name of the Microsoft Active Directory server. In our example, the exact output should be:
defaultNamingContext=DC=us,DC=MyCompany,dc=com
This includes adding to the synchronization profile used for synchronization the information explained in "Information Required During Setup".
If you are using the default synchronization profiles, then run the script $ORACLE_HOME/ldap/odi/admin/adprofilecfg.sh to set up the information. The script prompts you for the following:
The Oracle Internet Directory super user DN and password
The Microsoft Active Directory URL (host:port)
The Microsoft Active Directory user account and password to be used by the Active Directory connector
The Microsoft Active Directory domain to be synchronized-for example, cn=users,dc=us,dc=com.
Once you have entered the parameter values, adprofilecfg.sh invokes the Directory Integration and Provisioning Assistant. The Assistant sets up the Microsoft Active Directory connection information and mapping rules information in the default Active Directory synchronization profiles.
|
Note: This step is required only once for all the synchronization scenarios where default profiles are used. |
|
Note:
|
To start the directory integration and provisioning server as you would for synchronization, enter the following command:
oidctl connect=iasdb server=odisrv instance=2 configset=1 flags="port=3060" start
This section describes various scenarios for setting up one-way synchronization of users and groups between a single-domain Microsoft Active Directory and Oracle Internet Directory.
This scenario rests on these assumptions:
Only the default set of attributes must be synchronized from Microsoft Active Directory to Oracle Internet Directory.
No initial migration of data is required, as is typical for demo and test systems.
In general, to set up this scenario, do the following:
Perform Tasks 1 through 3 described in "Tasks Common to Various Scenarios".
If you are synchronizing groups, then perform Tasks 4 through 6 as described in this section.
Task 4: (Required only if you are synchronizing groups) Configure ACLs for Group Synchronization
|
Note: This step is required only if groups are being synchronized. |
This task sets up the proper access controls to enable groups to be created under the users container. To set up the proper access controls, do this:
Create an LDIF file named grantrole.ldif. The sample file is given at the end of this chapter. If the default realm is not dc=us,dc=mycompany,dc=com, then edit the file grantrole.ldif and replace every dc=us,dc=mycompany,dc=com string with the actual default realm—for example, dc=us,dc=YourCompany,dc=com. Save the file.
Enter the command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f grantrole.ldif
For example,
ldapmodify -c -h iasdemo -p 3060 -D cn=orcladmin -w welcome1 -f grantrole.ldif
This configures the required ACL policy in Oracle Internet Directory to enable creation and modification of groups in Oracle Internet Directory.
Task 5: Start the Synchronization from Microsoft Active Directory to Oracle Internet Directory
This requires enabling the respective profile by setting the profileStatus attribute to ENABLE. To do this, enter the command:
Dipassistant mp -profile ActiveChgImp odip.profile.status = ENABLE
Task 6: Verify that Synchronization Has Started
Enter the following command:
ldapsearch -h oid_host -p oid_port -D cn=dipadmin -w orcladmin_password -b "orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory' -s base "objectclass=*" orclodipsynchronizationstatus orclodiplastsuccessfulexecutiontime
Table 2-9 shows the values of the status attributes when synchronization is successfully started.
Table 2-9 Attribute Values Indicating Successful Synchronization
| Attribute | Value Indicating Successful Synchronization |
|---|---|
| Synchronization Status | Synchronization successful |
| Last Successful Execution Time | Date and time (Note: This must be close to the current date and time.) |
An example of a result indicating successful synchronization is:
Synchronization successful November 04, 2003 15:56:03
|
Notes:
|
This scenario rests on the same assumptions as those in "Scenario 1: One-Way Synchronization from Microsoft Active Directory to Oracle Internet Directory", but the synchronization is from Oracle Internet Directory to Microsoft Active Directory. This scenario does not require you to set up any additional information, nor does it require you to set up access controls.
In general, to set up this scenario, do the following:
Perform Tasks 1 through 3 described in "Tasks Common to Various Scenarios".
Perform Tasks 4 and 5 as described in this section.
Task 4: Start the Synchronization from Microsoft Active Directory to Oracle Internet Directory
This requires enabling the respective profile by setting the profileStatus attribute to ENABLE. To do this, enter the command:
Dipassistant mp -profile ActiveChgImp odip.profile.status = ENABLE
Task 5: Verify that Synchronization Has Started
Enter the following command:
ldapsearch -h oid_host -p oid_port -D cn=dipadmin -w orcladmin_password -b "orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory' -s base "objectclass=*" orclodipsynchronizationstatus orclodiplastsuccessfulexecutiontime
Table 2-10 shows the values of the status attributes when synchronization is successfully started.
Table 2-10 Attribute Values Indicating Successful Synchronization
| Attribute | Value Indicating Successful Synchronization |
|---|---|
| Synchronization Status | Synchronization successful |
| Last Successful Execution Time | Date and time (Note: This must be close to the current date and time.) |
An example of a result indicating successful synchronization is:
Synchronization successful November 04, 2003 15:56:03
|
Notes:
|
This section describes setup tasks for a two-domain Microsoft Active Directory environment. In a Microsoft Active Directory environment with more than two domains, the tasks for setting up synchronization for additional domains are similar to those outlined in this section.
|
Note: The Global Catalog can be used only for synchronizing changes from Microsoft Active Directory to Oracle Internet Directory. Further, it can be used only when the USNChanged method is used to track changes in Microsoft Active Directory. |
To illustrate this scenario, we use a sample deployment with two Microsoft Active Directory domain servers:
a.us.MyCompany.com
b.us.MyCompany.com
If there are more than two domains, then the setup procedures are the same as those in Scenario 1, with the exception of Task 4 in which the LDIF file is customized to the actual multiple-domain environment.
In general, to set up this scenario, do the following:
Perform Tasks 1through 3 as described in "Tasks Common to Various Scenarios".
Perform Tasks 4 through 6 as described in this section.
As you perform Tasks 1 through 3, keep these considerations in mind:
In Tasks 1 and 2, make sure that the Microsoft Active Directory host and port information are those where the Global Catalog is running. The default port number on which global catalog is running is 3268.
In Task 2, you must properly supply the value of the Microsoft Active Directory domain. Usually it should be the DN of the entry that is the parent of all the Microsoft Active Directory domains. In our example, this value should be dc=us,dc=MyCompany,dc=com.
Task 4: Create the Appropriate DIT Structure and Configure Required ACLs for User and Group Synchronization
Oracle Internet Directory does not have the complete DIT structure ready for use in a multiple-domain Microsoft Active Directory scenario. It requires performing the following:
Creating some entries in Oracle Internet Directory. In our example, to create the users container for the first domain, it requires creating entries with following DNs:
dc=a,dc=us,dc=mycompany,dc=com dc=b,dc=us,dc=mycompany,dc=com cn=users,dc=a,dc=us,dc=mycompany,dc=com
To create the users container for the second domain requires creating entries with following DN:
cn=users,dc=b,dc=us,dc=mycompany,dc=com
Assigning ACLs to the users containers to allow users and groups to be created under those containers
Reset the User Search Base and Group Search Base to point to the value dc=us,dc=mycompany,dc=com. This allows all Oracle applications to be able to find users and groups in the two users containers.
Creating an LDIF file by named multidomaindit.ldif. This file creates the appropriate DIT structure and the required ACLs for our example.
You can see an example of this file in "multidomaindit.ldif". You can edit this file by replacing sample Microsoft Active Directory domains in this scenario with those in your environment.
To load this file, enter the following command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f multidomaindit.ldif
For example:
ldapmodify -h iasdemo -p 3060 -D cn=orcladmin -p welcome1 -f multidomaindit.ldif
Task 5: Start the Synchronization from Microsoft Active Directory to Oracle Internet Directory
This requires enabling the respective profile by setting the profileStatus attribute to ENABLE. To do this, enter the following command:
Dipassistant mp -profile ActiveChgImp odip.profile.status = ENABLE
Task 6: Verify that Synchronization Has Started
Enter the following command:
ldapsearch -h oid_host -p oid_port -D cn=dipadmin -w orcladmin_password -b "orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory' -s base "objectclass=*" orclodipsynchronizationstatus orclodiplastsuccessfulexecutiontime
A shows the values of the status attributes when synchronization is successfully started.
Table 2-11 Attribute Values Indicating Successful Synchronization
| Attribute | Value Indicating Successful Synchronization |
|---|---|
| Synchronization Status | Synchronization successful |
| Last Successful Execution Time | Date and time (Note: This must be close to the current date and time.) |
An example of a result indicating successful synchronization is:
Synchronization successful November 04, 2003 15:56:03
|
Notes:
|
|
Notes:
|
In general, to set up this scenario, do the following:
On the first Microsoft Active Directory domain, perform Tasks 1 through 3 as described in "Tasks Common to Various Scenarios". You can call this domain, for example, a.MyOracle.com.
Perform Tasks 4 through 9 as described in this section.
As you perform Tasks 1 through 3, keep the following in mind:
In Tasks 1 and 2, make sure that the Microsoft Active Directory host and port information is that of first domain server. In our example, this is a.MyOracle.com.
In Task 2, the value of the Microsoft Active Directory domain must be properly supplied. Usually, this is the DN of the Microsoft Active Directory domain entry. In our example, this value is dc=a,dc=us,dc=MyCompany,dc=com.
Task 4: Create the Appropriate DIT Structure and Configure Required ACLs for User and Group Synchronization
Oracle Internet Directory does not have the complete DIT structure ready for use in a multiple-domain Microsoft Active Directory scenario. It requires performing the following:
Creating some entries in Oracle Internet Directory. In our example, to create the users container for the first domain, it requires creating entries with following DNs:
dc=a,dc=us,dc=mycompany,dc=com dc=b,dc=us,dc=mycompany,dc=com cn=users,dc=a,dc=us,dc=mycompany,dc=com
To create the users container for the second domain requires creating entries with following DN:
cn=users,dc=b,dc=us,dc=mycompany,dc=com
Assigning ACLs to the users containers to allow users and groups to be created under those containers
Reset the User Search Base and Group Search Base to point to the value dc=us,dc=mycompany,dc=com. This allows all Oracle applications to be able to find users and groups in the two users containers.
Creating an LDIF file by named multidomainditimp.ldif. This file creates the appropriate DIT structure and the required ACLs for our example.
You can find an example of this file at "multidomaindit.ldif".
To load this file, enter the following command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f multidomaindit.ldif
For example:
ldapmodify -h iasdemo -p 3060 -D cn=orcladmin -p welcome1 -f multidomaindit.ldif
Task 5: Rename a Profile
Renaming a profile requires:
Adding permissions for it in the directory. The permissions allow the directory integration and provisioning server to add, modify, and delete users and groups on behalf of the connector using the renamed profile.
Removing permissions for the old profile
For example, using the sample file in the section "renameprofile.ldif", create a profile with the name renameprofile.ldif. The sample profile assumes that you are renaming a default import profile from ActiveChgImp to ActiveChgImp1. Do the following:
Modify the LDIF file to replace the names ActiveChgImp and ActiveChgImp1 with your profile names.
Enter the following command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f renameprofile.ldif
For example:
ldapmodify -h iasdemo -p 3060 -D cn=orcladmin -p welcome1 -f renameprofile.ldif
Task 6: Create Another Profile for the Second Microsoft Active Directory Domain Server (b.MyCompany.com)
To do this, enter the following command:
Dipassistant cp $ORACLE_HOME/ldap/odi/conf/activechgimp.properties
This creates another profile named ActiveChgImp.
Task 7: On the New Profile, Perform Tasks 1 and 2
On the second directory domain, namely, b.MyOracle.com, perform Tasks 1 and 2 as described in "Tasks Common to Various Scenarios". Keep the following in mind:
In Tasks 1 and 2, make sure that the Microsoft Active Directory host and port information is that of second domain server. In our example, this is b.MyOracle.com.
In Task 2, the value of the Microsoft Active Directory domain must be properly supplied. Usually, it should be the DN of the Microsoft Active Directory domain entry. In the example described above, this value should be dc=b,dc=us,dc=MyCompany,dc=com.
Task 8: Start the Synchronization from Microsoft Active Directory to Oracle Internet Directory
This requires enabling the respective profile by setting the profileStatus attribute to ENABLE.
To start the synchronization enter the command:
Dipassistant mp -profile ActiveChgImp odip.profile.status = ENABLE
Dipassistant mp -profile ActiveChgImp1 odip.profile.status = ENABLE
This starts the synchronization from both Microsoft Active Directory domains to Oracle Internet Directory.
Task 9: Verify that Synchronization Has Started
Enter the following command:
ldapsearch -h oid_host -p oid_port -D cn=dipadmin -w orcladmin_password -b "orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory' -s base "objectclass=*" orclodipsynchronizationstatus orclodiplastsuccessfulexecutiontime
Table 2-12 shows the values of the status attributes when synchronization is successfully started.
Table 2-12 Attribute Values Indicating Successful Synchronization
| Attribute | Value Indicating Successful Synchronization |
|---|---|
| Synchronization Status | Synchronization successful |
| Last Successful Execution Time | Date and time (Note: This must be close to the current date and time.) |
An example of a result indicating successful synchronization is:
Synchronization successful November 04, 2003 15:56:03
|
Notes:
|
|
Notes:
|
In general, to set up this scenario, do the following:
On the first Microsoft Active Directory domain, perform Tasks 1 through 3 as described in "Tasks Common to Various Scenarios". You can call this domain, for example, a.MyOracle.com.
Perform Tasks 4 through 9 as described in this section.
As you perform Tasks 1 through 3, keep the following in mind:
In Tasks 1 and 2, make sure that the Microsoft Active Directory host and port information is that of first domain server. In our example, this is a.MyOracle.com.
In Task 2, the value of the Microsoft Active Directory domain must be properly supplied. Usually, this is the DN of the Microsoft Active Directory domain entry. In our example, this value is dc=a,dc=us,dc=MyCompany,dc=com.
Task 4: Create the Appropriate DIT Structure and Configure Required ACLs for User and Group Synchronization
Oracle Internet Directory does not have the complete DIT structure ready for use in a multiple-domain Microsoft Active Directory scenario. It requires performing the following:
Creating some entries in Oracle Internet Directory. In our example, to create the users container for the first domain, it requires creating entries with following DNs:
dc=a,dc=us,dc=mycompany,dc=com dc=b,dc=us,dc=mycompany,dc=com cn=users,dc=a,dc=us,dc=mycompany,dc=com
To create the users container for the second domain requires creating entries with following DN:
cn=users,dc=b,dc=us,dc=mycompany,dc=com
Assigning ACLs to the users containers to allow users and groups to be created under those containers
Reset the User Search Base and Group Search Base to point to the value dc=us,dc=mycompany,dc=com. This allows all Oracle applications to be able to find users and groups in the two users containers.
Creating an LDIF file by named multidomainditimp.ldif. This file creates the appropriate DIT structure and the required ACLs for our example.
You can find an example of this file at "multidomaindit.ldif".
To load this file, enter the following command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f multidomaindit.ldif
For example:
ldapmodify -h iasdemo -p 3060 -D cn=orcladmin -p welcome1 -f multidomaindit.ldif
Task 5: Rename a Profile
Renaming a profile requires:
Adding permissions for it in the directory. The permissions allow the directory integration and provisioning server to add, modify, and delete users and groups on behalf of the connector using the renamed profile.
Removing permissions for the old profile
For example, using the sample file in the section "renameprofile.ldif", create a profile with the name renameprofile.ldif. The sample profile assumes that you are renaming a default export profile from ActiveExport to ActiveExport1. Do the following:
Modify the LDIF file to replace the names ActiveChgImp to ActiveExport and ActiveChgImp1 to ActiveExport1.
Enter the following command:
ldapmodify -h host -p port -D DN of orcladmin -p password -f renameprofile.ldif
For example:
ldapmodify -h iasdemo -p 3060 -D cn=orcladmin -p welcome1 -f renameprofile.ldif
Task 6: Create Another Profile for the Second Microsoft Active Directory Domain Server (b.MyCompany.com)
To do this, enter the following command:
Dipassistant cp $ORACLE_HOME/ldap/odi/conf/activeexport.properties
This creates another profile named ActiveExport.
Task 7: On the New Profile, Perform Tasks 1 and 2
On the second directory domain, namely, b.MyOracle.com, perform Tasks 1 and 2 as described in "Tasks Common to Various Scenarios". Keep the following in mind:
In Tasks 1 and 2, make sure that the Microsoft Active Directory host and port information is that of second domain server. In our example, this is b.MyOracle.com.
In Task 2, the value of the Microsoft Active Directory domain must be properly supplied. Usually, it should be the DN of the Microsoft Active Directory domain entry. In the example described above, this value should be dc=b,dc=us,dc=MyCompany,dc=com.
Task 8: Start the Synchronization from Microsoft Active Directory to Oracle Internet Directory
This requires enabling the respective profile by setting the profileStatus attribute to ENABLE.
To start the synchronization enter the command:
Dipassistant mp -profile ActiveExport odip.profile.status = ENABLE Dipassistant mp -profile ActiveExport1 odip.profile.status = ENABLE
This starts the synchronization from both Microsoft Active Directory domains to Oracle Internet Directory.
Task 9: Verify that Synchronization Has Started
Enter the following command:
ldapsearch -h oid_host -p oid_port -D cn=dipadmin -w orcladmin_password -b "orclodipagentname=ActiveExport,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory' -s base "objectclass=*" orclodipsynchronizationstatus orclodiplastsuccessfulexecutiontime
Table 2-13 shows the values of the status attributes when synchronization is successfully started.
Table 2-13 Attribute Values Indicating Successful Synchronization
| Attribute | Value Indicating Successful Synchronization |
|---|---|
| Synchronization Status | Synchronization successful |
| Last Successful Execution Time | Date and time (Note: This must be close to the current date and time.) |
An example of a result indicating successful synchronization is:
Synchronization successful November 04, 2003 15:56:03
|
Notes:
|
If you are storing passwords in Microsoft Active Directory, then you must use the Active Directory external authentication plug-in to authenticate Microsoft Active Directory users from Oracle Internet Directory.
This section tells how to install and enable the Active Directory external authentication plug-in.
For the most part, these instructions are the same for setting up the plug-in both single-domain and multiple-domain Microsoft Active Directory environments. There is, however, one difference: In a multiple-domain environment, the external authentication plug-in requires the Microsoft Active Directory Global Catalog Server.
This section contains these topics:
Installing Active Directory External Authentication Plug-ins
Enabling the Active Directory External Authentication Plug-ins
To install the plug-in:
Execute $ORACLE_HOME/ldap/admin/oidspadi.sh.
|
Note: To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:
|
To execute oidspadi.sh, enter:
cd $ORACLE_HOME/ldap/admin sh oidspadi.sh
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
Enter the Microsoft Active Directory host name. This is the Microsoft Active Directory to which you are going to synchronize. This value is required.
Enter the Microsoft Active Directory port number. In a multiple domain environment, the default port can be that of the global catalog server, namely, 3268.
Enter directory server host name. This value is required.
Enter directory server port number. The default port is 389.
Enter the password of the Oracle administrator (orcladmin). This value is required.
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 Microsoft Active Directory. Note that this need not necessarily be the User Search Base supplied in Oracle Internet Directory Self-Service Console. All the users under this search base are authenticated externally to the Microsoft Active Directory. If more than one container is specified, then separate the DNs with semi-colons (;).
Enter the value of the entry that is to be excluded from authentication to Microsoft Active Directory. This value is the exception to Step 7 the distinguished name of the container to which the plug-in needs to be ap. 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 7 that has the cn=orcladmin and objectclass=inetorgperson attribute values will not be authenticated to Microsoft Active Directory.
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 vale for the Plug-in Request Group DN, then only requests coming from members of the Oracle 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.
Enter the choice of using SSL connection to Active Directory or not. If you choose to use SSL, then you need to enter the following:
The Active Directory SSL connection port number.
The location of the Oracle wallet. This wallet needs to have the valid certificate from the 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 backslash (\). For example, if the wallet location is D: storage\wallet, then enter D:\\storage\\wallet.
Specify the backup Microsoft Active Directory domain controller details (optional).
To enable the Active Directory external authentication plug-ins, use these two commands:
ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhencompare,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhenbind,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF
The section "Configuring the Active Directory Connector" describes how to configure the Active Directory connector in a simple deployment that requires minimal configurations beyond the default ones. However, your deployment may be more complex and require you to customize the connector configurations.
|
Note: Be sure that yourORACLE_HOME is set to the correct value, otherwise the commands specified in various scenarios do not function properly. |
This section describes various customizations a deployment may require. It contains these topics:
A deployment may require you to create new profiles instead of using the default profiles. It may also require you to modify the configurations in these profiles. There are three tools available for creating new profiles. These are:
The Directory Integration and Provisioning Assistant, a command-line tool for creating profiles and setting various configuration parameters (attributes) in a profile.
The script adprofilecfg.sh that creates the default profiles and sets the minimal information required for the Microsoft Active Directory environment into all the default profiles. This minimal information includes, for example, the Microsoft Active Directory host and port information.
Oracle Directory Manager, a standalone Java-based GUI tool that enables you to create, modify, and delete profiles. This is suitable when a deployment requires extensive customization.
|
See Also:
|
You must customize mapping rules when you need to:
Change domain-level mappings. The domain-level mappings establish how the DIT from Microsoft Active Directory maps to that of Oracle Internet Directory.
Change what attributes needs to be synchronized.
Change what transformations (mapping rules) are required to be performed while synchronizing them from the source directory to the target directory.
An example of domain level mapping is:
DomainRules %USERBASE%:%USERBASE%:
USERBASE refers to the container from which the Microsoft Active Directory users and groups must be mapped. Usually, this is the users container under the root of the Microsoft Active Directory domain.
For example, if the Microsoft Active Directory host is in the domain us.mycompany.com, then the root of the Microsoft Active Directory domain is us.mycompany.com and a user container under the domain would have a DN value cn=users, dc=us,dc=mycompany,dc=com.
For one-to-one domain mapping between Microsoft Active Directory and Oracle Internet Directory, Oracle Internet Directory must be installed with a default realm value of dc=us,dc=mycompany,dc=com that would automatically contain a users container under the default realm with a DN value cn=users,dc=us,dc=mycompany,dc=com. This enables one-to-one domain mapping between Microsoft Active Directory and Oracle Internet Directory.
If you plan to synchronize only the users under us.mycmpany.com, then the domain mapping rule is:
DomainRules cn=users, dc=us, dc=mycompany, dc=com :cn=users, dc=us, dc=mycompany, dc=com
This rule enables only the users container to be synchronized. Any changes to other entries outside users container are not synchronized.
If you later want to synchronize other objects in the domain, the rule can change to
DomainRules dc=us, dc=mycompany, dc=com :dc=us, dc=mycompany, dc=com
This rule enables every entry under dc=us,dc=mycompany,dc=com to be synchronized.
An example of attribute-level mapping is:
SAMAccountName:1: :user:orclADSAMAccountName: :orclADUser userPrincipalName: : :user:orclADUserPrincipalName: :orclADUser:name|userPrincipalName
Here, SAMAccountName and userPrincipalName from Microsoft Active Directory are mapped to orclADSAMAccountName and orclADUserPrincipalName respectively.
Adding another attribute to be synchronized requires adding another rule as indicated above. Similarly, if an attribute is no longer to be synchronized, then the corresponding rule simply needs to be removed or commented out.
Customizing the mapping rules requires:
Editing the mapping rules file stored under "" to make necessary modifications as discussed above.
Once the changes are complete, running the following command:
dipassistant mp -profile profile_name -host oid_host -port oid_port -dn DN -passwd password odip.profile.mapfile=path_name
For example:
dipassistant mp -profile ActiveChgImp -host iasdemo.us.oracle.com -port 3060 -dn cn=orcladmin -passwd welcome1 odip.profile.mapfile= activechgimp.map
A sample map file is located in the directory $ORACLE_HOME/ldap/odi/conf with the extension of map.master for the various profiles.
By default, the Active Directory connector pulls changes in all the types of objects from the container configured for synchronization. However, if a deployment is interested only in a certain types of changes—for example, only users and groups—then this can be easily achieved by configuring a search filter. The filter is used by the Active Directory connector to filter changes that are not required when it polls the Active Directory for changes. There is an attribute, named searchfilter, in the synchronization profile which stores the filter.
For example, if you are synchronizing changes to users and groups but not Computers objects, then the value of the searchfilter attribute should be: searchfilter=(|(objectclass=group)(&(objectclass=user)(!(objectclass=computer))).
You can use Oracle Directory Manager or the Directory Directory Integration and Provisioning Assistant to update this attribute.
The Active Directory connector enables secure synchronization between Oracle Internet Directory and Microsoft Active Directory by using SSL between the two servers. Whether to synchronize in the SSL mode depends on the deployment requirements. For example, synchronizing public data does not require SSL. However, synchronizing sensitive information such as passwords requires SSL. The security settings (hard settings) enable you to synchronize password changes from Oracle Internet Directory to Microsoft Active Directory only in SSL mode with server-only Authentication-that is, SSL Mode 2.
Securing the channel requires:
SSL between Oracle Internet Directory and the Oracle directory integration and provisioning server
SSL between Oracle directory integration and provisioning server and Microsoft Active Directory
Although you can enable SSL between Oracle Internet Directory and the Oracle directory integration and provisioning server, or between the Oracle directory integration and provisioning server and Oracle Internet Directory, Oracle Corporation recommends that you completely secure the channel before synchronizing sensitive information. In some cases, such as password synchronization, the synchronization can happen only over SSL.
Configuring SSL requires the following:
Running the Oracle directory server in the SSL mode as described in Oracle Internet Directory Administrator's Guide, Chapter 13, "Secure Sockets Layer (SSL) and the Directory"
Running the Oracle directory integration and provisioning server in the SSL mode as described in Oracle Internet Directory Administrator's Guide Chapter 36, "Security in the Oracle Directory Integration and Provisioning Platform". The SSL mode should be same under which Oracle Internet Directory server was started. The sslauth parameter to be specified when starting the Oracle directory integration and provisioning server will be 1 or 2 depending on whether the SSL communication is based on no authentication or server-only authentication.
Running the Microsoft Active Directory server in the SSL mode. Communication with Microsoft Active Directory over SSL requires SSL Mode 2—that is, server-only authentication. This requires Oracle Internet Directory as well as Directory Integration & Provisioning Server also be run in SSL mode 2.
Certificates for both Oracle Internet Directory and Microsoft Active Directory and a wallet to store them. See Oracle Internet Directory Administrator's Guide, Chapter 13, "Secure Sockets Layer (SSL) and the Directory" for more details.
|
Note: Oracle Application Server 10g does not support SSL in the client-server authentication mode |
You can synchronize passwords from Oracle Internet Directory to Microsoft Active Directory or the reverse.
Before the Active Directory connector can synchronize passwords in this direction, the following are required:
Adding a mapping rule in the mapping file that enables password synchronization. For example, the mapping rule could be:
Userpassword: : :person:unicodepwd: :user
Enabling the password policy and the reversible password encryption in the Oracle directory server. This, in turn, requires setting to a value of 1the orclPwdPolicyEnable and orclpwdEncryptionEnable attributes in the entry cn=PwdPolicyEntry,cn=common,cn=products,DN of realm. This can be done either from Oracle Directory Manager or by the ldapmodify command.
Starting these servers in the SSL Mode 2 (server authentication):
Oracle directory server
Oracle directory integration and provisioning server
Microsoft Active Directory server
Synchronizing passwords from Microsoft Active Directory to Oracle Internet Directory is not possible in the Oracle Application Server 10g release because passwords in Microsoft Active Directory are not accessible by LDAP clients. However, if a deployment requires passwords to be available in Oracle Internet Directory, then the following two methods are recommended:
Build a custom plug-in for Microsoft Active Directory that captures a password change and synchronizes it with Oracle Internet Directory
Manage Active Directory passwords from the Oracle environment. This enables passwords to be available in both Oracle Internet Directory and Microsoft Active Directory because the Active Directory connector can synchronize passwords from Oracle Internet Directory to Microsoft Active Directory.
The default ACLs enable creating, modifying, and deleting users and groups only. Further, they enable users and groups to be created only in the users and groups containers under the default realm.
Customizing the access control lists (ACLs) is required if:
You need to synchronize objects other than users and groups
The containers under which users and groups are synchronized are different from the designated containers. This can be the case when either the preferred containers are not users and groups containers, or they are not under the default realm.
|
See Also: Oracle Internet Directory Administrator's Guide, Chapter 14, "Directory Access Control" for instructions on customizing ACLs |
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
Customizing the LDAP schema requires:
Identifying the schema extensions on the source directory
Creating those extensions on the target directory before starting the data migration and the synchronization.
|
Note: Besides creating schema extensions, the attribute which will be required for synchronization also needs to be added into the mapping rules. |
Once the Active Directory connector and Plug-in configurations are complete, do the following:
Identify the data you want to migrate. You can choose to migrate the entire data in the directory or only a subset.
Make sure that the synchronization is not enabled yet.
Migrate data from one directory to another by using the Directory Integration and Provisioning Assistant with the bootstrap option. Bootstrapping is described in Oracle Internet Directory Administrator's Guide, Chapter 37, "Bootstrapping of a Directory in the Oracle Directory Integration and Provisioning Platform".
Once bootstrapping is accomplished, the profile status attributes are appropriately updated in the synchronization profile by the Directory Integration and Provisioning Assistant.
If you have used LDIF file-based bootstrapping, then you need to initialize the lastchangenumber value. This can be done by using the Directory Integration and Provisioning Assistant as follows:
Dipassistant mp -updlcn
This lastchangenumber attribute should be set to the value of the last change number in the source directory before you started the bootstrap.
If two-way synchronization is required, then enable the export profile and make sure that 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 shut down the Oracle directory server and start with the change log enabled by using the Oracle Internet Directory Control Utility.
This section contains these topics:
Typical Management Tasks
Managing the Active Directory External Authentication Plug-in
Typical ongoing management tasks include:
Managing synchronization profiles and mapping rules. This includes:
Creating new profiles
Changing configurations (attributes) in the profile
Disabling profiles to allow maintenance and then re-enabling them. Disabling profiles stops synchronization related to that profile.
Managing mapping rules. This includes:
Creating new rules when additional attributes needs to be synchronized
Changing existing rules when the way attributes are synchronized needs to change
Deleting or commenting out rules not required when a particular attribute is not required to be synchronized
Managing Access Controls
Starting and stopping the Oracle directory server and the Oracle directory integration and provisioning server
|
See Also:
|
This section explains how to delete, disable, and re-enable the Active Directory external authentication plug-in.
To delete the Active Directory external authentication plug-in, use these commands.
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"
To disable the Microsoft Active Directory external authentication plug-ins, use these two commands:
ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhencompare,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 0 EOF ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhenbind,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 0 EOF
To re-enable the Active Directory external authentication plug-ins, use these two commands:
ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhencompare,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=adwhenbind,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF
Microsoft Windows NT domain users can also be integrated into the environment. Microsoft Windows NT groups are not synchronized to Oracle Internet Directory, nor is information about the members of that group. In this case, each of the Microsoft Windows NT domains can be mapped to a domain object or an organization unit object in Oracle Internet Directory. Typical mapping of Microsoft Windows NT domains to domain containers in the Oracle Internet Directory directory information tree is shown in Figure 2-4.
Figure 2-4 Integration of Oracle Internet Directory DIT with Microsoft Windows NT Domains
Microsoft Windows NT domains are integrated with Oracle Internet Directory so that a minimal user footprint is automatically created in Oracle Internet Directory.
If a user entry exists in Microsoft Windows NT but not in Oracle Internet Directory, then, when that user tries to log in to use the Oracle Application Server components, the auto-registration plug-in creates a shadow entry with minimal footprint information in Oracle Internet Directory. This entry remains in Oracle Internet Directory for the next time the same user tries to log in.
External authentication, with Microsoft Windows NT acting as the external repository, is supported by the use of plug-ins. Ongoing synchronization with the Microsoft Windows NT environment is not supported.
The SQL script oidspnti.sql installs the plug-ins that enable Oracle Internet Directory for external authentication against the Microsoft Windows primary domain controller and auto provisioning.
To install the script:
Verify that the Oracle Internet Directory server is running.
Run the script by entering the following command:
cd $ORACLE_HOME/ldap/admin sh oidpnti.sh
Enter the Oracle Internet Directory host name and port number. The default port number is 389.
Enter the password of the Oracle administrator (orcladmin), the directory super user.
Enter the distinguished name of the container to which the plug-in needs to be applied. Every entry in this container is then authenticated against the Microsoft Windows NT domain. Note that this need not necessarily be the user search base supplied in the Oracle Internet Directory Self-Service Console. All the users under this search base are authenticated externally to the Microsoft Windows NT domain. If more than one value is specified, then use semi-colons (;) to separate them.
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 value for the plug-in request group DN, then only the requests coming from Oracle 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, should be specified.
Choose Auto Registration. The default is Yes. Upon registration, each entry is assigned the object class orclNTUser.
At the completion of these steps, the plug-in is installed and enabled.
Enabling the Windows NT External Authentication Plug-in
To enable external authentication, enter these two commands:
ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=ntwhencompare,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=ntwhenbind,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF
Disabling the Windows NT External Authentication Plug-in
To disable the external authentication plug-ins, set the value of the attribute orclpluginenable to 0 in each of the preceding command.
Enabling Auto Provisioning
To enable auto provisioning, enter the following command:
ldapmodify -h host -p port -D cn=orcladmin -w password <<EOF dn: cn=ntpostsearch,cn=plugin,cn=subconfigsubentry changetype: modify replace: orclpluginenable orclpluginenable: 1 EOF
Disabling Auto Provisioning
To disable auto provisioning, set the value of the attribute orclpluginenable to 0 in the preceding command.
Removing Active Directory External Authentication and Auto Provisioning Plug-ins
To remove external authentication and auto-registration, delete the two plug-in entries from Oracle Internet Directory:
ldapdelete -h host -p port D cn=orcladmin -w password "cn=ntwhencompare,cn=plugin,cn=subconfigsubentry" ldapdelete -h host -p port -D cn=orcladmin -w password "cn=ntwhenbind,cn=plugin,cn=subconfigsubentry" ldapdelete -h host -p port -D cn=orcladmin -w password "cn=ntpostsearch,cn=plugin,cn=subconfigsubentry"
Active Directory External Authentication Plug-in Debugging
If you are experiencing unknown errors, then you can enable the plug-in debugging. To do this:
sqlplus ods/odspassword @$ORACLE_HOME/ldap/admin/oidspdon.pls
To check the plug-in debugging log:
sqlplus ods/ods select * from plg_debug_log order by id;
To delete the plug-in debugging log:
sqlplus ods/ods truncate table plg_debug_log
To disable the plug-in debugging:
sqlplus ods/ods @$ORACLE_HOME/ldap/admin/oidspdof.pls
|
Note: If you need to change the Active directory external authentication plug-in setup—that is, the information you entered in the installation steps—then rerun the installation script. Before you rerun the script, remove the Active directory external authentication plug-ins by following the preceding instructions. |
This section contains these topics:
Troubleshooting Synchronization with Active Directory Connector
Microsoft Active Directory External Authentication Plug-in
You can debug the Active Directory connector by using the oditest utility.
To troubleshoot the Active Directory connector
Run oditest specifying AgentName as ProfileName
Look at the files ProfileName.trc and ProfileName.aud
If more than one profiles are enabled, then the tool can be run against each of them.
|
See Also: Oracle Internet Directory Administrator's Guide, Chapter 33, "Oracle Directory Synchronization Service" for instructions on using theoditest utility |
If you are experiencing unknown errors, then you can enable the plug-in debugging. To do this, enter:
sqlplus ods/odspassword @$ORACLE_HOME/ldap/admin/oidspdon.pls
To check the plug-in debugging log, enter:
sqlplus ods/ods select * from plg_debug_log order by id;
To delete the plug-in debugging log:
sqlplus ods/ods truncate table plg_debug_log
To disable the plug-in debugging:
sqlplus ods/ods @$ORACLE_HOME/ldap/admin/oidspdof.pls
This section contains these sample LDIF files:
# This ACL policy grants access to privilaged users to create groups under the container # cn=users,dc=us,dc=mycompany,dc=com which is the container for creating users dn: cn=Users,dc=us,dc=mycompany,dc=com changetype: modify add: orclaci orclaci: access to entry by group="cn=IASAdmins, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclcontainer) (browse,add) orclaci: access to entry by group="cn=oracledascreategroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup*) (browse,add) by group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (browse) orclaci: access to entry filter=(&(objectclass=orclgroup)(orclisvisible=false)) by groupattr=(owner) (browse, add, delete) by dnattr=(owner) (browse, add, delete) by group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (browse) by * (none) orclaci: access to entry filter=(&(objectclass=orclgroup)(!(orclisvisible=false))) by group="cn=oracledascreategroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup) (browse,add) by group="cn=oracledasdeletegroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (browse,delete) by group="cn=oracledaseditgroup, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (browse) by groupattr=(owner) (browse, add, delete) by dnattr=(owner) (browse, add, delete) by group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (browse) orclaci: access to attr=(*) filter=(&(objectclass=orclgroup)(orclisvisible=false)) by groupattr=(owner) (read,search,write,compare) by dnattr=(owner) (read,search,write,compare) by * (none) by group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, search, compare) orclaci: access to attr=(*) filter=(&(objectclass=orclgroup)(!(orclisvisible=false))) by groupattr=(owner) (read,search,write,compare) by dnattr=(owner) (read,search,write,compare) by group="cn=oracledaseditgroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read,search,write,compare) by group="cn=Common Group Attributes, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, search, compare) dn: cn=Users,dc=us,dc=mycompany,dc=com changetype: modify add: orclentrylevelaci orclentrylevelaci: access to entry by group="cn=oracledascreategroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup) (browse, add) by group="cn=IASAdmins, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclcontainer) (browse,add) by * (browse)
#Add the users container _dn: dc=a,dc=us,dc=mycompany,dc=com _changetype: add _dc: a _objectclass: domain _ _dn: cn=users,dc=a,dc=us,dc=mycompany,dc=com _changetype: add _cn: users _objectclass: orclcontainer dn: dc=b,dc=us,dc=mycompany,dc=com changetype: add dc: b objectclass: domain dn: cn=users,dc=b,dc=us,dc=mycompany,dc=com changetype: add cn: users objectclass: orclcontainer # ACLS for Users #Add the acls to create/delete/modify user entries in the users container dn: cn=users,dc=a,dc=us,dc=mycompany,dc=com changetype: modify add: orclaci #ACL to add user objects orclaci: access to entry by group = "cn=oracledascreateuser,cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orcluser*) (browse,add) #ACL to delete user objects orclaci: access to entry by group="cn=oracledasdeleteuser, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orcluser*) (browse,delete) #ACL to modify user objects orclaci: access to attr = (*) by group="cn=orcldasedituser, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, write, search, compare) by self (read,search,write,compare) by * (noread, nowrite, nocompare) #Add the acls to create/delete/modify user entries in the users container dn: cn=users,dc=b,dc=us,dc=mycompany,dc=com changetype: modify add: orclaci #ACL to add user objects orclaci: access to entry by group = "cn=oracledascreateuser,cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orcluser*) (browse,add) #ACL to delete user objects orclaci: access to entry by group="cn=oracledasdeleteuser, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orcluser*) (browse,delete) #ACL to modify user objects orclaci: access to attr = (*) by group="cn=orcldasedituser, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, write, search, compare) by self (read,search,write,compare) by * (noread, nowrite, nocompare) #Change the usersearchbase to point to dc=us,dc=mycompany,dc=com dn: cn=common, cn=products,cn=oraclecontext,dc=us,d=mycompany,dc=com changetype: modify replace: orclCommonUserSearchBase orclCommonUserSearchBase: dc=us,dc=mycompany,dc=com #ACLS for Groups #Add the acls to create/delete/modify group entries in the users container dn: cn=users,dc=a,dc=us,dc=mycompany,dc=com changetype: modify add: orclaci #ACL to add group objects orclaci: access to entry by group = "cn=oracledascreategroup,cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup*) (browse,add) #ACL to delete group objects orclaci: access to entry by group="cn=oracledasdeletegroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup*) (browse,delete) #ACL to modify group objects orclaci: access to attr = (*) by group="cn=orcldaseditgroup, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, write, search, compare) by self (read,search,write,compare) by * (noread, nowrite, nocompare) #Add the acls to create/delete/modify group entries in the users container dn: cn=users,dc=b,dc=us,dc=mycompany,dc=com changetype: modify add: orclaci #ACL to add group objects orclaci: access to entry by group = "cn=oracledascreategroup,cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup*) (browse,add) #ACL to delete group objects orclaci: access to entry by group="cn=oracledasdeletegroup, cn=groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" added_object_constraint=(objectclass=orclgroup*) (browse,delete) #ACL to modify group objects orclaci: access to attr = (*) by group="cn=orcldaseditgroup, cn=Groups,cn=OracleContext,dc=us,dc=mycompany,dc=com" (read, write, search, compare) by self (read,search,write,compare) by * (noread, nowrite, nocompare #Change the GroupSearchBase to point to dc=us,dc=mycompany,dc=com dn: cn=common, cn=products,cn=oraclecontext,dc=us,d=mycompany,dc=com changetype: modify replace: orclCommonGroupSearchBase orclCommonGroupSearchBase: dc=us,dc=mycompany,dc=com
#Modify the name of the profile dn: orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory changetype: modrdn newrdn: activechgimp1 deleteoldrdn: 1 #Remove the privileges given to the old profile and add the privileges to the new profile dn: cn=odipgroup,cn=odi,cn=oracle internet directory changetype: modify delete: uniquemember uniquemember: orclodipagentname=activechgimp,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory - add: uniquemember uniquemember: orclodipagentname=activechgimp1,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory You must include an introductory element, such as a Para, before inserting the first Sect1 element. This requirement prevents arriving at an empty XHTML page for the chapter if you have selected the option of breaking at Sect1 when generating XHTML output
