A surprising number of clients are still operating complex ADFS farms.

 

Here are 8 reasons to switch to Azure AD.

1. ADFS has a greater surface attack area than Azure AD. Example: NTLM Brute-Force (CVE-2019-1126).

2. ADFS can have multiple single points of failure unless designed properly

3. ADFS requires certificate maintenance – resulting in planned downtime

4. ADFS requires lots of IT overhead (Backups, Monitoring, OS Upgrades, etc)

5. Azure AD Conditional Access offers better security controls than ADFS Claims

6. Azure AD is lightweight and less complex to administer (No Claims Rules)

7. Azure AD more closely aligns to NIST 800-63b (Scan for breached passwords)

8. Azure AD has a better feature roadmap

It’s easy to switch from ADFS to Azure AD. For example, this one PowerShell command can migrate Office 365 from ADFS to Cloud in less than 5 minutes. Set-MsolDomainAuthentication -DomainName mydomain.com -Authentication Managed

You can also do a staged rollout of smaller groups at a time rather than a big bang cutover using (the first security group is limited to 200 users). Learn more about staged rollout (here).

Note: That’s the core command that moves the trust from ADFS to Azure AD. There are more planning steps involved like making sure you have enabled password hash sync. Learn more planning steps (here).

Here are 5 tips for moving other apps from ADFS to Azure AD

1. Use the new ADFS Application activity report (preview) or the ADFS to Azure AD app migration tool to analyze your current apps. This tool will quickly identify which apps can be migrated seamlessly and which require remediation (see figure one).
2. Acquire deployment guides for the relevant apps. Many are published on the Microsoft app gallery, but if not, you can open a ticket through the third-party vendor who developed the app.
3. Allocate appropriate time and resources to the high-touch apps.
4. Migrate the apps that are ready to go for quick wins.
5. Identify a test environment or plan a maintenance window to avoid moving large servicing app at peak usage.

Learn more here:

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/five-tips-to-improve-the-migration-process-to-azure-active/ba-p/445364

Scenario: You configure a relying party trust in ADFS for SSO. ADFS event logs show this error: “The encryption certificate of the relying part trust … is not valid. It might indicate that the certificate has been revoked, expired, or that the certificate chain is not trusted.”

After verifying that the certificate chain is valid the next thing to check is whether the ADFS server can make an outbound port 80 call to the HTTP path defined in the relying part trust’s SSL certificate for the Certificate Revocation List (CRL).

The easiest thing to do is browse to the internet from the ADFS server to make sure outbound port 80 is open.

But if the ADFS server sits behind a proxy server, then the winhttp service will not automatically inherit the proxy server settings from Internet Explorer.

You can configure the winhttp service to use the proxy server. Run this on the ADFS server in an elevated CMD session:

netsh winhttp import proxy source=ie

https://social.technet.microsoft.com/Forums/windowsserver/en-US/47345c69-7b68-4f09-907e-43ed2805cac0/adfs-30-signing-certificate-crl-check-with-http-proxy-to-the-internet?forum=Geneva

The above article also says you can disable ADFS from performing a CRL check, but this should only be used for troubleshooting, because CRL checking is a good idea for security (what if the certificate was compromised?).
Set-AdfsClaimsProviderTrust -TargetName “<IDP name>” -SigningCertificateRevocationCheck None