Change from AD FS authentication to Pass-Through Authentication with Seamless SSO


Imagine this scenario: You've been running Active Directory Federation Services (AD FS) since before it was cool, and you're tired of maintaining that highly available infrastructure (at least 4 servers) and the whole federation thing and its myriad of quirks and drawbacks and headaches (such as alt-id (which is still supported in Pass-through authentication with some caveats, listed below), claims rules, certificates, and the fun of trying to change UPN suffixes from one federated UPN to another).

There are still a few scenarios where AD FS is still needed or useful--such as SharePoint Hybrid Search, federation and single sign-on with third-party applications, and some certificate-based logon scenarios.

And, there are a few scenarios where pass-through authentication or password hash synchronization with seamless sso don't work yet (thanks to Lou for identifying these):

  • automatic alternate ID logon for Office ProPlus apps (to be fair, AD FS doesn't work in these instances, either)
  • Outlook 2016 alternate ID logon (detects correct mailbox based on SMTP address, but the authentication dialox box displays the UPN)

Oh, and if you're a public sector customer that has explicit STIG requirements to use AD FS (can't get around that, since Pass-Through Authentication with Seamless SSO has a whole bunch of different letters than Active Directory Federation Services).

But, if those scenarios don't really apply do you, then .... Welcome to the world of Seamless Single Sign-On.  It's new (ish). It's shiny. And it's here to help.

If you're not familiar with AD FS or aren't sure if you're using it, an easy test from an external computer or web browser, navigate to https://portal.office.com and attempt t sign in with your Office 365 address.  If you get redirected to a window that looks like this:

Congratulations, you're using AD FS.  There are several other ways to check as well, but chances are, if you're reading this blog, you know how.

Preparing your environment

First, I'd recommend <warning: shameless plug approaching> checking out the AAD Connect Network and Name Resolution Testing tool.  It has a bunch of nifty things to help make sure your AAD Connect server can communicate with everything it needs to.  If you're already using AAD Connect successfully, you can just run it with the -OnlineEndpoints switch parameter to check your outbound connectivity.

Second, you need to make sure you have all your credentials.  You'll need you on-premises domain admin credential for every Active Directory domain configured in AAD Connect as well as credentials for a global admin account in your Office 365 tenant.

Updating the configuration

