ADFS 2.0 Shenanigans

As part of the Office 365 project, UW-IT is deploying ADFS. This will enable federated logon to Office 365 services, and as time allows it can be used in other scenarios to federate other applications on the Windows platform.
I’ve talked and read a lot about ADFS, and listened to perhaps a dozen presentations on it, but haven’t had time to look at
it myself until this project came along.

My initial experiences are well summarized by a statement on a Virginia Tech blog: “Along comes ADFS 2… new, more powerful,
better, more standards compliant … documentation reads like scrawl on a napkin.”

I ran into a lot of “gotchas” most of which are noted on various websites, but very little of which is well-addressed by the Micrsoft documentation or tools. I don’t blog much about problems I run into, but this set of gotchas calls out for a blog post. šŸ™‚

Gotcha #1:
Don’t use the WS2008 Roles feature to install ADFS. You’d think you’d just install the ADFS role via Server Manager, right?


If you do this, you end up with ADFS 1.0. Nothing in Server Manager indicates the version number. Nothing tips you off in the interface until you read documentation somewhere which tells you you have to download the ADFS 2.0 installer and this is the only way to get 2.0 installed.

Gotcha #2:
If you install ADFS 1.0, you can’t install 2.0 without removing 1.0 first. No upgrade. Is this Microsoft software? OK, I can deal with this.

Gotcha #3:
If you use the ADFS GUI installer, you can’t use SQL Standard (or enterprise/datacenter). The UI at least gives you a small

warning note about this. However, this part of the UI and the Microsoft documentation are also a source of the next gotcha.
Gotcha #4:
The MS documentation uses the term “Windows Internal Database (WID)” consistently for the “small” ADFS cluster deployment option. Nowhere does it refer to SQL Express. The ADFS installer UI never uses the WID term, and only refers to SQL Express. Until you realize that WID is a SQL Express based database, you are confused. Maybe this terminology mismatch only confused
me …

Gotcha #5:
The fact that the WID option doesn’t support SAML artifact functionality isn’t well documented or presented. If you choose WID you are sacrificing some functionality. That’s an important point and shouldn’t be hidden.

Gotcha #6:
If you don’t want to use SQL Express, then you have to use a command line utility called fsconfig.exe to generate the SQL database for ADFS. The Microsoft documentation on this is … sparse? Almost non-existent? And what there is doesn’t really highlight the best way to approach this. Run:

Fsconfig.exe GenerateSQLScripts /ServiceAccount [account] /ScriptDestinationFolder [destination folder]

which will generate 2 .sql scripts which will do the work required on the desired SQL server.

Gotcha #7:
The commonly recognized best practice for the token-signing certificate is to use a self-signed certificate. This is becauseĀ self-signed certs automatically renew themselves, whereas replacing a CA signed cert can result in an ADFS outage or require you to notify all trust partners. But the installation UI doesn’t default to a self-signed cert for the token-signing cert. Good thing I’ve listened to so many ADFS presentations, and talked with folks who have been running ADFS for awhile.

Gotcha #8:
ADFS wants port 1501 for some of its communications. The TSM Client Scheduler service uses port 1501. This blocks installation of ADFS. You can get past this and still run TSM, but it requires stopping the TSM client during installation, then later changing the port that ADFS wants to use. See
to-change-the-net-tcp-ports-for-services-and-administration.aspx for how to change that port.

More gotchas? Maybe. I’ve only installed one ADFS server in our dogfood environment. I’m sure I’ll run into more shenanigans.

Leave a Reply

Your email address will not be published. Required fields are marked *