Adfs Office 365

-->

Note

Jun 23, 2017 Active Directory Federation Services (ADFS) had (and still has) its place within Office 365 environments, but it is not nearly as attractive and easy to use as the new methods. Switching from ADFS to password synchronization (or Pass-through Authentication) requires planning and communication. Possible issues you may come across. On another hand, if your issue persists, since we are focusing on Office 365 for Business Exchange Online Support, we have limited resource regarinding to ADFS proxy deplyment. However, Microsoft has a dedicated TechNet Forum, the dedicated support engineers there are focusing on this kinds of problems, and please post a new thread there to.

Office 365 ProPlus is being renamed to Microsoft 365 Apps for enterprise. For more information about this change, read this blog post.

Problem

When users sign in to a Microsoft cloud service such as Office 365, Microsoft Intune, or Microsoft Azure by using a federated user account, the connection to the Active Directory Federation Services (AD FS) service fails only when users try to do the following:

Connect from a remote Internet location
Use email connections to sign in

This situation also causes SSO testing that the Remote Connectivity Analyzer conducts to fail.

For more information about how to run the Remote Connectivity Analyzer to test SSO authentication in Office 365, see the following articles in the Microsoft Knowledge Base:

2650717 How to use Remote Connectivity Analyzer to troubleshoot single sign-on issues for Office 365, Azure, or Intune
2466333 Federated users can't connect to an Exchange Online mailbox

Cause

These failures can occur if the AD FS service isn't exposed correctly to the Internet. Typically, the AD FS proxy server is used for this purpose, and problems with the AD FS proxy server will cause these symptoms. Common problems include the following:

Expired SSL certificate that's assigned to the AD FS proxy server
Frequently, the same SSL certificate is used to help secure communication (HTTPS) for both the AD FS Federation Service and the AD FS proxy server. When this certificate becomes expired and the certificate is renewed or updated on the AD FS Federation Service farm, the SSL certificate must also be updated on all AD FS proxy servers. If the AD FS proxy server SSL certificate isn't updated in this case, Internet connections to the AD FS service may fail, even though the AD FS Federation Service is healthy.
Incorrect configuration of IIS authentication endpoints
The role of the AD FS proxy server is to receive Internet communication that's directed at AD FS and to relay that communication to the AD FS Federation Service. Therefore, it's important for the IIS authentication setting of the AD FS Federation Service and proxy server to be complementary. When the AD FS proxy server IIS authentication settings aren't set to complement the AD FS Federation Service IIS authentication settings, sign-in may fail or may generate multiple, unexpected prompts.
Broken trust between the AD FS proxy server and the AD FS Federation Service
The AD FS proxy service is designed to be installed on a non-domain joined computer. Therefore, the communication between the AD FS proxy server and the AD FS Federation Service can't be based on an Active Directory trust or credentials. Instead, the communication between these two server roles is established by using a token that is issued to the AD FS proxy server by the AD FS Federation Service and signed by the AD FS token-signing certificate. When this trust is expired or invalid, the AD FS Proxy Service can't relay AD FS requests, and the trust must be rebuilt to restore functionality.

Solution

To resolve this issue, use one of the following methods, as appropriate for your situation, on all malfunctioning AD FS proxy servers.

Method 1: Fix AD FS SSL certificate issues on the AD FS server

To do this, follow these steps:

Troubleshoot SSL certificate problems on the AD FS Federation Service (not the Proxy Service) by using the following Microsoft Knowledge Base article:
2523494 You receive a certificate warning from AD FS when you try to sign in to Office 365, Azure, or Intune
If the AD FS Federation Service SSL certificate is functioning correctly, update the SSL certificate on the AD FS proxy server by using the certificate export and import functions. For more info, see the following Microsoft Knowledge Base article:
179380 How to remove, import, and export digital certificates

Method 2: Reset the AD FS proxy server IIS authentication settings to default

To do this, follow the steps that are described in Resolution 1 of the following Microsoft Knowledge Base article for the AD FS proxy server:

