Category Archives: Office365

How to Bypass MFA for Autodiscover and Activesync in Windows Server 2016 Using Access Control Policies

ADFS, Client Access, MFA, Office365

Had trouble finding any info on this besides using the version of ADFS that comes with 2012 R2, configuring the exceptions through powershell. In ADFS in Windows Server 2016, you can know utilize Access Control Policies to configure rules around how users authenticate to ADFS. In our setup, we have a classic example where when client’s are in the office, they should automatically login using Windows Integrated Authentication (essentially that they are not prompted for credentials). When the users are not on the corporate network, they should be forced to utilize Multi-Factor Authentication (MFA for short).

Note there are some requirements for this setup.

  • You need to have ADFS deployed utilizing an ADFS proxy server to the internet (or some other proxy that can add the required headers to the internet based requests)
  • If your using multi-factor authentication it is assumed you are using Modern Authentication on your Outlook Clients

If we open up ADFS MMC, navigate to Access Control Policies:

Image

 

There are several pre-canned policies on the left, but we are going to create our own by clicking Add Access Control Policy in the upper right hand.

Give the policy a meaningful name and description, and then build your policy as follows:

 

Image

 

Note that it works similar to a firewall rule. We have the most restrictive policy at the top. Meaning if a user is a member of the AD Group DualAuth in this case, and they are logging in from outside the corporate network, they will be forced to use multi-factor authentication. The processing of rules for that user will stop. The Permit Users is required for ALL other users to be able to login without issue from the Internet, but also to allow ALL users to login using Windows Integrated Authentication from within the corporate network.

The initial problem with this policy is that not all applications have the ability to perform multi-factor authentication. The classic ones or Exchange Activesync and Exchange Autodiscover. So we need to exclude those from this processing.

If we select our initial rule block and click edit, we can select under the except tab, the with specific claims in the request checkbox.

Image

 

Next, click on the link in the word specific. Select the claims radio button. Under claim type, change this to read client application -> contains -> Microsoft.Exchange.Autodiscover. Add another row and change the Claim Value to be Microsoft.Exchange.Activesync.

Image

 

Hit okay, save your changes and your good to go!

How to Troubleshoot SAML Login’s with Office 365 and Fiddler

Office365, SAML

Recently had an issue where a user could not log into his Office 365 account. The organization was using Azure AD Sync and SAML based login. The user could successfully authenticate to the ADFS login, but once they tried to access the Office 365 resources they would receive an error. Below is a screen shot of the error when they tried to login to OWA.

Image

 

Troubleshooting SAML can be a bit complicated, so I’ll go through some of the steps that I used to determine what the SAML server was providing to Office 365, and where the breakdown was in this specific case.

First, I downloaded and installed Fiddler on a test machine – https://www.telerik.com/download/fiddler-wizard.

After the install, I needed to configure Fiddler to decrypt my HTTPS traffic.

Go to Tools -> Options->HTTPS

Ensure that Decrypt HTTPS traffic and Ignore server certificate errors are selected

Image

Image

You will get some warnings about trusting the local certificate. You want to click accept and yes to this warnings. What happens is Fiddler acts as a Man in the Middle proxy so that it can decrypt your traffic. You allowing it to install a certificate to the machines local store so that it trusts this certificate. You can view it in Local Computer -> Trusted Root Certificate Authorities

Image

 

Next, open your web browser (I use Edge for this since it utilizes the local machine’s certificate store) and open it to a blank page. In Fiddler, clear the tracing results that are already present:

Image

 

Now, browse to the OWA site for your organization in Office 365. Its in the format https://outlook.office.com/domainname.com. So for my test I’m using https://outlook.office.com/abacusflex.net. This should land you on the login page for your SAML provider. Log in as normal:

Image

Next, get to a place where your login breaks, or you get the error, in our case, it is the original error message:

Image

 

In Fiddler, go to File -> Capture Traffic to stop the capture.

Image

Now, in the results section, find the last entry that has your SAML host name, and the URL beginning with /adfs/ls. In our example below we are looking at line 41.

Image

We want line 41 because this is the last entry from our SAML provider before we are pushed back to login.microsoftonline.com so this has our SAML session ticket in the response.

Select that entry, and on the right hand side, select Inspectors along the top row, and Raw along the bottom row:

Image

Now copy out the line underneath Content Length to a text editor

Image

You will have a big blog of text. In the first few lines, find the entry name=”wresult” value=

Image

You want to copy everything AFTER the equals sign in value:

Image

Until the string ends with RequestSecurityTokenResponse>”

Image

In our example, that leaves us with the following string (adjusted for formatting reasons):

“<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"><t:Lifetime><wsu:Created …/t:RequestSecurityTokenResponse>”

So the string you have, isn’t that nice or easy to ready, so lets run it through some HTML decoders.

I used the one on opinionatedgeek.com – https://opinionatedgeek.com/Codecs/HtmlDecoder

Image

Copy the decoded result to a text editor. Now we want to format that for XML. I used the one from WebToolKitOnline – http://www.webtoolkitonline.com/xml-formatter.html

Image

Okay, now we have readable XML data that we can paste into our favorite XML viewer.

So for us, we can now see the SAML response that we are sending to Office 365. In our case we are interested in the UPN attribute and the Immutable ID values:

Image

We suspected that the Immutable ID we were getting from ADFS was not matching with the Immutable ID we have stored in Office 365. We can see here that the values we are getting from ADFS are:

UPN – pponzeka@abacusflex.net

ImmutableID – xPPblRWKMkqRDhd6jO4O4Q==

So if we check in Microsoft Online we can get the UPN and ImmutableID through powershell:

Get-Msoluser -UserPrincipalName pponzeka@abacusflex.net | select userprincipalname,immutableid

This gives us the following output:

Image

We can see that the ImmutableID value’s do not match between ADFS and Office 365. In this case, the client was syncing a custom attribute that was not converting the value correctly. They fixed their back end process and then the user was able to log in.

I hope this article helps some of you with using Fiddler to troubleshoot SAML login issues with ADFS.