none
[MS-ADTS][MS-DRSR] selecting DC to DC SPN for communication RRS feed

  • Question

  • Hello,

    MS-DRSR specify a set of SPN which can be used for DC to DC communication in 2.2.3.2 SPN for a Target DC in AD DS

    Basically:

    The scenario determines how the DC constructs an SPN for the service it is using:
    ▪ A DC wants to connect to a DC in a particular domain. The DC constructs the following SPN:
    ▪ "<DRS interface GUID>/<DSA GUID>/<DNS domain name>"
    ▪ A DC wants to connect to a GC server in the forest. The DC constructs the following SPN:
    ▪ "GC/<DNS hostname>/<DNS forest name>"

    As I understood, the fact that a DC is a GC is evaluated in regards with the NTDS Setting object and if the options attribute has the flag NTDSDSA_OPT_IS_GC (0x00000001) as explained in MS-ADTS 6.1.1.2.2.1.2.1.1 nTDSDSA Object

    The fact that a DC is a GC can be evaluated by the constructed attribute as explained in 3.1.1.4.5.31 msDS-isGC

    My understanding is:

    - if a DC is a GC (as evaluated by msDS-isGC), then the SPN should be on the form GC/<DNS hostname>/<DNS forest name>

    - else the SPN should be on the form <DRS interface GUID>/<DSA GUID>/<DNS domain name>

    => Question: is this logic correct or are there any exception to that ?

    Indeed, here are a set of screenshot prooving that my test DC is not a GC:

    (next ...)


    • Edited by vletoux2 Wednesday, August 30, 2017 3:10 PM grammar
    Wednesday, August 30, 2017 2:58 PM

Answers

  • Posting a summary on the forum thread:

    The creation of the DC computer object is specified in MS-ADTS. From there, it references MS-DRSR about the SPNs that need to be created (Note: the SPN with GC class is not based on msDS-isGC). This is also justified by the fact IDL_DRSRemoveDsServer removes all SPNs with the specified classes.

    The DRSR and ADTS specs appear to cover this. ADTS also mentions the mutual authentication.

     

    “MS-ADTS 6.1.1.3 Critical Domain Objects” defines SPN attribute of DC and RODC objects which links back to MS-DRSR Section 2.2.2.

    MS-ADTS

    6.1.1.3.1               Domain Controller Object

    servicePrincipalName: This attribute contains all of the SPNs for a normal (not read-only) DC, as specified in [MS-DRSR] section 2.2.2.

    6.1.1.3.2               Read-Only Domain Controller Object

    servicePrincipalName: This attribute contains all of the SPNs for the RODC, as specified in [MS-DRSR] section 2.2.2.

     

    As documented, all DCs must store the SPN with GC class, along with other SPNs (6 SPNs for RODC, and 7 SPNs for other DCs).

    “MS-DRSR 4.1.1.2.3 CreateNtdsDsa” is calling ConstructReplSpn() for creating the DRS replication SPN class on the computer object of the DC.

    MS-DRSR

    2.2.3.2 SPN for a Target DC in AD DS https://msdn.microsoft.com/en-us/library/dd207688.aspx

    . . .

    To allow mutual authentication to occur in DC-to-DC protocol operations, an AD DS RODC MUST store the form of SPN that begins with "GC/" as values of the servicePrincipalName attribute of the DC's computer object, but not the other form of SPN because that form of SPN is used for outbound replication. Other AD DS DCs MUST store both forms of SPN as values of the servicePrincipalName attribute of the DC's computer object. Additional forms that must be stored for client-to-DC protocol operations are described in section 2.2.4.2.

     

    2.2.4.2 SPN for a Target DC in AD DS https://msdn.microsoft.com/en-us/library/cc228113.aspx

    . . .

    To allow mutual authentication to occur in client-to-DC protocol operations, an AD DS DC MUST store these seven forms of SPN as values of the servicePrincipalName attribute of the DC's computer object. The GC SPN for client-to-DC is identical to the GC SPN for DC-to-DC. Therefore, when the requirements of this section are added to the requirements of section 2.2.3.2, an AD DS RODC MUST store six, and other AD DS DCs MUST store seven, servicePrincipalName values in all.

     

    The following DRSRemoveDsServer function also shows that all SPNs are supposed to be added.

    MS-DRSR 4.1.18.2             Server Behavior of the IDL_DRSRemoveDsServer Method

       foreach spn in computer!servicePrincipalName 

         if StartsWith(spn, "ldap/") or

            StartsWith(spn, "GC/") or

            StartsWith(spn, "E3514235-4B06-11D1-AB04-00C04FC2DCD2/") or

            StartsWith(spn, "RPC/") then

           spnsToRemove := spnsToRemove + {spn}

         endif

       endfor

     

    Thanks,

    Edgar

    Monday, September 25, 2017 4:40 PM
    Moderator

