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: john...@microsoft.com -----Original Message----- From: John Dunning Sent: Thursday, November 19, 2009 4:41 PM To: 'Kamen Mazdrashki' Cc: p...@tridgell.net; cifs-proto...@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: john...@microsoft.com -----Original Message----- From: Kamen Mazdrashki [mailto:kamen.mazdras...@postpath.com] Sent: Thursday, November 19, 2009 3:00 PM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@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.mazdras...@postpath.com http://repo.or.cz/w/Samba/kamenim.git ------------------------------------- CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
