23
Oracle Directory Integration and Provisioning

This chapter describes the issues associated with Oracle Directory Integration and Provisioning. It includes the following topics:

• Section 23.1, "Configuration Issues and Workarounds"

• Section 23.2, "Administration Issues and Workarounds"

• Section 23.3, "Documentation Errata"

23.1 Configuration Issues and Workarounds

This section describes configuration issues and their workarounds for Oracle Directory Integration and Provisioning. It includes the following topics:

• Section 23.1.1, "Specify Encoding in the Property File Before Using the Directory Integration and Provisioning Assistant"

• Section 23.1.2, "When a Directory Integration Profile Is Created by Using Oracle Directory Manager, ACIs Are not Set Up Correctly"

• Section 23.1.3, "Align the Location of the Default Identity Management Realm with the Third-Party Directory Domain"

• Section 23.1.4, "Directory Integration and Provisioning Server Status Post-Installation"

• Section 23.1.5, "Two Oracle Internet Directory Plug-in Features Are not Supported after Upgrade from Oracle Internet Directory Release 9.2"

23.1.1 Specify Encoding in the Property File Before Using the Directory Integration and Provisioning Assistant

You must specify the encoding used by an LDIF if the file:

• Is generated by using a utility of a third-party directory

• Contains NLS data

• Is processed on a different platform

This is because, by default, the Directory Integration and Provisioning Assistant assumes that the file is processed on the system on which it was generated.

To specify encoding, use the odip.bootstrap.srcenc property of the configuration property file used for bootstrapping. For more details, see the Directory Integration and Provisioning Assistant documentation in Chapter 37 of the Oracle Internet Directory Administrator's Guide.

23.1.2 When a Directory Integration Profile Is Created by Using Oracle Directory Manager, ACIs Are not Set Up Correctly

When a profile is created using the Create Like functionality in Oracle Directory Manager, the ACIs are not copied properly. The workaround is as follows:

1. Create LDIF file profileacl.ldif:

   dn: orclODIPAgentName=<Profile Name>,cn=subscriber profile,cn=changelog 
   subscriber, cn=oracle internet directory
   changetype: modify
   replace: orclaci
   orclaci: access to attr = (*) by group="cn=odisgroup,cn=odi,cn=oracle 
   internet directory" (read,write,search,compare)
   orclaci: access to entry by group="cn=odisgroup,cn=odi,cn=oracle internet 
   directory" (browse,proxy)
   
   

   Upload the file:

   $ORACLE_HOME/bin/ldapmodify -h <OID host> -p <OID port> -D <OID superuser> 
   -w <OID superuser password> -v -f profileacl.ldif 
   
   

23.1.3 Align the Location of the Default Identity Management Realm with the Third-Party Directory Domain

If you are installing the Oracle Identity Management infrastructure with the aim of eventually synchronizing with a third-party directory, then align the location of the default identity management realm with the third-party domain. For example, if your third-party domain is sales.acme.com, then locate the root of your Oracle identity management realm at dc=sales,dc=acme,dc=com.

If you have already installed an infrastructure, and the realm you specified is not aligned with that of the third-party directory, then you have two options depending on whether you are already using that realm:

• If you have not installed any other middle tiers against this infrastructure, then re-install the infrastructure and choose the correct default realm location. To make sure that the user and group objects are stored correctly in the DIT, see "Customizing Identity Management Realms Based on Deployment Requirements" located at http://otn.oracle.com.

• If you are already using the non-aligned realm, then follow the instructions in "Customizing Identity Management Realms Based on Deployment Requirements" located at http://otn.oracle.com.

  See Also: Part VII of the Oracle Internet Directory Administrator's Guide for fuller instructions on integrating Oracle Internet Directory and third-party directories

23.1.4 Directory Integration and Provisioning Server Status Post-Installation

Only after Oracle Internet Directory is installed along with the infrastructure does the OID configuration Assistant launch the directory integration and provisioning server. In standalone installations of Oracle Directory Integration and Provisioning, the OID Configuration Assistant simply registers the server, and does not launch it.

The restriction behind all of this is that two instances of the directory integration and provisioning server cannot have either the same instance number or the same configuration set number.

