Category Archives: Office365

Office365

Implementing Active Directory Federation Services step-by-step

Leave a comment

In 2013 I installed my first ADFS environment and I was pretty impressed. Several other deployments followed and I always wanted to blog about it, but it never happened. A good way to start the new year, approx. 7 years after I deployed my first ADFS environment here’s my blog about implemeting ADFS 😊.

And… Early 2022 I had to install another ADFS environment, this time running on Windows 2022. It is not very different than Windows 2019 or Windows 2016 but I have changed this blogpost slightly to reflect Windows 2022 ADFS.

I am not going to discuss pros and cons of password hash synchronization, Pass-through Authentication (PTA) or 3rd party solutions like Octa. Neither am I going to discuss whether you should implement ADFS or another solution. I just see a lot of customers using password hash synchronization and looking into other scenarios where authentication takes place in-house (for all kind of reasons). In this blogpost I will show you in a step-by-step manner how to deploy a federation infrastructure based on ADFS.

In Office 365 there are multiple ways for users to authenticate, and this is related to the type of identity being used:

  • Cloud Identity – is created in the cloud, password lives in the cloud and user authenticates in the cloud.
  • Synced Identity – is create in on-premises Active Directory and is synchronized to the cloud, including its password (most of the times). User authenticates in the cloud with on-premises password.
  • Federated Identity – is created in on-premises Active Directory and is synchronized to the cloud, sometimes including its password (recommended for disaster recovery). User authenticates against on-premises Domain Controllers using federation infrastructure (ADFS).

Active Directory Federation Services

In a federated environment when you try to logon to a cloud service (in Office 365 this can be SharePoint, Teams, Exchange, OneDrive, the Microsoft Portal) an authentication request is presented. Instead of entering a password that can be authenticated by an Azure AD Domain Controller, the request is redirected to an on-premises federation server. This service is called the Security Token Service or STS. The STS in an Active Directory environment is implemented by means of an ADFS instance running on a Windows 2022 server in the DMZ. This is the Web Application Proxy or WAP server. Common names for this server are sts.contoso.com, adfs.contoso.com or federation.contoso.com.

The authentication request is proxied to the internal ADFS server, which hands over the request to an Active Directory Domain Controller. Once authenticated, the ADFS server uses the STS to return a SAML token which authenticates the user in the Office 365 service.

For this to work you need an Azure AD Connect server which synchronized the accounts in Active Directory to Azure Active Directory. This is not different from a password hash synchronization solution. Then you need an ADFS solution on-premises which handles the requests from Office 365. The last thing you need is a domain in Azure AD that’s configured as a federated domain, where a regular domain is configured as a managed domain.

This is show in the following figure:

I assume that you already have configured your Office 365 tenant and that Azure AD is already up-and-running and you have synced identities in your Office 365 environment. At this point they can be configured with mailboxes, that’s not important for the remainder of this blogpost.

My WAP server is a stand-alone Windows 2022 server (in the DMZ) named ams-sts01.exchangelabs.nl. It has a Digicert certificate with the federation.exchangelabs.nl as the Common Name. It has an internal IP address and an external IP address. It can resolve IP addresses of internal servers (be aware that federation.exchangelabs.nl should resolve to the internal ADFS server) and is externally only accessible on port 443.

The internal ADFS server is a domain-joined Windows 2022 server with only an internal IP address (of course) named AMS-ADFS01.labs.local. It has the same SSL certificate as the WAP server (federation.exchangelabs.nl). The WAP server should be able to reach this server on port 443.

Building the infrastructure

Building the ADFS infrastructure consists of several steps:

  • Deploying the first ADFS server of an ADFS farm (Configuration of the first ADFS server is part of the installation process).
  • Deploying additional servers in the ADFS farm (not in this blogpost).
  • Deploying the first WAP server in the DMZ.
  • Configure te first WAP server.
  • Deploying additional servers in the DMZ (not in this blogpost).

I will discuss these steps in the following sections.

Deploying the first federation server

The first step is to deploy the internal ADFS server. After installing and patching the Windows 2022 server this you can use Server Manager to install the ADFS server role. Open Server Manager, select local server, click Manage and select Add Roles and Features.

In the Add Roles and Features wizard, click Role-Based or feature-based installation, select the server you want to install the ADFS role and check the Active Directory Federation Services checkbox. Leave the select features options default and finish the wizard. The ADFS Role will now be installed.

When the installation has finished, click on configure the federation service on this server to start the ADFS configuration.

Create the first federation server in a federation farm

Specify an account with sufficient privileges to perform the ADFS configuration. Typically, a domain administrator account will do. When needed, select an alternative account, otherwise click Next to continue.

You can import the SSL certificate from a PFX file, or if you have imported the SSL certificate during installation of the Windows 2022 server you can use the drop-down box to select it. Enter a federation service name, this is the name that’s visible on the ADFS logon page after installation, so you should use a name that makes sense.

