Tag Archives: authentication

Security

The federation server proxy configuration could not be updated with the latest configuration on the federation service

Leave a comment

After the latest Windows Updates (June 2022) I could not logon to Office 365 using a federated domain (Microsoft Teams in particular, the mailboxes are in Exchange 2019 for this domain), regular domains did not experience any issues.

Trying the regular ADFS URLs did not help, the site was not available:

When checking the WAP server I noticed the WAP service was not running and was not willing to start. At the same time, EventID 224 was logged in the eventlog with the “The federation server proxy configuration could not be updated with the latest configuration on the federation service” error messages as shown in the following screenshot:

Especially the additional data reveals a lot:

Retrieval of proxy configuration data from the Federation Server using trust certificate with thumbprint ‘76426A7DB45871F25A7BD5D883F2C5196B82E0DA’ failed with status code ‘Unauthorized’. The remote server returned an error: (401) Unauthorized.

At the same time, Event ID 276 is logged on the internal ADFS Server:

Obviously, the trust between the proxy server and the ADFS server is broken (it has been some time when I look at the timestamps, this happens in a test environment 😊) so the trust relationship needs to be re-established.

This can be done using the wizard in the Remote Access Management Console:

If you get a warning message like “Web Application Proxy could not connect to the AD FS configuration storage and could not load the configuration” you must change the ProxyConfigurationStatus in the registry (HKLM\Software\Microsoft\ADFS) from “2” to “1” as shown in the following screenshot.

Follow the wizard, select the appropriate certificate, check the changes and click the Configure button as shown in the following two screenshots:

When you check the eventlog, you’ll see Event ID 252 with the configuration changes:

And you can see that the ADFS Proxy server can authenticate successfully:

The server is now fully functional again.

Office365

Microsoft disables basic authentication in Office 365

1 Comment

I already wrote about Office 365 and Basic Authentication in two earlier blogposts:

The last update from Microsoft regarding basic authentication is published in June 2021:

https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-june-2021-update/ba-p/2454827

Microsoft has announced that it starts to disable basic authentication for customers that do not use basic authentication (for new Office 365 basic authentication is disabled by default).

I have disabled basic authentication is my tenant long ago and last week I got an email from Microsoft (MC274505, which can also be found in the admin portal) announcing basic authentication will be disabled in my tenant:

“We’re making some changes to improve the security of your tenant. We announced in 2019 we would be retiring Basic Authentication for legacy protocols and in early 2021 we announced we would begin to retire Basic Authentication for protocols not being used in tenants.

30 days from today we’re going to turn off Basic Authentication for POP3, IMAP4, Remote PowerShell, Exchange Web Services, Offline Address Book, MAPI, RPC and Exchange ActiveSync protocol in your tenant, and will also disable SMTP AUTH completely.

Note: Based on our telemetry, no users in your tenant are currently using Basic Authentication with those protocols and so we expect there to be no impact to you.”

If disabling basic authentication causes issues for your tenant, you can always re-enable basic authentication as outlined in the Microsoft link in the beginning of this blogpost. But please remember that basic authentication will be disabled permanently some day!

Azure AD, Exchange, Exchange Hybrid

Configure OAuth authentication in Exchange 2016

39 Comments

As long as I can remember the Hybrid Configuration Wizard finishes successfully, and itgenerates the error about the OAuth portion of the hybrid configuration.

Configure Intra-Organization Connector

HCW8064 – The HCW has completed, but was not able to perform the OAuth portion of your Hybrid configuration. If you need features that rely on OAuth, you can try running the HCW again or manually configure OAuth using these manual steps.

The Learn more option redirects to the Microsoft page Configure OAuth authentication between Exchange and Exchange Online organizations. I used that article for the PowerShell commands in this blogpost.

OAuth is used cross-premises to logon to other services, on behalf of the user. So, if you are logged on to some Microsoft service, this service can use OAuth to access services in Exchange on-premises and vice versa.

Example of these cross-premises services are:

  • Message Records Management (MRM).
  • Exchange in-place eDiscovery.
  • Exchange in-place Archiving.
  • Teams calendaring.

The HCW can configure Azure Active Directory for OAuth authentication, it can create the IntraOrganizationConnectors, but it cannot export and import the (self-signed) certificate on the Exchange server, nor can it (or does it) create the authorization server objects in Active Directory. So, time to test, guided by the Microsoft article and write down my experiences.

Note. This only works for Exchange 2013 and higher, I have been working on this in a mixed Exchange 2016 and Exchange 2019 environment.