Once you have your ducks in a row, it's time to run through the configuration wizard to change your settings.

    1. Log on to the server running Azure AD Connect.
    2. Double-click / open the Azure AD Connect icon on the desktop.
    3. Acknowledge the User Account Control prompt (if displayed).
    4. Select the green Configure button.
    5. Select Change user sign-in and click the green Next button.
    6. On the Connect to Azure AD page, enter your global admin credentials and click the green Next button.  I prefer to use a cloud identity credential for AAD Connect configuration changes.

      If you had previously configured federation with the AAD Connect wizard, when you are presented with the User sign-in page, the Federation with AD FS radio button will already be selected (as it is in the screenshot).  If you had previously configured AD FS outside of AAD Connect, your previous method will be selected (either Password Synchronization, Pass-through authentication, or Do not configure).  If you configured AD FS federation outside of AAD Connect (like most of us have), you'll want to stop what you're doing and go convert your federated domains to managed (Set-MsolDomainAuthentication or Convert-MsolDomainToStandard--just a brief bit of warning: as soon as you do this, users will be unable to log in until you complete the pass-through authentication setup).
    7. Select the radio button for Pass-through authentication, and then select the Enable single sign-on to enable the Seamless Single Sign-On configuration process.  Click the green Next button to proceed.
    8. Click the green Enter credentials button to enter a Domain Admin credentials for each of your connected domains.  AAD Connect won't save this credential (it's only used for the configuration tasks).  When you're finished entering credentials, click the green Next button.
    9. Confirm your choices and click the green Configure button.
    10. Wait while the installed completes.  If you are switching from Federated, the domain type will change from Federated to Managed.
    11. Close the wizard.  Yes, it will probably return errors.

      You can view the log file at C:\ProgramData\AADConnect\trace-<date>.  Look towards the end for content that looks like this:

      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - AcquireTokenHandlerBase: === Token Acquisition started: Authority: https://login.windows.net/aaronoffice365lab.onmicrosoft.com/ Resource: https://proxy.cloudwebappproxy.net/registerapp ClientId: cb1056e2-e479-49de-ae31-7812af012ed8 CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (2 items) Authentication Target: User
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - TokenCache: Looking up cache for a token...
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - TokenCache: An item matching the requested resource was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - TokenCache: 45.708348125 minutes left until token in cache expires
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - TokenCache: A matching item (access token or refresh token or both) was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:44: 5eb59608-f2e8-48bd-adbc-f506042b36ab - AcquireTokenHandlerBase: === Token Acquisition finished successfully. An access token was retuned: Access Token Hash: X6aumeoyaYrqRlFECdG+86V8/9QSfJqpX4pYWOhHFeM= Refresh Token Hash: kvfHZVrbK0xojK/FH5IaIRDoCxHDswuvy6mkFXw4zTI= Expiration Time: 04/03/2018 20:44:27 +00:00 User Hash: 4YKOw7hBlXlBGxeHn8UL3EDZcYimAu5yJnGGYFubIgc=
      AzureADConnect.exe Information: 0 : Changing the passthrough authentication feature enablement state to enable.
      AzureADConnect.exe Information: 0 : 'IPassthroughAuthenticationService' channel is not available for communication. Asking lock to recreate. 
      AzureADConnect.exe Information: 0 : 'IPassthroughAuthenticationService' channel is still not available. Recreating. 
      AzureADConnect.exe Information: 0 : 'ChannelFactory`1' is not available. Recreating factory. 
      AzureADConnect.exe Information: 0 : 'ChannelFactory`1' recreated successfully. 
      AzureADConnect.exe Information: 0 : WCF cient connection: https://a6716add-e182-4ee2-9acb-db34d4cc84f1.registration.msappproxy.net/register - 0 active connections in service point before opening new channel
      AzureADConnect.exe Information: 0 : Creating a new 'IPassthroughAuthenticationService' channel. 
      AzureADConnect.exe Information: 0 : Opening the new 'IPassthroughAuthenticationService' channel. 
      AzureADConnect.exe Information: 0 : 'IPassthroughAuthenticationService' channel recreated successfully. 
      AzureADConnect.exe Information: 0 : Passthrough authentication enable - successful
      [19:58:47.400] [ 20] [INFO ] enable passthrough authentication was successful
      [19:58:47.400] [ 20] [INFO ] Task 'Configure Passthrough Authentication' has finished execution
      [19:58:47.400] [ 10] [INFO ] Task 'Configure Passthrough Authentication' finished successfully
      [19:58:47.400] [ 10] [VERB ] Executing task Setting DesktopSso enablement
      [19:58:47.401] [ 24] [INFO ] EnableDesktopSsoTask: desktopsso is currently False.
      [19:58:47.401] [ 24] [INFO ] EnableDesktopSsoTask: desktopsso enablement is setting from False to True.
      [19:58:47.403] [ 24] [INFO ] EnableDesktopSsoTask: Setting DesktopSSO policy to: True
      [19:58:47.466] [ 24] [INFO ] DiscoverAzureEndpoints [PassthruAuthentication]: ServiceEndpoint=https://{0}.registration.msappproxy.net/register, AdalAuthority=https://login.windows.net/aaronoffice365lab.onmicrosoft.com, AdalResource=https://proxy.cloudwebappproxy.net/registerapp.
      [19:58:47.466] [ 24] [INFO ] AcquireServiceToken [PassthruAuthentication]: acquiring additional service token.
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - AcquireTokenHandlerBase: === Token Acquisition started: Authority: https://login.windows.net/aaronoffice365lab.onmicrosoft.com/ Resource: https://proxy.cloudwebappproxy.net/registerapp ClientId: cb1056e2-e479-49de-ae31-7812af012ed8 CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (2 items) Authentication Target: User
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - TokenCache: Looking up cache for a token...
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - TokenCache: An item matching the requested resource was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - TokenCache: 45.66185952 minutes left until token in cache expires
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - TokenCache: A matching item (access token or refresh token or both) was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:47: a161212a-debc-428e-a169-d1a50763d7fa - AcquireTokenHandlerBase: === Token Acquisition finished successfully. An access token was retuned: Access Token Hash: X6aumeoyaYrqRlFECdG+86V8/9QSfJqpX4pYWOhHFeM= Refresh Token Hash: kvfHZVrbK0xojK/FH5IaIRDoCxHDswuvy6mkFXw4zTI= Expiration Time: 04/03/2018 20:44:27 +00:00 User Hash: 4YKOw7hBlXlBGxeHn8UL3EDZcYimAu5yJnGGYFubIgc=
      [19:58:49.752] [ 24] [INFO ] EnableDesktopSsoTask: DesktopSSO policy successfully set to: True
      [19:58:49.754] [ 24] [INFO ] EnableDesktopSsoTask: Updating desktopsso secret for forestc.com
      [19:58:49.837] [ 24] [INFO ] DiscoverAzureEndpoints [PassthruAuthentication]: ServiceEndpoint=https://{0}.registration.msappproxy.net/register, AdalAuthority=https://login.windows.net/aaronoffice365lab.onmicrosoft.com, AdalResource=https://proxy.cloudwebappproxy.net/registerapp.
      [19:58:49.837] [ 24] [INFO ] AcquireServiceToken [PassthruAuthentication]: acquiring additional service token.
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - AcquireTokenHandlerBase: === Token Acquisition started: Authority: https://login.windows.net/aaronoffice365lab.onmicrosoft.com/ Resource: https://proxy.cloudwebappproxy.net/registerapp ClientId: cb1056e2-e479-49de-ae31-7812af012ed8 CacheType: Microsoft.IdentityModel.Clients.ActiveDirectory.TokenCache (2 items) Authentication Target: User
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - TokenCache: Looking up cache for a token...
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - TokenCache: An item matching the requested resource was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - TokenCache: 45.6223529983333 minutes left until token in cache expires
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - TokenCache: A matching item (access token or refresh token or both) was found in the cache
      AzureADConnect.exe Information: 0 : 04/03/2018 19:58:49: 717a981b-ee81-4d32-91dc-a2c241c717b5 - AcquireTokenHandlerBase: === Token Acquisition finished successfully. An access token was retuned: Access Token Hash: X6aumeoyaYrqRlFECdG+86V8/9QSfJqpX4pYWOhHFeM= Refresh Token Hash: kvfHZVrbK0xojK/FH5IaIRDoCxHDswuvy6mkFXw4zTI= Expiration Time: 04/03/2018 20:44:27 +00:00 User Hash: 4YKOw7hBlXlBGxeHn8UL3EDZcYimAu5yJnGGYFubIgc=
      [19:58:51.784] [ 24] [INFO ] Task 'Setting DesktopSso enablement' has finished execution
      [19:58:51.784] [ 10] [INFO ] Task 'Setting DesktopSso enablement' finished successfully
      [19:58:51.784] [ 10] [INFO ] Task 'Change Sign-In Method' has finished execution
      [19:58:51.795] [ 7] [INFO ] The Azure AD Connect Installation was successfully completed.
      [19:58:51.798] [ 7] [INFO ] MicrosoftOnlinePersistedStateProvider.Save: saving the persisted state file
      [19:58:51.798] [ 7] [INFO ] ConfigureSyncEngineStage.StartADSyncConfiguration: AADConnectResult.Status=Warning
      [19:58:51.814] [ 1] [VERB ] ReleaseSyncConfigurationMutex(): Releasing sync config changes mutex.
      [19:58:51.816] [ 7] [INFO ] MicrosoftOnlinePersistedStateProvider.Save: saving the persisted state file
      

      As long as you see things that say "finished successfully," you should be able to ignore any warnings. I've talked to the AAD Connect team, and they're going to look into suppressing any non-critical warnings, so we don't cause any higher levels of anxiety.

    12. Test Pass-through authentication with Seamless SSO.  The first test is opening a browser to https://portal.office.com from an outside network and making sure you don't get redirected to your federation prompt.  That in conjunction with the log file will let you know that Setup has updated the domain configuration in the tenant.

