Directory Programming .NET

I have an ADFS test environment set up with an ADFS account federation server, an ADFS resource federation server and an ADFS proxy server for the ADFS resource federation server.

Everything works fine if I configure the account federation server to communicate directly with the resource federation server but I get errors showing up if I configure the account federation server to work through the proxy instead.

Running the ADFS Diagnostic Tool on the proxy server I get the following error:

The error log on the resource server shows the following:

2009-05-29T14:03:30 [VERBOSE] Processing HTTP GET: https://wsfed.internaltest.com/adfs/fs/FederationServerService.asmx
2009-05-29T14:03:30 [VERBOSE] Received message that is not SignIn Request or Response.
2009-05-29T14:04:56 [INFO] Processing HTTP POST: https://wsfed.internaltest.com/adfs/fs/FederationServerService.asmx
2009-05-29T14:04:56 [VERBOSE] Received message that is not SignIn Request or Response.
2009-05-29T14:04:59 [INFO] Loading trust policy from C:\ADFS\TrustPolicy.xml
2009-05-29T14:05:00 [INFO] IsValidDomainName: DnsValidateName_W returned 0
2009-05-29T14:05:00 [INFO] FS Account Name: Using computer name 'TESTDOMAIN1\TESTPSAPP1$'
2009-05-29T14:05:00 [ERROR] MethodInvocationCheck: Client cert is not present
2009-05-29T14:05:00 [EVENTLOG] Error ProxyWebMethodAccessDeniedNoCert ()
2009-05-29T14:05:00 [ERROR] MethodInvocationCheck: Denying access

I've tried several different client authentication certificates and have found the same error with each one.  Both self-signed certificates (generated using makecert) and certificates signed by an internal CA (generated through Microsoft certificate services) have been tested.  I've verified the certs were added to the FSP Certificates tab in ADFS on the resource server and the "Trusted Root Certification Authorities" store for the local computer on the resource server as well.

There was a similar problem posted in one of the ADFS blogs where the problem was related to permissions reading the certificate's private key on the proxy server but I don't think that's the problem here.  I've ensured the certificates are in the local system certificate store and have the appropriate permissions on them.  Even changing the ADFS application pool to run under the local system account doesn't work.

Please let me know if anyone has suggestions on the problem or what the next step in troubleshooting could be.  Is there some requirement for the client authentication certificate that I may have missed?  I am looking at getting a certificate chained to a real public CA to try out but I had understood from looking at the documentation that this shouldn't be necessary.

Thanks in advance and let me know if I can provide additional information that would be useful in assisting.

It sounds like the proxy is not even trying to use the client cert in this case, so there is something wrong with the PKI setup somehow.  Here are a couple of things to check:

• Verify that the client cert is in the Personal or "MY" container of Local Machine store on the proxy box
• Verify that the MMC says the cert has a private key.
• Verify that the proxy app pool identity (probably network service) has read rights on the private key file.
• Verify that the client cert actually has the client authentication EKU.
• Verify that the certificate chains properly on the proxy box (cert GUI for the client cert shows no errors in the chain). 
• Verify that any certs in the chain are in the proper intermediate and trusted root containers of the Local Machine store, not the store of the current logged on user.
• Verify that the cert also chains properly on the fed server box with the same rules about the intermediates and roots being in the Local Machine store there as well.

If you set the permissions on the private key such that the admin user has read rights as well, you should be able to browse to the FS fed server URL (https://wsfed.internaltest.com/adfs/fs/FederationServerService.asmx) and have that do a successful client cert authentication as well. One thing you could do to test would be to create another vdir on the FS outside of the /adfs/ vdir, configure it with the same server cert and set it to REQUIRE client cert authentication.  You could just put a plain html page in the vdir to test against.  The key is to see if you can get the SSL layer functioning correctly.

I hope that helps.  The proxy can be a PITA as SSL client cert auth itself a bit painful.

I verified your points above and everything looked okay.  Setting up a separate vdir on the FS showed a similar error though ("The page requires a client certificate") so I think you're correct that this is really just an SSL client certificate authorization problem and not really an ADFS problem.

I'll take another look at the certificates I'm using and troubleshoot that separately.

Thanks for your help!

I realize that this is not strictly ADFS related but I will still post the solution here for the benefit of anyone that runs in to the same problem with the validation of the proxy server client authentication certificates.

It turns out that there were too many certificates with the ability to be used for client authentication installed in the trusted root store of the local machine on the resource federation server.  There is a not-well-known limitation on the number of client authentication certificates that can be supported.  Here is a sample of the error that shows up in the system event log on the first call after each restart that requires a client authentication certificate:

Event Type: Warning
Event Source: Schannel
Event Category: None
Event ID: 36885
Date: 2/9/2007
Time: 9:32:44 AM
User: N/A
Computer: USMASVGDOIM259
Description:
When asking for client authentication, this server sends a list of trusted
certificate authorities to the client. The client uses this list to choose a client
certificate that is trusted by the server. Currently, this server trusts so many
certificate authorities that the list has grown too long. This list has thus been
truncated. The administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that do not really
need to be trusted.

There's also a good description of this problem at the following link.

Thanks for posting.  That should have been something you could have discovered with the browser as well if the private key on all the available certs was available to the browser.  With client cert auth required on the vdir, IE should have prompted you to select a certificate to use.  That would have been the clue that there was more than one option which (as you discovered) does not work in a server to server scenario since there is no way for the selection to be made by the SSL client on the proxy.

Glad you got it sorted!