ADFS Service Properties

The following step is to enter a service account that’s used by the ADFS service. You can manually create one, or use a group managed service account. This has the advantage of changing its password automatically, so I recommend using this.

ADFS Group Managed Service Account

Next is the selection of the database where the configuration data is stored. This can be a Windows Internal Database or a SQL database. I will skip this screenshot.
The last step is to review the configuration options:

ADFS Review Options

When the review options are ok, you can click Next and a prerequisite check is performed.

ADFS Prerequisite checks

When all prerequisites are installed and configured correctly you can click Configure and the installation and configuration of the first ADFS server will be started. After a few minutes the installation and configuration is finished and the results are shown:

ADFS this server was configured successfully

At this moment I don’t worry about the warning messages. Click Close and reboot the server as requested.

On the internal DNS server, create an A record for your federation server (federation.exchangelabs.nl) and point it to your internal ADFS server. Also create a CNAME record for enterpriseregistration, and use the FQDN of your ADFS server (federation.contoso.com).

When the ADFS server is rebooted and the DNS record is in place you can use a URL similar to this one (https://federation.exchangelabs.nl/adfs/fs/federationserverservice.asmx) to check the federation service on your ADFS server. It will show an XML output similar to the following screenshot:

Check Federation Service

At this point you have successfully deployed your first ADFS server. The next step is to deploy the first WAP server.

Deploying the Proxy servers

After installing and patching the Windows 2016 server (don’t forget the SSL certificate) you can use Server Manager to install the Web Application Server as part of the Remote Access services.

Note. One of the new features in Windows 2022 is the support for TLS 1.3. I have found out the hard way that ADFS won’t work correctly with TLS 1.3 and that you have to disable this in the registry of the WAP server. For more information check my blogpost on https://jaapwesselius.com/2022/01/19/adfs-web-application-proxy-configuration-wizard-fails-with-trust-certificate-error/.

In the Add Roles and Features wizard, click Role-Based or feature-based installation, select the server you want to install the Web Application Proxy role and check the Remote Access checkbox.

Leave the select features options default, and in the Role Services window check the Web Application Proxy checkbox. In the additional features pop-up window click on Add Features and continue with the wizard to install the Web Application Proxy server.

When the WAP server software is installed, click on Open the Web Application Proxy wizard (under notifications in Server Manager).

For the federation service name use the name you are planning to use (i.e. federation.exchangelabs.nl) and enter the credentials of a local administrator on the ADFS server that was installed in the previous section.

Select the SSL certificate that was installed on the Windows 2022 server during installation (I will skip this screenshot here) and the confirmation window will be shown.

Click Configure to start the configuration of the Web Application Proxy server and after a few moments the Results window will be shown.

To check the operations status of the WAP server after the installation, open the Remote Access Management Console (under Administrative Tools), click on the server and you’ll see two green checkboxes to indicate the server is up-and-running:

You can also check the Event viewer. Under Server Roles | Active Directory Federation Services you should be able to find EventID 245, indication that the WAP server successfully retrieved its configuration settings from the internal ADFS server:

A quick external check can be to retrieve the federation metadata from your ADFS server. From an external client use a URL similar to this (https://federation.exchangelabs.nl/federationmetadata/2007-06/federationmetadata.xml) to retrieve the federation metadata. It should shown an XML output similar to the following:

ADFS Federation MetaData

Another test is to use the Idp Initiated Signon page, located on https://federation.exchangelabs.nl/adfs/ls/idpinitiatedsignon.htm. There’s one catch here, this is enabled by default in Windows 2012 R2, but not in Windows 2016. To enable it, execute the following PowerShell command on your (internal) ADFS server:

[PS] C:\> Set-AdfsProperties –EnableIdpInitiatedSignonPage $True

Now when you navigate to the IdpInitiatedSignon page you’ll see a static HTML page with a Sign In button. When you click on it you can use your credentials to sign in to your environment and you’ll see something like the following screenshot:

idp initiated signon page

Now we know the ADFS environment is working properly, and we can continue with the configuration of Azure AD and Office 365.

At this moment we’ve installed and configured a simple ADFS infrastructure into the existing on-premises Windows environment, capable of handling Office 365 authentication request. I will discuss the configuration of Office 365 (and thus Azure Active Directory) in the next blog.

Exchange Hybrid, Office365

Outlook 2010 stays offline with Exchange Online

7 Comments

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

Office365

Authenticator app for Office 365

Leave a comment

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.

Exchange, Office365

SPF and DMARC when domain is not used for email

Leave a comment

Just a quick post on SPF and DMARC when you have a domain that’s not used for email. In this scenario mail will never be sent out by any mailserver. If someone does send out email, it is most likely malicious email and can be ignored.

You can add the following records to your DNS:

SPF:

V=spf1 -all

DMARC:

v=DMARC1;p=reject;sp=reject;pct=100

Receiving mail servers that check for SPF and DMARC will see that it’s not valid and will reject the message.

 

Office365

Office 365 Message Encryption OME

8 Comments

Office 365 Message Encryption (OME) is a Microsoft solution to send mail safely, fully encryption with multiple layers of protection. Instead of sending an email to a recipient via SMTP, the message is encrypted and stored on a Microsoft viewing portal. An informational message is sent to the recipient with a one-time password which the recipient can use to logon to the viewing portal and read the (decrypted) message as shown in the following picture:

Office 365 Message Encryption Overview

To configure OME you have to enable Azure Rights Management first. To do this, open the Office 365 Admin portal and select Settings | Services & Add-ins. In the details pane select Microsoft Azure Information Protection. Click Manage Microsoft Azure Information Protection Settings as shown in the following screenshot:

Enable Azure information Protection

Click Activate and after a few moments you will see a confirmation.

Azure Rights Management is activated

If you open Exchange Online Powershell and execute Get-IRMConfiguration you will see that AzureRMS is enabled as shown in the screenshot below. Please note that the LicensingLocation is empty, this is important in subsequent steps.

Get-IRMConfiguration

According to Microsoft documentation you should now be able to test the IRM configuration using the Test-IRMConfiguration command, but this will fail with a “Failed to acquire RMS templates” error as shown in the following screenshot:

Test-IRMConfiguration Fails

The reason for this (took me some time to figure out) is that the LicensingLocation property is empty. To populate this property, we can retrieve the correct value from the Azure AD Right Management service using PowerShell. This can be installed using the Install-Module AIPService command.

After installing, open the Exchange Online PowerShell module and execute the following commands:

PS C:\> $RMSConfig = Get-AadrmConfiguration

PS C:\> $RMSConfig

PS C:\> $LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl

PS C:\> $LicenseUri

PS C:\> Set-IRMConfiguration -LicensingLocation $LicenseUri

PS C:\> Set-IRMConfiguration -InternalLicensingEnabled $true

Note. The only reason for executing the $RMSConfig and $LicenseUri commands is to check is there are any values in these variables. The output is shown in the following screenshot:

RMSConfig

When you execute the Test-IRMConfiguration command again you will see it succeeds:

Test-IRMConfiguration

So how do you know this works?

The easiest way is to use OWA. To create an additional “encrypt” button in OWA, execute the following command in the Exchange Online PowerShell window:

PS C:\> Set-IRMConfiguration -SimplifiedClientAccessEnabled $true

Now when creating a new message in OWA this button is clearly visible. Send a new message (to your own test account for example in Gmail) and click the Encrypt button. A message will appear that this message is encrypted, nice to know, the recipients cannot remove the encryption, only the sender of the message can change this. You can use the change permissions button to change it from encrypt only to do not forward or confidential.

Encrypt button in OWA

After a few second the email will appear in Gmail, but not directly. You have to open the decrypted message on the viewing portal. A one-time password can be used (which is sent to the same email address, i.e. the Gmail address we used here) or you can use the Gmail account to logon. The latter is also true if the recipient is a hotmail mailbox or even nicer, an Office 365 mailbox.

OME in Gmail

When you click Read the message it will be opened on the viewing portal.

view ome

A message is displayed again that this is an encrypted message. When you reply to the message, an encrypted message is returned to the original sender. If you have selected do not forward in the permissions drop down box earlier, the recipient does not have this option and can only reply to the message.

It also works fine in Outlook (I have tested this with Outlook 2016 Click-2-Run, still have to test other versions). If you create a new message and select Options, you can select Connect to Rights Management Server and get templates under Permissions as shown in the following screenshot:

Outlook Connect to Rights Management Server

This will retrieve the RMS templates from Exchange Online that were created earlier in this blog post. In a few seconds you will see the following options:

  • Encrypt Only
  • Do not forwards
  • Confidential
  • Confidential View Only

Outlook Set permissions on this item

When you select Encrypt Only  as shown in the following screenshot an encrypted message will be sent to the intended recipient:

Outlook Encrypt Only

From this point the behavior will be the same as with Outlook Web App as discussed earlier in this blog post.

Summary

Outlook Message Encryption as outlined in this blog post is a way to send encrypted messages to recipients. It’s not encryption in transit like TLS or S/MIME, but the encrypted message is stored on a Microsoft server. The recipient will receive an email that an encrypted message is waiting, and the recipient can logon to a special website using a one-time password (or using a Microsoft or Gmail account).

Since the RMS (Rights Management Service) templates are used it is also possible to use additional features like do not forward (the forward button is greyed out) or tag a message as confidential. This can be used in combination with transport rules to add additional features or mail flow when it comes to confidential information, functionality that’s not available when using good old email.