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.
Create a shadow user for adatumadamcar 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
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)
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
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
Add both domain service accounts to the Web Server machine’s local IIS_WPG group
Make sure both domain service accounts have write access to c:windowstemp and c:windowsmicrosoft.netframeworkv2.0.50727temporary asp.net files
Change the Application Pool Identity for Web application to the webservice domain service account
Change the ADFS Web Agent service to run under the ifs_account
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.
Add the Web application code from here to the web server and enable the ADFS NT-Token based Web Agent
In ADFS.MSC on the FS-R, add a new token application – only enable the UPN claim.
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)
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 treyresearchadamcar, 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: TREYRESEARCHadamcar
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:
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: TREYRESEARCHadamcar
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
