ber_read_OID_String patch

[Stefan (metze) Metzmacher]

Kamen Mazdrashki schrieb:
> 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.

The prefixMap attribute on the schema head object is never exposed via
any protocol directly (you can't get it via LDAP).

That's why we can store it as we like.
And we use oid strings instead of truncated binary oids.

> 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. 

I think we should just use a special function maybe called
ber_read_trunated_OID_String() ) to correctly decode/encode
the binary oid value to a string in
ndr_pull_drsuapi_DsReplicaOID/ndr_push_drsuapi_DsReplicaOID.

> 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

It's just a uint32, the reason we have some special hardcoded values in
our idl is that some of the prefix mappings are also hardcoded.
See the table in
http://msdn.microsoft.com/en-us/library/cc228445%28PROT.10%29.aspx
This makes the coding of the DsAddEntry call easier, however we could
also change that and always create prefix tables with the hardcoded
values and do dynamic mapping.

> 2. decoding of PrefixMap received during replication must be postponed to the point when we decode Attrubute OIDs received in replica

I don't understand why this would be needed, we just need a parser for
the truncated binary oids.

> 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.

Yes, that's why we have to check that the
drsuapi_DsReplicaOIDMapping_Ctr matches between the source dsa and us
(as destination dsa) before replicating naming contexts other than the
schema partition. If we hit a mismatch we first need to replicate the
schema partition (maybe we need to directly replicate from the schema
master, but we have to test that).

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


Yes, the only difference seems to be that we use strings instead of
truncated binary oids internally. And that difference is no logical
difference.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090903/f2c993db/attachment.pgp>