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