2461628 A federated user is repeatedly prompted for credentials during sign-in to Office 365, Azure, or Intune

Method 3: Rerun the AD FS Proxy Configuration wizard

To do this, rerun the AD FS Federation Server Proxy Configuration Wizard from the Administrative Tools interface of all affected AD FS proxy servers.

Note

It's usual to receive a warning from the 'Deploy browser sign-in Web site' step when you rerun the configuration wizard. This isn't an indication that the wizard did not rebuild the trust between the AD FS proxy server and the AD FS Federation Service.

More information

For more info about how to expose the AD FS service to the Internet by using an AD FS proxy server, go to the following Microsoft website:

Still need help? Go to Microsoft Community.

-->

Note

Office 365 ProPlus is being renamed to Microsoft 365 Apps for enterprise. For more information about this change, read this blog post.

Summary

Use of SupportMultipleDomain switch, when managing SSO to Office 365 using ADFS

When an SSO is enabled for O365 via ADFS, you should see the Relying Party (RP) trust created for O365.

Commands that would create the RP trust for O365 are below:

The RP trust created above came with 2 claims rules

Get-MsolFederationProperty -DomainName on the federated domains shows that the 'FederationServiceIdentifier' was the same for source ADFS and O365 i.e. the http://stsname/adfs/Services/trust

