Tag Archives: MFA

Implementing Active Directory Federation Services step-by-step part II

In the previous blog (Implementing Active Directory Federation Services step-by-Step) I have showed you how to install and configure Active Directory Federation Services (ADFS) in your internal network and DMZ, capable of handling Office 365 authentication request. In this blog I’ll show you how to configure Office 365 and how to test it.

Federated Domains

In a typical managed domain, the user accounts and password hashes are synchronized to Azure Active Directory. Office 365 uses Domain Controllers in Azure AD to authenticate the users and grant them access to the resources in the cloud.

In a federated domain, the user accesses the Office 365, but access is denied, and the request is redirected to Azure Active Directory. There, the home realm (the user’s domain) is discovered and the request is redirected to the ADFS server based on the home realm. If my user account is j.wesselius@exchangelabs.nl, my home realm is exchangelabs.nl and the request is redirected to the federation server that was created earlier, and that was used to configure the domain in Azure Active Directory.

I did a session on this at IT Dev Connections in 2017 (in San Francisco), the following is one animated slide that can be downloaded which shows the flow between a client, Office 365, Azure AD and the on-premises ADFS and Domain Controller:

ADFS Federation Flow

To get this working, the domain in Azure Active Directory needs to be converted to a federated domain so that Azure AD knows any authentication request needs to be redirected to the on-premises ADFS environment.

When adding a domain to Azure Active Directory it is automatically created as a managed domain. As said before, authentication takes places against Domain Controllers in Azure AD. You can check a domain using the Get-MsolDomain -DomainName exchangelabs.nl PowerShell command as shown in the following screenshot:

Get-MsolDomain

To convert this to a federated domain, start a PowerShell command (with elevated privileges) and enter the following commands:

[PS] C:\> Connect-MsolService

[PS] C:\> Set-MsolADFSContext -Computer ams-adfs01.labs.local

[PS] C:\> Convert-MsolDomainToFederated -DomainName Exchangelabs.nl

Note. Use the FQDN of the local first ADFS server with the Set-MsolADFSContext command, not the federation URL

This will connect the existing on-premises infrastructure to Azure AD, and convert the domain to a federated domain. Now, when checking the domain in Azure AD using the same command as before you’ll see it now is a federated domain:

Set-MsolAdfsContext Exchangelabs

In in the ADFS Management Console you’ll a new Relying Party Trust (RPT) for use with Office 365:

ADFS Relying Party Trust

To get more into detail in Azure AD about the federation settings, you can use the Get-MsolDomainFederationSettings command which shows more information:

Get-MsolDomainFederationSettings

Clearly visible are the Logon, Issuer and LogOffUri, which point to our on-premises ADFS implementation. Even more information can be retrieved using the Get-MsolFederationProperty command as shown in the following screenshot:

Get-MsolFederationProperty

To test the new configuration, navigate to the Microsoft Online Portal and login using an account with the domain we just configured, i.e. j.wesselius@exchangelabs.nl:

Microsoft Online Portal

When selecting this account, Azure AD determines the home realm (exchangelabs.nl) and redirect to the on-premises URL as found in the federation settings in Azure AD. You’ll see this happen on the fly in your browser:

Taking you to your organizations sign-in page

And a few seconds later we are redirected to our on-premises ADFS environment:

ADFS Federation Sign-in page

Clearly visible is the Federation Service display Name which was configured with the first ADFS server in the previous blogpost.

Enter your password, and how wonder, MFA is still working as well (which was a pleasant surprise for me 😊):

ADFS Exchangelabs MFA

