Oracle Internet Directory OID - Distinguished Name DN

OID DN Distinguished Name and its case - Uppercase or Lowercase and spacing between attributes

A LDAP server like OID provides graphical as well as command line interface for an administrator to view, edit, search the Directory server for various operations. This post deals with following issues
(1) issue about  changing the case of the DN or Distinguished Name letters- viz from "User" to "user" as in for example,  cn=Users, dc=company, dc=com
(2) whether OID LDAP server is case insensitive for the Distinguished Names 
(3) whether space (whitespace) between the comma separated RDN (Here is reference to what is DN (Distinguished Name) and RDN (Relative Distinguished Name) ) matters 

(1) issue about  changing the case of the DN
In order to confirm whether the case in U or u i.e. Uppercase U and lowercase u matters, following was run on OID 11.1.1.6. The test case was to validate whether OID differentiates between
cn=Users, dc=company, dc=com
cn=users, dc=company, dc=com

The test case created one user with cn entry with Uppercase U and another user with cn entry with lowercase u
See results below with screenshots

--------------------------------------------------------------------------------------------------------------------------
Here is the original question posted in Oracle forum
Currently OID is using the below DN name but we have noticed there is a space in between Users and domain(cn=Users, dc=company). Now we would like to remove the space in between them also needs to update the Users from upper case 'U' to lower case 'u'. Please provide is there any command to update the same.

cn=Users, dc=company,dc=com    -->  cn=users,dc=company,dc=com
--------------------------------------------------------------------------------------------------------------------------


The case for Users vs users does not matter for OID when it lists the entries.
user3 was created with  cn=users (lowercase u  in users)
user1 was created with  cn=Users (uppercase U in Users)
Both above users were created under the same Directory Tree (only the cn entry for changed, lowercase u and uppercase U)

See below screenshot with user1




























See below screenshot for user3





























See below screenshot how the cn entry was manually entered as cn=users,... (lowercase) when creating user3.

















user3 was created with  cn=users (lowercase u  in users)
user1 was created with  cn=Users (uppercase U in Users)
See above Distinguised Name of the users, both are in the same DIT, but one shows with lowercase u and second one shows with Uppercase U.
Also see below screenshot for output of ldapsearch, for cn=users and second one for cn=Users, provided in the ldapsearch parameters. Both outputs are same, showing that ldapsearch treats them as same.

See above, when ldapsearch -b option is given cn=Users or cn=users, both give the same output.

However, note that since user3 was created with with cn=users (lowercase), it is reported by ldapsearch with lowercase (just for reporting or output purposes) See below screenshot.

(2) whether OID LDAP server is case insensitive for the Distinguished Names 
Example showing ldapsearch treats the DN values as case insensitive or the case does not matter. Below shows output of two ldapsearch, one is with cn=john and the other is with cn=JOHN. Both give the same output. This shows that OID treats the DN entries for john or JOHN as being same.
















Another confirmation that OID LDAP server treats the DN entry for john or JOHN as same - is by trying to create another user entry, this time for "john", since "JOHN" already existed. Result: OID did not allow the user entry for "john" to be created. Following was the error given by OID when this was attempted.










See above error when trying to create a new entry for user "john" (all lowercase). The entry for user "JOHN" already existed and OID disallowed the creation of this user with all lowercase letters. The LDAP error code 68 reported - Object already exists.

(3) whether space (whitespace) between the comma separated RDN (Here is reference to what is DN (Distinguished Name) and RDN (Relative Distinguished Name) ) matters
Now the issue regarding whitespace between each of the RDN members (in the screenshot below, several whitespaces have been put between cn=Users and dc=dsa).
With regards to spaces between cn=Users and dc entry, the ldapsearch command ignores the whitespaces. See below output with ldapsearch where I have provided lots of whitespace between cn=users entry and dc=  entry. The output of the command has clearly ignored extra whitespaces.

In summary, you should be fine with whitespaces between cn=Users,   and dc= entry.
Distinguished Name Case Sensitivity is dependent on the LDAP Server Implementation and the LDAP Protocol Exchange you are performing. During a bind Request, the Distinguished Name SHOULD NOT be case sensitive regardless of the makeup of the attributes (RDNs) within the Distinguished Name.
However, to be sure test your LDAP server by running these tests as provided above to confirm that your LDAP server is indeed case insensitive or is NOT case sensitive.



Comments

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Session Timeout in Oracle Access Manager

SOAPUI - import certificate