Isaac Butt's questions

I'm trying to set up a claims-aware web app development environment. I am new to ADFS 2.0 and ultimately, I want to be able to authenticate against two different domains. I think I am very close but I'm getting a certificate error from one of the ADFS servers.

During processing of the Federation Service configuration, the element 'serviceIdentityToken' was found to have invalid data. The private key for the certificate that was configured could not be accessed.

This error is recorded in the ADFS server event log on domain #1 after I enter credentials in the web app. Even with working credentials, I get passed to a 401 unauthorized access page.

The user account running the ADFS service has permissions to the private key of the certificate so I am not sure why I am getting this error.

What I have done so far:

1. Created a server on domain #1 and installed ADFS 2.0
2. Created a server on domain #2 and installed ADFS 2.0
3. Created a third development server with VS 2010 on domain #1
4. Built a simple application on the dev server and made it federation aware (as per http://msdn.microsoft.com/en-us/library/bb897402.aspx); in the web.config, the federation server is set to the server on domain #1

I also haven't set up a Relying Party Trust on either of the ADFS servers. Is this necessary? I can't seem to find any good documentation explaining how this is supposed to work.

I have followed this ( http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx ) guide in setting this up, but I feel like there is probably a simple step I have missed somewhere.

To summarize:

1. Why might I get that certificate error above?
2. Am I missing any steps in setting up ADFS so that I can authenticate against both domains? (I am probably missing a step to link the two ADFS servers together)

Thanks in advance for any help on this. Someone who is familiar with ADFS could probably set this up in matter of minutes!

This issue has been extremely frustrating for us: when transferring a large VHD (virtual hard disk) file from a Windows 7 machine over the network to a physical Windows Server 2008 machine at our datacenter, the windows file transfer fails at 4 GB consistently. We have a direct 100 mbit connection from our main office to our data center.

When the transfer fails, the error message we receive is:

There is a problem accessing \\server-name\d$ Make sure you are connected to the network and try again.

It is only VHD files larger than 4 GB that fail. If we send any other file type, it works fine. If we zip the VHD, that also works. Moreover, we can send a VHD the other direction (from the data center to the main office) no problem. It is just VHD files in that direction.

Important notes:

• All partitions are NTFS!!
• There is no firewall between workstation and server
• We have tried disabling the antivirus on the workstation (no antivirus on server)
• We have tried transferring the file from a machine not on the domain
• We have tried transferring the file from a Ubuntu machine (still fails but at around 450MB instead of 4GB)
• Wireshark capture shows 40 DUP ACKs when transfer fails
• Xcopy and Robocopy (with restart flags) both fail (same point)
• FTP transfer fails at 4,14X,XXX,XXX bytes and cannot be restarted at that point
• We tried changing the file extension (stupid, but a last resort) to something other than vhd before sending it, but it still failed
• Connection is as follows: Dell Workstation (Main Office) -> Dell PowerConnect 5448 Managed Switch (MO) -> HP Procurve 2910al-24G Layer 3 Router (MO) -> 100Mb TLS link -> HP Procurve 2910al-24G Layer 3 Router (Data center) -> Dell PowerConnect 5448 Managed Switch (DC) -> Dell Server (DC)

So basically, it is JUST vhd files > 4GB, from our main office to our datacenter that fails. This all just doesn't add up... at this point I believe it is a issue with our network hardware settings, but I don't understand what the difference is between transferring a large VHD (which fails, at 4GB) and a large video file (which works always).