I am doing a number of ADFS to Azure AD based authentication projects, where authentication is moved to Password Hash Sync + SSO or Pass Through Auth + SSO. Once that part of the project is complete it is time to decommission the ADFS and WAP servers. This guide is for Windows 2012 R2 installations of ADFS. There are guides for the other versions online.
This guide assumes you were using ADFS for one relying party trust, that is Office 365, and now that you have moved authentication to Azure AD you do not need to maintain your ADFS and WAP server farms.
Compile a list of server names
So first check that these conditions are true. Login to the primary node in your ADFS farm. If you don’t know which is the primary, try this on any one of them and it will tell you the primary node! Run Get-ADFSSyncProperties and you will either get back a list of properties where LastSyncFromPrimaryComputerName reads the name of the primary computer or it says PrimaryComputer.
If you don’t know all your ADFS Server Farm members then you can use tools such as found at this blog for querying AD for service account usage as ADFS is stateless and does not record the servers in the farm directly.
There is no list of the WAP servers in the farm – so you need to know this server names already, but looking in the Event Viewer on an ADFS server should show you who have connected recently in terms of WAP servers.
On the primary ADFS server run (Get-ADFSProperties).CertificateSharingContainer. Keep a note of this DN, as you will need to delete it near the end of the installtion (after a few reboots and when it is not available any more)
Check no authentication is happening and no additional relying party trusts
Login to each ADFS box and check the event logs (Application). If any service is still using ADFS there will be logs for invalid logins. Successful logins are not recorded by default, but failures are – so if you have failures to login currently happening then something is still using ADFS and so you will not be wanting to uninstall it until you have discovered that.
On the primary ADFS farm member open the ADFS admin console and navigate to Trust Relationships >Relying Party Trusts
If all you can see if Microsoft Office 365 Identity Platform (though it has an different name if you initially configured it years and years ago). Device Registration Service is built into ADFS, so ignore that. If you have any others, you need to work on decommissioning these before you decommission ADFS. If you have done the Azure AD authentication migration then the Office 365 Relying Party Trust will no longer be in use. Run Get-MSOLDomain from Azure AD PowerShell and check that no domain is listed as Federated. If all domains are Managed, then you can delete the relying party trust.
Uninstall Additional Connectors etc.
If you have added connectors into ADFS, for example MFA Server tools, then uninstall these first. For example if you have Microsoft MFA Server ADFS Connector or even the full MFA Server installed, then you have this and IIS to uninstall. MFA Server is removed from the control panel (there are a few different things to remove, such as MFA Mobile Web App Service, MFA User Portal etc. Remove the MFA Server piece last. IIS is removed with Remove-WindowsFeature Web-Server. If you uninstall MFA Server, remember to go and remove the servers from the Azure AD Portal > MFA > Server Status area at https://aad.portal.azure.com/ ds
Uninstall the WAP Servers
Login to each WAP server, open the Remote Access Management Console and look for published web applications. Remove any related to ADFS that are not being used any more. Look up Azure App Proxy as a replacement technology for this service. Make a note of the URL that you are removing – its very likely that this means you can remove the same name from public and private DNS as well once the service is no longer needed.
When all the published web applications are removed, uninstall WAP with the following Remove-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess. You might not have CMAK installed, but the other two features need removing.
Reboot the box to complete the removal and then process the server for your decommissioning steps if it is not used for anything else.
Uninstall the ADFS Servers
Starting with the secondary nodes, uninstall ADFS with Remove-WindowsFeature ADFS-Federation,Windows-Internal-Database. After this run del C:\Windows\WID\data\adfs* to delete the database files that you have just uninstalled.
Remove Other Stuff
Your ADFS Service account can now be deleted, as can:
Your DNS entry, internal and external for the ADFS Service, as can:
The firewall rules for TCP 443 to WAP (from the internet), and between WAP and ADFS, as well as:
Any load balancer configuration you have. Finally, you can:
Remove the certificate entries in Active Directory for ADFS. If you have removed ALL the ADFS instances in your organization, delete the ADFS node under CN=Microsoft,CN=Program Data,DC=domain,DC=local. If you have only removed one ADFS farm and you have others, then the value you recorded at the top for the certificate is the specific tree of items that you can delete rather than deleting the entire ADFS node.
11 responses to “Decommission ADFS When Moving To Azure AD Based Authentication”
I have a few AD servers each on a sub domain. Example A.apple.com, B.apple.com, C.apple.com. they all user ADFS I need to demote C.apple.com. I first shut down the domain controller to see if it breaks anything. It looks like when creating a new user ADFS no longer syncs to O365 and provisions the user. I turned the C.apple.com domain controller back on and ADFS now provisions the users again. How can I remove c.apple.com domain without breaking ADFS
Note that ADFS does not sync users to the cloud – that is the job of AADConnect. If AADConnect sync fails when you turn off this domain controller, it is probably because it is running on this server. If its not running on this server then login to the AADConnect server, start the Synchronization Service application and look for an resolve the issues
This is very helpful. However, do you have a blog about the actual migration from ADFS to AAD? How did you move the authentication to AAD?
I do not have a blog on the steps, as it is well documented elsewhere and I only write blog posts for stuff that is not covered by lots of other people!
Thanks for the detailed writeup. I had my own checklist but was not sure how to find the correct location for the farm “stuff” that gets stored in AD. While looking at it today, i am curious if you know how the certs and/or keys are encoded in the “contact” objects. I see that the two objects not named “CrypoPolicy” have “l” and “thumbnailPhoto” attributes set, but can’t figure how these are related to the certs/keys used by the farm. Do you know?
Sorry – no. But are you sure that ThumbnailPhoto is not just the JPG image data for this users photo!
Thank you for the great write up! We have a few RPTs still enabled and showing traffic in Azure ADFS Activity portal. It is 2012R2 and I am trying to find how to “discover” where the logins are coming from. We have full auditing enabled as far as I can tell and see no host/source IP info in any of the ADFS related events. Any ideas on how I see the source of this traffic?
Have you installed the new ADFS to AAD reporting tool? This adds ADFS sign-in reporting to the Sign-Ins view in Azure Active Directory portal. It might not help, but it will give you another view of your data to consider. Also have you tested for the possibility these are not active and working logins, but only login attempts – ie something trying password spray or brute force. If the login activity report is including “attempts” and not just “successes” then make 10 or so attempts to login and see if your reporting goes up.
All good ideas for sure! I am new to the environment. But I think we have the reporting stuff in place but in Azure I only see counts of users/ logins success and fails. No usernames or caller IP or host info. I know something has to direct the traffic at the RPT and these apps have all been migrated away so noting should be pointing there. Good point about these just being random attempts though. I was trying to take the approach that maybe the network or load balance team could see something from their perspectives. I have searched so may articles looking for an easy button. I don’t think there is one! Thanks again. I will do my best to come back and update if I can get to any conclusions.
What’s the password.txt file for? Have you guys seen this being useful ? I have seen this in other documentations and i’m curious if anyone know what this password.txt file is for.
I think it dates back to early Office 365 around 2011 and when you removed sync you needed to reset each users password. That is what this was then used for.