[cifs-protocol] 115051412733033 x.uuidDsa in MS-ADTS 6.2.2.5 - KCC connection translation
Sreekanth Nadendla
srenaden at microsoft.com
Fri Jun 5 12:44:48 MDT 2015
Hello Douglas,
uuidDsa holds actual GUID and NOT GUID based DNS names like A2f6c43e-e9c9-4040-a2b0-e9ebf2ec02b8._msdcs.379135dom.lab. We will update the relevant sections of MS-ADTS in a future release. Please let me know if you have any questions on this.
Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications
-----Original Message-----
From: Sreekanth Nadendla
Sent: Thursday, May 14, 2015 11:13 AM
To: 'Douglas Bagnall'
Cc: 'cifs-protocol at samba.org'; MSSolve Case Email
Subject: RE: 115051412733033 x.uuidDsa in MS-ADTS 6.2.2.5 - KCC connection translation
Hello Douglas, I will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.
Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications
-----Original Message-----
From: Sreekanth Nadendla
Sent: Wednesday, May 13, 2015 8:39 PM
To: 'Douglas Bagnall'
Cc: cifs-protocol at samba.org; MSSolve Case Email
Subject: 115051412733033 x.uuidDsa in MS-ADTS 6.2.2.5 - KCC connection translation
Dochelp in Bcc
Casemail in Cc
Hello Douglas,
Thank you for your inquiry about MS-ADTS specification. We have created incident 115051412733033 to track the investigation for this issue. One of the Open specifications team member will contact you shortly.
Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications
-----Original Message-----
From: Douglas Bagnall [mailto:douglas.bagnall at catalyst.net.nz]
Sent: Wednesday, May 13, 2015 7:34 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: x.uuidDsa in MS-ADTS 6.2.2.5 - KCC connection translation
hi,
In a couple of places in MS-ADTS 6.2.2.5 (connection translation), the uuidDsa attribute of a repsFrom tuple is used as a "GUID-based DNS name". In other places it is just a GUID.
The "GUID-based DNS name" phrase occurs in this bit, on page 584 of
v20140502:
* If s and the local DC's nTDSDSA object are in the same site,
cn!transportType has no value, or the RDN of cn!transportType is
CN=IP:
* Bit DRS_MAIL_REP in t.replicaFlags is clear.
* t.uuidTransport = NULL GUID.
* t.uuidDsa = The GUID-based DNS name of s.
* Otherwise:
* Bit DRS_MAIL_REP in t.replicaFlags is set.
* If x is the object with dsname cn!transportType,
t.uuidTransport = x!objectGUID.
* Let a be the attribute identified by
x!transportAddressAttribute. If a is the dNSHostName
attribute, t.uuidDsa = the GUID-based DNS name of s.
Otherwise, t.uuidDsa = (s!parent)!a.
That last phrase ("t.uuidDsa = (s!parent)!a") also refers to a DNS name.
Should we assume these mean something like "the GUID corresponding to the GUID-based DNS name"? Or is it never actually a GUID? Or does this really involve some other attribute of t other than uuidDsa?
cheers,
Douglas
More information about the cifs-protocol
mailing list