I was setting an ADFS 3.0 lab setup and thought I would share couple of gotchas – nothing particularly new here but could save someone some time.

Gotcha #1: Use Different Federation Service Name

In my case, I wanted to set my federation service on the same domain controller machine. This is of course not realistic in a production setup, but it’s common in a lab setup as you’d be preparing a POC or just playing around with stuff.

In this case, you cannot have the Federation Service name the same as the server name. In other words, my machine FQDN is “dc1.lab1.local”. Therefore I cannot have my federation service URL as: https://dc1.lab1.local/adfs/ls.

Instead I need to create a different service name; say for example “fs1.lab1.local”. So the URL will be https://fs1.lab1.local/adfs/ls.

Reason ADFS must have a different name of the service, is that a SPN will be registered for this name. So we must not duplicate this SPN by using the same server name.

Gotcha #2: Certificate Common Name

Since you will be using a different name of the federation service, the CN of the certificate you use during setup should not be “dc1.lab1.local”; it should actually be “fs1.lab1.local”.

I always like to use makecert to create a test CA and use this CA to sign my certificate. Something like this to create the CA:

makecert -pe -n “CN=FS1 CA” -ss my -sr LocalMachine -a sha1 -sky signature -r “FS1 CA.cer”

And like this to create a certificate signed by the CA:

makecert -pe -n “CN=FS1.lab1.local” -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in “FS1 CA” -is My -ir LocalMachine -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12 FS1.lab1.local.cer

During configuration, you will be asked to supply the SSL certificate. Supply FS1.lab1.local” and this automatically sets the Federation Service Name to “FS1.lab1.local”

Gotcha #3: DNS A Record

We must create a DNS record for the ADFS instance. This maps to the ADFS namespace (FS1.lab1.local). This record is needed for clients to be able to resolve the Federation Service Name. Recall that clients will use https://fs1.lab1.local/adfs/ls to talk to the federation service and the name fs1.lab1.local needs to be resolved properly to the same server IP.

The DNS A record maps a host name to an IP address:

Gotcha #4: Set Host File

So in my case I am running a VM (DC1.lab1.local) and I want to access this VM from the host machine. In other words the Relying Party web application is running on my host machine, and wants to talk to the federation service described previously.

I added the following lines in my hosts file so that “dc1.lab1.local” and “fs1.labl1.local” point to the same VM IP:

Note: of course for setting such lab, I have to give my VM an IP in the same range as that of my host machine. I prefer not to set static IPs on my host (as I switch to different connections), so whenever I want to run my VM I use ipconfig to get my host IP, then I configure my VM to use a static IP on the same range and to properly access the default gateway accordingly.

Gotcha #5: Use Signing Token, Not SSL Certificate

Finally, if you test your ASP.NET application and get an error “The issuer of the security token was not recognized by the IssuerNameRegistry”, then make sure that the thumbprint you specify in the <issuerNameRegistry> is that of the singing token and not the SSL token (I fell into this trap more than once).

In ADFS console you can see you have multiple certificates, use the one for digital signature not the one supplied during setup for SSL:

In the web.config use the thumbprint  of this certificate: