ber_read_OID_String patch

[Kamen Mazdrashki]

Hi Metze,

I am reposting this again as my previous mail was returned from 
mailing-list as being too big. Now log file is compressed.

---------------------------------------------------------------------------------------

It seems I can't convince you without an example of what I am talking about :).

Please see the attached log file - it is produced by extending the DSSYNC test a little bit and by tuning the drsuapi.idl file a little bit (I will publish the branch tomorrow so you could play with it if you wish to). 
Last of the log file represents following information for every Object in the replica received (by replica I mean data we receive by calling GetNCChanges()):
  attribute OID decoded by implementation described in MS-DRSR documentation
  map_idx - PrefixMap entry index that matches this attribute
  attid   - ATTRTYP of the attribute as received from w2k3
  ldap_name - Attribute name that corresponds to decoded OID
  idl_name  - corresponding value in drsuapi_DsAttributeId enumeration (from IDL)

Look at line 1680 - it's an Exchange attribute value being replicated.
  OID: 1.2.840.113556.1.4.7000.102.50050
  ldap_name: msExchPoliciesIncluded
Now, in our (Samba4) implementation, this attribute shall be encoded in following way:
  PrefixMap entry oid: [1.2.840.113556.1.4.7000.102]
  last subidentifier: 50050
During marshaling (in hex):
  PrefixMap entry bin-oid: 2A864886F7140104B65866
  ATTRTYP (lo-word): C382

I think at this point the differences with what w2k3 sends us is obvious.
For this particular attribute w2k3 sends (in hex):
  PrefixMap entry bin-oid: 2A864886F7140104B6586683
  ATTRTYP (lo-word): 0x8382

Using my patch for ber_read_OID_String() is bad idea as it would lead to:
  PrefixMap entry bin-oid: 2A864886F7140104B6586683 -> 1.2.840.113556.1.4.7000.102.3
  ATTRTYP (lo-word): 0x8382 -> 33666
  Resulting attribute OID: 1.2.840.113556.1.4.7000.102.3.33666
There is no such attribute in my schema and the replication will fail.

I hope this time it is more clear what my concerns are.


BR,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
CISCO SYSTEMS BULGARIA EOOD
18 Macedonia Blvd. Sofia 1606
Bulgaria
http://www.cisco.com/global/BG/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: RPC-DSSYNC_02_01-after_adding_new_user.log.gz
Type: application/octet-stream
Size: 8267 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090907/f048f4a6/attachment.obj>