For those of you who needs the Oracle Unified Directory Certification Matrix and have hard times to find it, here is THE link: Certification Matrix
OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.
In general, default OUD access control settings are stricter than ODSEE. Appropriate privileges must be added to achieve behavior that is equivalent to that of ODSEE. For instance, by default, OUD ACIs don’t allow users to reset another users’s password. Alternatively, it is possible to disable the privilege subsystem.
By default, normal users are not granted any of the privileges listed above. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user’s entry. ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.
As an example, the following modification can be used to add the proxied-auth privilege to the usercn=Proxy User,dc=example,dc=com:
dn: cn=Proxy User,dc=example,dc=com
Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I’ll cover Virtual attribute in a subsequent post.
Alternatively, It is possible to disable those privileges leading to aci behavioral differences between OUD and ODSEE. For instance, the unindexed-search privilege can be disabled so that users can perform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the following command:
dsconfig set-global-configuration-prop –add \
disabled-privilege: unindexed-search -n
The list of OUD privileges is available here.
By default, OUD schema scheck is stricter than ODSEE. Schema checking is key for data sanity, however this might cause some trouble when “incorrect” data have to be imported into OUD or when incorrect data are replicated from ODSEE.
Generally speaking, it is not recommanded to disable schema checking and the data should be fixed whenever possible before import and on the ODSEE side when ODSEE and OU cohabit in the same replication topology. In some cases, this is not possible, so some specific checks can be disabled to accomodate with common inconsistency:
Structural object class unicity
Per LDAP standard, every LDAP entry must contain exactly one structural object class. In many deployments, some LDAP entries contain 0 or more than 1 objectclass and several LDAP server implementations do not enforce this. By default OUD does. Such check can be relaxed w/o know adverse effect by using the command below:
dsconfig set-global-configuration-prop --set \ single-structural-objectclass-behavior:accept -n
Attribute type names containing invalid characters
A few customers defined their own attribute types, using forbidden characters, e.g undercores, or leading digit in attribute names and/or in attribute type extensions (e.g 4you;x_bad_extension). Such check can be relaxed using the command below:
dsconfig set-global-configuration-prop --set \ allow-attribute-name-exceptions:true -n
Zero-length attribute value
Zero-length attribute values (that is, an empty string) is technically not allowed by the revised LDAPv3 specification, but some environments may require it for backward compatibility with servers that do allow it. Empty string can be explicitely allowed on a per LDAP syntax basis, using the example below for DirectoryString syntax:
dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \ --set allow-zero-length-values:true -n
The root DSE entry (empty dn) is often used by LDAP client applications to discover directory services capabilities. For instance, attribute namingContexts gives indications about the suffixes managed by the directoy server instance. All these attributes are flagged as OPERATIONAL, so, they should not be returned to client applications unless they are explicitely specified in the search attribute list.
OUD strictly adheres to LDAP standards so these attributes are not returned by default. In Oracle Directory Server Entreprise Edition (ODSEE), these attributes are treated as standard ones and are systematically returned to client applications. Applications depending on the ODSEE behaviour might be impacted as many of them do no specify any search attribute list. To make OUD behave like ODSEE with regards to the access of rootDSEE attributes, run the following command:
dsconfig set-root-dse-backend-prop –set show-all-attributes:true
To make OUD treat schema operational attribute like user attributes, run the following too:
dsconfig set-workflow-element-prop –element-name schema –set show-all-attributes:true
Oracle Optimized Solution for Oracle Unified Directory is a complete solution – Software and Hardware engineered to work together.
It implements Oracle Unified Directory software on Oracle’s SPARC T4 servers to provide highly available and extremely high performance directory services for the entire enterprise infrastructure and applications. The solution is architected, optimized, and tested to deliver simplicity, performance, security, and savings in enterprise environments.
More details available at http://www.oracle.com/us/solutions/1571310