Mark Wilcox

Subscribe to Mark Wilcox feed
Oracle Blogs
Updated: 13 hours 24 sec ago

How To Do Highly Available OVD-EUS

Tue, 2011-03-22 23:21

Got a question from sales on our mailing list that I think is good to have generally available:

My customer is considering using OVD for EUS (against AD) but worries about having one more point of failure (OVD).
Mark Comment - This is covered in our product documentation as well.

Question - What are the failover solutions available?
Answer - It's easy to make OVD highly available. All that is required that you have 2 (or more) OVD instances installed. Then you can synchronize the configuration. I typically prefer to get 1 server configured and then do the synchronize.

  Question - What  are the best practices?
Answer - After you have multiple OVD instances configured - then you can either put OVD behind an existing hardware load-balancer (most common) or if OVD implementation is restricted to just OVD-EUS, can list the specific OVD servers hostname and ports in the database's ldap.ora file. The reason why I put this caveat is that not all applications lets you list multiple connections for fail-over.

Question - Do we have customers working with highly available OVD solution?
Answer - As far as I know, everyone has OVD deployed in a highly available configuration

Posted via email from Virtual Identity Dialogue

Upcoming Webcast: Do You Have The Right Directory Services For Cloud Computing?

Sun, 2011-03-20 23:40

I'm giving a new webcast this week about making sure you choose the right directory service for cloud computing:
Webcast Date: Thursday, March 24, 2011
Webcast Time: 10:00 AM Pacific Daylight Time / 1:00 PM Eastern Daylight Time

Please register and attend to learn about the key points you need to keep in mind when choosing a directory service for your cloud initiatives.

Posted via email from Virtual Identity Dialogue

Lessons From OpenId, Cardspace and Facebook Connect

Wed, 2011-03-09 23:12

Teach and Listen
(c) denise carbonell

I think Johannes Ernst summarized pretty well what happened in a broad sense in regards to OpenId, Cardspace and Facebook Connect.

However, I'm more interested in the lessons we can take away from this.

First  - "Apple Lesson" - If user-centric identity is going to happen it's going to require not only technology but also a strong marketing campaign. I'm calling this the "Apple Lesson" because it's very similar to how Apple iPad saw success vs the tablet market. The iPad is not only a very good technology product but it was backed by a very good marketing plan. I know most people do not want to think about marketing here - but the fact is that nobody could really articulate why user-centric identity mattered in a way that the average person cared about.

Second - "Facebook Lesson" - Facebook Connect solves a number of interesting problems that is easy for both consumer and service providers. For a consumer it's simple to log-in without any redirects. And while Facebook isn't perfect on privacy - no other major consumer-focused service on the Internet provides as much control about sharing identity information. From a developer perspective it is very easy to implement the SSO and fetch other identity information (if the user has given permission). This could only happen because a major company just decided to make a singular focus to make it happen.

Third - "Developers Lesson" -  Facebook Social Graph API is by far the simplest API for accessing identity information which also is another reason why you're seeing such rapid growth in Facebook enabled Websites. By using a combination of URL and Javascript - the power a single HTML page now gives a developer writing Web applications is simply amazing. For example It doesn't get much simpler than this "" for accessing identity. And while I can't yet share too much publicly about the specifics - the social graph API had a profound impact on me in designing our next generation APIs. 

Posted via email from Virtual Identity Dialogue

Moving OVD from Test to Production

Tue, 2011-01-04 03:00

Customer asked support "How to move a test OVD server to production".

There is a couple of ways to do this.

One way is to clone the environment:

Another way - which is particularly useful if you want to push configuration from a parent OVD server to children in a cluster:
Note if you use the second option and you have any data in a Local Store Adapter - you may also need to use the oidcmprec tool to synchronize that data:

Posted via email from Virtual Identity Dialogue

Debugging Tip with Weblogic and Oracle Virtual Directory

Thu, 2010-10-28 09:01

I helped one of our other teams debug an issue with an app protected with Oracle Weblogic server and Oracle Virtual Directory (OVD).

You can read more about it here

Posted via email from Virtual Identity Dialogue

Clarifying OVD-AD EUS Password Question

Mon, 2010-10-18 07:48

Got a question from a customer:
"We had a question about one of the attributes added by the schema extension: orclCommonAttribute.

Is the user’s password hash stored in this attribute when using Kerberos authentication (OVD and AD option)? Is the user’s password hash stored in any other AD attributes? Or does this attribute remain empty?"

First a quick explanation about orclCommonAttribute. If you use EUS with username and password authentication, the database fetches the password hash and compares it locally instead of doing a traditional LDAP bind. One of the reasons it does this is because this way the password is never communicated to the database in clear-text. Yes, there are a variety of ways to prevent that (such as encrypted network connection) - but when EUS was first conceived (over a decade ago) - those were not as common as they are today.

For most directories - this isn't a problem - they store the passwords in a hashed format that can be retrieved. Except for Microsoft Active Directory. To work-around this problem - OVD-EUS uses a password filter to capture password changes on the domain controller, hashes it and stores it in an extended attribute orclCommonAttribute.

If a customer were to choose to deploy EUS with Kerberos instead, there wouldn't be any reason to deploy the password filter and thus the attribute wouldn't be populated. Not only that - the database won't even query the directory for the password since the authentication would happen via Kerberos. Instead EUS is just providing user to schema mapping and more importantly - role to group mapping.

Posted via email from Virtual Identity Dialogue