[cifs-protocol] Structure of prefixMap over LDAP
Sebastian Canevari
Sebastian.Canevari at microsoft.com
Wed Feb 3 14:38:53 MST 2010
Hi Kamen,
Per our original response - this is just an implementation detail and as that, it does not require any additional documentation.
It was just the current number that happened to be in our code-base at the time we put the response together.
How any 3rd party chooses to implement this, is a particular implementation decision.
In retrospect, it was probably a mistake to include that count in our previous communication, but we were looking to be complete and didn't consider this misinterpretation.
Please keep in mind that the detail we provided was just intended to be an example.
Thanks and regards,
Sebastian
Sebastian Canevari
Senior Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
7100 N Hwy 161, Irving, TX - 75039
"Las Colinas - LC2"
Tel: +1 469 775 7849
e-mail: sebastc at microsoft.com
-----Original Message-----
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Obaid Farooqi
Sent: Friday, January 15, 2010 11:28 AM
To: Kamen Mazdrashki
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [cifs-protocol] Structure of prefixMap over LDAP
Hi Kamen:
I'll look into it and will get back to you with my findings.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
-----Original Message-----
From: Kamen Mazdrashki [mailto:kamen.mazdrashki at postpath.com]
Sent: Friday, January 15, 2010 3:09 AM
To: Obaid Farooqi; abartlet at samba.org
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] Structure of prefixMap over LDAP
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
_______________________________________________
cifs-protocol mailing list
cifs-protocol at cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list