Directory Programming .NET

I am asuming that this is a FAQ, but I am not sure about the best answer.
AD FS in Windows Server 2008 installs under the Windows directory. So everything is protected bij WRP. I cannot just overwrite clientlogon.aspx. What is the best approach to do the normal clientlogon.aspx customization, also global.asax etc.? Anyone any experience?

I'm not actually sure what the best way to do this is would be.  I mostly use 2003 server still.

One way you could do this would be to have the IIS Vdir point to a different directory on the file system and copy the files there.  I'm not sure if there is a better way to deal with the WRP "feature" in 2008 to get the control you need.

Yes, that is what I thought off too. But I was afraid of the amount of work and testing. Another one I have in mind is copying clientlogon.aspx to clientsignin.aspx and then modify that new clientsigin.aspx. Need to change name off course in Federation Server Service of course...
I will post the results of my experiments.

It will take some time because I bumped into some other issues that I will need to solve too. 2008 is so much nicer in setup, defaults, test options etc. But it appears to have some other hurdles.

Yeah, I think the choice of putting those files in the Windows directory under WRP is a curious one as the files need to be modified in many cases but it certainly makes it hard that way. 

I don't think it would be a huge deal to have the vdir point to a different file location though.  There really isn't too much magic in the ADFS files.  The important assemblies are all stored in the GAC.  Creating a different file and changing the web.config to point to it would work as well though.

I work mostly with ADFS on S2003R2-32bit and with Geneva on S2008-64bit. I was trying to setup for a training, physically far away from my normal training location. And of course that means ADFS on S2008-32 bit because of memory constraints on the equipment for the training... So I had to create new images.

I ran into several problems at the same time. Signing certificate problem, clientlogon.aspx customization, my applications wouldn't work and I couldn't get the ADFS agents to work on my DC with ADFS Server and ADFS Agents.

Signing certificate problem.
Apparently I have finally upset the otherwise very tolerant ADFS server with a signing cert. It complained with SingleSignOn.CertificateHasNoPrivateKeyException. Event ID 601 and 610.
The ACL was OK, there was a key. I assume, but didn't test, that ADFS didn't like the SubjectName (only CN) or something else. I took the SSL server cert. That works for now.

clientlogon.aspx customization impossible
That was a very stupid mistake on my side. I tried to change the wrong directory..... (\Windows\ADFS\sts\ls) I should have changed \Windows\SystemData\ADFS\sts\ls. No WRP there!
But I tried the possibilities described above.
- changing clientlogon.aspx to clientsignin.aspx works, but you also have to change the default document in IIS on the ls directory to clientsignin.aspx.
- Move the directory. That is more complicated. Probably better stay away from that one. The move works, need to repoint IIS and then a bunch of registry entries. And more ADFS snapin work. It works, but none of this is documented. And the MS supporters may not be happy when they have to help..... Now I know why it is tough/impossible to run two ADFS servers on the same machine :-)

My apps didn't work.
That was another stupid mistake. It was the IIS7/IIS6 handler/httphandler issue. I knew that one! But forgot about it. See http:/www.dasblonde.net/downloads/ADFSServer2008LabErrata.pdf for details. Or use "appcmd migrate config".

Not both ADFS agents and ADFS server on the same DC.
I knew that one too. But also forgot about it. I was trying to economize on the number of VMs. This is not a practical problem because in the enterprise environments, these features are not combined on a single machine.
But I had to tell the client of the training that I tried, but they had to get more memory into their machines....

Regarding the token signing cert, if you use WinCA on the 2008 version, you have to be certain that you don't get a certificate that uses the new ECC (elliptic curve) key algorithm and uses a "normal" RSA pair instead.  .NET still does not understand ECC keys and thus the .NET code in ADFS that does the signing doesn't see the cert as being valid with the same error you reported.

Laura Hunter ran into this issue.  I had never heard of it before.  :)  Not sure if that affected you or not in this case.

Glad you found some answers to the other problems as well.  I remember when Michelle was working through the lab and found all those problems, especially the issue with the IIS 7.  I didn't have much experience with it at the time and we had to ask one of her friends instead.  Luckily, she has many very smart friends and was also kind enough to document all the issues.

Thanks for detailing out the problems and solutions.  Hopefully it will help others as well.

Cert for SAML signing. Only requirement is Key Usage: Digital Signature (80).
Can do with V1 "Code Signing" template but then I get a username in subject.

So duplicate "Code Signing" to "SAMLsigner2003" (yep, V2 template), change some things so subject name can be specified in request. Works fine.

Duplicate "Code Signing" to "SAMLsigner2008" (yep, V3 template), change same things so subject name can be specified in request. Will not work with ADFS.

ADFS complains about rights (ACL) on private key, but that isn't the problem. The inner exception is in the debug log. There ADFS complains about: "Cannot instantiate CSP". And yes, that is the only difference between the pfx files! 2003 template allows me to select "Microsoft Enhanced Cryptographic Provider v1.0" and 2008 automatically goes for "Microsoft Software key Storage Provider".

I don't know why ADFS has this problem with the new KSP, but for ADFS I will stick to the V2 templates. Maybe I will check Geneva Beta2 if it has the same issue, then I probably should report it.

I think it has to do with the underlying APIs, but basically the way ADFS is getting to the key data doesn't work with the new CNG support.  Thus, if you use a cert that depends on this, you are in trouble.

One thing I don't know about is even if the fed server could use these ECC key certs whether they would interop with other systems.  It might be a really bad idea to use them even if it was possible.  It would be good to get some perspective on that from MS.  I have concerns about that for the new cert template defaults in 2008 in general.

Thanks for posting the WinCA details on how one might go about requesting certs that will work.  That's very helpful.

The PG told me that the "CertHasNoPrivateKey" error on using v3 cert templates was due to the EEC algorithm, but I've encountered the same error even when I explicitly specify that the template use only the downlevel non-EEC configuration particulars. So not sure -why- v3 cert templates don't work when issuing token-signing certs, still, but the end result is that v2 is the way to go. (Haven't tested against Geneva yet, though, will be worth investigating when I have a moment.)