Clarifying OVD-AD EUS Password Question

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

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today