The first instance of the directory integration and provisioning server always starts by using instance number 1 and configuration set number 0. If another instance of the server is then launched from another installation, then it, too, tries to use instance number 1 and configuration set number 0. As a result, the second instance errors out because that instance number and configuration set number are already in use.

However, because the directory integration and provisioning server is registered, you can manually launch an instance of it. You do this by using the script $ORACLE_HOME/bin/odisrv. When you do this, be sure that the server instance does not have the same instance number or configuration set number as any other currently running instance.

23.1.5 Two Oracle Internet Directory Plug-in Features Are not Supported after Upgrade from Oracle Internet Directory Release 9.2

In Oracle Application Server 10g (9.0.4), the following plug-in features are not supported in the directory server running against Oracle9i Database Server Release 9.2:

• Windows NT Domain external authentication plug-in.

• The simple_bind_s() function of LDAP_PLUGIN package provided as the OID PL/SQL PLUGIN API for connecting back to the directory server as part of plug-in definitions.

23.2 Administration Issues and Workarounds

This section describes administration issues and their workarounds for Oracle Directory Integration and Provisioning. It includes the following topics:

• Section 23.2.1, "Restarting Directory Replication and Directory Integration and Provisioning Server Instances in Real Application Cluster or Rack-Mounted Mode"

• Section 23.2.2, "Using Real Application Clusters and the Directory Integration and Provisioning Service"

• Section 23.2.3, "Required User Schema in Windows-Synchronized Realms"

• Section 23.2.4, "Synchronizing Selected Types of Objects from Active Directory to Oracle Internet Directory"

• Section 23.2.5, "Password Synchronization from Oracle Internet Directory to Active Directory"

• Section 23.2.6, "Group Names with Special Characters Cannot Be Synchronized with Microsoft Active Directory"

23.2.1 Restarting Directory Replication and Directory Integration and Provisioning Server Instances in Real Application Cluster or Rack-Mounted Mode

If the primary node that is running either the directory replication server (oidrepld), or the directory integration and provisioning server (odisrv), or both, fails, then, after five minutes, the OID Monitor on the secondary node starts these processes on the secondary node. However, when the primary node is restarted, these servers are not automatically restarted on the primary node.

Normal shutdown is not treated as a failover. If all the processes are stopped normally, then the OID Monitor running on the secondary node does not start these processes on the secondary node after five minutes. Moreover, as in the case of a failure, when the primary node is restarted, these servers are not automatically restarted on the primary node.

23.2.2 Using Real Application Clusters and the Directory Integration and Provisioning Service

Suppose that you have the following scenario:

• Oracle Internet Directory is configured in Real Application Clusters (RAC) mode.

• The directory integration and provisioning server is executing as part of an Oracle Directory Integration and Provisioning-only installation on another node.

• The Oracle Internet Directory node against which the directory integration and provisioning server is executing fails.

In this scenario, the directory integration and provisioning server cannot transparently switch execution to one of the other RAC-enabled Oracle Internet Directory nodes. As a result, the directory integration and provisioning server also aborts, and must be started manually by using the $ORACLE_HOME/bin/odisrv script.

23.2.3 Required User Schema in Windows-Synchronized Realms

In Microsoft Windows-connected deployments, users in one identity management realm may need to be able to authenticate locally--that is, to Oracle Internet Directory--while those in others realms may need to be authenticated by Microsoft Active Directory. The external authentication plug-in must be configured only for the identity management realms whose users authenticate to Microsoft Active Directory.

All users within such realms need to include the attributes defined in the object class orclADUser, which contains the required attributes for Windows authentication. All users created in Microsoft Active Directory and synchronized into Oracle Internet Directory have these attributes by default, because Microsoft Active Directory creates them by default. Conversely, users provisioned within such realms by Oracle Internet Directory and synchronized into Microsoft Active Directory do not by default inherit from the correct schema unless properly configured.

This can be accomplished in multiple ways:

• Oracle Delegated Administration Services can be configured to ensure that newly-provisioned Oracle Internet Directory user entries automatically inherit the attributes from the OrclADUser object class. Some of these are mandatory, such as orclSAMAccountName, and must be specified when the user is created by using the Oracle Internet Directory Self-Service Console.

• Users can be synchronized from a third-party directory by using a mapping configuration profile that adds the additional attributes to the entries when synchronizing them into Oracle Internet Directory.

