[cifs-protocol] Structure of prefixMap over LDAP

Fri Jan 15 02:09:20 MST 2010

Hi Obaid,

Could you please point out where those default 39 entries for prefixMap are described?
I am looking at: http://msdn.microsoft.com/en-us/library/cc228445%28PROT.13%29.aspx
and there are only 19 default prefixes listed here.

Thanks,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
http://repo.or.cz/w/Samba/kamenim.git
-------------------------------------
CISCO SYSTEMS BULGARIA EOOD
http://www.cisco.com/global/BG/

> -----Original Message-----
> From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-
> bounces at cifs.org] On Behalf Of Obaid Farooqi
> Sent: Thursday, January 14, 2010 8:27 PM
> To: abartlet at samba.org
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: Re: [cifs-protocol] Structure of prefixMap over LDAP
> 
> Hi Andrew:
> Please let me know if the following answers your question. If yes, I'll
> consider this issue resolved.
> 
> Regards,
> Obaid Farooqi
> Sr. Support Escalation Engineer | Microsoft
> 
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Wednesday, January 06, 2010 2:03 PM
> To: 'abartlet at samba.org'
> Cc: 'cifs-protocol at samba.org'; 'pfif at tridgell.net'
> Subject: RE: Structure of prefixMap over LDAP
> 
> 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.
> 
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol