An Oracle blog about Consulting Security Corner

  • July 20, 2010

Schema Extension Options with OVD-Enterprise User Security and Microsoft Active Directory

Guest Author

A customer asked support recently about how to minimize the schema extensions needed to configure Oracle Database Enterprise User Security with Oracle Virtual Directory.

EUS is the database feature that allows you to externalize username, roles and (optionally) passwords from the database to your enterprise directory. I say the password is optional because if you are using Kerberos authentication with the database - authentication happens via Kerberos KDC (either MIT or - more often, Microsoft Active Directory) - leaving EUS to just handle the database schema to LDAP user mapping.

Now to talk about the schema extensions and EUS. There is two types of data stored in the directory for EUS when using OVD-EUS with AD. One is the database meta-data containing information about which databases are registered for EUS, the database schema to LDAP user mapping and the database role to LDAP role mapping. The other type is mapping of the LDAP user password.  The password schema extension is needed is that unlike every other LDAP we support for EUS - AD doesn't provide a mechanism to get back a standardized (e.g. MD5, SSHA, SHA1) hash password for a user. So we use a password filter to capture a password change, hash the password and store it in the user entry.  EUS needs the hashed password because it fetches the hash password (over SSL) to compare against the hash password sent from the client (in the database - passwords are never, ever, sent in clear text - which is why the database doesn't just use LDAP bind like other apps such as Weblogic).

Many AD administrators don't like to extend the schema. This is because in part - Microsoft doesn't give you any way to back-out a schema change. You can't even manually delete elements. 

So we have a configuration option (shown in the diagram here) - that lets you split the data. You can put the meta-data into OID (or technically ODSEE - though that is not yet officially documented, contact me if you wish to do this) and leave only the password hash attribute extension in AD. Thus you only need to add two things to the AD domain controller - one attribute ("orclCommonAttribute") and the password filter.

The only way I'm aware of to completely avoid the schema extension if you are using OVD-EUS is if you are using Kerberos authentication - you can configure OVD-EUS without needing to do any AD schema extension and put all of the meta-data into OID/ODSEE.

Finally don't forget to sign-up for our upcoming 11gR1 Identity & Access Management webcast on Wed. July 21, 2010.

Posted via email from Virtual Identity Dialogue

Join the discussion

Comments ( 2 )
  • Micheal P Tuesday, July 20, 2010
    This is great!
  • Adrian P Wednesday, July 21, 2010
    I have read and observed a procedure to isolate an AD domain controller offline when applying schema changes, but now Microsoft says that is not supported nor recommended.
    So testing schema changes in non-production domains is the best practice. Of course that is true for any directory technology. :)
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.