Deploying to your users

Now that you've got it configured from AAD Connect's perspective, you need get your users ready to consume it.

Overview

Buried in one of our myriad document repositories is this little nugget:

To roll out the feature to your users, you need to add the following Azure AD URL to the users' Intranet zone settings by using Group Policy in Active Directory:

In addition, you need to enable an Intranet zone policy setting called Allow updates to status bar via script through Group Policy.

Why do you need to modify users' Intranet zone settings?

By default, the browser automatically calculates the correct zone, either Internet or Intranet, from a specific URL. For example, "http://contoso/" maps to the Intranet zone, whereas "http://intranet.contoso.com/" maps to the Internet zone (because the URL contains a period). Browsers will not send Kerberos tickets to a cloud endpoint, like the Azure AD URL, unless you explicitly add the URL to the browser's Intranet zone.

So, in order to get this to be seamless for your internal users, you need to add https://autologon.microsoftazuread-sso.com to your local intranet zone.  I'd also recommend adding https://aadg.windows.net.nsatc.net to your local intranet zone, as autologon.microsoftazuread-sso.com is a CNAME of it.  Once you do that, your browser will see that web site as "internal" and will send your Kerberos ticket to it.

Note: Based on some feedback that I've received from a reader and an open support case, if you are using Office ProPlus with Shared Computer Activation AND Pass-through Authentication with Seamless SSO, you'll need to deploy the following registry key to prevent authentication popups as well.  You may want to deploy a Group Policy Preference for this setting.

[HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\DisableADALatopWAMOverride] - REG_DWORD "1"

On with the show!

Group Policy Deployment for Internet Explorer (and Edge)

  1. Open the Group Policy Management Console (gpmc.msc).
  2. Edit a group policy that is applied to some or all your users, or create a new one. This example uses Default Domain Policy.
  3. Browse to User Configuration | Administrative Templates | Windows Components | Internet Explorer | Internet Control Panel | Security Page. Then select Site to Zone Assignment List.
    Single sign-on
  4. Enable the policy, and then enter the following values in the dialog box:
    • Value name: The Azure AD URL where the Kerberos tickets are forwarded.
    • Value (Data): 1 indicates the Intranet zone.The result looks like this:
      Value: https://autologon.microsoftazuread-sso.com
      Data: 1

    Note: If you want to disallow some users from using Seamless SSO (for instance, if these users sign in on shared kiosks), set the data in the value column to 4 in a separate group policy that applies to those users. This action adds the Azure AD URLs to the Restricted zone, and causes Seamless SSO to fail all the time.

  5. Repeat the process for the second URL.Value: https://aadg.windows.net.nsatc.net
    Data: 1
  6. Select OK, and then select OK again.
  7. Browse to User Configuration | Administrative Templates | Windows Components | Internet Explorer | Internet Control Panel | Security Page | Intranet Zone. Then select Allow updates to status bar via script.
    Single sign-on
  8. Enable the policy setting, and then select OK.
    Single sign-on

Firefox

Firefox doesn't use Kerberos authentication by default.  To update the Firefox configuration, follow these steps.

  1. Launch Firefox.
  2. In the URL bar, type about:config and press enter.
  3. Click the I accept the risk! button.
  4. In the search bar, type network.negotiate-auth.trusted-uris to locate the settings object to modify.  Double-click it to open.
  5. In the dialog box, enter https://autologon.microsoftazuread-sso.com,https://aadg.windows.net.nsatc.net and click OK.
  6. Close and reopen Firefox for the settings to take effect.

Ensuring high availability

So, this is cool and all, but I'm sure you're dying to ask ... isn't this a single point of failure?

Yes. Yes it is.

Fortunately, we've thought of that, too.  Enter, the dragon.

Err, no. Wait.

Let's try this again.

Fortunately, we've thought of that, too.

We've made a standalone agent available that can be deployed on systems in your environment. To deploy it, follow these steps.

  1. Select servers that you want to install the agent on.  They need to be able to communicate out to the internet on at least ports 80 and 443, though I've seen some requirements that give additional ports as well.
  2. Download the pass-through authentication agent from here: http://aka.ms/getauthagent
  3. Run the installer, and then click Install.
  4. At the Modern Authentication dialog box, enter a global admin credential and click Next.
  5. Click Close to dismiss the installer after it completes.
  6. Log into https://aad.portal.azure.com with a global admin credential.
  7. Select Azure Active Directory from the navigation blade.
  8. On the Azure Active Directory blade, select Azure AD Connect.
  9. On the Azure AD Connect blade, select the agents link next to Pass-through authentication to display the servers that have the pass-through authentication agent installed.
  10. Verify that the servers where you have installed the pass-through authentication agent are registered and showing online.  The pass-through authentication agent is installed on the server running Azure AD Connect as part of the initial configuration.

As always, feel free to leave remarks or questions in the comments area.

May all your auths be passed through successfully.

 