Another interesting test is using the Remote Connectivity Analzyer ( (https://aka.ms/exrca) which has a Single Sign-On test. Navigate to the Remote Connectivity Analyzer, click the Office 365 tab and select the Office 365 Single Sign-On test radio button.

Enter username and password, do the verification code test and await the results. You’ll see something similar as the following screenshot:

Remote Connectivity Analyzer Single Sign-On Test

The logon attempt was successful, but more interesting is that you can expand all test steps to see what’s going on under the hood and try to understand how ADFS works.

Summary

In the previous two blogposts I demonstrated how to install and configure ADFS in your on-premises infrastructure. I installed only one ADFS server and one WAP proxy, which is far from a high available environment. Why high available? Without the ADFS server it is no longer possible to logon to any Office 365 service, so a high available infrastructure is a requirement for any ADFS implementation.

But customers are moving to the cloud to decommission their on-premises solutions, and with ADFS we’re building an on-premises solution for authenticating cloud solutions. But for compliancy reasons it might be needed to authenticate against local domain controllers (no passwords in the cloud for example). On the other hand, you can use Pass Through Authentication (PTA, see my blogpost Azure AD Connect Pass-through authentication) for this as well. PTA doesn’t offer as much possibilities as ADFS yet, but it is improving.

Is ADFS future proof? Some people say it isn’t, but as long as I find articles like What’s new in Active Directory Federation Services for Windows Server 2019 on the Microsoft website I don’t see too many issues with that.

More information

Outlook 2010 stays offline with Exchange Online

One of my clients is running Exchange 2010 in hybrid mode, and they have Outlook 2010 and Outlook 365 ProPlus client. For testing purposes, I have two VMs, one with Windows 7 and Office 2010 and one with Windows 10 and Office 365 ProPlus. And every Monday morning I run the Windows 7 VM for an hour or so to see if everything is working fine 😊

This morning my Outlook 2010 was working offline, and it didn’t want to go online (OWA and Outlook 365 ProPlus were working fine). Remove the Outlook profile but creating a new Outlook profile didn’t work. After a minute the dreaded an encrypted connection to your mail server is not available error message appeared:

An encrypted connection to your mail server is not available

Mostly this is caused by Autodiscover that goes wrong somewhere, the Remote Connectivity Analyzer shows that Autodiscover to the on-premises Exchange 2010 goes well, but that the redirect to Exchange Online goes wrong and it generates the following error message:

An HTTP 456 Unauthorized response was received from the remote Unknown server. This indicates that the user may not have logged on for the first time, or the account may be locked. To logon, go to http://portal.microsoftonline.com.

And further down more details are revealed:

X-AutoDiscovery-Error: LiveIdBasicAuth:AppPasswordRequired:<RequestId=8a51c25b-9213-4873-aff8-ebc1da40544f>;

An HTTP 456 Unauthorized response was received from the remote Unknown server

The AppPasswordRequired explains more. Last week I changed the MFA settings (see previous authenticator app for Office 365 blogpost). This works fine for OWA and Office 365 ProPlus, but not for Outlook 2010. Since Outlook 2010 does not work with Office 365 MFA, especially not in a hybrid environment (not even with an App Password).

The only workaround here was to temporarily disable MFA for my user account, create a new Outlook profile (which worked fine without MFA) and re-enable MFA. Again, Outlook 2010 does not recognize the MFA and still works with Exchange Online using basic authentication, but all other Office 365 services work fine with Office 365 MFA (both SMS and Authenticator authentication).

Authenticator app for Office 365

I have been running MFA for Office 365 user accounts up-and-running for quite some time now and very satisfied with it. But as you may have seen in the blogpost, I have been running SMS only, and with a 30 days renewal that works fine. But I was also interested in the Authenticator app, especially when running multiple clients on mobile devices.

Changing the authentication can be done on a per-user basis. Logon to the Microsoft portal (portal.office.com) using your regular work account. Select My Account (under your thumbnail profile picture) and select Security and Privacy and click Additional security verification as shown in the following screenshot:

Select Update your phone numbers used for account security, check the Authenticator app or token checkbox and click Setup authenticator app button.

Scan the QR code on your mobile device in the authenticator app, confirm the registration, click Save and you’re all set. The next time you logon to Office 365 you’ll see the following Approve Sign in Request window:

But instead of entering a verification code received via SMS you must approve the sign in on the Authenticator app.

Prepopulate mobile phone for multi-factor authentication

I am working with a customer where we want to enable multi-factor authentication for their users as a measure to secure their environment. But when you enable MFA and a user logs on for the first time, the user has to enter his mobile phone number, even if the mobile phone number is populated in on-premises Active Directory and synchronized to Azure Active Directory (which is default).

additional security verification

When you check the user account in the Azure AD portal, you can see that the mobile phone number is synchronized, but the authentication phone number is empty.

authentication contact info

This is not a desired solution, if a user can set a new mobile phone during logon, a malicious user can do this as well. A typical user will logon shortly after the MFA is set, but especially when doing bulk changes this might not be the case. And when a user account that is MFA enabled, but hasn’t set the authentication phone property is compromised you’re screwed.

Out of the box there’s no easy way to prepopulate the authentication phone number. The authentication phone number is not store in on-premises Active Directory, it’s an Azure AD property. The property to control the strong authentication is called StrongAuthenticationMethods and you can set this using PowerShell. When you set this, the authentication phone number is still prepopulated, but when the mobile phone number is synchronized, this is used in the first place.

To set this StrongAuthenticationMethods property you can use the following PowerShell commands:

Connect MsolService 
$UserPrincipalName = "j.brown@exchangelabs.nl"
$SMS = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$SMS.IsDefault = $true
$SMS.MethodType = "OneWaySMS"
$Phone = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$Phone.IsDefault = $false
$Phone.MethodType = "TwoWayVoiceMobile"
$PrePopulate = @($SMS, $Phone)
Set-MsolUser -UserPrincipalName $UserPrincipalName -StrongAuthenticationMethods $PrePopulate

Now when the user logs on for the first time with MFA enabled, he’s presented the enter code dialog box, without having to enter a mobile number first.

we texted your phone

If you do this, and the mobile phone number is not set in on-premises Active Directory, MFA will still try to use the mobile phone number, but nothing will happen as shown in the following screenshot:

we are having trouble verifying your account

Since there’s no mobile phone number to use, and no option to add this anymore directly by the user you’re stuck here (until the mobile phone number is added to on-premises Active Directory of course).

Note. If you want to enable MFA using PowerShell, you can use the following commands (and maybe combine them with the commands mentioned earlier):

$Strong = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$Strong.RelyingParty = "*"
$Strong.State = "Enabled"
$MFA = @($Strong)
Set-MsolUser -UserPrincipalName j.smith@exchangelabs.nl -StrongAuthenticationRequirements $MFA

More information

Implement Azure AD two-factor authentication for users

Recently one of my customers had a user’s account compromised. Because the user had a weak password (name of the local soccer team followed by a sequential number) his account was compromised using a password spray attack.

One way (of many) to avoid this is to use multi-factor authentication (MFA). Besides a regular username and password, MFA uses another authentication option, like a text message, an app on your mobile device or an ‘app password’ when the other two options cannot be used for some reason.

Note. MFA is available in three versions. There’s an MFA for admin accounts (MFA for admin accounts), there’s a full version as part of the Azure AD Premium subscription and there’s a lightweight version part of all Office 365 business subscriptions called the Multi-Factor Authentication for Office 365. This version can only be used with Office 365 services and is the one I used for this blog.

MFA Requirements

Before you start with implementing MFA in your environment, make sure your Office 365 tenant and your devices meet the following criteria.

Office 2016 clients support MFA natively using Active Directory Authentication Library (ADAL), the same is true for browsers. Not all Office 365 tenants have ADAL functionality enabled by default, especially the older tenants have not. To check if your tenants support this, open the Exchange Management Shell for Exchange Online and enter the following command:

Get-OrganizationConfig | Format-Table name, *OAuth*

If it returns False as shown in the screenshot below (I have an older tenant) you can use the following command to enable it on an organization level:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

OAuth2ClientProfileEnabled

The same should is true for Skype for Business Online clients. To check the ADAL support in your tenant, open a Skype for Business Online PowerShell command and execute the following command:

Get-CsOAuthConfiguration | select *client*

If it’s not enabled (as shown in the following screenshot) you can use the following command to enable it:

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

Set-CsOAuthConfiguration

For older apps, or apps that do not support MFA through ADAL, you can use an AppPassword. This is a special password, especially for the device you work on. You can only use the AppPassword on this specific device, and not on any other device. For other devices you need to have an additional AppPassword. An AppPassword is created the first time you use MFA on a device which will be shown later in this blog.

For mobile device I strongly recommend installing the Microsoft Authenticator to help you make authentication life a bit easier. The MFA information is stored on this specific device and is only available on this specific machine. The Microsoft Authenticator is available via the App Store on your device.

Enable MFA

To enable MFA for cloud accounts, open the Microsoft Online Portal (https://portal.office.com) and logon using the tenant admin account. Select Active Users, but before you select any user click on the More drop-down box and select Multifactor Authentication Setup as shown in the following screenshot:

Enable Azure MFA

In the next window, select the user you want MFA to enable for and click enable in the right pane. In the confirmation box click enable multi-factor auth.

In the same Window you can also change the service settings as shown below:

service settings

In the service settings, you can change variables like whether or not to have users create AppPasswords, what authentication options can be used and the timeframe to remember MFA authentications:

allow users to create app passwords

Make sure the Allow users to create app passwords to sign in to non-browser apps radio button is checked. At the same time have a look at the Allow users to remember multi-factor authentication on devices they trust option. Using this option, you can set the number of days before the user has to use MFA again for authentication. In the mean time the device is trusted and MFA is not needed.

Using MFA on your clients

After enabling MFA and you logon to for example OWA an additional pop-up is presented where additional information is requested. The mobile phone number is already in Active Directory and thus prepopulated, and a text message is sent to this number.

30 days OWA

After entering the validation code you are officially logged on. The last step is that an AppPassword is presented, you can use this AppPassword on this device for application that do not support the Microsoft MFA (through ADAL).

When Outlook 2016 is started an additional pop-up is shown where the validation code has to be entered. Since the MFA is remembered for 30 days you won’t see this again the upcoming 4 weeks (and two days 😊).

The same is true for OneDrive for Business and Skype for Business clients, they need to authenticate as well. My work laptop is Azure AD joined, and the advantage here is that I only need to logon once, and need to enter the SMS authentication only once since both tokens are stored on the device.

When enabling MFA as shown below it is enforced on mobile device as well. I have an iPhone with iOS 12.2 and this supports MFA natively. The next time the device needs to authenticate (can take some time after enabling MFA) a validation code is sent to the device. This can be a bit challenging since you need to enter this code on the device itself. The Microsoft Authenticator (or any authenticator) can help you here, especially if you have multiple profiles with multiple (MFA enabled) mailboxes.

The next 30 days (or whatever timeframe you’ve entered) you won’t get the MFA validation challenge, unless you change the password, then the MFA is triggered, and you need to authenticate again. Remember that the token is stored on the local device, so if you want to check your email on another device you have a authenticate using MFA on that device as well. And this is what will frustrate the bad guys in Nigeria (screenshot below shows where out attacker was hiding) since they don’t have access to your device, so even with a weak password (still not recommended!) you should be much safer.

Nigeria-attack

Summary

You can use Multi Factor Authentication as an additional measure against hackers that want to use user credentials to access your environment. Since an additional authentication method is needed, it is much more difficult to get access to your environment for the bad guys. Since they don’t have access to the mobile device it’s hardly impossible to misuse the mailbox.

The next logical step would be to implement a password less authentication, but that’s for a future blog 😊

More information