re: Using ADFS with Constrained Delegation

icts-kul — Wed, 09 Jul 2008 16:57:55 GMT

Hello,

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:

User: ADFSRESOURCE\IUSR_ADFSRESOURCE

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

Description:

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

User: NT AUTHORITY\SYSTEM

Computer: ADFSRESOURCE

Description:

Logon Failure:

Reason: Unknown user name or bad password

User Name:

Domain:

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

-> KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED (25)

TGS-REQ (S4U2SELF client name: adamcar@adatum.com; Server Name: ifs_account@treyresearch.net)

-> KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6)

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: http://support.microsoft.com/kb/331951)

After the ifs_account and the webservice have read permission on the TGGAU properties, through the 'Builtin\Windows 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.