ADFS Product Support Blog

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: http://technet2.microsoft.com/WindowsServer/en/Library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx?mfr=true

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 adatum.com using domain.msc  - the shadow account uses the adatum upn suffix address

2. Create two domain service accounts in the Treyresearch.net 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\microsoft.net\framework\v2.0.50727\temporary asp.net 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 Adamcar@adatum.com  - launch a browser and open https://adfsweb.treyresarch.net/ou/default.aspx

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

Computer:   ADFSRESOURCE

Description:

Successful Network Logon:

      User Name:  adamcar@adatum.com

      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:

WEBSERVICE@TREYRESEARCH.NET

      Source Network Address: 192.168.0.121

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

Computer:   ADFSRESOURCE

Description:

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: adamcar@adatum.com

      Client Domain:   

      Client Logon ID:  (0x0,0x5791A)

      Accesses:   List Contents

      Properties:

      List Contents

organizationalUnit

      Additional Info: 

      Additional Info2:

      Access Mask:      0x4

Published Tuesday, May 13, 2008 5:08 PM by jimsim

Attachment(s): ou enumeration app.zip