• Directory administrators, by using Oracle Directory Manager, can manually ensure that all orclADUser attributes exist for each user before configuring the Active Directory connector for the identity management realm in question.

• If an individual user's credentials are stored within Oracle Internet Directory and not authenticated by Active Directory, then this user's nickname attribute value can be added to the exceptionEntry property of the external authentication plug-in entry. This would be needed, for example, when all users in Oracle Internet Directory are configured to authenticate externally. In this case you must specify local account names such as cn=orcladmin as exceptionEntry values because these accounts do not exist in Active Directory.

By default, none of the preseeded users in the realm have the orclSAMAccountName attribute populated. You must, therefore, populate this attribute to orcladmin under the realm.

23.2.4 Synchronizing Selected Types of Objects from Active Directory to Oracle Internet Directory

If you are synchronizing user entries from Microsoft Active Directory to Oracle Internet Directory, and you need to synchronize only certain types of objects, then be sure to populate the connected directory search filter appropriately. For example, if you are synchronizing changes to user and group information, but not changes to computer information, then the value of this attribute must be as follows:

SEARCHFILTER=(|(objectclass=group)(&(objectclass=user)(!(objectclass=computer)))

Use Oracle Directory Manager or the Directory Integration and Provisioning Assistant to update this attribute.

23.2.5 Password Synchronization from Oracle Internet Directory to Active Directory

The Oracle directory server enables password modifications in both SSL and non-SSL mode, but Microsoft Active Directory supports them in SSL mode only. Thus, synchronization of passwords from Oracle Internet Directory to Microsoft Active Directory can happen only if the following are true:

• The Oracle directory server is executing in server authentication SSL mode

• The directory integration and provisioning server is connected to Microsoft Active Directory in that mode

  See Also: Chapter 43, "Integration with the Microsoft Windows Environment" in Oracle Internet Directory Administrator's Guide

23.2.6 Group Names with Special Characters Cannot Be Synchronized with Microsoft Active Directory

The samaccountname attribute in Active Directory does not allow special characters. As a result, if Oracle Internet Directory is the source of truth for group names for Active Directory, and if a group name, found in its cn attribute, contains special characters, then export synchronization fails. This is because the Oracle Internet Directory cn attribute is mapped to the samaccountname attribute in Microsoft Active Directory. For user entries, a workaround exists: In the mapping configuration file, map some other attribute containing no special characters to the Microsoft Active Directory samaccountname attribute.

For groups, however, there is no mandatory attribute in the orclGroup object class other than cn available to map to samaccountname. For this reason, there can be no special characters in Oracle Internet Directory group names being exported to Microsoft Active Directory.

23.3 Documentation Errata

This section describes errors in the documentation for Oracle Directory Integration and Provisioning. It includes the following topics:

• Section 23.3.1, "Incorrect Wording About Supported Configurations for Integrating with Microsoft Active Directory".

• Section 23.3.2, "Incorrect Wording About Configuring the Default Integration Profile for Two-Way Synchronization with Microsoft Active Directory"

23.3.1 Incorrect Wording About Supported Configurations for Integrating with Microsoft Active Directory

In the Oracle Internet Directory Administrator's Guide, in Chapter 43, "Integration with the Microsoft Windows Environment," in the section "Supported Configurations for Integrating with Microsoft Active Directory," the following wording is incorrect: "Password synchronization. In this environment, synchronization ensures only the creation of footprints on the SunONE Directory Server." The correct wording is: "Password synchronization. In this environment, synchronization ensures only the creation of footprints on the Microsoft Active Directory."

Similarly, the following wording is incorrect: "In a deployment with SunONE Directory Server as the central repository". The correct wording is: "In a deployment with Microsoft Active Directory as the central repository."

23.3.2 Incorrect Wording About Configuring the Default Integration Profile for Two-Way Synchronization with Microsoft Active Directory

In the Oracle Internet Directory Administrator's Guide, in Chapter 43, "Integration with the Microsoft Windows Environment," in the section "Configuring the Default Integration Profile for Two-Way Synchronization," the following wording is incorrect: "modifiersname != DN of the user account with which changes are made by the export profile in SunONE". The correct wording is: "modifiersname != DN of the user account with which changes are made by the export profile in Microsoft Active Directory."