Oracle® Application Server Release Notes
10g Release 2 (10.1.2) for hp-ux PA-RISC (64-bit) B15511-05 |
|
![]() Previous |
![]() Next |
This chapter describes the issues associated with Oracle Directory Integration and Provisioning. It includes the following topics:
This section describes configuration issues and their workarounds for Oracle Directory Integration and Provisioning. It includes the following topics:
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.
In Oracle Application Server 10g Release 2 (10.1.2), 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.
This section describes administration issues and their workarounds for Oracle Directory Integration and Provisioning. It includes the following topics:
Section 19.2.2, "Directory Integration and Provisioning Assistant Does not Support SSL Mode 2"
Section 19.2.3, "Shell Script-based Profile Configuration Tools Are Being Deprecated"
In deployments with only a single domain of Microsoft Active Directory, you can simplify the default mapping rule installed with Oracle Directory Integration and Provisioning.
The default mapping rule is:
sAMAccountName,userPrincipalName: : :user:orclSAMAccountName: :orclADUser:toupper(truncl(userPrincipalName,'@'))+"$"+sAMAccountname
If your deployment has a single domain of Active Directory, then you can simplify the default mapping rule to this:
sAMAccountName: : :user:orclSAMAccountName::orclADUser
In 10g Release 2 (10.1.2), you can use the Directory Integration and Provisioning Assistant with either a non-SSL connection or an SSL connection with no authentication, namely SSL Mode 1, which provides encryption on the connection. You cannot use the Assistant with SSL mode 2 in which one-way (server only) SSL authentication is required.
Shell script-based profile configuration tools ldapcreateConn.sh, ldapdeleteConn.sh, and ldapUploadAgentFile.sh are being deprecated as of 10g Release 2 (10.1.2).Oracle recommends that you use the Java-based Oracle Directory Integration and Provisioning Server Administration tool for configuring profiles.
The Oracle Directory Integration and Provisioning server propagates events resulting from add, modify and delete operations in Oracle Internet Directory. It does not propagate events resulting from the modrdn operation.
In multimaster replication, the last change number is stored locally on an Oracle Internet Directory node. In a high availability environment, if that node fails, and the provisioning profile is moved to another Oracle Internet Directory node, then the last applied change number in the profile becomes invalid. That number in the profile must then be reset manually on the failover node. Even then, however, events may not be propagated or may be duplicated.
To determine whether to shut down, the Oracle Directory Integration and Provisioning server polls the registration entry stored under cn=odisrv,cn=subregistrysubentry
. It does this every 30 seconds. If you stop, then restart, the server within 30 seconds, then the old server instance may not shut down before the new instance starts. To alleviate this, wait for 30 seconds before restarting the server.
To modify the lastchangenumber
entry in the profile, use ldapmodify.
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.
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.
The Oracle Identity Management Integration Guide fails to provide the following information about specifying the distinguished name mapping when configuring mapping rules:
In the DomainRules
section of the mapping file, the following should be noted about the DstDomain
component: If the source is anything other than LDAP/LDIF, then this field is required. This field indicates the container in which the entry is to be created.
In the DomainRules
section of the mapping file, the following should be noted about the DomainMappingRule
component: This field is meaningful only when importing to Oracle Internet Directory or when exporting to an LDIF file or another external LDAP-compliant directory. Specify this field if the RDN of the entry in the destination directory is different from that in the source directory entry.
When synchronizing from the NONLDAP, that is, tagged, interface, this field is required. It indicates how the DN is to be constructed. The attribute specified in the RDN component must be specified as a required attribute in the attribute mapping rules.