AD FS Vs ADConnect

Often, customers ask “What’s the difference between AD FS and ADConnect?”. In this post I hope to cover what both of these things are and more importantly the differences.


Let’s start with AD FS or ‘Active Directory Federated Services’. What does it mean to federate? Google says; (with reference to a number of states or organizations) form or be formed into a single centralized unit, within which each state or organization keeps some internal autonomy.”. In the real world this manifests itself as being asked less-often for a username and/or password. For example, have you ever logged into Gmail, checked your emails and then browsed to YouTube? YouTube won’t ask you to login again because ‘’ is federated with ‘’.


This process is called ‘Single-Sign-On’ (SSO). Be careful because people talk of password syncronisation on it’s own as “SSO” but it’s not true single sign-on. What’s the difference? Some identity syncronisation will provide a Same-Sign-On experience (annoyingly the same acronym). Meaning that users can use the same account for multiple platforms but they will have to enter the credentials manually on each. Single-Sign-On is a one-time deal, you pop your password in once and boom you have access to all federated entities.

AD Connect

ADConnect is almost the slang term used for the tools full name ‘AAD Connect’ or ‘Azure Active Directory Connect’.  AAD Connect is a federation service wizard-based tool from Microsoft (replaced DirSync a while back), you can download it for free here;

There’s a ton more information available here;

Pro’s and Con’s

Password synchronisation (recommended by Microsoft)


  • Significantly less complex than AD FS
  • Users can log in to Office 365 even if your on-premises Active Directory is unavailable.
  • Fewer additional servers are required to deploy password synchronization.
  • No third-party certificates are required.
  • Doesn’t require external access to your on-premises Active Directory via AD FS.
  • Deployment can often be completed in just a few hours.


  • Disabling a user account in your on-premises Active Directory doesn’t disable it in Office 365. You need to manually disable the account in the Office 365 Admin portal.
  • Requires on-premises Active Directory. Other directory services aren’t supported.



  • Password changes are immediate.
  • Disabling a user in your on-premises Active Directory disables both their on-premises network access and their Office 365 account.
  • Supports directory services other than Active Directory.
  • Supports very large and diverse deployments.
  • Support for two-factor authentication.


  • Requires more servers, at least one of which needs to reside in your perimeter network.
  • Requires a public IP address and TCP port 443 to be opened on your firewall.
  • Connectivity with your on-premises Active Directory is required to detect changes to account passwords and with an account has recently been enabled or disabled.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s