Tag Archives: Azure AD

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 II

Leave a comment
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.

In my previous blogpost I explained more about basic and modern authentication, how they work and how to identify which method your outlook client is using. In this blogpost I will explain more about monitoring basic authentication to find out which clients are currently still using basic authentication in your Office 365 environment. I will continue with how to disable basic authentication and how to test what might happen.

Monitoring Basic Authentication

In my previous blogpost I explained a bit more about basic authentication and how to identify it, and the working of modern authentication.

The next step is to identify how many users and application are actually using basic authentication in your Office 365 environment. After all, these are the users that are impacted when Microsoft stops basic authentication.

To identify this, logon to the Azure Active Directory Portal (https://aad.portal.azure.com) and select sign-ins (under Monitoring). There you will see an overview of all sign-ins in Azure AD, successful and failed, for all clients, all services and all locations. An example is shown in the following screenshot (click to enlarge):

This shows all logins in Azure AD, for all aplications and services, failed and successful. You can use the Add Filters button to narrow down the information, in this blogpost to show only information regarding Basic Authentication.

To do this, click Add Filter | Select Client App | Click Apply

Click on “Client App: None Selected” and select all options except Browser and Mobile Apps and Desktop Clients as shown in the following screenshot (click to enlarge):

Modern Authentication Clients

Note. Updated the screenshot on April 6, 2020. Microsoft made a nice GUI enhancement here to easily identify different clients (modern vs legacy).

Now an overview will be shown of all basic authentication attempts in your environment. When you select one entry it will show additional details, including the client application, the username and the the user agent (which identifies the client app) as shown in the following screenshot (click to enlarge):

Another interesting thing is that you can identify where all failed basic authentication attempts are coming from. Add a filter Status | Failure and you will see only failed attempts. Some are legitimate (typo when entering password) but most of them are just brute force attacks. The following screenshot shows attempts coming from Russia, Thailand and New Caledonia, located where we don’t have offices. You can also see that the attempt is coming from a script (User agent CBAInPROD) and that it’s using IMAP4 (which is disabled for all mailboxes). This is one reason why you want to disable basic authentication in your tenant. Click to enlarge:

This is an easy way to identify mobile clients that use ActiveSync as a protocol and thus are using basic authentication. Apple iOS native mail client support OAuth2 since iOS11, so all recent iPhones are using modern authentication. For the Android native mail client things are different. The native Gmail client support OAuth2 but cannot be used of course with Office 365. Most other mail clients do not support OAuth2 yet, so these are using basic authentication and will run into issues when Microsoft stops basic authentication. In other words, these clients will stop working. Change the Client App filter to Exchange ActiveSync only and remove the Status | Failure filter. It will show a list of mobile users that use basic authentication as shown in the following screenshot (username is removed for privacy reasons) (click to enlarge):

Note. Outlook for iOS and Outlook for Android are using OAth2 so these will continue to work.

So, using the filtering options on the sign-in page in the Azure AD portal you can identify which clients are still using basic authentication when accessing Office 365 services (and thus which clients are impacted when basic authentication is stopped).

Disabling basic authentication

It is possible to disable basic authentication in your Office 365 by creating an Authentication Policy and apply this policy to users. Once applied they can no longer use basic authentication to logon to any Office 365 service. To create a new Authentication Policy use the following command in Exchange Online PowerShell:

[PS] C:\> New-AuthenticationPolicy -Name “Block Basic Authentication”

To add a user to the policy and effectively block basic authentication for this user you can use the following command in Exchange Online PowerShell:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication”

It will take up to 24 hours before this policy is effective. To take the policy effect (almost immediately, or at least within 30 minutes) you can use the following command:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication” -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

To remove a user from an authentication policy you can use $Null for the authentication policy:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy $Null

When you have a number of users added to this authentication policy you can start testing with various clients and create a table with clients and scenarios, like the table below:

Client Results
Office 2010 Stops working (keeps asking for password)
Office 2013/2016 Continues to work (was already using Modern Authentication)
Outlook 2010 on-premises mailbox, cross-premises free/busy Continues to work, but need further investigation (note 1)
Outlook 2013/2016 on-premises mailbox, cross-premises free/busy Continues to work
iPhone 8, iOS13, native mailclient Continues to work
iPhone 8, iOS13, Outlook for iOS Continues to work
Samsung A10, Android 9, native Email client 6.1.11.6 Stops working
Samsung A10, Android 9, AquaMail (by MobiSystems, supports OAuth) Continues to work (note 2)
Samsung A10, Android 9, Outlook for Android Continues to work
Exchange Online PowerShell New-PSSession Stops working (note 3)
Exchange Online PowerShell module Continues to work
Exchange PowerShell V2 Continues to work
POP3 Clients TBD
IMAP4 Clients TBD

Note 1. In this scenario an Outlook client is using an on-premises mailbox but tries to retrieve free/busy information from a mailbox that’s in Exchange Online. Both accounts have basic authentication disabled in Azure AD.

Note 2. The native mailclient in Android 9 (on my Samsung A10) only supports basic authentication. This is not a device limitation but an application limitation. AquaMail (from MobiSystems) for example does support OAuth and keeps working when basic authentication is disabled. AquaMail however is not a free application but a subscription based application.

Note 3. It is possible to connect to Exchange Online as shown in line 9 of the table using the following method:

$ExCred = Get-Credential TenantAdminAccount
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $ExCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

This is using basic authentication and will stop working. However, you should not use this way of working anyway because it does not support MFA, which is a recommended best practice for admin accounts! For more information please check Multi Factor Authentication MFA in Office 365 for admin accounts.

Summary

In the previous two blogposts I tried to explain a bit more about basic and modern authentication, and what might happen when Microsoft ends support for basic authentication in Exchange Online next October.

For sure, things will break when connecting to Exchange Online. The most obvious is Outlook 2010 which won’t connect anymore. Native mobile clients that do not support oAuth2 (common in Android mail apps, but also older iPhones) stop working too. If you don’t act now you will be in a lot of trouble when Microsoft makes the change.

For now, start testing using the options I explained in this second blogpost. Create your own list of apps and services that use basic authentication and start testing with an authentication policy that blocks basic authentication. That’s the only way to prepare for this major (mega major) upcoming change. But in the end, we will all benefit from a security point of view.

More information

Office365

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

5 Comments

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

Office365

Block creation of Office 365 Groups

1 Comment

I’m an old school IT guy, in my world provisioning is done via the IT department or via a provisioning tool. What I don’t want is that regular users create all kinds of objects in my environment, whether it be Active Directory, Azure Active Directory or Office 365.

In Office 365 everything is different, multiple services (Outlook, Teams, Planner, SharePoint, PowerBI and others) are using Office 365 Groups under the hood. So, when users create a new plan in Planner or a new team in Teams, they also create an Office 365 Group in Azure Active Directory.

I’m currently working in a 12,000-user environment, and the last thing I want to happen is 12,000 users randomly creating all kinds of groups, ending up in a total mess where nobody can find information and where it is impossible to delete anything without hurting other people.

The solution for this is to assign the creation of new Office 365 to a security group in Azure Active Directory (this can be a cloud object or a synchronized object). To create a new security group in Azure Active Directory you can use the following PowerShell command:

New-AzureADGroup -DisplayName "O365 Group Creators" -SecurityEnabled:$True -MailEnabled:$False -MailNickName "Nothing"

New-AzureADGroup

Note. It is also possible to create a security group in the Azure AD Portal.

The next step is to assign the permission to create Office 365 Groups to this new security group. This can only be achieved using PowerShell and the Azure AD Preview Module, using the following script:

$GroupName = "O365 Group Creators"
$AllowGroupCreation = "False"
Connect-AzureAD
$settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
if(!$settingsObjectID)
{
  $template = Get-AzureADDirectorySettingTemplate | Where-object {$_.displayname -eq "group.unified"}
  $settingsCopy = $template.CreateDirectorySetting()
  New-AzureADDirectorySetting -DirectorySetting $settingsCopy
  $settingsObjectID = (Get-AzureADDirectorySetting | Where-object -Property Displayname -Value "Group.Unified" -EQ).id
}
$settingsCopy = Get-AzureADDirectorySetting -Id $settingsObjectID
$settingsCopy["EnableGroupCreation"] = $AllowGroupCreation
if($GroupName)
{
  $settingsCopy["GroupCreationAllowedGroupId"] = (Get-AzureADGroup -SearchString $GroupName).objectid
}
Set-AzureADDirectorySetting -Id $settingsObjectID -DirectorySetting $settingsCopy
(Get-AzureADDirectorySetting -Id $settingsObjectID).Values

When you run this script, you will see a similar output:

GroupCreators

The first box corresponds to the objectID of the security group we’ve created in the first step, just compare with the ObjectID shown in the first screenshot.

The second box shows $false for the EnableGroupCreation property, indicating no other groups are allowed to create Office 365 Groups.

All members of the security group we just created are allowed to create Office 365 groups. There are some exceptions though, Exchange admins, SharePoint admins, Teams admins and User Management admins are by default allowed to create Office 365 groups as well, but typically these are not regular users.

This way you can control who is able to create Office 365 Groups in your environment, and make sure group creation doesn’t explode in your tenant.

More information

Office365

Office 365 Group Based Licensing

4 Comments

If you have a smaller organization and you want to assign Office 365 licenses that’s no big deal. Open the user properties in the Microsoft Online Portal and assign the proper license. If needed you can assign only specific services without too much hassle. Besides using the Portal it is also possible to use PowerShell to assign licenses as discussed in an old blog: https://jaapwesselius.com/2014/09/04/assign-office-365-license-via-powershell/

For larger organizations this can be cumbersome and prone to error. Also, when using a dedicated provisioning solution it can be tricky. An interesting solution is to use Group based licensing. You can assign Office 365 licenses to a security group and when a user is added to this group, the user automatically gets the assigned licenses.

In this example we’re going to implement Group based licensing. First we are going to create a baseline where only the basic features of Office 365 E3 are implemented. Next we are going to create another option where additional features are added.

  • Labs_O365_E3_Base
  • Labs_O365_E3_TeamsAndPlanner

License Security Group Active Directory

After synchronization these groups will show up in Azure Active Directory:

License Security Group Azure Active Directory

The next step is to assign the licenses to these security groups.

In the Azure Portal, select Azure Active Directory | Licenses | Office 365 E3 and click + Assign. In the Users and Groups box select the first group (Labs_O365_E3_Base in this example) and in the Assignment Options box select the options you want to assign to this group:

License Options

Use the same steps to assign additional options to the second group:

additional license options

When you create a new user in Active Directory and add this user to the base security group, you’ll see that the user will receive only the licenses assigned to the group. If you want to assign more license options, just add the user to the additional group. This way you are very flexible in assigning licenses, and chances on errors are minimized.

Note. You can assign licenses directly on the user object or using security groups, it is not possible to combine both. So, if you use groups to assign licenses it is not possible to add additional licenses directly on the users object in the Office 365 Portal.

More information