Configuring OAuth between Office 365 and Exchange Online involve a number of steps.

Create Authorization server objects in Exchange on-premises

To create the authorization server objects in your on-premises environment enter the following commands in the Exchange Management Shell.

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl https://login.windows.net/contoso.com/federationmetadata/2007-06/federationmetadata.xml

Your verified domain contoso.com (in the command) should be something like exchangelabs.nl, and not <your tenant name> as outlined in the Microsoft article.

New-AuthServer

Enable the partner application for use with Exchange Online

The partner application was created in the previous step (the first command) and this should be enabled. Do this using the following command in Exchange Management Shell (on-premises):

Get-PartnerApplication | ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true

Export the Exchange authorization certificate

Authentication cross-premises is using certificates, so the on-premises certificate needs to be exported to Azure Active Directory. In case you were wondering where the CN=Microsoft Exchange Server Auth Certificate certificate was coming from when running the Get-ExchangeCertificate command in Exchange Management Shell, here you go.

Use the following PowerShell commands and store them in a PowerShell script called ExportAuthCert.ps1 or something and run it. This should export the OAuth certificate to a file called OAuthCert.cer.

$ThumbPrint = (Get-AuthConfig).CurrentCertificateThumbprint
If((Test-Path $ENV:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
md $ENV:SYSTEMDRIVE\OAuthConfig
}
CD $ENV:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | ?{$_.ThumbPrint -Match $ThumbPrint}
$CertType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$CertBytes = $oAuthCert.Export($CertType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $CertBytes)

ExportAuthCert

Note. The Export-ExchangeCertificate command doesn’t work in this scenario since the self-signed certificate isn’t exportable.

Import the Exchange authorization certificate into Azure AD

The next step is to import the OAuthCert.cer certificate into Azure AD. Connect to the Microsoft Online service (Connect-MSOLService, if you don’t have this installed you can use the Install-Module MSOnline command) and run the following commands when connected:

$Cred = Get-Credential
Connect-MSOLService -Credential $Cred
$CertFile = "$ENV:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
$objFSO = New-Object -ComObject Scripting.FileSystemObject
$CertFile = $objFSO.GetAbsolutePathName($CertFile)
$CER = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$CER.Import($CertFile)
$binCert = $cer.GetRawCertData()
$CredValue = [System.Convert]::ToBase64String($binCert)
$ServiceName = "00000002-0000-0ff1-ce00-000000000000"
$P = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
New-MsolServicePrincipalCredential -AppPrincipalId $P.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue

This will import the self-signed certificate from the Exchange server into Azure AD so it can be used for mutual authentication.

I did not run the commands mentioned above on my Exchange server but on my Azure AD Connect server since the MSOL module was loaded on that server. For importing the certificate file I had to use the following command accessing the certificate file (instead of the $ENV:System variable):

$CertFile = "\\AMS-EXCH01\C$\OAuthConfig\OAuthCert.cer"

Register endpoints in Azure Active Directory

The last step is to register the endpoints of your on-premises Exchange environment into Azure Active Directory. You can use the following commands to register the endpoints:

$ServiceName = "00000002-0000-0ff1-ce00-000000000000";
$x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
$x.ServicePrincipalnames.Add("https://webmail.exchangeserver.com/");
$x.ServicePrincipalnames.Add("https://autodiscover.exchangeserver.com/");
Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;

Instead of webmail.exchangeserver.com and Autodiscover.exchangeserver.com you must use your own local FQDNs of the Exchange server (shown below in the verification screenshot).

You can use the the following command to check if this was configured correctly.

Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

As shown in the following screenshot:

Register Endpoints

Note. Over the years I have run the HCW several times. Domains have been added, but not (automatically) deleted in Azure Active Directory.

IntraOrganizationConnectors and AvailabilityAddressSpace

The Hybrid Configuration Wizard created the IntraOrganizationConnectors (both in Exchange 2016 as well as Exchange Online) and configured the AvailabilityAddressSpace. There’s no need to create these, but you have to check them using the Get-IntraOrganizationConnector and the Get-AvailabilityAddressSpace commands)

Verify the OAuth configuration

To verify the OAuth configuration you can use the Test-OAuthConnectivity command. You must do this on the on-premises Exchange server and in Exchange Online.

On the on-premises Exchange server use the Exchange Online Uri and a mailbox on-premises:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox onprem-user@exchangeserver.com -Verbose | Format-List

In Exchange Online, use the Exchange on-premises Uri with a mailbox in Exchange Online:

Test-OAuthConnectivity -Service EWS -TargetUri https://webmail.exchangeserver.com/metadata/json/1 -Mailbox Online-User@exchangeserver.com -Verbose | Format-List

The output is an extended list, but in the end you should see ResultType: Success and IsValid:True on your console:

Test-OAuthConnectivity

You have now configured the OAuth between Exchange Online and Exchange On-Premises.

 

Azure AD, Office365

Basic Authentication in Office 365 Part I

2 Comments

 

Update. Microsoft has changed their plans due to the Covid-19 crisis going on at the moment. Support for Basic Authentication in Exchange Online has been postponed to the second half of 2021 according to their blogpost on Basic Authentication and Exchange Online – April 2020 Update.

There are a few things to be aware of. For new tenants, Basic Authentication is already turned off, for older tenants it is still turned on. However, if Basic Authentication has not been used in a tenant it will be turned off as well. This will start upcoming October.

Microsoft will stop support for basic authentication in October 2020 as outlined in the following blogpost: Basic Auth and Exchange Online – February 2020 Update. By doing this Microsoft increases security in (especially) Exchange Online, since basic authentication is a perfect attack vector for malicious users.

But what does it mean? Clients that use Exchange Web Services (EWS), ActiveSync, PowerShell, POP3 and IMAP4 and authenticate using basic authentication will stop working. Which clients are we talking about? Basic authentication only stops for Exchange Online and not for Exchange on-premises, but what happens when you are using a hybrid scenario? Of using Outlook for iOS in combination with an on-premises mailbox.

In this blogpost I’ll try to dive a bit deeper into authentication and explain what is going to happen.

Basic Authentication

Basic Authentication is one of the oldest ways of authenticating in any web application. You access an application, a dialog box is presented, you enter your credentials and the credentials are sent (in clear text) across the wire. To improve security typically an SSL connection is used, so the connection between the client and the server is encrypted.

For Exchange Online this means the (Outlook) client sends it credentials in clear text to Exchange Online, and Exchange Online authenticates against Azure AD as shown in the following screenshot:

When using ADFS, basic authentication is not very different. The client authenticates and sends the credentials in clear text to Exchange Online, and Exchange Online takes care of the remaining communication using ADFS and the on-premises Domain Controllers (step 2 and 3 in the following screenshot):

Important to note is that the client here still use basic authentication.

So what clients are using basic authentication? Outlook 2010 is the most common, but also lots of ActiveSync clients, POP3 and IMAP4 clients, PowerShell and Exchange Web Services (scripts and tools!) are still using basic authentication.

I leave it up to your imagination what will happen when Microsoft stops support for basic authentication (step 1 in the screenshots above) this October!

Modern Authentication

Modern authentication is a token-based authentication mechanism and as such it has similarities with federation services. On IT Dev Connections 2017 in San Francisco I did a presentation on this subject. The following screenshot is an animated slide from the presentation showing the authentication flow between a client, Exchange Online, Azure AD and the on-premises Domain Controller:

Modern Authentication is based on the OAuth2 framework. When using OAuth2, you grant permissions to an application (‘consent’) to contact the server on your behalf. The client contacts the server the first time and you enter your credentials in a web frame, this is a server-based web frame and when the credentials are entered two tokens are generated:

  • Access token, which is used to access various services.
  • Refresh token, which is used to renew the access token when it is about to expire.

This is shown in the following image:

Source: Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow.

The access token is constantly renewed (and thus no need to re-authenticate manually) until it cannot be renewed, for example when the password expires, the account is blocked (the access token is revoked) or when a Conditional Access policy can no longer be applied. In all these scenarios access to the service is denied.

Outlook 2013 and higher support Modern Authentication. In Outlook 2013 you had to set some registry keys, but in Outlook 2016 and higher it is enabled by default.

The way to identify if you are using modern authentication is the HTML based login screen which look like this:

While the basic authentication (in Exchange 2016, but similar in Outlook 2010) looks like:

Another way to identify Modern Authentication is to use the connection status in Outlook:

When you see ‘Bearer’ (coming from OAuth bearer token) Outlook is using Modern Authentication, if you see ‘Clear’ then basic authentication is used by Outlook.

Summary

In this first part I have tried to explain the difference between basic authentication and modern authentication, how modern authentication works and how to identify which authentication method your Outlook client is using.

In my next blog (Part II) I will explain more about how to monitor basic authentication and how to start testing what happens when disabling basic authentication.

Office365

Implement Azure AD two-factor authentication for users

Leave a comment

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