Comments (34)

  1. Trent says:

    Are there is Office 365 Services that don’t support pass-through? or any that require ADFS?

    1. Legacy auth apps (like Outlook 2010 or Outlook 2013 WITHOUT modern auth enabled) and SharePoint Hybrid Search are two examples that still have solid use cases for AD FS.

      1. Nils says:

        Legacy apps like 2010 and 2013 also works when I tested this. Only not yet fully supported regarding the docs page.

        1. @Nils: Depending on how you have your environment configured (such as using Password Hash Sync instead of Pass Through Authentication), legacy apps will still work because you’re going to be authenticating against the cloud account. I haven’t tested legacy apps under PTA scenarios, but I’ve got my environment turned up to do some testing and further report.

      2. Josh says:

        Hey Aaron, do you know if setting this up will allow for seamless single sign on directly to a SPO site? I had set pass through auth in the past and it didn’t work well, and I had to end up implementing ADFS and setting up something called SharePoint auto-acceleration in order for our users to get a perfect single sign on and still be directed to the exact SPO URL they were going to. I would love to ditch my 4 ADFS servers and just use this, but not if domain users can;t get a perfect SSO just like if SharePoint was on premise.

        1. @Josh: If you add the URLs specified above to the Intranet Zones, I think it should. I haven’t tested auto-acceleration with PTA. Our guidance (https://support.office.com/en-us/article/Enable-or-disable-auto-acceleration-for-your-SharePoint-Online-tenancy-74985ebf-39e1-4c59-a74a-dcdfd678ef83) says “there must be a single identity provider,” which I think PTA still meets. I’ll do some testing and try to get a response back here. My friend Adam Fowler might have some more detail (https://www.adamfowlerit.com/2016/12/azure-ad-connect-pass-authentication-tips/). His blog references PTA when it first came out, but I don’t think much has changed since then.

          1. Josh1892 says:

            Great! Thanks so much, and sorry for all the posts, I obviously have no clue how to post! In the past MS Support told me the single identity provider did need to be ADFS as I put the ticket in trying to get to get it to work with Pass-Through. Really looking forward to what you find out, it’s near impossible to did this info out of any documentation.

    2. Lisa Smith says:

      Did this at our company, and the mapped document libraries in Windows Explorer stopped working once the users changed their passwords. With the seamless, pass-through (which worked great), they could no longer get a “persistent single sign-on” cookie. After a week, we had to revert the settings.

  2. Turbomcp says:

    Thanks for excelent writeup

  3. Jean-Philippe Breton says:

    There is some scenarios where ADFS is still required…maybe you could expand on those?
    I am thinking :
    Like Active Directory CBA auth: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-certificate-based-authentication-android and Windows Hello for Business (Hybrid Azure AD joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates)

    1. I updated the post with a few scenarios mentioned by one of my colleagues.

  4. Josh says:

    I’m currently using ADFS in conjunction with auto-acceleration to do a seamless single sign on to a SharePoint Online site. Will this set up give users the same experience? I know when I had set this up about roughly a year ago, when going to an SPO site it would not give you a seamless SSO experience, and I was forced to build out ADFS.

  5. Jean-Philippe Breton says:

    Excellent write up. any plan to include scenarios where ADFS is still required:

    Windows Hello for Business and Active Directory CBA are 2 examples that comes to my mind..

    thanks

  6. Josh says:

    Hey Aaron, do you know if setting this up will allow for seamless single sign on directly to a SPO site? I had set pass through auth in the past and it didn’t work well, and I had to end up implementing ADFS and setting up something called SharePoint auto-acceleration in order for our users to get a perfect single sign on and still be directed to the exact SPO URL they were going to. I would love to ditch my 4 ADFS servers and just use this, but not if domain users can;t get a perfect SSO just like if SharePoint was on premise.

  7. Anonymous says:
    (The content was deleted per user request)
  8. Does real sso and auto activate work for office365 proplus? We had to enter username first. With adfs the user has not to enter his credential

    1. Yes, it should work. If you are using alternate ID, you’ll most likely get prompted. Seamless SSO, when using modern apps (Office 2013+ with ADAL/modern auth support enabled), should give you the same end-user experience as AD FS.

  9. Steven Melville says:

    We’ve recently made the switch from ADFS to Pass-through with SSO (we flipped the switch last week).
    While PTA seems to be working fine, SSO doesn’t appear to be working.

    When users visit O365 entry points, such as portal.office.com, they hit login.microsoft.com and are asked for their username and password. This happens in IE and Edge.
    The same thing happens in the Office 365 ProPlus client. We’re using Shared Computer activation and all users are prompted to sign in when they use a machine for the first time. This used to be silent with ADFS.

    SSO is showing as enabled in the AzureAD Admin page, the local AD computer account is in place and I’ve made sure that the two URL’s are in the Intranet Zone, yet still nothing.

    It doesn’t even appear to be trying to use SSO when hitting login.microsoftonline.com. I’m not seeing any firewall traffic to https://autologon.microsoftazuread-sso.com.

    I’ve logged a support ticket, but any suggestions?

    1. I’d be interesting in hearing what support’s answer is. There is an issue (but closed) on GitHub regarding SCA: https://github.com/MicrosoftDocs/azure-docs/issues/6379

    2. One of the updates from our internal resources says make sure Office ProPlus is at version 16.0.8730.xxxx.

      1. JayF says:

        Office 16.0.8730.xxxx is still monthly channel at the time of this reply. We standardized on Semi-Annual channel and are not looking to switch. It this version absolutely required?

        1. From what I understand, yes. It will be needed in order to get Office ProPlus to work with Pass-Through authentication.

  10. Andrew Kemp says:

    Great article I didn’t know about the authentication package for high availability! Thanks for that! One question, how does this tie in with MFA? 2 scenarios,
    1. ADFS 3 with the Azure MFA server (on 4 additional servers)
    2. ADFS 4 and azure cloud MFA
    I can see a lot of my customers ditching ADFS if we can still use MFA and the conditional access and hybrid AD.
    If you’ve not tried that don’t worry I’ll give it a go in my lab 🙂

    1. It doesn’t. In Pass-through authentication, are not configured as “federated,” so authentication is never being redirected to an AD FS environment. You can, however, use EMS / Azure conditional access policies with PTA and Seamless SSO.

  11. Paul says:

    So if your domain is currently federated doing this changes it to ‘managed’?

    Thanks

    1. Yes. It becomes a “managed” domain from the perspective that you’re not pointing it to an on-premises STS.

  12. Darth Jorge says:

    So you mention that this does not work with single sign-on with third-party applications. We have setup SSO with third-party applications in Azure AD. Would that stop working or is this only if you independently setup SSO outside of Azure?

    1. Are they Azure AD applications that you’ve added from the Azure marketplace? The question is where are those applications looking for identity (Azure AD or your on-premises AD via AD FS)?

      1. Darth Jorge says:

        Yes, these are pre-configured applications we added from Azure Marketplace.

  13. Stephan V. says:

    Hi Aaron,
    thanks for that greatfull article. One question i got from my customer.
    How is the impact for the end-users at the point of changing from federated to managed? I heard about different impacts.

    Yes, we plan to do the change on one weekend. Is it correct that the wizard will change also each user from federated to manged? So we got about 5000 Azure AD Accounts in customers tenant. Could be take some time to work.

    I heard about the impact that users prompt for password one-time after changing ADFS to PTA? We have users on normal Office 365 Pro Plus and on Shared Computer Activation (Citrix Pooled Desktops). Also “they” say that sometimes you need to clean up the Windows / Office Credential Manager ?

    Could you say something with your experience?

    Kind Regards
    Stephan

    1. In my experience, they haven’t had to. However, you do need to make sure you’re up-to-date. PTA and seamless SSO with for Office ProPlus you to be running at least Office 16.0.8730 and AAD Connect version from March 2018. Those two pieces together introduced silent sign-on for Office ProPlus apps (https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#march-2018).

  14. Matt says:

    Is there a way to keep a subdomain within a tenant as a federated domain auth’ing to ADFS. I have a customer who needs to keep it that way but also wants PTA and SSA.

    1. I don’t quite understand the question.

      You can use a mixture of both ADFS and PTA in the same tenant; however, there are some caveats:

      1. If the top-level domain was added first and then child domains were added, when federating the top-level domain, the child domains will follow.
      2. You can federate a subdomain without federating the top-level domain.
      3. You cannot use ADFS *and* PTA/Seamless Sign-On for the same domain (nor can you do one as a backup for the other).
      4. If you want to mix, you must set up PTA/Seamless SSO inside of AAD Connect and then set up AD FS separately.

Skip to main content