locked
Kerberos Constrained delegation for cross a forest boundary RRS feed

  • Question

  • Hi

    We have a SharePoint 2010 farm server on Cloud with following physical architecture.

     1-    2 WFE Server with load balancer

    2-     2 App server (One Application Server have Search & Indexing services and Another one have rest of services)

    3-     SQL cluster at backend.

    4-     One AD on Cloud which is providing manage account for entire SharePoint Farm

    5-     Another AD is trusted (One-way Trust)through a tunnel to our customer corporate AD to Cloud AD. By this corporate AD all end user are authenticated on SharePoint Portal.

    6-      Currently the system is using the default authentication i.e. classical mode with NTLM.

    In above architecture end user are getting slow response from SharePoint Portal. As I have checked on TechNet & other Microsoft blog this issue is just due to the NTLM authentication.

    For resolution of this issue I have found the Kerberos or claim base authentication mechanism.

    Now, Client have required to change it Kerberos authentication mechanism i.e. the SharePoint portal, all service application will use Kerberos to authenticate users from AD.

    also we are using different SharePoint business applications/services, i.e.

    • Excel Services
    • Performance Point services

    And its required Constrained delegation.For Constrained delegation, it cannot cross a forest boundary regardless of trust relationship.

    So that is it work on one-way AD trust or required two-way AD trust for Constrained delegation on cross a forest domain?

    So we need some help on identifying risk factors in Kerberos implementation in above scenario as well as that will be helpful to resolve our current issue or not?

    Your assistance is very grateful for us.

    Thanks
    Deepak


    Friday, February 24, 2012 4:29 AM

Answers

  •  

    The Kerberos protocol supports two kinds of delegation, basic (unconstrained) and constrained.

    Basic Kerberos delegation can cross domain boundaries in a single forest, but cannot cross a forest boundary regardless of trust relationship.

    Kerberos constrained delegation cannot cross domain or forest boundaries in any scenario.

    For more details about KCD configuration for your scenario , i could suggest to refer the white paper on Kerberos

    http://www.microsoft.com/download/en/details.aspx?id=23176

    Friday, February 24, 2012 7:26 AM

All replies

  • Kerberos constrained delegation cannot cross domain boundaries or forest boundaries

    Recommend to ADFS authentication

    Friday, February 24, 2012 6:56 AM
  • Ok Any work around with given scenario withou ADFS authentication.

    Thanks
    Deepak

    Friday, February 24, 2012 7:06 AM
  •  

    The Kerberos protocol supports two kinds of delegation, basic (unconstrained) and constrained.

    Basic Kerberos delegation can cross domain boundaries in a single forest, but cannot cross a forest boundary regardless of trust relationship.

    Kerberos constrained delegation cannot cross domain or forest boundaries in any scenario.

    For more details about KCD configuration for your scenario , i could suggest to refer the white paper on Kerberos

    http://www.microsoft.com/download/en/details.aspx?id=23176

    Friday, February 24, 2012 7:26 AM
  • Hello Senthil,

    On Above architecture, If we will enable ADFS to accept  Kerberos authentication then it will work on forest domain?

    Please suggest us.

    Regards
    Deepak


    Wednesday, April 18, 2012 9:09 AM
  • Hi Deepak,

    Yes, You can enable ADFS to accept Kerberos authentication applicable only which Kerberos constrained delegation front end and back end servers are in same domain[http://blogs.technet.com/b/ad/archive/2007/10/24/kerberos-constrained-delegation-fe-and-be-servers-must-be-in-same-domain.aspx]

    CASE studies : http://www.forefront-tmg.de/download/CaseStudy_ADFS_KCD.pdf

    Kerberos Constrained Delegation (KCD) is limited to having your front-end and back-end in the same domain:

    http://blogs.technet.com/b/ad/archive/2007/10/24/kerberos-constrained-delegation-fe-and-be-servers-must-be-in-same-domain.aspx

    Transitive trust or not, the important piece is where the computer accounts and service accounts live for this scenario. If all front-end and back-end computer and service accounts in the same domain, then KCD will succeed. The same goes for the contoso.com resources.

    When AD FS and KCD are in the same scenario, we know that we will need to transition from claims to a Windows token at the front-end server in one of two ways:

    1. In AD FS 1.0/1.1 days, we use the Windows token Web Agent to transition from claims to a Windows token.
    2. With AD FS 2.0, we utilize the Claims to Windows Token Service (C2WTS) which ships with Windows Identity Foundation (WIF) to transition from claims to a Windows token.

    Once we have a Windows token for the user, we can invoke KCD as long as the computer and service accounts are in the appropriate domains.

    Regards

    Senthil

    Thursday, April 19, 2012 6:26 AM
  • This is a really interesting topic that I wanted to solve at my company but never got the time to do it.

    these sites says a two way trust is a must

    http://blogs.technet.com/b/askds/archive/2008/11/25/fun-with-the-kerberos-delegation-web-site.aspx

    http://www.adopenstatic.com/cs/blogs/ken/archive/2008/06/28/17805.aspx

    I believe in windows server 8 there are changes to kerberos that help.

    http://technet.microsoft.com/en-us/library/hh831747.aspx


    Please mark my response as an answer if appropriate.
    Learn.SharePoint.com

    Thursday, April 19, 2012 6:36 AM