ber_read_OID_String patch

[Kamen Mazdrashki]

On Wed, Sep 2, 2009 at 11:43, Kamen Mazdrashki wrote: 
> Hi guys,
> 
> I've hit a strange problem while testing DRSUAPI interface against W2K3
> server - NDR pull layer failed to decode drsuapi_DsReplicaOIDMapping
> structure.
> After some digging, it turns out to be  ber_read_OID_String() function
> fault for the failure.
> And here is the strange part - it always fail to decode BER encoded OID
> with __ndr_size=12 bytes. According to documentation (ref.
> http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf ->
> 8.19) this function works correctly. Basically every subidentifier is
> encoded as a series of octets with bit 8 set to 1 and last octet with
> bit 8 set to 0. So far so good. Unfortunately, W2K3 server sends BER
> encoded OID where last identifier is encoded as 0x81 for example - btw,
> this always happens when BER encoded value is of size 12 (as I
> mentioned earlier).
> 
> I've made a little patch to overcome this problem temporary (please see
> the attachment).
> However, I am not quite sure this is the right thing to be done - after
> decoding PREVIX MAP returned from W2K3 it seems ok - as far as I can
> tell, prefix-to-OID mapping seems good and valid. But it is a little
> bit strange W2K3 encodes OID this way.
> I think we have several possibilities here - please bear in mind that
> this is against W2K3 with Exchange provisioning:
> 1. it is a bug in MS BER encoding functionality - as we all know, MS
> likes to make buffer optimizations so I won't be surprised if they have
> hard coded buffer of 16 bytes to encode [size, BER value] :) 2. it's an
> interpretation of the BER encoding documentation - the document does
> not state clearly how the BER value must end - just states that every
> sub identifier ends with a byte where bit-8 = 0.
> 3. it is a bug in NDR pull layer and __ndr_size is not decoded
> correctly
> 
> Sorry for writing such a big mail about this issue, but the
> ber_read_OID_String() function is a very low-level API and I feel this
> should be discussed more widely.
> 

After reading the docs some more I've come to another possible reason for the above-mentioned problem:
4. Current implementation for PrefixMap for DRSUAPI is not correct.
I hope I am really wrong here :(. Otherwise code base to be altered and tested is a LOT.
Please, take a look at http://msdn.microsoft.com/en-us/library/cc228445%28PROT.10%29.aspx
As I understood this - BER encoded OIDs in PrefixMap are not complete. In order to completely decode an OID we need to add ATTRTYP value to the corresponding PrefixMapEntry. 

This leads to following consequences:
1. attids enum (drsuapi_DsAttributeId) are kind of obsolete - or, more properly said, those values are correct only for certain cases
2. decoding of PrefixMap received during replication must be postponed to the point when we decode Attrubute OIDs received in replica
3. PrefixMap creation is flexible and depends on the set of objects being replicated. As it depends on current Schema, we can re-create it when schema is updated.

Reading current implementation it seems PrefixMap creation/decoding algorithms are same as those described in MS docs.

Please, correct me if I am wrong.

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