LHA Consulting, Incorporated

So in setting up an AD FS test lab in the house to try a few things out, I ran into an unpleasant behavior that I don't remember seeing before:

Environment:

1 machine (ACCOUNT, hereafter) running 2K8 EE. Domain controller in account domain, Enterprise Root CA, running ADFS Federation Service.

1 machine (RESOURCE, hereafter) running 2K8 EE. Domain controller in resource domain, Enterprise Root CA, running ADFS Federation Service.

1 machine (WEB, hereafter) running 2K8 EE. Joined to resource domain, IIS and ADFS Claims-aware web agent installed, sample claims-aware web application installed from the 2K8 ADFS step-by-step guide on the technet2.microsoft.com site.

Troubling behavior:

Configure ACCOUNT and RESOURCE with token-signing certs that are based on version 3 (compatible with Windows Server 2008) certificate templates.

Configure all organizational claims, claim mappings, etc., as required for normal function.

On attempting to access the ~/claimapp on WEB, the following gets logged to ADFS debug logging:

2009-01-28T17:19:58 [EVENTLOG] Error BadConfigurationCertificateHasNoPrivateKey
(system.web/FederationServerConfiguration,X509SigningMethod/X509Thumbprint,
4AF6E328C6E0B7186EB847AF35A560F4A3BF18C4

(Obviously your debug output will reference the thumbprint of your token-signing cert.)

Additional unhappiness:

Go to the General tab in ADFS properties on either ACCOUNT or RESOURCE, click 'View' on the token-signing cert and everything comes up fine.

Now click 'Select', browse to the self-same cert in the Machine store to select it, and you get thrown a dag-nasty error message as follows:

Troubleshooting ruled out the following:

* Verified that the NetworkService account had read perms on the private key.
* Verified that the cert was sitting in the Computer's personal store, not the user's.
* Verified that the root cert was sitting in the Computer's Trusted Root Authority store, again not the user's.

(It's about at this point that, if you're like me, you've walked away from your test machine in despair assuming that you've done something wrong and you just can't put your finger on what. Which is why it took about a week for me to come back to it and find the "fix" that follows.)

As it turns out, if you follow the above and use version 2 (compatible with W2K3) certificate templates instead of version 3 (compatible with W2K8 only) templates, everything works peachy.

My first thought after pinning down the cause was that we'd gotten fracked by Windows Update, as I just don't remember seeing this crop up before. On testing the theory, though, this behavior occurs consistently on Windows Server 2008 regardless of Windows Update levels - tried it on a clean RTM install, tried it with all available WU updates installed, same-same.

The reason for this? Is that the .NET Framework 2.0 apparently does not support private keys based on the ECC algorithms that were introduced in Certificate Services in 2K8. Using a different certificate template (version 3 or otherwise) that uses RSA based public/private key pair works peachy.

Now I'm not sure if the error messages above are textually accurate, per se, or if it's just AD FS encountering a condition it doesn't recognize and throwing the "best" error message that it can. Resolution on it is the same, regardless.

Now, in theory this shouldn't affect that many production deployments, because one assumes that publicly-signed certs are going to be de regur in that case. That said, if you're generating a cert request locally on a 2K8 box, you'll need to be sure the key pair generation used for the cert request didn't use the ECC key gen algorithm - if the CA in question (Verisign, or whoever) wasn't bothered by this and issued you a cert using this key pair, you could easily end up with this issue even with a publicy-signed cert. Anyone ever requested a public cert from a 2K8 box? I haven't run across it yet so I don't know how the public CAs are behaving in this regard.

(And if you're still reading by this point, you've got a much better attention span than I do, devoted readers, so thanks for hanging in there. :-))