ADFS: Time to say goodbye
Active Directory Federation Services (AD FS) is a service that allows the secure sharing of identities information for third-party application outside your organization(extranet), in other words, it allows you to log in to application using your domain credentials, i.e. single sign-on. Whilst AD FS can provide identities just fine, it is a hassle to configure and maintain the infrastructure.
According to AD FS documentation, organizations with 100 or fewer trust relations configured that need to provide internal and external access should use the topology shown in figure 1.
So as we can see, that means managing and updating four servers, well that’s not fun. So is there an alternative? The answer is yes! Azure Active Directory is capable of providing identities as AD FS does and it doesn’t require the management the on-premise solution needs.
Now that we introduced the subject, let’s talk about how I change my company’s Identity Provider to the cloud. While planing for the migration I came across this very useful document describing everything I needed to know, so I planned accordingly the typical phases of a migration project as figure 2 illustrates.
On this post I am not gonna cover how to register your app on Azure AD, but here is some helpful documentation on how to do it.
Phase 1 & 2:
Discovering what applications are currently using AD FS is easy, on your primary AD FS server, open the AD FS Management > Relying Party Trust. From there, you will be able to list all your apps as well gather some information. In my case, I only had Office 365 and three other apps configured.
For the three apps, POCs (Proof Of Concept) were conducted using some test users and everything worked fine so I was able to draw up a migration plan. For Office 365 things weren’t so simple.
Since my company is in a hybrid deployment, Office 365 users, sign-in using the configured method on Azure AD Connect, which was Federation with AD FS and I could not change the user sign-in method during business hours as it is recommended to schedule a two hour window to change the User sign-in method to Password Hash Synchronization. So I didn’t conduct a POC for Office 365 but I draw up a plan after I read some documentation on Hybrid deployment identities.
PS: on this phase of the project, make sure you look at your apps endpoints and verify if there are any apps using ARTIFACT binding instead of POST binding. Azure AD only accepts POST bindings.
Phase 3:
Communicating is a critical part of any migration project, since it may result in some down time during the maintenance window. Make sure you communicate your users about the change and how the change will impact them. In this case, users had to type in their passwords again Monday morning, not that big of a deal but still, better safe than sorry.
At this point, you already talked to your vendors and exchanged the required federation metadata during the POC. Remember I said to check your endpoints? Make sure you know all of them are POST bindings or you might get yourself in the same place I was, explaining the difference of HTTP GET and POST to one of our vendors and telling them to change their code.
Since all of our users login to the mentioned apps using single sign-on I needed to assign the apps to all of them on Azure AD and for that, I used a dynamic group querying (user.objectid -ne null). So now I don’t have to worry if I forgot to assign the app to a specific user nor new users that are created in my directory. #WorkSmarterNotHarder.
Time for the migration:
At the time of the change I already had all the applications registered on Azure AD, I just had to check if my vendors updated their apps with the metadata I provided them. Once I verified all apps were working properly I still was being redirected to my AD FS login page and the explanation is simple, Azure AD Connect was still configured to authenticate users using AD FS, so let’s change that.
Once all of my users had gone home and my maintenance window started, it was time to change the user sign-in method to Password Hash Synchronization which was pretty simple. This tutorial guides you step by step on how to achieve that. After configuration is done you can start a new sync process with PowerShell command: Start-ADSyncSyncCycle -PolicyType Initial.
PS: While changing the sing-in method on Azure AD Connect you will be prompted to enable SSO. If you get an error while performing this operation, make sure your network firewall is configured to accept connections on outbound port 9090.
Phase 4:
I am still gaining insights about the change and studying which conditional access policies to implement, but now, let’s go over the benefits this change has brought to my company:
1 — The infrastructure shown in figure 1 was hosted on Azure as IaaS, costing us something around U$500 per month. Since my company already uses Office 365 Enterprise, all of our users are licensed for Azure AD Premium P1. So this change means the company will save U$6000 this year.
2 — Still about the infrastructure, my team and I are so happy we won’t have to manage those four servers anymore. No more certificate changes, complicated AD FS tracing or updating these machines.
These are the main benefits, other positive impacts are reduced management risk, improved reliability, self-service for end users and conditional access compliant with the company’s requirements.
This was a great project to start of the year. Now it is time to plan for other changes and keep innovating whether it is on Azure or other cloud solutions.
