[cifs-protocol] Object(OR-Name) syntax implementation

[Dominic Salemno]

Kamen,

We have received your inquiry and one of our engineers will follow-up with you in regards to this issue.

Dominic Michael Salemno
Senior Support Escalation Engineer
US-CSS DSC Protocols Team

-----Original Message-----
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com] 
Sent: Thursday, November 19, 2009 4:00 PM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Object(OR-Name) syntax implementation

Hi,

While I was trying to implement "Object(OR-Name)" syntax handling in Samba, I've got some unexpected results.
There are several places to describe this syntax:
http://msdn.microsoft.com/en-us/library/cc223181%28PROT.13%29.aspx - from ADTS
http://msdn.microsoft.com/en-us/library/cc228440%28PROT.13%29.aspx - from DRSR

Documentation says (ADTS and DRSR) that values with "Object(OR-Name)" syntax are in 'object_DN' format which is in "Object(DS-DN)" format.
At first I got the impression, that "Object(OR-Name)" and "Object(DS-DN)" are the same.
But then, LDAP queries against AD always returns plain-dn DNs - even when 'extended dn' control is passed.
So I come to a conclusion, 'object_DN' means "DN part from Object(DS-DN) syntax".

After some tests with DRSUAPI interface though, it turns that values with 'OR-Name' syntax are transmitted in
"<GUID=..>;<SID=...>;dn" format which is "Object(DS-DN)" format!

At this point, I decided, that "Object(OR-Name)" is represented in two ways:
1. plain_dn - when working through LDAP
2. Object(DS-DN) - when transmitted using DRS interface

But then, after few hours of debugging/testing I was surprised to find out that through DRS interface, values with "Object(OR-Name)" syntax are transmitted as "Object(DN-Binary)"!


Here is some test data:
I am playing with "authOring" attribute (from MS Exchange 2003 provisioning)
Through DRS I am getting blob with value: 
0x960000001c000000167dcc23a03d3a4f99210ad60a99230f0105000000000005150000009ca04dcc46a0a763e4b37ba4f40100002e00000043004e003d00410064006d0069006e006900730074007200610074006f0072002c0043004e003d00550073006500720073002c00440043003d006b006d0061002d0065007800630068002c00440043003d0064006500760065006c000000000004000000

When I assume this value is in Object(DS-DN) format, it is correctly converted to following extended-DN:
<GUID=23cc7d16-3da0-4f3a-9921-0ad60a99230f>;<SID=S-1-5-21-3427639452-1671929926-2759570404-500>;CN=Administrator,CN=Users,DC=kma-exch,DC=devel

However, the above mentioned extended-DN does not match exactly the blob value when it is converted back to blob using "Object(DS-DN)" syntax handling. 

On the other hand, when using "Object(DN-Binary)" syntax implementation, forward/backward conversions match perfectly. I.e. the abovementioned blob value should be decoded to DN-Binary value:
B:0::<GUID=23cc7d16-3da0-4f3a-9921-0ad60a99230f>;<SID=S-1-5-21-3427639452-1671929926-2759570404-500>;CN=Administrator,CN=Users,DC=kma-exch,DC=devel";


I think there is a bug in documentation?
Please, clarify?


Thanks,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/