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:[email protected]] Sent: Friday, January 15, 2010 3:09 AM To: Obaid Farooqi; [email protected] Cc: [email protected]; [email protected] 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 [email protected] http://repo.or.cz/w/Samba/kamenim.git ------------------------------------- CISCO SYSTEMS BULGARIA EOOD http://www.cisco.com/global/BG/ > -----Original Message----- > From: [email protected] [mailto:cifs-protocol- > [email protected]] On Behalf Of Obaid Farooqi > Sent: Thursday, January 14, 2010 8:27 PM > To: [email protected] > Cc: [email protected]; [email protected] > 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: '[email protected]' > Cc: '[email protected]'; '[email protected]' > 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:[email protected]] > Sent: Tuesday, December 15, 2009 1:39 AM > To: Obaid Farooqi > Cc: [email protected]; [email protected] > 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 > [email protected] > https://lists.samba.org/mailman/listinfo/cifs-protocol _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
