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

•
•
•
•
•
•

Update: We now have some public documentation available for this as well, so be sure to check there, too! https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-deployment-plans

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.

# Checking to see if you have AD FS deployed

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.

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.

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 : 'ChannelFactory1' is not available. Recreating factory.
AzureADConnect.exe Information: 0 : 'ChannelFactory1' 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 ] 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 ] 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.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.

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.

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.
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:
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.
8. Enable the policy setting, and then select OK.

## 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.
6. Close and reopen Firefox for the settings to take effect.
7. You can also configure settings via the Firefox Group Policy ADMX templates: https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy.

# 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. Enter, the secret agent.

No, that’s not right, either.

Fortunately, we’ve thought of that, too. Enter, the standalone agent.

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.
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.
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.

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

1. Henrik Bernhard says:

As this seems to be one of the best resources for making this switch, thought i would leave this comment here incase anyone else has this scenario.

We just switched over, and only issue we faced that wasn’t very well described was in relation to a 3rd party app connected to azure AD.
It was setup with
domain_hint=contoso.com

Immediately after switching over users on contoso.com would be able to use seamless SSO for regular SharePoint/office 365/azure ad logon

However for the first 30-60 minutes after the change any requests that were forwarded from the app to Microsoft would still get forwarded to our ADFS servers and result in an error such as:

After 60 minutes, or maybe a bit less – it went away.

2. Henrik Bernhard says:

Thanks for an excellent article and followup
Do you have any more information on why SharePoint Hybrid Search still has a solid use cases for AD FS instead of seamless sso?

3. Matt says:

Aaron – Thank you for the great write-up. I’m getting reports from users that Teams Web does not load in firefox and chrome, but does load in IE. Did I potentially miss a step in GP?

1. Aaron Guilmette says:

I just updated with the Google enterprise support info for their Group Policy templates. I think you’re going to want to configure the policy “Kerberos delegation server whitelist” as the description of it is managing what servers it will attempt integrated authentication. You’ll want to add the same SSO logon URLs.

4. Donallyb says:

Hi Aaron, thanks a million for the great article. On point number 7 you noted that you should switch from Federated to managed before completing the setup. In my case i have pretty much done exactly as you have done in this article but i was going to switch our federated domain to a manged domain outside business hours ( Note: we have about 1200 users ) Is this still an advisable approach? and also while the change over from Federated to managed is happening what the best way to check the progress of this?

Also just to note I was able to confirm that PTA is working with another domain we have which is managed

Thanks

1. Aaron Guilmette says:

Yes. There isn’t a way to “check” per-se.

5. 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. Aaron Guilmette says:

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.

6. 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

7. 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. Aaron Guilmette says:

1. Darth Jorge says:

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

8. Paul says:

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

Thanks

1. Aaron Guilmette says:

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

9. 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. Aaron Guilmette says:

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.

1. Brandon1978 says:

@aaron Can you expand more on your response to MFA doesn’t? What affect will this change have on mobile users syncing mail via Outlook (IOS, Android) and native mail app on IOS? Currently users are prompted for MFA challenge because of how we have our conditional access rules set in Intune.

10. 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. Aaron Guilmette says:

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. Aaron Guilmette says:

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

11. dirkverhagen123 says:

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. Aaron Guilmette says:

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.

12. Anonymous says:

(The content was deleted per user request)

13. 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.

14. 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

15. 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.

1. Aaron Guilmette says:

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

16. Trent says:

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

1. Aaron Guilmette says:

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. Aaron Guilmette says:

@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. Aaron Guilmette says:

@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. 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.

This site uses Akismet to reduce spam. Learn how your comment data is processed.