Category: Authenticator

AD FS 2016 Access Control Policies troubleshooting

The Access Control (AC) policies were introduced in AD FS 2016.

See this official documentation to get familiar with AD FS Access Control policies concept and settings.

Recently had to troubleshoot the following scenario.

Customer has Hybrid Exchange environment with email boxes located in on premises Exchange 2010 and archives located in Exchange Online.

Exchange on premises did not have Modern Authentication enabled.

Office 365 domain federated with AD FS 2016.

AD FS was configured to use Azure MFA.

The goal was to require MFA for all external users using Outlook 2016 and accessing their mailboxes and archives and skip MFA if the user is located inside corporate network.

At the beginning the following AD FS AC policy was configured for Office 365 Relying Party Trust (RPT).

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location;

Permit everyone
}

The issue with this policy is the “Permit everyone” at the second part, since this rule will allow anybody who didn’t meet requirement in first policy, to authenticate.

So the AD FS AC policy was modified the following way and applied to O365 RPT.

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location
}

And that’s where the unexpected authentication pop-up windows and MFA prompts started to happen when users inside corporate network were opening Outlook to access their email.

User continuously was receiving the Windows Security pop-up window that didn’t except correct user credentials and there was a second pop-up asking to authenticate again and that was triggering the MFA call to the user’s phone.

Analyzing the authentication flow based on the Exchange layout mentioned above, it was confirmed that its expected to have following authentication events to happen:

  1. User accessing email box located in on premises Exchange must authenticate via AD FS using legacy authentication from Intranet.
  2. When accessing email archive, Exchange Online has to authenticate user as well and since the legacy authentication was used, Exchange Online was authenticating on behalf of the user from outside of the corporate network.

By the way, due to the fact of legacy authentication flow we were not able to use Microsoft Claims X-Ray service.

To reduce the impact to production users, it was recommended to change the Access Control policy to contain these settings:
1. Permit users from the security group with MFA and exclude Intranet
2. Permit users from the security group with MFA and exclude Internet if the client IP (public IP of the office) matches the regex.
3. Permit all.

AD FS Access Control policy now looked like this.

{
Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'intranet' location;

Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'extranet' location
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit everyone
}

Applied this AD FS AC policy to Office 365 RPT and still there were two prompts when the Outlook 2016 is opened – basic authentication window when accessing on premises email box and Modern Authentication prompt with MFA when accessing EXO archive.

In the AD FS Admin logs we saw the error: “MSIS5007: The caller authorization failed for caller identity XXX for relying party trust urn:federation:MicrosoftOnline.”

And in the AD FS Debug logs see the MFA is still required regardless the fact that the authentication attempt is coming from Intranet.

After multiple additional tests and getting better understanding how the Access Control policies are applied the following AD FS AC Policy was crafted that has addressed the issue completely.

{
Permit users 
	from 'extranet' location
	and from ‘TEST’' group
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'extranet' location
	and from 'TEST' group
	and when authentication includes MFA
except 
	with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'intranet' location
	and from 'TEST' group;

Permit everyone
} 

The AD FS Access Control polices above work the following way:
1. Permits authentication coming from Internet if its EXO legacy authentication protocol on behalf of the user in the test security group coming from office public IP address;
2. Permits any other authentication for the test group coming from Internet if the MFA completed, but excludes office public IP from this rule (to make sure the first rule works as expected);
3. Permits authentication from the Intranet with no MFA for the test group (authentication to on premises Exchange)
4. And the last one catch Permit All group to make sure prod users are not affected during testing.

ADFS Access Control Policy

When the AD FS AC policy was successfully tested with the users added to the TEST group, the policy was applied to the rest of the production users by removing the TEST group condition from the first three policies and removing “Permit everyone”.

Advertisements

Mobile app authentication with Azure Multi-Factor Authentication Server – Error calling the local authentication service troubleshooting

Customer was configuring the Mobile application authenticator portal in his new MFA server environment. One server was used to hold MFA server, MFA User portal and mobile portal roles.

Official documentation was used – https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server-webservice

All the prerequisites were met:

  • Azure Multi-Factor Authentication Web Service SDK installed;
  • Web.Config in the C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService was updated with the correct Service Account (member of “PhoneFactor Admins” Group) credentials;
  • Web Service SDK URL value updated;
  • SSL certificate bind to Mobile App Web Service website in IIS;
  • Mobile App Web Service URL was accessible from inside and outside of corporate network, no SSL errors in the browser;
  • the mobile app settings were configured in the Azure Multi-Factor Authentication Server;
  • MFA server is running latest version – 7.3.0.3.

But when the user tried to activate Mobile Authenticator app on his iOS device via MFA user portal he was getting following error:

Error calling the local authentication service. Contact your local IT administrator to resolve the problem.

IphoneMFAerror2

Trying Google Authenticator application returned following error:

Invalid barcode ‘phonefactor://activate_account?code=381470548&url=https%3a%2f%mfa.contoso.com%2fMultiFactorAuthMobileAppWebService’ is not a valid authentication token barcode. Try Again.

InkedGoogleAuthError_LI2

Decided to check the Mobile App Web Service URL using my old friend – Qualys SSL Labs.

The site was graded as B because “This server’s certificate chain is incomplete”.

An intermediate CA certificate was installed (it’s usually provided with the SSL certificate you purchase or can be downloaded from Certificate Authority support site) on MFA server (holding IIS role), but the Authenticator application still was throwing the “Error calling the local authentication error”.

As next troubleshooting made sure the Mobile App Web Service site host name on the MFA server resolves to internal MFA server IP.

After that from IIS browsed to Mobile App site and selected the TestPfWsSdkConnection link, under the Test section pressed the Invoke command and got following error:

131 – Exception calling the Web Service SDK: The underlying connection was closed: An unexpected error occurred on a receive.

Looking at the System Event logs see a lot of EventID 36871A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

It turned out that the server has TLS 1.0 protocol support disabled and that is required by MFA Web SDK (this dependency should be removed in future MFA server versions). As soon as the TLS 1.0 was enabled on the server, the users were able to configure their mobile Authenticator apps.