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

John Dunning johndun at microsoft.com
Fri Dec 11 09:24:30 MST 2009


Hello Karmen,  

Thank you for bringing this issue  to our attention. [MS-ADTS] section 3.1.1.3.4.1.5 and [MS-DRSR] section 5.16.3.13 will be updated. A Windows Behavior note from [MS-DRSR] Appendix B will also be removed. The conversion to SYNTAX_DISTNAME_BINARY from attributes with Object(OR-Name) syntax will be documented in [MS-DRSR] section 5.16.3 and more specifically [MS-DRSR] 5.16.3.13. Something very similar to the following changes will be made in a future release of these documents, [MS-ADTS] and [MS-DRSR].

For the [MS-ADTS] document the following section will be changed:

[MS-ADTS] 3.1.1.3.4.1.5   LDAP_SERVER_EXTENDED_DN_OID
The LDAP_SERVER_EXTENDED_DN_OID control is used with an LDAP search request to cause the DC to return extended DNs. The extended form of an object's DN includes a string representation of the object's objectGUID attribute; for objects that have an objectSid attribute, the extended form also includes a string representation of that attribute. The DC uses this extended DN for all DNs in the LDAP search response. Attributes with Object(OR-Name) syntax are not affected by this control, as in those cases, the DC always uses the DN form as specified in RFC2253. 
The extended DN format is as follows:
<GUID=guid_value>;<SID=sid_value>;dn 
where guid_value is the value of the object's objectGUID attribute, sid_value is the value of the object's objectSid attribute, and dn is the object's RFC 2253 DN. For objects that do not have an objectSid attribute, the format is instead as follows:
...

For the [MS-DRSR] document the following will be made:

5.16.3.13   Object(OR-Name)
The LDAP representation of the attribute value corresponds to SYNTAX_DISTNAME_BINARY. The object DN portion of the LDAP representation is treated as if it were in Object(DS-DN) syntax and converted to the DSNAME syntax representation, as explained in section 5.16.2.5

Appendix B, Windows Behavior (note 34) in the most recently released document will be removed. The number of the Windows Behavior note may change depending on document revision.  It currently reads: 

<34> Section 5.16.3.13: Only Object(OR-Name) values that consist of only a DN are supported and can be converted to the SYNTAX_DISTNAME_BINARY syntax. Values with an OR_Name portion cannot be converted and are rejected by the DC.

Please let me know if you have any additional questions as well as if this response resolves your issue.

Thanks
John Dunning
Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM
Email: johndun at microsoft.com



-----Original Message-----
From: John Dunning 
Sent: Thursday, November 19, 2009 4:41 PM
To: 'Kamen Mazdrashki'
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Object(OR-Name) syntax implementation

Hello Karmen,
   My name is John Dunning and I am a member of the Microsoft Protocols Documentation team. I will be working on your question Object(OR-Name) syntax implementation. I will keep you up to date as things progress on my end. In the meantime if you have any additional questions please let me know.

Thanks
John Dunning
Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM
Email: johndun at microsoft.com


-----Original Message-----
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com] 
Sent: Thursday, November 19, 2009 3: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/




More information about the cifs-protocol mailing list