Good day Tridge! I have included below the answer I provided on November 13. I
will archive the case next Monday (December 14) if I do not hear from you; if
necessary, we can reopen the case.
Regards,
Bill Wesse
MCSE, MCTS / Senior Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL: +1(980) 776-8200
CELL: +1(704) 661-5438
FAX: +1(704) 665-9606
From: Bill Wesse
Sent: Friday, November 13, 2009 1:11 PM
To: 'tri...@samba.org'
Cc: 'cifs-proto...@samba.org'; 'h...@highlandsun.com'
Subject: Status: limits on rDN size in AD (SRX091112600056 [MS-ADTS] limits on
rDN size in AD)
The length of a delete-mangled RDN may indeed exceed rangeUpper, due to the
additional delete-mangle decoration.
I should first note that the delete-mangled RDN format contains a '\0A'
character - not a '\0'. Perhaps this is a typo in your email?
\0A is a character not allowed in Active Directory names, per [MS-ADTS]
3.1.1.5.1.2 - and is certainly a handy way to verify whether or not a name has
been mangled (a.k.a. strchr(pszRDN, (int)0x0a) ).
The format is, of course, noted in [MS-ADTS] 3.1.1.5.5 , like
"objectName\0ADEL:dashed_string_objectGUID". As noted in [MS-ADTS] 3.1.1.5.1.2.
the maximum RDN length is 255; it is further constrained to 64 ([MS-ADA1] 2.110
Attribute cn, rangeUpper: 64).
That said, the length of a delete-mangled RDN can be up to 105 characters (not
including the terminating NUL character): {rangeUpper:64} + {0x0A:1} +
{'DEL:':4} + {dashed-string-Guid:36}.
[MS-ADTS] 3.1.1.5.1.2 also notes that "Naming constraints are not enforced for
replicated updates.", so the additional length of a delete-mangled RDN will
replicate properly.
I have filed a TDI against [MS-ADTS] section 3.1.1.5.5 Delete Operation to have
this annotated.
References:
[MS-ADTS]: Active Directory Technical Specification
3.1.1.5.1.2 Naming Constraints
During an originating update of the Add, Modify, and Modify DN operations, the
server validates the following naming constraints. Unless otherwise specified,
the server returns LDAP error namingViolation if a naming constraint is not met.
o The RDN must not contain a character with value 0xA.
o The RDN must not contain a character with value 0x0; otherwise, the server
SHOULD return LDAP error invalidDNSyntax. However, if the DC functional level
is DS_BEHAVIOR_WIN2000, the server will not return an error.
o The DN must be compliant with [RFC2253].
o The RDN size must be less than 255 characters.
Naming constraints are not enforced for replicated updates.
3.1.1.5.5 Delete Operation
...
In most cases, upon deletion, a tombstone, deleted-object, or recycled-object
is moved into the Deleted Objects container of its NC; for exceptions see
section 3.1.1.5.5.6. The RDN of the object is changed to a "delete-mangled
RDN"-an RDN that is guaranteed to be unique within the Deleted Objects
container. If O is the object that is deleted, the delete-mangled RDN is the
concatenation of O!name, the character with value 0x0A, the string "DEL:", and
the dashed string representation ([RFC4122] section 3) of O!objectGUID. A
"delete-mangled DN" is a DN such that the leaf RDN is a delete-mangled RDN.
==============================================================================
Question:
From: tri...@samba.org [mailto:tri...@samba.org]
Sent: Monday, November 09, 2009 6:58 PM
To: Hongwei Sun
Cc: cifs-proto...@samba.org; h...@highlandsun.com
Subject: RE: limits on rDN size in AD ?
Hi Hongwei,
We're back to the old question of rDN size limits again!
I just got a DRS replication reply from w2k8-r2 with a CN that has a length
larger than 64. So I suspect that things are a bit more complex than what we'd
discussed before.
The object was:
CN=89532b80-09fe-445e-afef-965c0d7f7d15\0ADEL:462902b4-1824-4f02-8956-9f934f64fa01,CN=Deleted
Objects,CN=Configuration,DC=vsofs8,DC=com
which gives a length of 80.
Are we perhaps supposed to interpret the \0 as a termination character for the
purposes of this length constraint? (note that this is a \ followed by a 0, not
a nul byte).
Or perhaps deleted objects are special in their constraints in some way?
Cheers, Tridge
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