Earlier before the ADFS Rollup 1 and Rollup 2 updates, Microsoft Office 365 customers who utilize single sign-on (SSO) through AD FS 2.0 and have multiple top-level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.com or @fabrikam.com) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. There is now a rollup for AD FS 2.0 (https://support.microsoft.com/kb/2607496) that works in conjunction with the 'SupportMultipleDomain' switch to enable the AD FS server to support this scenario without requiring additional AD FS 2.0 servers.

With the ADFS rollup 1 update, we added the following functionality:

Multiple Issuer Supports

'Previously, Microsoft Office 365 customers who require single sign-on (SSO) by using AD FS 2.0 and use multiple top-level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.us or @contoso.de) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. After you install this Update Rollup on all the AD FS 2.0 federation servers in the farm and follow the instructions of using this feature with Office 365, new claim rules will be set to dynamically generate token issuer IDs based on the UPN suffixes of the Office 365 users. As a result, you do not have to set up multiple instances of AD FS 2.0 federation server to support SSO for multiple top-level domains in Office 365.'

Support for Multiple Top-Level Domains

'Currently, Microsoft Office 365 customers who utilize single sign-on (SSO) through AD FS 2.0 and have multiple top-level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.com or @fabrikam.com) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. There is now a rollup for AD FS 2.0 (https://support.microsoft.com/kb/2607496) that works in conjunction with the 'SupportMultipleDomain' switch to enable the AD FS server to support this scenario without requiring additional AD FS 2.0 servers.'

Commands that would create the RP trust for O365 are below:

Get-MsolFederationProperty -DomainName on the federated domains now shows that the 'FederationServiceIdentifier' is different for ADFS and O365. Every federated domain will have the 'FederationServiceIdentifier' ashttp://<domainname>/adfs/services/trust/ whereas the ADFS configuration still has http://STSname/adfs/Services/trust

Adfs Office 365 Setup

Due to this mismatch in configuration, we need to ensure that when a token is sent to O365 the issuer mentioned in it, is the same as one configured for the Domain in O365. If not you will get the error below:

So when adding or updating RP trust with SupportMultipleDomain switch, a third claim rule is automatically added to the RP trust for O365.

Default third rule:

c:[Type 'http://schemas.xmlsoap.org/claims/UPN](http://schemas.xmlsoap.org/claims/UPN']=> issue(Type = 'https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid', Value = regexreplace(c.Value, .+@(?<domain>.+), http://${domain}/adfs/services/trust/));

This rule uses the suffix value of user's UPN and uses that to generate a new claim called 'Issuerid.' Example http://contoso.com/adfs/services/trust/.

Using fiddler, we can trace the token being passed to login.microsoftonline.com/login.srf. After copying the token passed in wresult, paste the content in notepad and save that file as .xml.Later you can open the token saved as .xml file using IE and see its content.

Adfs Office 365 Sign In

It's interesting to note that the rule issues 'Issuerid' claim, we don't see this claim in the response token, in fact we see the 'Issuer' attribute modified to the newly composed value.

NOTE

SupportMultipleDomain is used without the ADFS rollup 1 or 2 installed. You will see that the response token generated by ADFS has BOTH the Issuer='http://STSname/adfs/Services/trust' and the claim 'Issuerid' with the composed value as per the third claim rule.

Support for Sub domains

Office 365 Outlook Login

'It is important to note that the'SupportMultipleDomain' switch is not required when you have a single top-level domain and multiple sub domains. For example if the domains used for upn suffixes are @sales.contoso.com, @marketing.contoso.com and @contoso.com and the top-level domain (contoso.com in this case) was added first and federated then you don't need to use the 'SupportMultipleDomain' switch. This is because these sub domains are effectively managed within the scope of the parent and a single AD FS server can be utilized to handle this already.'

If however, you have multiple top-level domains (@contoso.com and @fabrikam.com) and these domains also have sub domains (@sales.contoso.com and @sales.fabrikam.com) the 'SupportMultipleDomain' switch will not work for the sub domains and these users will not be able to log in.

Why will this switch not work, in the above scenario?

Answer:

Adfs Office 365 Login

For child domain, sharing the same namespace, we don't federate them separately. The federated root domain covers the child as well, which mean that thefederationServiceIdentifier value for the child domain will also be the same as that of parent i.e. https://contoso.com/adfs/services/trust/.
But the third claim rule, which ends up picking the UPN suffix for the user to compose the Issuer value ends up with https://Child1.contoso.com/adfs/services/trust/, again causing a mismatch and hence the error 'Your organization could not sign you in to this service.'
To resolve this, we can modify the third rule such that it ends up generating an Issuer value that matches 'FederationServiceIdentifier' for the domain at O365 end. 2 different rules that can work in this scenario is below. This rule just picks up the root domain from the UPN suffix to compose the Issuer value. For a UPN suffix child1.contoso.com, it will still generate an Issuer value of https://contoso.com/adfs/services/trust/ instead of https://Child1.contoso.com/adfs/services/trust/ (with default rule)

Adfs With Office 365

Customized third rule

Rule 1:

Rule 2:

NOTE

The rules above may not apply to all scenarios, but can be customized to ensure that the 'Issuerid' value matches 'FederationServiceIdentifier' for the domain added/federated at O365 end.

The mismatch of federationServiceIdentifier between ADFS and O365 for a domain can also be corrected by modifying the 'federationServiceIdentifier' for the domain at O365 end, to match the 'federationServiceIdentifier' for ADFS. But the federationServiceIdentifier can only be configured for ONE federated domain and not all.

Set-MSOLDomainFederationSettings -domain name Contoso.com –issueruri http://STS.contoso.com/adfs/services/trust/

Compfox283

Adfs Office 365

Problem

Cause

Solution

Method 1: Fix AD FS SSL certificate issues on the AD FS server

Method 2: Reset the AD FS proxy server IIS authentication settings to default

Method 3: Rerun the AD FS Proxy Configuration wizard

More information

Summary

Use of SupportMultipleDomain switch, when managing SSO to Office 365 using ADFS

Commands that would create the RP trust for O365 are below:

With the ADFS rollup 1 update, we added the following functionality:

Multiple Issuer Supports

Support for Multiple Top-Level Domains

Commands that would create the RP trust for O365 are below:

Adfs Office 365 Setup

Adfs Office 365 Sign In

Support for Sub domains

Office 365 Outlook Login

Why will this switch not work, in the above scenario?

Adfs Office 365 Login

Adfs With Office 365

Customized third rule

More information that should help you write your own claim rules.**