All replies

  • oups, message cutted

    ------------------------------------------

    However when calling IDL_DRSReplicaAdd with a v1 structure filled like:

    msgAdd.V1.pNC = root;
    msgAdd.V1.pszDsaSrc = "the FQDN of the DC";
    msgAdd.V1.ulOptions = DRS_WRIT_REP;

    The SPN constructed by a Windows 2008 R2 DC (same functional level for domain / forest) is build starting with a "GC". And this server is NOT a GC

    Note: this information has been gathered by enabling the debugging mode at HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics


    As explained in MS-DRSR "4.1.19.2 Server Behavior of the IDL_DRSReplicaAdd Method", the connection is made in IDL_DRSReplicaAdd using "hDrsSrc := BindToDSA(msgIn.pSourceDsaDN)"

    BindToDSA is described in MS-DRSR 5.19 BindToDSA() as "The BindToDSA procedure establishes an RPC connection to the target DC represented by its DSA object. It also performs the IDL_DRSBind call. It returns the RPC handle on success or null on failure"
    Nothing more.

    So Question:

    => where is the logic to build the SPN for a connection described ? Because the test I conducted seems to indicate that the logic to build the SPN is more complex than documented.

    OR

    => what would be the case that a remote DC will consider a non GC to be seen as a GC

    regards,

    Vincent



    Wednesday, August 30, 2017 3:09 PM
  • Hi Vletoux2:

    I have alerted the Open Specification regarding your inquiry. A member of the tea will be in touch soon. 


    Regards, Obaid Farooqi

    Wednesday, August 30, 2017 7:34 PM
    Owner
  • Vincent,

    I will investigate this and follow-up.

    Thanks,

    Edgar

    Wednesday, August 30, 2017 10:00 PM
    Moderator
  • Vincent,

    If we have the DNS host name, we just use the GC SPN type. This is not based on msDS-isGC.

    All DCs register the SPN with GC class. This probably comes from historical reasons. The design intended to have a GC SPN, but people were misusing the GC SPN to contact non-GCs. The situation has been “addressed” by registering this SPN for all DCs. This has been around for a long time, even in Server 2003.

     

    Thanks,

    Edgar

    Friday, September 1, 2017 7:40 PM
    Moderator
  • Edgar,

    Can you reflect the changes to:

    5.19 BindToDSA()

    (maybe add the DRS_OPTION parameter forwarded from the parent function and add a AND with DRS_SYNC_BY_NAME)

    And maybe 4.1.1.2.1 ConstructReplSpn to reflect that only 1 of the 2 required SPN is added.

    And then maybe MS-ADTS (because having a GC SPN because a requirement)

    regards,

    Vincent

    Saturday, September 2, 2017 6:00 AM
  • Vincent,
    Can you please contact me at this alias: dochelp < at > microsoft [ dot ] com?
    Please mention this thread and address the message to my attention.
    I'd like to get more details about your latest post.
    Thanks,
    Edgar
    Wednesday, September 6, 2017 9:41 PM
    Moderator
  • Posting a summary on the forum thread:

    The creation of the DC computer object is specified in MS-ADTS. From there, it references MS-DRSR about the SPNs that need to be created (Note: the SPN with GC class is not based on msDS-isGC). This is also justified by the fact IDL_DRSRemoveDsServer removes all SPNs with the specified classes.

    The DRSR and ADTS specs appear to cover this. ADTS also mentions the mutual authentication.

     

    “MS-ADTS 6.1.1.3 Critical Domain Objects” defines SPN attribute of DC and RODC objects which links back to MS-DRSR Section 2.2.2.

    MS-ADTS

    6.1.1.3.1               Domain Controller Object

    servicePrincipalName: This attribute contains all of the SPNs for a normal (not read-only) DC, as specified in [MS-DRSR] section 2.2.2.

    6.1.1.3.2               Read-Only Domain Controller Object

    servicePrincipalName: This attribute contains all of the SPNs for the RODC, as specified in [MS-DRSR] section 2.2.2.

     

    As documented, all DCs must store the SPN with GC class, along with other SPNs (6 SPNs for RODC, and 7 SPNs for other DCs).

    “MS-DRSR 4.1.1.2.3 CreateNtdsDsa” is calling ConstructReplSpn() for creating the DRS replication SPN class on the computer object of the DC.

    MS-DRSR

    2.2.3.2 SPN for a Target DC in AD DS https://msdn.microsoft.com/en-us/library/dd207688.aspx

    . . .

    To allow mutual authentication to occur in DC-to-DC protocol operations, an AD DS RODC MUST store the form of SPN that begins with "GC/" as values of the servicePrincipalName attribute of the DC's computer object, but not the other form of SPN because that form of SPN is used for outbound replication. Other AD DS DCs MUST store both forms of SPN as values of the servicePrincipalName attribute of the DC's computer object. Additional forms that must be stored for client-to-DC protocol operations are described in section 2.2.4.2.

     

    2.2.4.2 SPN for a Target DC in AD DS https://msdn.microsoft.com/en-us/library/cc228113.aspx

    . . .

    To allow mutual authentication to occur in client-to-DC protocol operations, an AD DS DC MUST store these seven forms of SPN as values of the servicePrincipalName attribute of the DC's computer object. The GC SPN for client-to-DC is identical to the GC SPN for DC-to-DC. Therefore, when the requirements of this section are added to the requirements of section 2.2.3.2, an AD DS RODC MUST store six, and other AD DS DCs MUST store seven, servicePrincipalName values in all.

     

    The following DRSRemoveDsServer function also shows that all SPNs are supposed to be added.

    MS-DRSR 4.1.18.2             Server Behavior of the IDL_DRSRemoveDsServer Method

       foreach spn in computer!servicePrincipalName 

         if StartsWith(spn, "ldap/") or

            StartsWith(spn, "GC/") or

            StartsWith(spn, "E3514235-4B06-11D1-AB04-00C04FC2DCD2/") or

            StartsWith(spn, "RPC/") then

           spnsToRemove := spnsToRemove + {spn}

         endif

       endfor

     

    Thanks,

    Edgar

    Monday, September 25, 2017 4:40 PM
    Moderator