Using ADFS with Constrained Delegation

With ADFS - the authentication token issued is good for the web server with the agent installed.  It is a local RPC token and cannot go off the box.  With some additional configuration, you can configure ADFS to go off the box and delegate with a kerbitized back-end.  There are some caveats - namely, a shadow account must exist in the resource forest.  If you are in a WebSSO scenario - then this isn't a big deal because the account is already there.  If you are in a Federated WebSSO scenario, you will need to create accounts that have a matching UPN address.

Also, keep in mind that you will need to first do Protocol Transition, then Constrained Delegation.

Start with the ADFS step-by-step lab found here with Adatum (account) and Treyresearch (resource) setup as noted:

FS-A is running on a DC

FS-R is running on a DC

Web Server is running on a member server of the FS-R domain

The web application used for this test is attached – it simply enumerates the contents of ou=a,dc=treyresearch,dc=net.

This guide enables constrained delegation without TCB on an AppPool identity.  Many admins are concerned about any accounts with TCB enabled, so this should allow for better security practices with ADFS.  This Whitepaper discusses the requirements and TCB user right in fairly good detail:

The steps necessary to demo the functionality are detailed below.

  1. Create a shadow user for adatum\adamcar in the treyresearch forest

    • You must first add a upn suffix of using domain.msc  - the shadow account uses the adatum upn suffix address

  2. Create two domain service accounts in the domain –

    • One called webservice (for the web app pool identity)

    • The other called ifs_account (for the adfs web agent)

  3. On the local security policy of the web server – add these user rights to ifs_account:

    • Act as part of the operating system

    • Logon as a Service

    • Generate Security Audit Events

  4. On the local security policy of the web server – add these user rights to webservice:

    • Logon as a Service

    • Generate Security Audit Event

    • NOTE:  The App pool identity does not have TCB in this setup

  5. Add both domain service accounts to the Web Server machine's local IIS_WPG group

  6. Make sure both domain service accounts have write access to c:\windows\temp and c:\windows\\framework\v2.0.50727\temporary files

  7. Change the Application Pool Identity for Web application to the webservice domain service account

  8. Change the ADFS Web Agent service to run under the ifs_account

  9. On the resource DC open the Users and Computers snapin, and on the delegation tab of both domain service accounts specify

    • Trust user for specified services only

    • Use any authentication protocol

    • Add the domain controller’s LDAP service record. 

  10. Add the Web application code from here to the web server and enable the ADFS NT-Token based Web Agent

  11. In ADFS.MSC on the FS-R, add a new token application – only enable the UPN claim.

  12. In ADFS.MSC on the FS-R, go to the A. Datum account partner properties and on the resource accounts tab choose Resource accounts exist for some users (prefer resource accounts)

  13. Create an OU and remove authenticated users from the security, add the adamcar shadow account and grant permissions.  Enable object access auditing on the OU.

From an XP client in the Adatum forest logged on as  - launch a browser and open

The page writes out the identity of treyresearch\adamcar, then simply press the button and the contents of ou=a,dc=treyresearch,dc=net are displayed in the text box.

The DC’s security log should show the following:

Event Type: Success Audit

Event Source:     Security

Event Category:   Logon/Logoff

Event ID:   540

Date:       5/2/2008

Time:       11:44:14 AM

User:       TREYRESEARCH\adamcar



Successful Network Logon:

      User Name:

      Domain:           TREYRESEARCH.NET

      Logon ID:         (0x0,0x5791A)

      Logon Type: 3

      Logon Process:    Kerberos

      Authentication Package: Kerberos

      Workstation Name:

      Logon GUID: {f825dc83-9f3c-feea-5c82-663d6ca646f8}

      Caller User Name: -

      Caller Domain:    -

      Caller Logon ID:  -

      Caller Process ID: -

      Transited Services:


      Source Network Address:

Source Port:      1150

Event Type: Success Audit

Event Source:     Security

Event Category:   Directory Service Access

Event ID:   566

Date:       5/2/2008

Time:       11:44:14 AM

User:       TREYRESEARCH\adamcar



Object Operation:

      Object Server:    DS

      Operation Type:   Object Access

      Object Type:      organizationalUnit

      Object Name:      OU=a,DC=treyresearch,DC=net

      Handle ID:  -

      Primary User Name:      ADFSRESOURCE$

      Primary Domain:   TREYRESEARCH

      Primary Logon ID: (0x0,0x3E7)

