[cifs-protocol] Structure of prefixMap over LDAP

[Obaid Farooqi]

Hi Andrew,

We understand the reasons for your inquiry as to the exact content and format of the LDAP attribute prefixMap.  We’d like to propose that we explain the content and format of the attribute in this mail, and after that, discuss whether it belongs in the documentation.  

As you’ve no doubt already determined, prefixMap is related to the ‘Prefix Table’ documented in MS-DRSR and used in ATTRTYP-to-OID conversion; it’s also documented in MS-DRSR (section 5.16.4.)  The prefixMap attribute itself though serves no purpose in the context of "replication-protocol" beyond locally storing the state necessary for a replication partner to decompress an implementation-specific means of representing OIDs.  The attribute itself is never requested or written over-the-wire by any Windows implementation nor is it necessary for a partner DC to know how the map is stored.  DRSR does not reference the attribute by name or refer to where the map is maintained in any more general sense; it only provides the necessary detail to define how the OIDs are decompressed to their native form on the partner DC.  

More specifically – prefixMap is a cache of the parts of the Prefix Table that relate to user-defined attributes (which is a subset of the whole Prefix Table used in MS-DRSR.)  Theoretically, this structure could have been built on the fly and not cached.  Certainly this cache could have been stored somewhere else, besides in an attribute of the directory, e.g. on a protocol-inaccessible area in memory or on disk (i.e. not in abstract state).  We certainly didn’t envisage any need or value in a client reading it or writing it – we would have included the entire Prefix Table were that the case.  So if we don’t want any client to ever read or write it then “why is it an attribute?”.  Basically, because it was a convenient place for our implementation to locally store it – our directory implementation IS a handy place to store things.  Plus, for the purposes of debugging our implementation, being able to read implementation-specific values via LDAP is very practical (since we read everything else that way too).

Anyway, the prefixMap structure contains user-defined attribute info for ATTRTYP-to-OID conversion.  This means e.g. for Windows 2008 R2 it does not contain the ATTRTYP-to-OID conversion info for the first 39 attributes in the Prefix Table as used by MS-DRSR, just the ‘rest’ of them.  When this attribute has a value, it is stored as a binary blob with the following formatting:

1. First 4 bytes are a DWORD showing the total number of prefixes represented in the map.  That is, the number of elements in the series of data structures described below.

2. Next 4 bytes are a DWORD showing the total size of the binary blob, including both these first 8 bytes and any remaining bytes representing OID prefixes.

3. Following these first 8 bytes is a series of variable length data structures, each element in the series representing a single mapping between an OID prefix and the internal WORD value representing the prefix.  The WORD is used as the high-word of a DWORD holding an internal attribute type.  These internal attribute types are not useful via LDAP, they are used only in the replication protocol. Each element of the series has this format:
	- First 2 bytes are a WORD holding the internal WORD value.
	- Next 2 bytes are a WORD holding the length of the actual OID prefix.  Call this value N.
	- Next N bytes are the BER encoding of the OID prefix.

Please let me know if this answers your question. If yes, I'll consider this issue resolved.

Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft


                
-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, December 15, 2009 1:39 AM
To: Obaid Farooqi
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: Structure of prefixMap over LDAP
 
On Tue, 2009-12-15 at 06:22 +0000, Obaid Farooqi wrote:
> Hi Andrew:
> In an effort to fully understand your goals, please explain what you 
> are looking  to achieve through the addition of documentation that 
> defines the internal structure of the prefixMap attribute.
 
As a start: 
 
The ability to generate a matching prefixMap attribute, should any client request it.  The ability to verify prefixMap values over DRS and LDAP to confirm consistency.  The ability to include prefixMap values in comparison tests we may make between AD and Samba4.  An understanding of how the contents of this attribute interacts with msDs-intID and other prefix mapping functionality. 
 
Finally, I'm simply looking to ensure that the documentation set explains the format of every value (generated or otherwise) in AD, so we don't have to come back to this later. 
 
Thanks,
 
Andrew Bartlett
 
--
Andrew Bartlett                                http://samba.org/~abartlet/ Authentication Developer, Samba Team           http://samba.org Samba Developer, Cisco Inc.