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: https://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 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
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:\windows\temp and c:\windows\microsoft.net\framework\v2.0.50727\temporary 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 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:
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
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
December 03, 2010
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. support.microsoft.com/.../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 support.microsoft.com/.../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.Anonymous
December 03, 2010
Sorry the second link above should be support.microsoft.com/.../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.