locked
ADFS 3.0 CrossForest : Slowness for Trusted forest while sign -on RRS feed

  • Question

  • We have 2 Forest within trust. Only one of the forest have the ADFS environment hosted for sign-on for users in all the relevant domains. We are using WAP as well .

    Need To know, How can I specify/restrict the Domain controller to be used from the closest site rather the referring to completed servers in the for trusted forest/domain ?

    Also, where will this authentication happen will it be at WAP or at ADFS ?

    Friday, November 20, 2015 5:35 PM

Answers

  • The authentication is always coming from the ADFS servers. The source of the authentication is the ADFS server receiving the connexion request. There is an exception though: when a user is authenticating against the WAP to access to a Non Claim Aware relying party trust (using the KCD feature). In that case, the WAP server needs to be domain joined and will request Kerberos tickets on behalf the users. See here: https://technet.microsoft.com/en-us/library/dn508281.aspx.

    The ADFS servers will always try to find the closest DC for the user's domain. Which works fine for users within the same forest, which might not be fine for external or forest trusts since they do not share the same sites' names. Let's make an example:

    The forest contoso.com is composed of contoso.com and child.contoso.com.
    Those two domains share the same site topology since they belong to the same forest.
    There are two sites: Toronto and Seattle.
    If the ADFS servers is deployed in the site Toronto, when users from contoso.com and child.contoso.com will use a DC of Toronto (if any, else it falls back to any available DC for the domain). So it also means that if you want to optimize authentication, you would do like you do to optimize logon time or GPO application, you would add local DCs of each domain in Toronto.

    The contoso.com forest trusts the fabrikam.com forest.
    It happens that this forest also have two sites located in Toronto and Seattle BUT with different names: TOR and SEA.
    When the ADFS servers (belonging to the contoso.com forest) try to locate a local DC for the farbikam.com users' authentication, they will look for a DC on the site called Toronto. This query will fails because there are no such site in the fabrikam.com forest. Hence, they will fall back to any DC of this target domain.

    As you see, if the sites names were alike on both side, this would be optimized. So that would be one way to do it. But you don't have to change the site topology. You can tweak your DNS in a way that the fabrikam.com DCs of the site TOR will also register their DNS records for a site called Toronto (even though this site does not exist in the fabrikam.com forest, no need to create the site in the Sites and Services console). So a smart way to make sure the ADFS servers from contoso.com will always use the DCs of fabrikam.com located in the site TOR, you can create a group policy in the fabrikam.com domain, link it to the Domain Controllers OU and apply a filter to make sure only some DCs (the DCs you want the ADFS server to locate) will apply it. Then you can use the following setting to create a manual coverage:

    Now the bummer... If you are using the Extranet Lockout Policy on the WAP servers... The ADFS servers will always try to locate the PDC of the user's domain to check the badPwdCount attribute (see: http://blogs.technet.com/b/pie/archive/2015/10/11/adfs-extranet-lockout-and-pdc-requirement.aspx). And the PDC might just not be local... So it's your call to let it enabled or move the PDCs of your trusted domain to a closer location...

    Hope this helps.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, November 20, 2015 11:35 PM

All replies

  • The authentication is always coming from the ADFS servers. The source of the authentication is the ADFS server receiving the connexion request. There is an exception though: when a user is authenticating against the WAP to access to a Non Claim Aware relying party trust (using the KCD feature). In that case, the WAP server needs to be domain joined and will request Kerberos tickets on behalf the users. See here: https://technet.microsoft.com/en-us/library/dn508281.aspx.

    The ADFS servers will always try to find the closest DC for the user's domain. Which works fine for users within the same forest, which might not be fine for external or forest trusts since they do not share the same sites' names. Let's make an example:

    The forest contoso.com is composed of contoso.com and child.contoso.com.
    Those two domains share the same site topology since they belong to the same forest.
    There are two sites: Toronto and Seattle.
    If the ADFS servers is deployed in the site Toronto, when users from contoso.com and child.contoso.com will use a DC of Toronto (if any, else it falls back to any available DC for the domain). So it also means that if you want to optimize authentication, you would do like you do to optimize logon time or GPO application, you would add local DCs of each domain in Toronto.

    The contoso.com forest trusts the fabrikam.com forest.
    It happens that this forest also have two sites located in Toronto and Seattle BUT with different names: TOR and SEA.
    When the ADFS servers (belonging to the contoso.com forest) try to locate a local DC for the farbikam.com users' authentication, they will look for a DC on the site called Toronto. This query will fails because there are no such site in the fabrikam.com forest. Hence, they will fall back to any DC of this target domain.

    As you see, if the sites names were alike on both side, this would be optimized. So that would be one way to do it. But you don't have to change the site topology. You can tweak your DNS in a way that the fabrikam.com DCs of the site TOR will also register their DNS records for a site called Toronto (even though this site does not exist in the fabrikam.com forest, no need to create the site in the Sites and Services console). So a smart way to make sure the ADFS servers from contoso.com will always use the DCs of fabrikam.com located in the site TOR, you can create a group policy in the fabrikam.com domain, link it to the Domain Controllers OU and apply a filter to make sure only some DCs (the DCs you want the ADFS server to locate) will apply it. Then you can use the following setting to create a manual coverage:

    Now the bummer... If you are using the Extranet Lockout Policy on the WAP servers... The ADFS servers will always try to locate the PDC of the user's domain to check the badPwdCount attribute (see: http://blogs.technet.com/b/pie/archive/2015/10/11/adfs-extranet-lockout-and-pdc-requirement.aspx). And the PDC might just not be local... So it's your call to let it enabled or move the PDCs of your trusted domain to a closer location...

    Hope this helps.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, November 20, 2015 11:35 PM
  • Any update of this?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    • Marked as answer by M810-007 Thursday, November 26, 2015 12:08 AM
    • Unmarked as answer by M810-007 Thursday, November 26, 2015 12:08 AM
    Wednesday, November 25, 2015 11:14 PM
  • Thanks Pierre!! Seems good to proceed with !! I would definitely like to proceed with this option and GPO But currently as a mitigation we are assigning the local subnet of adfs location to the site of DC in destination Environment. So that all requests coming from ADFS location or DC's from that should be reaching to intended closest DC due to subnet mapping for site. I am hoping this should also serve the purpose and work. Any suggestion.!!!
    Thursday, November 26, 2015 12:08 AM