I always felt the implementation of AD FS 2.0 was klunky in Windows 2008 and from all appearances was a bolt on. With the release of 4.5 WIF and AD FS support was built into the .NET framework. As a bonus part of this upgrade to the .NET framework AD FS was better baked into the Windows 2012 operating system. Microsoft also made some significant changes to the technology that were impressive and potentially worth the upgrade.
I was finally given an opportunity to upgrade to Windows 2012 R2 and given a chance to upgrade our STS to use AD FS 3.0. There were a number of positive changes that you can read on other blogs and from Microsoft's web site(s) on the subject of AD FS 3.0. Here are a few observations I noted during the process of getting AD FS 3.0 working in our testing environment.
First, an AD FS 3.0 (Windows 2012 R2) proxy will not work with a AD FS 2.0 (Windows 2008 R2) service. It was clear during setup that the new proxy server was able to communicate to the old AD FS 2.0 service, however, it wasn't able to save the new proxy settings. I would always get the error "Unable to save profile." I am sure that if I used the PowerShell commands I could have gotten a better error message. This experiment was enough to request another Windows 2012 R2 server where I could install and configure an AD FS 3.0 service.
Second, before setting up an AD FS 3.0 service (Windows 2012 R2) against a Windows 2008 R2 Active Directory server you have to upgrade the AD data store. This is documented on Microsoft's TechNet site here. Good news here is that any existing AD FS 2.0 proxy/services will not be affected by this upgrade - you can continue to use them without any issue. Additionally all the AD management software on your Windows 2008 R2 server will continue to work as expected - likely a given to most but it was something that needed to be tested prior to a production roll out.
Third, an AD FS 3.0 and AD FS 2.0 proxy/service servers can co-exist without any conflict. However, you can't load balance them or expect them to behave in a cohesive fashion. You must treat them like two different end points for RP's to send the login requests. This would be helpful if you wanted to roll out the new proxy/service servers without affecting any existing RP's. We took advantage of it by slowly migrating existing RP's to the new servers. Any new RP's would be automatically using the new proxy/service servers.
Forth, the wizard to set up the AD FS 3.0 service server didn't work for me. And it isn't clear to me how it would for anyone based upon the PowerShell script it creates while in the wizard. I had a couple of stumbling blocks that showed up during my experience. I first needed a certificate that matched the domain in which I was installing the AD FS service. While I understand using a certificate issued for the same domain is a normal case scenario. Our AD FS 2.0 instance in the test environment was setup with a certificate issued by a different domain. I created and installed a temporary certificate to get past the first set of error(s). The Install-ADFSFarm commandlet in PowerShell requires the name and credentials of a services account that will be used for the running setup process as well as for access to any MS SQL instance you will be using. Well those credentials weren't in the PowerShell script nor was there a prompt to ask for them. When the wizard executed you'd never get prompted for the user / password (this despite the need to provide one during the wizard setup process!). Using the setup wizard doesn't give you very good (any) error messages that would help you complete the setup if there was an issue. A great deal of time would have been solved by using the PowerShell environment to begin with. The certificate problem and the missing credentials were all errors being suppressed by the wizard - it only reported "An error has occurred" with each unsuccessful attempt. Take my advice and skip the wizard for the creation of the first node in the AD FS Farm and use the PowerShell command.
Fifth, when installing the AD FS 3.0 service do not upgrade your AD FS 2.0 MSSQL database. Doing this will effectively leave your AD FS 2.0 installation in a non-functional state. Use a different MSSQL server (or instance). Or if in a test environment use the internal MSSQL instance running on the server you are installing the AD FS 3.0 server. There is adequate warning for this - well at least there is you are paying attention. The installation process will tell you that it found an existing ADFS data store and that it will be overwritten during this process. "Overwritten" should be the give away that if you continue you won't be using your AD FS 2.0 proxy/server anymore.
And finally, the new login screen in AD FS 3.0 prevents most customization. It allows for some basic changes which you can read about here. However, overriding the behaviors within the onload.js file, adding any Javascript libraries, adjusting the login page's HTML from within the onload.js file are an "at your own risk affair" and Microsoft will not will provide any support. This is of course expected - but I found it entertaining when on Microsoft's own site they showed you how to override the default behavior to allow someone to only enter a user name on the login page. I understand why this was done, but I also found it irritating as it would take a bit of effort to provide the same functionality/customization that was present in our AD FS 2.0 login page. And trying to make a page look good as a result of adding new elements in Javascript is difficult for the best of web developers.
No comments:
Post a Comment