Client User Name:

      Client Domain:   

      Client Logon ID:  (0x0,0x5791A)

      Accesses:   List Contents


      List Contents


      Additional Info: 

      Additional Info2:

      Access Mask:      0x4

ou enumeration

Comments (3)
  1. Anonymous says:


    I was having trouble setting up the scenario you described above. I performed all the configuration steps you listed, but when I logged into the webapplication, it displayed:


    When I pushed the button to initiate the LDAP query I got  an Error saying:

    Exception Details: System.Runtime.InteropServices.COMException: The specified domain either does not exist or could not be contacted.

    Line 41: string ADsPath = "LDAP://CN=Users," + (string)rootDSE.Properties["defaultNamingContext"][0];

    The creation of the rootDSE object failed, probably due to some authorization failure.

    Luckily I found the solution to this problem, so I thought to share it with you.

    First I’ll describe the errors I encountered.

    The eventviewer listed the following warnings:

    1. Application event:

    Event Type: Warning

    Event Source: ADFS ISAPI Extension

    Event Category: None

    Event ID: 107

    Date: 9/07/2008

    Time: 12:35:12

    User: N/A

    Computer: ADFSRESOURCE


    The ADFS Web Agent Internet Server Application Programming Interface (ISAPI) Extension was unable to obtain a Windows NT token from the authentication service.

    An anonymous token will be generated for this request.

    User Action

    Ensure that this application is configured as a Windows NT token-based application in the Federation Service trust policy.

    If the user comes from an account partner where Windows Trust may be applicable, ensure that Windows Trust is enabled for the account partner and that the account partner has enabled Windows Trust for this resource partner.

    If you are using shadow accounts:

    – Ensure that a shadow account exists for this user.

    – Ensure that user principal name (UPN) claims or e-mail claims are enabled for this application.

    – Ensure that UPN claims or e-mail claims are being produced for this user by the account store or the account partner.

    Additional Data

    Look for additional events in the security log that may contain more details. Consider enabling failure auditing on this Web server if auditing is not already enabled.

    2. Security event:

    Event Type: Failure Audit

    Event Source: Security

    Event Category: Logon/Logoff

    Event ID: 529

    Date: 9/07/2008

    Time: 12:35:12


    Computer: ADFSRESOURCE


    Logon Failure:

    Reason: Unknown user name or bad password

    User Name:


    Logon Type: 3

    Logon Process:

    Authentication Package: Kerberos

    Workstation Name: ADFSRESOURCE

    Caller User Name: ifs_account

    Caller Domain: TREYRESEARCH

    Caller Logon ID: (0x0,0x10610786)

    Caller Process ID: 12700

    Transited Services: –

    Source Network Address: –

    Source Port: –

    When I sniffed the network for kerberos traffic towards the KDC, I found the following:

    AS-REQ (Client Name:


    TGS-REQ (S4U2SELF client name:; Server Name:


    Apparently the service/computer account that runs the ADFS webagent must have read access on the TGGAU attribute of all users objects in the domain in order to obtain an NT token for the user using Kerberos S4U. (related KB:

    After the ifs_account and the webservice have read permission on the TGGAU properties, through the ‘BuiltinWindows authorization access’ group membership, the problem was solved.

    It would be great if the solution is added to the event description of event 107 mentioned above, because it took me quite a while to figure this one out.

  2. Spike Robinson says:

    When using Kerberos with ADFS 2.0, you may intermittently see HTTP error 400 from the ADFS server, protesting that the headers are too long. This is likely to occur if using Kerberos authentication and if the user has a large number of AD group memberships. See this KB article.…/2020943

    This would suggest that increasing the MaxRequestBytes registry key from the 16K default to say 65534 (64K out of a maximum 16MB) is the best course of action.

    BUT, given that the above KB references another KB article…/2020943 that states (rightly or wrongly) that increasing the maximum accepted header size is *extremely dangerous*, the prudent course of action is probably to use NTLM only.

    In IIS 7 this is accomplished in IIS manager by editing IIS Authentication for the adfs/ls virtual directory. Select Providers and remove ‘Negotiate’, leaving only NTLM.

    Unfortunately it appears there is no way to safely use Kerberos in conjunction with ADFS 2.0, which is a great shame.

  3. Spike Robinson says:

    Sorry the second link above should be…/en-us

    this is the article that specifically declares the reg key edit to be "extremely dangerous", though the first article also says it is dangerous.

Comments are closed.

Skip to main content