Tag: MFA

Troubleshooting NPS extension for Azure Multi-Factor Authentication

I’m sure you are familiar with following official documentation how to use your existing NPS infrastructure with Azure Multi-Factor Authentication. 

And the following one is proving detailed steps to troubleshoot error messages from the NPS extension for Azure MFA

Here are the recommended troubleshooting steps in case you see the following combination of errors in the NPS Security and Microsoft-AzureMfa-AuthZ.

Log Name:     Security
Source:       Microsoft-Windows-Security-Auditing
Date:         1/22/2019 12:32:30 PM
Event ID:     6274
Task Category: Network Policy Server
Level:         Information
Keywords:     Audit Failure
User:         N/A
Computer:     XXX
Description:
Network Policy Server discarded the request for a user.
Contact the Network Policy Server administrator for more information.

User:
                    Security ID:                                                        XXX
                    Account Name:                                                XXX
                    Account Domain:                         XXX
                    Fully Qualified Account Name:                 XXX
Client Machine:
                    Security ID:                                                        NULL SID
                    Account Name:                                                –
                    Fully Qualified Account Name:                 –
                    Called Station Identifier:                             –
                    Calling Station Identifier:                            –
NAS:
                    NAS IPv4 Address:                      –
                    NAS IPv6 Address:                      –
                    NAS Identifier:                                                 –
                    NAS Port-Type:                                                –
                    NAS Port:                                                            –
RADIUS Client:
                    Client Friendly Name:                                   –
                    Client IP Address:                                            –

Authentication Details:
                    Connection Request Policy Name:          Use Windows authentication for all users
                    Network Policy Name:                                  VPN-
                    Authentication Provider:                             Windows
                    Authentication Server:                                 xxx
                    Authentication Type:                                    PAP
                    EAP Type:                                                           –
                    Account Session Identifier:                        –
                    Reason Code:                                                    9
                    Reason:                                                                The request was discarded by a third-party extension DLL file.

Log Name:     AuthZAdminCh
Source:       Microsoft-AzureMfa-AuthZ
Date:         1/22/2019 12:32:30 PM
Event ID:     3
Task Category: None
Level:         Critical
Keywords:    
User:         NETWORK SERVICE
Computer:     XXX
Description:
The following information was included with the event:
CID: xxx :Exception in Authentication Ext for User XXX :: ErrorCode:: CID :xxx ESTS_TOKEN_ERROR Msg:: Verify the client certificate is property enrolled in Azure against your tenant and the server can access URL in Registry STS_URL. Error authenticating to eSTS: ErrorCode:: ESTS_TOKEN_ERROR Msg:: Error in retrieving token details from request handle: -895352831 Enter ERROR_CODE @ https://go.microsoft.com/fwlink/?linkid=846827 for detailed TroubleShooting steps. Enter ERROR_CODE @ https://go.microsoft.com/fwlink/?linkid=846827 for detailed TroubleShooting steps.

In case you have verified that the certificate generated during NPS configuration was correctly associated with Azure MFA Client SPN and there are no network connectivity issues, I would recommend checking if Azure MFA Client and Connector SPN are enabled in your tenant.

You can do this either via Azure AD portal – go to Enterprise Applications – Change the Application Type to All, search for Azure Multi-Factor Auth Connector and Azure Multi-Factor Auth Client and make sure they are enabled.

Or you can use Azure AD PowerShell. Connect to MSOLServicies and issue following commands (first checks Client, second Connector):

Get-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720" | fl *
Get-MsolServicePrincipal -AppPrincipalId "1f5530b3-261a-47a9-b357-ded261e17918" | fl *

 

If the AccountEnabled attribute is set to False, you can enable it with this PowerShell command:


Set-MsolServicePrincipal -AppPrincipalId "xx" -AccountEnabled $True

 

I will also highly recommend to have a look at the following Azure MFA NPS Extension Health Check Script – http://azuredummies.com/2018/09/11/azure-mfa-nps-extension-health-check-script-v1/

Advertisements

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

Azure Multi-Factor Authentication Server not sending emails out for new users

Recently was troubleshooting the issue when no email is sent to the new MFA server users regardless all the configurations seems to be correct. See following official documentation for more details. 

Because Administrator was able to send the Update email to the end user, we excluded the improper SMTP server configuration.

Per MFA server Help file: New Users – An email is sent to a user added that is enabled and complete (phone specified, mobile app activated, or OATH token secret key specified), or to an updated user that was either disabled or incomplete and is now enabled and complete.

Note: Emails are only sent when Send email to users is checked and the user’s email address is specified or their username is in email address format.

Confirmed that the New user has “Send email” check box selected on the User profile General Tab and the email address is correct.

MFAnewUser

Also, by going to MFA UI – Email – Email Context confirmed all the New User templates have correct email address specified in the From field.

Checked the SMTP server logs and don’t see any email send attempt from MFA server for New User email, only connections for Update email to be send.

Time to check the MFA Server logs!

To make sure you are looking at the latest logs, go to MFA UI – Logging – View Log Files.

Looking at the MultiFactorAuthAdSyncSvc.log see following error correlating to the time when the new user was added:

2018-03-07T18:20:20.006280Z|e|2960|4036|pfadssvc|***** ERROR ***** Error sending email to NewUser@domain.com: Access to the path ‘\\FileShare\public\MFA-Instructions\MFA-Guide.pdf’ is denied.

So the Administrator used the Attachment option to send additional instructions to new users, but the File share had access restrictions preventing the MFA server Local System account reading this document.

MFAnewUser2

Solution was to either move the MFA instructions files to the MFA server or adjust the file share access permissions to allow Everyone to read the files.

Morale of the story: Read the manuals and logs, those are written by smart people 😊

Azure Multi-Factor Authentication Server with ADFS – EventID 105 troubleshooting.

One of the customers was following these instructions to configure Azure MFA Server to work with ADFS – https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-adfs-w2k12

In his environment the MFA and ADFS roles were installed on separate servers (1 MFA and 2 ADFS servers with SQL database).

After carefully completing instructions, we saw following errors in the ADFS Admin logs after ADFS adapter was installed and ADFS service was restarted.

Log Name:      AD FS/Admin
Source:        AD FS
Date:          1/17/2018 10:16:59 AM
Event ID:      105
Task Category: None
Level:         Error
Keywords:      AD FS
User:          XXX
Computer:      XXX
Description:
An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: AzureMfaServerAuthentication
Context: Passive protocol TLS pipeline

And

Log Name:      AD FS/Admin
Source:        AD FS
Date:          1/17/2018 10:16:59 AM
Event ID:      105
Task Category: None
Level:         Error
Keywords:      AD FS
User:          XXX
Computer:      XXX
Description:
An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: AzureMfaServerAuthentication
Context: Proxy TLS pipeline

During troubleshooting performed following steps:

  • Made sure the Web Service SDK is installed on MFA server;
  • The Web Service SDK URL is accessible from MFA server and from ADFS server with the account that is specified in the MultiFactorAuthenticationAdfsAdapter.config file (no SSL certificate errors);
  • User specified in the MultiFactorAuthenticationAdfsAdapter.config file is a member of the PhoneFactor Admins domain security group;
  • Unregistered the ADFS adapter (need to do this on one ADFS server), restarted ADFS service (all ADFS servers), registered ADFS adapter again (on one ADFS server) – still the same EventID 105 error;

As a next troubleshooting step enabled ADFS debug log (open Event Viewer – check “Show Analytic and Debug Logs” under View menu – go to Applications and Services Logs – ADFS Tracing – right click on Debug log and select Enable log).

After restarting the ADFS service again, saw following EventID in the Debug logs.

Log Name:      AD FS Tracing/Debug
Source:        AD FS Tracing
Date:          1/17/2018 11:00:50 AM
Event ID:      183
Task Category: None
Level:         Error
Keywords:      ExternalAuthentication
User:          XXX
Computer:      XXX
Description:
ExternalAuthenticationHandler.OnAuthenticationPipelineLoad() exception: System.IO.InvalidDataException: Error parsing configuration data. —> System.InvalidOperationException: There is an error in XML document (3, 6). —> System.Xml.XmlException: Unexpected node type Element. ReadElementString method can only be called on elements with simple or empty content. Line 3, position 6.

Definitely something is wrong with the MultiFactorAuthenticationAdfsAdapter.configfile.

So we decided to copy the new file from \Program Files\Multi-Factor Authentication Server directory on MFA server to ADFS and carefully filled in the following fields:

UseWebServiceSdk
WebServiceSdkUrl
WebServiceSdkUsername
WebServiceSdkPassword

After that no errors in the ADFS admin logs and MFA started working as secondary authentication method!

Comparing the Bad and Good configuration files discovered the root of the issue 🙂

It was a missing “<” after word true in line <UseWebServiceSdk>true</UseWebServiceSdk> that was accidentally deleted when customer was changing “false” value to “true”.

P.S. Check my new post for other possible typos in the config file that will cause slightly different error in the ADFS Debug logs.