In-place upgrading an Active Directory Domain Controller to Windows Server build 17093 might fail

Windows Server Preview Build 17093

Last week, Microsoft announced the latest Windows Server Insider Preview build, nicknamed Build 17093, referencing its 10.0.17093.1000 version number. This Windows Server version was released to Windows Server Insiders on February 13, 2018.

 

About Windows Server Preview Build 17093

This build is a preview build of the next Semi-Annual Channel (SAC) release of Windows Server.

Microsoft uses two release channels:

  1. The Long-term Servicing Channel (LTSC)
  2. The Semi-annual Channel (SAC)

The Long-term Servicing Channel is the release channel most IT Pros are familiar with. Windows Server 2016 is Microsoft latest LTSC-released Windows Server version.

The Semi-annual Channel is the new release channel. Windows Server, version 1709 was Microsoft first SAC-release. Microsoft intends to release SAC-releases twice per year (hence the name). SAC releases differ from LTSC releases in several ways, beyond their intended shorter release schedules: SAC releases don’t have graphical interfaces and SAC releases have shorter support cycles.

Windows Server Preview Build 17093 is only available as Server Core installation and Nano Server. Windows Server Preview Build 17093 will stop working on July 2, 2018.

 

Known issue for Domain Controllers

The Known Issues section of the blogpost titled Announcing Windows Server Insider Preview Build 17093 and Project Honolulu Technical Preview 1802 by Donna Sarkar on February 3, 2018 mentions:

In-place OS upgrade: Domain Controllers

During an in-place OS upgrade, Active Directory (AD) Domain Controllers (DC) might not be upgraded correctly. Back up any AD DCs before performing an in-place OS upgrade.

 

 

Further reading

Known issues with Windows Server Build 17093
Microsoft Announces Windows Server 17093 Preview

0  

Hybrid Identity features per Active Directory Domain Services Domain Controller Operating System, Domain Functional Level, Forest Functional Level and Schema version

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations.

These components have requirements of Active Directory Domain Services (AD DS) in terms of the schema, the Windows Server versions on the Domain Controllers an organization runs, the Domain Functional Level (DFL) and the Forest Functional Level (FFL).

The requirements and the information on the features you gain when you run certain Active Directory Domain Services constellations is scattered over the Internet, so I decided to create one blogpost with all this information in seven scenarios that may depict your organization’s specific Active Directory characteristics:

  1. Everything on Windows Server 2003
  2. Using Windows Server 2008 Domain Controllers, but 2003 functional levels
  3. Everything on Windows Server 2008
  4. Everything on Windows Server 2008 R2
  5. Running the Windows Server 2012 R2 schema, and a minimum Operating Systems of Windows Server 2008 R2 on your Domain Controller, for your Domain Functional Level and Forest Functional Level
  6. Running the Windows Server 2016 schema, and a minimum Operating Systems of Windows Server 2008 R2 on your Domain Controller, for your Domain Functional Level and Forest Functional Level
  7. Running the Windows Server 2016 schema, and at least one Windows Server 2016-based Domain Controller in your environment and functional levels defined as Windows Server 2008 R2, or up.

 

Legend

In the above tables, the colors represent the inability to deploy Domain Controllers with an Operating System (on the row labeled ‘Active Directory Domain Controllers’) in red, the possibility but not necessity to deploy Domain Controllers with an Operating System, raise the Domain Functional Level or raise the Forest Functional Level in orange, and the requirement to meet to unlock certain Hybrid Identity features in green.

 

Scenario 1: Everything Windows Server 2003

Although we all know Windows Server 2003 is no longer supported unless you have an extended support contract with Microsoft, there are still organizations out there, that have Windows Server 2003-based Domain Controllers.

In this scenario, you gain the following functionality:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2

AD FS functionality you cannot use:

  • You cannot add Windows Server 2016-based AD FS Servers to an AD FS Farm running Windows Server 2012 R2.
  • You cannot use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
  • You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
  • Although you can implement Windows Server 2012 R2-based AD FS servers, you cannot deploy Workplace Join through the Device Registration Service.
  • Since you cannot implement AD FS Servers running Windows Server 2016 you cannot have the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing.
  • Since you cannot implement AD FS Servers running Windows Server 2016 you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP port 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2.

Azure AD Connect

Azure AD Connect features you can use:

  • You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.

Azure AD Connect features you cannot use:

  • You cannot use the Device Write-back feature.
  • You cannot use the Password Write-back feature, unless:
    • You add at least one Windows Server 2008-based Active Directory Domain Controller to the environment and install hotfix KB2386717 to the intended server running Azure AD Connect
    • You add at least one Windows Server 2008 R2-based Active Directory Domain Controller (or up) to the environment.
  • You cannot use a group Managed Service Account (gMSA) as the service account.
  • You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

 

Scenario 2: Windows Server 2008 Mixed

Now, many organizations have upgraded their Active Directory Domain Controllers to Windows Server 2008 in the past years. Some organizations, though, may have forgotten to also raise the Active Directory Domain Functional Level (DFL) and Active Directory Forest Functional Level (FFL).

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2
  • You can add AD FS Servers running Windows Server 2016 to Windows Server 2012 R2-based AD FS Farms, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.

AD FS functionality you cannot use:

  • You cannot use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
  • You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

  • You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
  • You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.

Azure AD Connect features you cannot use:

  • You cannot use the Device Write-back feature.
  • You cannot use a group Managed Service Account (gMSA) as the service account.
  • You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

When compared to the previous scenario, your organization effectively gains the ability to add Windows Server 2016-based AD FS Servers to existing Windows Server 2012 R2-based AD FS farms, but cannot take advantage of the Windows Server 2016 AD FS Farm Behavioral Level. In addition, you can now take advantage of Password Write-back through Azure AD Connect.

 

Scenario 3: Everything Windows Server 2008

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you are part of this scenario.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2
  • You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
  • You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).

AD FS functionality you cannot use:

  • You cannot use a group Managed Service Account (gMSA) as the AD FS service account.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

  • You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
  • You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.

Azure AD Connect features you cannot use:

  • You cannot use the Device Write-back feature.
  • You cannot use a group Managed Service Account (gMSA) as the service account.
  • You cannot use the Active Directory Recycle Bin feature. Azure AD Connect recommends this feature and will notify you when you run the Azure AD Connect wizard.

Effectively, your organization gains the ability to perform client certificate authentication when certificates are explicitly mapped to users’ accounts in Active Directory Domain Services (AD DS).

 

Scenario 4: Everything Windows Server 2008 R2

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you are part of this scenario.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2
  • You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
  • You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
  • You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.

AD FS functionality you cannot use:

  • Although you can implement AD FS Servers running Windows Server 2016, you cannot use Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

  • You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
  • You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.
  • You can use a group Managed Service Account (gMSA) as the service account.
  • You can use the Active Directory Recycle Bin feature.

Azure AD Connect features you cannot use:

  • You cannot use the Device Write-back feature.

Effectively, your organization gains the ability to use group Managed Service Accounts (gMSAs) for Active Directory Federation Services and Azure AD Connect, and benefit from the Active Directory Recycle Bin.

 

Scenario 5: The Magic of the Windows Server 2012 R2 Schema

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you can optionally upgrade the Active Directory schema to Windows Server 2012 R2.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2
  • You can add AD FS Servers running Windows Server 2016, however, you cannot setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
  • You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
  • You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.
  • You can deploy the Device Registration Service on AD FS servers running Windows Server 2012 R2.

AD FS functionality you cannot use:

  • Although you can implement AD FS Servers running Windows Server 2016, you cannot use its Workplace Join through the Device Registration Service, the built-in Azure MFA adapter, device compliance claims, Windows Hello for Business (also known as Passport for Work), per-Relying Party Trust (RPT) branding, and/or streamlined auditing. These features require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • Although you can implement AD FS Servers running Windows Server 2016, you cannot federate applications using Open ID Connect, SCIM or SAML 2.0 eGov. These protocols require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation will need 2-way trusts with the Active Directory forest where the AD FS Farm is joined to.

Web Application Proxies

Device authentication will use TCP 49443 for device authentication on Web Application Proxies running Windows Server 2012 R2 and Windows Server 2016, by default. This feature require you to upgrade the AD FS Farm Behavioral Level (FBL) to Windows Server 2016.

Azure AD Connect

Azure AD Connect features you can use:

  • You can use Azure AD Connect with Federation and Password Hash Sync as sign-in method.
  • You can use the Password Write-back feature, but you will need to install hotfix KB2386717 to the intended server running Azure AD Connect.
  • You can use a group Managed Service Account (gMSA) as the service account.
  • You can use the Active Directory Recycle Bin feature.
  • You can use the Device Write-back feature.

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to use the Device Registration Service on Windows Server 2012 R2-based AD FS Servers. Azure AD Connect offers the ability to perform Device Write-back, too.

 

Scenario 6: Unlock most features with the Windows Server 2016 Schema

When you’ve implemented Active Directory Domain Services using Windows Server 2008 as the Operating System for all Domain Controllers, the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL) and the Active Directory schema, you can optionally upgrade the Active Directory schema to Windows Server 2016.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

AD FS functionality you can use:

  • You can add AD FS Servers running AD FS 2.0 and AD FS 2.1
  • You can add AD FS Servers running Windows Server 2012 R2
  • You can add AD FS Servers running Windows Server 2016, and even setup new AD FS Farms with Windows Server 2016 AD FS Servers only.
  • You can use client certificate authentication if the certificate is explicitly mapped to a user’s account in Active Directory Domain Services (AD DS).
  • You can use a group Managed Service Account (gMSA) as the AD FS service account on Windows Server 2012 R2-based AD FS Servers and Windows Server 2016-based AD FS Servers.
  • You can deploy the Device Registration Service and use Workplace Join.
  • When your organization runs the Windows Server 2016 AD FS Farm Behavioral Level (FBL) (by either adding Windows Server 2016-based AD FS Servers to a Windows Server 2012 R2-based AD FS Farm, removing the Windows Server 2012 R2-based AD FS servers and raising the FBL, or by starting a new AD FS Farm using Windows Server 2016-based AD FS Servers, only), your organization can use the built-in Azure MFA adapter, device compliance claims, per-Relying Party Trust (RPT) branding, streamlined auditing, and/or federate applications using Open ID Connect, SCIM or SAML 2.0 eGov.
  • In multi-forest environments, Active Directory forests with user accounts in scope for federation no longer need 2-way trusts.

AD FS functionality you cannot use:

  • Although you can implement AD FS Servers running Windows Server 2016, you cannot use Windows Hello for Business (also known as Passport for Work).

Web Application Proxies

Device authentication will use TCP 443 for device authentication for AD FS Farms running the Windows Server 2016 Farm Behavioral Level (FBL) when you add the certauth.sts.domain.tld Subject Alternative Name (SAN) to the AD FS Service Communications Certificate.

Azure AD Connect

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to deploy new AD FS Farms using Windows Server 2016 with all its great features and upgrade existing Windows Server 2012 R2-based AD FS Farms to do the same. Azure AD Connect offers all its functionality.

 

Scenario 7: Unlock Windows Hello for Business with a Windows Server 2016 Domain Controller

Regardless of the Active Directory Domain Functional Level (DFL), the Active Directory Forest Functional Level (FFL), you can unlock all current Hybrid Identity features when you run the Windows Server 2016 Active Directory schema and deploy at least one Domain Controller running Windows Server 2016.

Note:
Although Windows Server 2008 R2 allows you to revert the Active Directory functional levels, when you enable the Active Directory Recycle Bin feature, it cannot be reverted back to a lower functional level.

In this scenario, the following functionality is available:

Active Directory Federation Services

You can use all of the features of Active Directory Federation Services.

Web Application Proxies

Device authentication will use TCP 443 for device authentication for AD FS Farms running the Windows Server 2016 Farm Behavioral Level (FBL) when you add the certauth.sts.domain.tld Subject Alternative Name (SAN) to the AD FS Service Communications Certificate.

Azure AD Connect

You can use all of Azure AD Connect features.

Effectively, your organization gains the ability to use Windows Hello for Business (also known as Passport for Work).

 

Concluding

While Hybrid Identity doesn’t require the most recent Active Directory functional levels, it does depend on the latest Active Directory schema.

My advice will always be to upgrade the schema to the latest version of Windows Server, whenever you extend the schema for anything else, like Exchange Server, Skype for Business or the Local Administrator Password Solution (LAPS).

When you’re running the Windows Server 2008 R2 Active Directory Functional Levels you’ll be fine, with the exception of the Windows Hello for Business feature, that requires at least one Windows Server 2016-based Domain Controller.

Resources

I’ve used these official Microsoft Documentation resources to create the lists above:

AD FS Requirements for Windows Server 2012 R2
AD FS Requirements for Windows Server 2016
Prerequisites for Azure AD Connect
Azure AD Connect: Enabling device Write-back
What’s New in AD DS: Active Directory Recycle Bin

1  

Configuring the Azure AD Connect Health Agent for AD FS on Server Core

When you get serious about security in Hybrid Identity implementations, you would opt to implement AD FS servers and Web Application Proxies as Server Core installations. However, this poses a slight problem with the Azure AD Connect Health Agent for AD FS, because at first glance, you can’t configure it on Server Core installations of Windows Server.

I have the Azure AD Connect Health Agent for AD FS working on my Server Core-based Active Directory Federation Services (AD FS) servers and my Web Application Proxies. I’ve gone back and forth and have successfully used the method below on AD FS Servers and Web Application Proxies running:

  • Server Core installations of Windows Server 2012 R2
  • Server Core installations of Windows Server 2016
  • Installations of Windows Server version 1709

Let me show you how:

 

About Azure AD Connect Health

Azure AD Connect Health helps administrators monitor and gain insights into their Hybrid Identity implementations. It enables you to maintain a reliable connection to Office 365 and Microsoft Online Services by providing monitoring capabilities for your key identity components:

  • Azure Active Directory Connect installations
  • Active Directory Federation Services (AD FS) servers
  • Web Application Proxies
  • Active Directory Domain Controllers

Azure AD Connect Health makes the key data points about these components easily accessible in the Azure AD Connect Health portal so performance monitoring, usage analysis, troubleshooting and gaining other important insights becomes easy.

Azure AD Connect Health agent for AD FS

To monitor Active Directory Federation Services (AD FS) servers
and Web Application Proxies you can install the Azure AD Connect Health agent for AD FS on these servers.

After installation, the agent needs to be configured to communicate to the Azure Active Directory tenant, that is part of the Hybrid Identity implementation. During configuration, the agent, therefore, asks for global admin credentials.

When communicating to the Azure AD Connect Health service, the Azure AD Connect Health agent for AD FS communicates to several endpoints and sets up outgoing connections, based on TCP 80, TCP443 and TCP5671.

 

Configuring the Azure AD Connect Health Agent for AD FS on Server Core

Step 1. Download the Azure AD Connect Health AD FS Agent

The first thing we need to do is get our hands on the installer for the Azure AD Connect Health Agent for AD FS. To this purpose, we perform these steps on any Windows installation:

  • Go to the Microsoft Azure Portal using your favorite browser.
  • Log on with credentials of an account in the Azure Active Directory tenant with Global Admin (Company Administrator) privileges. Perform multi-factor authentication, when prompted.
  • In the left navigation pane, click on Azure Active Directory.
  • In Azure Active Directory’s navigation pane, click on Azure AD Connect.
  • In the main pane for Azure AD Connect, click on the Quick Start tile.
  • In the new pane, in the Get Tools section, click the link Download Azure AD Connect Health Agent for AD FS.

Download the Azure AD Connect Health Agentfor AD FS from the Azure Portal (click for orginal screenshot)

  • Save the AdHealthAdfsAgentSetup.exe to an easy accessible location.

 

Step 2. Getting the installer on the Server Core installations

There are several ways to get the installer for Azure AD Connect Health Agent for AD FS onto Server Core installations. While some prefer the file share method, this is not particularly useful in scenarios where the Web Application Proxies are placed in a strictly managed perimeter network, where you’d have RDP access, at best.

There’s a little trick I use to get the files I need onto Server Core installations, making clever use of the built-in functionality of RDP and Notepad.

While you could get fooled into believing you don’t have File Explorer-like functionality on Server Core installation, Notepad actually offers this functionality as part of its File, Open dialogue screens.

I perform these steps:

  • On the Windows installation where you previously downloaded the installer for Azure AD Connect Health Agent for AD FS, select the installer by left-clicking it. Then, right-click it and select Copy from the context menu.
  • Log on to the Server Core installation using RDP with default settings, using the Remote Desktop Connection (mstsc.exe)
  • On the Server Core’s command line, type Notepad.exe.

Notepad File Open (click for original screenshot)

  • In Notepad, click on File in the menu bar, and then click Open.
  • In the Open dialogue window, select the option All Files instead of the default Text Documents (.txt) for Files of type:.
  • Navigate to a folder where you can easily access the installer from the command line. As I prefer short command lines, I usually place installers in the root of the C:\ drive.
  • Click in an empty space in the folder where you’d want to place the installer, and type Ctrl and V at the same time, to paste the installer in the location.

Notepad Paste (click for original screenshot)

  • Verify the file was pasted into the location and then click Cancel in the Open dialogue window.
  • Close Notepad.

Note:
For security purposes, disable the clipboard ability for Remote desktop sessions on the Server Core-based Web Application Proxies, when you’re done configuring.

 

Step 3. Installing the Azure AD Connect Health AD FS Agent

To start the installation of  the Azure AD Connect Health Agent for AD FS, simply run the following command on the command line of the Server Core installation:

C:\AdHealthAdfsAgentSetup.exe

Installing the Azure AD Connect Health Agent for AD FS, step 1 (click for original screenshot)

In the Azure AD Connect Health AD FS Agent window, click the Install button.

Installing the Azure AD Connect Health Agent for AD FS, step 2 (click for original screenshot)

After the Installation succeeds, click the Configure Now button.

The Azure AD Connect Health Agent for AD FS configuration will fail, stating the following error:

Register-AzureADConnectHealthAgent: The type initializer for ‘Microsoft.identityModel.Clients.ActiveDirectory.Internal.

WindowsFormsWebAuthenticationDialogBase’ threw an exception.

 

This is expected.

A log file is created. When you go through the log file, you’ll notice a line stating

Unable to load DLL ‘IEFRAME.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

 

Here is the cause of the failure. Internet Explorer is not availabile on Server Core installations and the Azure AD Connect Health Agent for AD FS tries to leverage Internet Explorer to display the login prompt for Azure Active Directory, using the Azure Active Directory Authentication Libraries (ADAL) experience.

 

Step 4. Configuring the Azure AD Connect Health AD FS Agent

Luckily, the Azure AD Connect Health Agent for AD FS provides information how to solve this situation. To solve this issue, we are advised to run the Register-AzureADConnectHealthADFSAgent PowerShell Cmdlet manually.

Now, of course, strictly running it results in the same error. Therefore, we run it slightly different, in a way that consists of two lines of PowerShell code:

$cred = Get-Credential

Register-AzureADConnectHealthADFSAgent -Credential $cred

 

After the first line of PowerShell, we are prompted for credentials. We need to enter the userPrincipalName and password for an account in Azure Active Directory with Global Admin (Company Administrator) privileges in the Azure AD Tenant and does not have multi-factor authentication enabled.

Note:
Enforcing multi-factor authentication on privileged accounts in Azure Active Directory is a best practice, and actually free for admins. However, in this case, we need to temporarily use an account without multi-factor authentication.

After the second line of PowerShell code, the Azure AD Connect Health Agent for AD FS will be successfully configured and communicating to the Azure AD Connect Health endpoints, reporting:

Agent registration completed successfully.

 

Concluding

You can get the Azure AD Connect Health Agent for AD FS working on Server Core installations.

However, you can’t configure it, when using a privileged Azure Active Directory account that has multi-factor authentication enforced.

0  

Pictures of NIC Future Edition

Raymond and me at NIC Future Edition. (picture by Andy Malone)

Last week, Crayon organized the 7th Nordic Infrastructure Conference (NIC), labeled the Future Edition. Raymond Comvalius and I presented two sessions. In this blogpost I share our pictures and most memorable moments.

On Thursday February 2, Raymond and I were scheduled for the early flight from Amsterdam Schiphol airport to Oslo Gardermoen airport. It meant we had to get out of bed early. It also meant we had front row seats to an amazing view of the moon.

View from the window of flight KL1141 to Oslo Gardermoen (click for larger photo)First row seat to the Moon (click for larger photo)

Gardermoen airport was cold and snowy. We had an uneventful, yet delayed, flight due to the snow, that caused limited capacity at the airport. Since this is our fourth visit to Oslo for NIC, we know our way around. We boarded the FlyToGet train to Oslo SentralStasjon and made our way to the Oslo Spektrum in a new record time.

Oslo Gardermoen airport (click for larger photo)Welcome to NIC (click for larger photo)

Raymond and I spent Thursday fine tuning our slides and demos. We also sat in some sessions that we found interesting and showed up at Andy Malone’s book signing at the GlassPaper booth. Of course, we also checked out the rooms for our sessions.

For diner, Raymond and I joined Andy Malone, Alexander Nikolic and John Craddock at Brugata Landhandleri, where we enjoyed some delicious lamb shanks.

Lamb shanks and a Weizener at Brugate Landhandleri (click for larger photo)

Friday morning, Raymond and I were scheduled for an 8:30 AM session on Microsoft Multi-Factor Authentication (MFA). This session was scheduled in room 8, which was one of the two suspended stages…

Raymond checking out the stage in room 8 (click for larger photo)The back of the stage for room 8, suspended about 10 meters in the air (click for larger photo)

We shared the specifics for MFA Server, Azure MFA and Office 365, as well as some real-world tips and tricks. We had a lot of fun!

Our 2PM session focused on Microsoft’s cloud offerings as an alternative to on-premises datacenters, identity and productivity.

Ray demoing before our second audience (click for larger photo)Presenting on ... Identity ;-) (click for larger photo)

At the end of the session, our audience was unanimous in their opinion if the Microsoft Cloud is ready for prime-time productivity.

After our session, we took the train back to Oslo Gardermoen airport, where we enjoyed diner in the airport lounge with Andy and Sami Laiho, before flying back to Amsterdam.

Thank you!

A big ‘Thank You!’ to all NIC attendees, sponsors, speakers and staff for making the past week such an enjoyable experience!

Will I see you in 2019? (click for larger photo)

I hope to see you all next year for NIC 2019.

0  

What’s New in Azure Active Directory for January 2018

Azure Active Directory

Azure Active Directory is Microsoft’s Identity Management-as-a-Service solution, offering seamless access, easy collaboration, efficiency in IT processes and improved security and compliance. In its Release Notes for Azure Active Directory, Microsoft communicated the following new functionality for Azure Active Directory for January 2018:

 

What’s New

New Federated Apps available in Azure AD App gallery

Service category: Enterprise Apps
Product capability: 3rd Party Integration

In January 2018, the following new apps with federation support were added in the Azure AD App gallery :

 

“Sign-in with additional risk detected”

Service category: Identity Protection
Product capability: Identity Security & Protection

While Azure AD Premium P2 provides the most detailed information about all underlying insights for detected risk events, the information is also provided to organizations with Azure AD Premium P1 licenses. For these organizations, detections that are not covered by their license appear as the risk event “Sign-in with additional risk detected”.

 

Hide Office 365 applications from end user’s access panels

Service category: My Apps
Product capability: Single Sign-On (SSO)

You can now better manage how Office 365 applications show up on your user’s access panels through a new user setting. This option is helpful for reducing the amount of apps in a user’s access panels if you prefer to only show Office apps in the Office portal. The setting is located in the User Settings and is labeled Users can only see Office 365 apps in the Office 365 portal.

 

Seamless sign into apps enabled for Password SSO directly from the app’s URL

Service category: My Apps
Product capability: Single Sign-On (SSO)

The My Apps browser extension is now available for Edge, Chrome and Firefox.
This tool gives you the My Apps single-sign on capability as a shortcut in your browser. After installing it, users will see a waffle icon in their browser that provides them quick access to apps. Additionally, login pages for Azure AD-integrated apps are recognized and mention the ability to seamlessly sign in using the browser extension.

 

What’s Deprecated

Azure AD administration experience in Azure classic portal has been retired

Service category: Azure AD
Product capability: Directory

As of January 8, 2018, the Azure AD administration experience in the Azure classic portal has been retired. This took place in conjunction with the retirement of the Azure classic portal itself. Going forward, you should use the Azure AD admin center for all your portal-based administration of Azure AD.

 

Phonefactor Web administration experience has been retired

Service category: Azure Multi-Factor Authentication
Product capability: Azure Multi-Factor Authentication

As of January 8, 2018, the PhoneFactor web portal (PFWEB) has been retired. This portal was used for the administration of MFA server, but those functions have been moved into the Azure portal at portal.azure.com.

The MFA configuration is located at: Azure Active Directory > MFA Server

 

DeprecateD Azure AD reports

Service category: Reporting
Product capability: Identity Lifecycle Management

With the general availability of the new Azure Active Directory Administration console and new APIs now available for both activity and security reports, the report APIs under “/reports” endpoint have been retired as of end of December 31, 2017.

However, two new APIs are available for retrieving Azure AD Activity Logs. The new set of APIs provide richer filtering and sorting functionality in addition to providing richer audit and sign-in activities. The data previously available through the depracted reports can now be accessed through:

  • The Azure Active Directory reporting API
  • The Identity Protection risk events API in Microsoft Graph
0  

Configuring Geo-Redundancy for AD FS on-premises with Azure Traffic Manager

Hybrid Identity

Last week, I showed you how to perform a simple Hybrid Identity implementation with AD FS on-premises. While this scenario is easy and fast to deploy, it also has a couple of downsides. One of them is the risk of ‘AD FS Unavailability’ and the inability to authenticate to cloud resources when the on-premises environment is unreachable from the Internet.

My weapon of choice to mitigate that risk is Azure Traffic Manager.

In this blog post I share how I see Azure Traffic Manager play its role in making Active Directory Federation Services (AD FS) on Windows Server 2016 and Windows Server version 1709 highly available through geo-redundancy and, thus, failing over between multiple locations if need be.

 

Introduction to Azure Traffic Manager

Traffic Manager LogoAzure Traffic Manager is a Azure-based user traffic load-balancing solution. It can direct user traffic between and/or to IP-addresses associated with endpoints for Azure Virtual Machines, Azure (cloud and app) services, and on-premises networks.

Traffic Manager uses the Domain Name System (DNS) to direct client requests to the most appropriate endpoint in its configuration, based on the traffic-routing method of your choice and the health of the endpoints. It provides automatic failover.

The four ways Azure Traffic Manager helps AD FS

Azure Traffic Manager is capable of helping make Active Directory Federation Services (AD FS) on multiple locations highly available in all of its four routing methods. Let’s look at these methods using real-life examples:

  1. Failover / Priority
    Your organization has deployed AD FS in both Azure IaaS and on-premises. Traffic Manager allows you to direct user authentication traffic from Internet-based clients to your organizations’ Azure Infrastructure-as-a-Service-based AD FS implementation, only if the on-premises AD FS implementation fails or becomes unreachable from the Internet.
  2. Performance
    Your organization has multiple offices worldwide with corresponding datacenters. Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. Azure Traffic Manager directs them to the “closest” endpoint in terms of the lowest network latency.
  3. Geographic
    Your organization has deployed AD FS in multiple Azure regions. Like the ‘Performance’ method, Traffic Manager can direct user authentication traffic from Internet-based clients to endpoints in different geographic locations. This time it’s not based on the lowest latency, but the actual geographic location.
  4. Weighted / Round-Robin
    You have multiple AD FS deployments, but they vary in compute power and bandwidth. Traffic Manager can distribute user authentication traffic from Internet-based based to any combination of Azure and non-Azure endpoints using weights your organization defines. You could use this method to direct 20% of the traffic to the on-premises AD FS implementation on your first datacenter, 20% to your other datacenter and the rest of the traffic to your organizations Azure Infrastructure-as-a-Service-based AD FS implementation.

While all four traffic manager methods have their pros and cons, my customers mainly prefer the Priority method. They chose to implement AD FS initially, because they need to be in reach of the auditing data to prove they are in control of the authentication mechanisms. The choice for on-premises AD FS comes from the wish to take advantage of the x-ms-client-ip, insidecorporatenetwork claimtypes and/or automatic Workplace and/or Azure AD Join, based on domain membership.

However, recently, I configured the Performance routing method for a customer, so we’ll use it for this example, because it’s way more exiting. Here’s an overview

 

Before you begin

Overview

Building on top of the simple Hybrid Identity implementation where I showed you how to implement AD FS, the end result of this blogpost looks like this:

The georedundant AD FS deployment scenario using Azure Traffic Manager (click for larger image)

Networking

Microsoft’s Hybrid Identity Required Ports and Protocols document doesn’t list the requirement to allow TCP 80 (HTTP) for Web Application Proxies.

In addition to the network traffic depicted in that document, we need to take care of  the ability of our Web Application Proxies to communicate plain HTTP towards the Internet (or at least the Azure Traffic Manager probing IP address ranges).

Name resolution

Normally, we’d point DNS to the external IP address of the load balancer on the edge of the perimeter network featuring the Web Application Proxies. However, since Azure Traffic Manager leverages DNS, we’ll need to create a CNAME record for our sts.domain.tld AD FS Farm name in external DNS Zones towards Azure Traffic Manager. For instance, we’ll create a CNAME record for sts.domain.tld to domainsts.traffficmanager.net.

Next, we’ll need to configure proper name resolution. Azure Traffic Manager uses DNS records to locate the endpoints, so the external IP addresses for the Web Application Proxies you’d want to integrate with Azure Traffic Manager will need to have a fully-qualified Domain name (FQDN) attached.

My suggestion is to use the same naming convention used for the AD FS farm name, but add a location or region to it. This way, an sts.domain.tld farm name would feature EastUsSTS.domain.tld and WestEuropeSTS.domain.tld endpoints, for example.

 

Step 1: Configuring the second AD FS server

In contrast to the simple deployment scenario, we’ll deploy more than one Active Directory Federation Services (AD FS) server. We don’t have to worry about the scope of the group Managed Service Account (gMSA), because the AD FS server takes care of that.

Deploy a new server running Windows Server 2016 or Windows Server 1709, join it to the Active Directory domain as adfs2.domain.tld and import the AD FS service communications certificate.

Then, run the following PowerShell one-liners:

Install-WindowsFeature ADFS-Federation

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match sts.domain.tld}).Thumbprint

Add-AdfsFarmNode -CertificateThumbprint $thumb -PrimaryComputerName adfs1.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$

Restart-Computer

      

Step 2: Configuring the second Web App Proxy

Configuring additional Web Application Proxies to an AD FS Farm is not different than adding the first.

In the scenario of multiple datacenters, however, you might want to pay specific detail to the contents of the HOSTS file on the Web Application Proxies to point them to the closest AD FS server, instead of the AD FS server in the other datacenter.

The following PowerShell one-liner provides a good way to add a line to the HOSTS file using an elevated PowerShell (ISE) session:

Add-Content “C:\windows\system32\drivers\etc\hosts” “`nsts.domain.tld 10.4.0.5

Then, import the certificate and run the PowerShell one-liner to add the Web Application Proxy to the AD FS farm:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match sts.domain.tld}).Thumbprint

Install-WebApplicationProxy -CertificateThumbprint $thumbFederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.

 

Step 3: Configuring both Web App Proxies

For optimum load-balancing, we’ll need proper probes. We need to probe the infrastructure for something that is available only when the infrastructure is up and the functionality (the service) is running properly. A mere ping won’t suffice.

While you’d need to install KB2975719 on Windows Server 2012 R2 to enable the /adfs/probe endpoint, in Active Directory Federation Services (AD FS) on Windows Server 2016, this endpoint is available and enabled, by default.

Note:
You won’t see the /adfs/probe/ endpoint in the list of endpoints in AD FS Management (.msc), under Service, Endpoints.

However, the /adfs/probe/ endpoint is not available by default on Web Application Proxies, so we’ll need to perform a manual action to allow it through its Windows Firewall.

To this purpose, create the following Windows Firewall rule using Windows PowerShell on each of the Web Application Proxy servers you want to be probable by Azure Traffic Manager. Log onto each Web Application Proxy with an account with local admin privileges, start an elevated PowerShell (ISE) window and issue the following lines of code:

Import-Module NetSecurity

New-NetFirewallRule -Name Allow_HTTP -DisplayName “AD FS HTTP Services” -Protocol HTTP -Profile Any -Action Allow

Note:
You should be aware that this rule allows Azure Traffic Manager to probe the status of each of the Web Application Proxies, and, thus, the availability of the connection and running services on these servers, but not the AD FS services on the AD FS Servers. For the purpose of geo-redundancy, however, this should be sufficient.

 

Step 4: Adding DNS records

Internal DNS

When you want your AD FS farm name to be available for users on-premises, add another DNS A record for the second AD FS server in the internal DNS zone:

Add-DNSServerResourceRecordA -IPv4Adddress 10.4.0.5 -Name sts -ZoneName domain.tld

Since we’re creating A records, Active Directory site awareness takes care of pointing internal clients to the nearest AD FS server.

External DNS

For the external DNS zone, we’ll need the following DNS changes:

sts.domain.tld CNAME domainsts.trafficmanager.net

EastUsSTS.domain.tld A <ExternalIPAddressinDatacenter1>

WestEuropeSTS.domain.tld A <ExternalIPAddressinDatacenter2>

 

Step 5: Configuring Azure Traffic Manager

Now, all we need to do is configure Azure Traffic Manager, itself:

  • Log onto the Microsoft Azure Portal.
  • If you have multiple tenants, choose the right tenant by clicking on your name or e-mail address in the top right corner. Select the tenant you want to use from the bottom of the context menu.
  • Click on the green big plus sign in the left navigation menu to add products and services to your tenant.
  • In the Search the Marketplace field, search for Traffic Manager Profile. by beginning to type its name. When Azure suggests it to you, click on it, or use the down cursor to go to it and then press Enter.
  • A new blade appears named Traffic Manager Profile. It contains information on what Traffic Manager does, information on its publisher and help links. Click on the Create button on the bottom of the blade.
  • A new blade appears, labeled Create Traffic Manager profile.

Create a Traffic Manager Profile in the Azure Portal (click for original screenshot)

  • Type and select the following information:
    • Type the DNS name of your Traffic Manager profile, for instance DomainSTS. This will be appended by trafficmanager.net to become the FQDN your external DNS zone has a CNAME for: DomainSTS.trafficmanager.net.
    • Select a Routing method from the drop-down list. We’ll choose Performance.
    • Select a Subscription from the drop-down list.
    • Create a new Azure Resource Manager (ARM) Resource group, or if you already have a resource group for Traffic Manager profiles and other load-balancing/high-availability resource, reuse that, by selecting it from the drop-down list.
    • Select a Resource group location from the drop-down list, when you create a new Resource group, otherwise continue with the next step.
  • Select the Pin to dashboard option for your convenience.
  • Click Create on the bottom of the blade.
  • You will be redirected back to the Azure Portal dashboard, where you’ll see the profile be provisioned. After that, you’ll be taken into the configuration of your freshly created Azure Traffic Manager profile. If not, click it’s tile on the dashboard to continue.
  • In the left navigation blade, click on Configuration under SETTINGS.
  • In the Configuration blade that appears, click on the Path field under Endpoint monitor settings. Change it to /adfs/probe/.

Configure Traffic Manager Endpoint Monitoring in the Azure Portal (click for original screenshot)

  • Click Save on the top of the blade.
  • In the left navigation blade, click on Endpoints.
  • Follow the + Add link on the top of the blade.
  • A new blade appears, labeled Add endpoint.

Add a Traffic Manager Endpoint in the Azure Portal (click for original screenshot)

  • From the Type drop-down list, select External endpoint.
  • Type something meaningful as the name. This makes for a good opportunity to exercise the organization’s naming convention. You might also just opt to type the hostname of the Web Application Proxies.
  • For the Fully-qualified Domain Name (FQDN) enter the DNS name you assigned to the external IP address of the load balancer of Web Application Proxy in the particular location.
  • Select a Location from the drop-down list. This determines the end-user device locations to be directed to this particular endpoint.
  • Click OK.

Now, add any additional endpoints you’d like to include in the Azure Traffic Manager profile, like EastUsSTS.domain.tld. After that, your Endpoints overview should look like this:

Traffic Manager Endpoints in the Azure Portal (click for original screenshot)

 

Concluding

Azure Traffic Manager is a cost-effective, relatively easy to set up, robust service in Microsoft’s Azure datacenters to add geo-redundancy to your Active Directory Federation Services (AD FS) implementations.

Further reading

Azure Traffic Manager & ADFS 2012r2
Configure the Web Application Proxy Infrastructure
How to install and configure Web Application Proxy for ADFS
Web Application Proxy Server in 2012 R2
Overview of Traffic Manager

0  

Performing a simple Hybrid Identity implementation with AD FS on-premises

Hybrid Identity

In this blogpost, I’ll explain how to install and configure Active Directory Federation Services (AD FS) and Azure AD Connect to achieve Hybrid Identity with Azure Active Directory, based on Windows Server 2016.

The implementation outlined in this blogpost is relevant for one on-premises datacenter and an Active Directory Domain Services environment, consisting of one Active Directory domain. We’ll try to keep this as simple as possible, so we’ll make the following choices:

  • We won’t deploy the AD FS Servers in a redundant/high-available fashion
  • We’ll use Windows Internal Database (WID) to host the AD FS Configuration database
  • We wont deploy the Web App Proxies in a redundant/high-available fashion
  • We’ll use an AD FS service communications certificate issued by a publicly-trusted Certification Authority (CA).

 

Before you begin

Before you begin, you should have access to the following information:

  • The DNS domain name of your organization’s Active Directory Domain Services (AD DS) environment
  • Credentials for an Enterprise Admin account in the AD DS environment
  • Credentials to access the DNS zone of the DNS Domain Name of your organization

Of course, it’s a good idea to make a back-up of your Domain Controllers and test one of the backups in a separate networking environment to make sure you’re able to restore.

Requirements

Before you can implement Hybrid Identity, based on Windows Server 2016, your environment needs to comply with these requirements:

  • The Active Directory schema needs to be at least Windows Server 2016.
  • Your organization needs at least one Windows Server 2012-based (or up) Active Directory Domain Controller
  • The Active Directory Domain Services Domain Functional Level needs to be at least Windows Server 2008 R2.

Overview

In the blogpost, we’ll implement the following:

SimpleADFS

Step 1: Configuring Active Directory

Service Accounts

Before we can setup Hybrid Identity, we need to create a service accounts. We’ll use a group Managed Service Accounts (gMSAs) for AD FS, because it offers the best security.

Run these two elevated PowerShell one-liners:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

New-ADServiceAccount ADFSgMSA –DNSHostName adfs1.domain.tld

 

DNS Records

Next up, we’ll configure the internal DNS records for the AD FS Farm Name:

Add-DNSServerResourceRecordAIPv4Adddress 10.0.0.5 -Name sts -ZoneName domain.tld

 

Step 2: Setting up the AD FS Server

About AD FS

Active Directory Federation Services (AD FS) can be seen as an add-on to Active Directory Domain Services (AD DS). AD DS offers single sign-on for on-premises functionality like file servers and printer servers, leveraging protocols like NTLM and Kerberos. AD FS also offers single sign-on, but based on standards like WS-Federation, SAML, Oauth2 and SCIM. AD FS can be used to provide single sign-on to (web) applications on-premises, but it is particularly useful for cloud-based (web) applications.

The AD FS server is the component that performs the security translation between the ‘old’ protocols and the new standards. In the RFCs, it is referred to as a Security Token Service (STS).

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring AD FS.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

AD FS Role

To install the AD FS role, run the following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

AD FS Service Communications certificate

AD FS requires a certificate.

On a Windows or Windows Server installation, simply create a certificate request for a certificate with the following DNS subjects:

  • CN=sts.domain.tld
  • DNS=sts.domain.tld
  • DNS=enterpriseregistration.domain.tld
  • DNS=certauth.sts.domain.tld

Make sure you create a certificate request for a certificate with the SHA-2 hashing algorithm, a 2048-bit key length (or longer) and a legacy key pair.

You can use any Certificate Authority (CA) you’d like, but I recommend certificates issued by Let’s Encrypt for the AD FS service communications certificate. Let’s Encrypt is a free, automated, and open Certificate Authority (CA).

Submit your certificate request, pass the validation checks and then receive a perfectly valid TLS certificate for free. Smile

I installed the certificate on the box where I requested it. Then I exported it and protected the key material with a password. I copied it the hard disk of the AD FS Server where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureStringString YourPasswordHere” –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

After the role is installed and the certificate is installed, we can configure AD FS, using the following PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match sts.domain.tld}).Thumbprint

Install-AdfsFarm -CertificateThumbprint $thumb -FederationServiceName sts.domain.tld -GroupServiceAccountIdentifier domain.tld\ADFSgMSA$

Restart-Computer

The AD FS Server is setup after it comes online.

 

Step 3: Setting up the Web Application Proxy

About the Web Application Proxy

To use AD FS with Azure Active Directory, we need to publish it publicly, or at least to Microsoft. Microsoft recommends to use the Web Application Proxy role to publish AD FS publicly. Yes, you could make the previously configured AD FS Server to the Internet, but this is not recommended.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation for the Web Application Proxy, too. This time, however, it’s located on a perimeter network, if your organization has any.

The server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with installing and configuring it as a Web Application Proxy.

Log on as a local admin and copy the certificate over to this server.

Then, install the role, using the  following Windows PowerShell one-liner in an elevated PowerShell window:

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

I copied the exported certificate to the hard disk of the Web Application Proxy where I stored it as C:\sts.pfx. This allowed me to run the following PowerShell one-liner to import the certificate:

Import-PfxCertificate -FilePath C:\sts.pfx -Password (ConvertTo-SecureStringString YourPasswordHere” –AsPlainText -Force) –CertStoreLocation cert:\LocalMachine\My

Now that the role is installed and the certificate is installed, we can configure the Web Application Proxy, using the following two PowerShell one-liners:

$Thumb = (Get-ChildItem -path cert:\LocalMachine\My | Where-Object {$_.Subject -match sts.domain.tld}).Thumbprint

Install-WebApplicationProxyCertificateThumbprint $Thumb -FederationServiceName sts.domain.tld

Enter the credentials of a local administrator account on the AD FS Server at the login screen and then, the Web Application Proxy is setup.

 

Step 4: Setting up Azure Active Directory

About Azure Active Directory

Azure Active Directory is Microsoft’s cloud-based Identity Management as-a-Service solution. It offers single sign-on access to Office 365 and over 2800 other cloud apps and services from the likes of Google and Amazon.

Setup the Azure AD tenant

We’ll configure a new Azure Active Directory tenant, by leveraging the Office 365 trial wizard. This wizard allows you to create an Azure Active Directory tenant without the need of a credit card.

Follow the link above and register the tenant. Do not forget to write down the password for the built-in tenant administrator account somewhere safe.

Connect to the tenant

Next, let’s connect to the tenant. Use an elevated PowerShell session and type the following one-liner to install the Azure Active Directory PowerShell Module:

Install-Module AzureAD

Press Yes twice. Now, Let’s put it to action to log into our tenant using the bootstrap/fallback admin account we created when we created the tenant:

Connect-AzureAD

In the pop-up authentication window, type your username and press Next. Then, in the password stage, enter the password and press Sign in.

Configure your DNS domain name

Next, configure your DNS domain name:

New-AzureADDomain -Name domain.tld -IsDefault $true

Your Azure AD Tenant is now ready to go.

 

Step 5: Setting up Azure AD Connect

About Azure AD Connect

Azure AD Connect is Microsoft’s free bridge between Active Directory Domain Services (AD DS) and Azure Active Directory. It helps organizations make themselves known towards Microsoft as a tenant by synchronizing objects and attributes and configuring synchronization and sign-in options.

Windows Server 2016

We’ll start with a fresh Windows Server 2016 installation, located on the internal network. Of course, the server will be properly setup for updates, backups, monitoring, and anti-malware, according to your organization’s requirements, before we proceed with downloading, installing and configuring Azure AD Connect.

The server needs to be joined to the domain and subsequently restarted. Log on with a domain account afterwards.

Download Azure AD Connect

Use a browser to download the latest version of Azure AD Connect to disk.

Install and configure Azure AD Connect

Double-click the AzureADConnect.msi file.

After the initial installation, you will begin configuring Azure AD Connect, automatically. In the Welcome to Azure AD Connect screen, select the I agree to the license terms and privacy notice option and click Continue.

In the Express Settings screen, click Customize.

Note:
When we would’ve used Express Settings, one of the configuration outcomes would have been PAssword Hash Synchronization (PHS) as the Sign-in option.

Click Install on the Install required components screen.

Azure AD Connect - User sign-in

In the User sign-in screen select Federation with AD FS as the sign on method.
Click Next.

Azure AD Connect - Connect to Azure AD

In the Connect to Azure AD screen, enter the username and password for the Azure AD bootstrap/fallback account. Click Next when done.

Azure AD Connect - Connect your directories

In the Connect your directories screen, click the Add Directory button. In the AD Forest account pop-up window, specify a user account with at least Domain Admin credentials for the Active Directory domain you want to add, or a user account with at least Enterprise Admin credentials, when you want to add an entire Active Directory forest. Press OK when done. Then, press Next on the Connect your directories screen.

Azure AD Connect - Azure AD sign-in configuration

In the Azure AD sign-in configuration screen, click Next to accept the userPrincipalName attribute as the on-premises attribute to use as the Azure AD username.

Press Next in the Domain and OU filtering screen to accept synchronizations of all domains and organizational units (OUs) within the connected Active Directory.

Note:
Some objects will not be synchronized by default, like the built-in Administrator account and other privileged accounts when these privileges stem from memberships to well-known privileged groups, like the Domain Admins and Account Operators groups.

Azure AD Connect - Uniquely identifying your users

In the Uniquely identifying your users screen, click Next.

In the Filter users and devices screen, click Next. to Synchronize all users and devices instead of creating a pilot group for synchronization.

Azure AD Connect - Optional Features

In the Optional features screen, click Next.

In the Domain Administrator Credentials screen, enter the username and password of a user account in the Active Directory Domain Services environment where AD FS will be managed with Domain Admin privileges. Click Next when done.

Azure AD Connect - AD FS farm

In the AD FS farm screen, select Use an existing AD FS farm. In the SERVER NAME field, enter adfs1.domain.tld, or use the Browse button to select the AD FS server from Active Directory. Click Next when done.

In the Azure AD Domain screen, select the DNS domain name that you wish to federate from the dropdown list.

Azure AD Connect - Verify Azure AD Domain

Now, we face the challenge of verifying our DNS Domain Name. In your external DNS zone, implement the following DNS records:

  • The above TXT or MX record as shown in Azure AD Connect
  • An A record for sts.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server
  • An A record for enterpriseregistration.domain.tld, pointing to the external IPv4 address of your Web Application Proxy server.

Also, this is a good time to make sure traffic is allowed from the Internet to the Web Application Proxy, using TCP 443. Open up this firewall port when you haven’t yet. The time this takes makes sure the DNS records are populated and visible, as this tends to take some time at some DNS providers…

Then, click the green Verify Domain button, next to the DNS domain name.

Azure AD Connect - Verified Azure AD Domain

Eventually, you’ll receive the message that your DNS Domain name is now a managed domain that will be converted into a federated domain. Click Next.

Azure AD Connect - Ready to configure

On the Ready to configure screen, click Install.

On the Configuration complete screen, click Next.

Azure AD Connect - Verify federation configuration

On the Verify federation configuration screen, select the I have created DNS A records that allow clients to resolve my federation service from both the intranet and the extranet. option. Then, click Verify to verify name resolution of the AD FS Farm using external DNS and access to the AD FS Farm using TCP 443.

After successful verification, click the Exit button.

You can now use Azure Active Directory with Single Sign-On.

 

Concluding

Congratulations! Thumbs up

You have setup Hybrid Identity using Active Directory Federation Services (AD FS) as the sign-in option. Now you can use this new piece of infrastructure to rollout Microsoft Intune, give your colleagues access to Microsoft Office 365 or over 2800+ applications that are ready to integrate with Azure Active Directory, all without the hassle of logon prompts and disparate passwords between solutions.

Note:
For the AD FS Server and the Web Application Proxy, you can use Windows Server version 1709 or other Server Core installations, too, even though the above blogpost only mentions Windows Server 2016.

4  

I’m speaking at NIC Future Edition

Nordic Infrastructure Conference Speaker

For its seventh edition, the theme for the annual Nordic Infrastructure Conference (NICConf) is Future Edition. Raymond Comvalius and I are delivering sessions again. It’s our fourth edition of this fantastic event and we’re looking forward to it!

 

About the Nordic Infrastructure Conference

The Nordic Infrastructure Conference (NICConf) provides IT and business professionals with unmissable networking and learning experiences from the leading Global IT experts.

NIC is the industry’s foremost collaboration and learning event offering global best in class content and structure, delivered by some of the leading technical IT speakers in the world. The main focus is on Cloud technology, automation & management, security, client & server, collaboration and productivity & analytics.

NICConf will be hosted for the seventh time from January 31 to February 2, 2018. Its location will be the Oslo Spektrum in the heart of Oslo, Norway, again. James Whittaker, Microsoft Distinguished Engineer and Tech Evangelist, is scheduled to deliver the keynote on February 1.

 

About our sessions

Raymond and I deliver two 60-minute sessions:

Azure Multi-Factor Authentication: Who do you think you are?

February 2, 2018 8:30AM – 9:30AM, Room 8

Passwords have been introduced to solve the authentication problems decades ago. Today, we have different challenges and we need more in-depth solutions for authentication assurance. Office365- and Azure Multi-Factor Authentication (MFA) offer this solution for both your organizations’ cloud and on-premises resources. Your organization will no longer be in the dark on the person on the other side of the line: it’s really you and you’ve got the means to prove it!

With several large and complex Azure MFA implementations and upgrades under their belts, Sander Berkouwer (Directory Services and Enterprise Mobility MVP) and Raymond Comvalius (Windows IT Pro MVP) share their experiences with these products, their licensing, on-premises deployment scenarios, end-user expectations and the inner workings of the product line-up, including MFA Server, the Security Graph and Azure AD Identity Protection.

Looking for your next-generation identity primer? Look no further!

 

Achieving productivity without an on-premises infrastructure: Mission Impossible?

February 2, 2018 2PM – 3PM, Room 4

The daily announcements from Microsoft on cloud-based opportunities for organizations, might give you the idea that your organization might be able to achieve productivity without an on-premises infrastructure, too. How do you, as a system administrator for a large organization, embrace these new possibilities and get rid of the square footage, cooling needs, firewalls and even your Domain Controllers? Can you go 100% cloud?

Dive into the full stack of Microsoft cloud possibilities and impossibilities with Sander Berkouwer (Directory Services and Enterprise Mobility MVP) and Raymond Comvalius (Windows IT Pro MVP). With their ‘Trust, but verify’ view on these items, they’ll share their real-life experiences with bringing organizations to the cloud, embracing a dual cloud provider strategy and the often-overlooked exit strategies you’ll need to have.

Find out why Group Policies, VPNs and typical file servers are rapidly becoming remnants of a long gone era in systems management and productivity. In the process, gain an end-to-end overview, featuring the latest and greatest Windows and Azure technologies to achieve the goals on your organizations horizon.

 

Related blogposts

Pictures of the 2017 Nordic Infrastructure Conference in Oslo last week
I’m speaking at the 2017 Nordic Infrastructure Conference
Pictures of the 2015 Nordic Infrastructure Conference
I will be speaking at Nordic Infrastructure Conference 4th Edition
Pictures of the 2014 Nordic Infrastructure Conference
I will be speaking at NIC 2014
My Cybersecurity Talk interview with CQURE Academy is now available

0  

Installing Multi-Factor Authentication Server with the new Portal Experience

Microsoft Azure Multi-Factor Authentication

Per this week, Azure Active Directory is no longer available in the ‘Old’ Portal experience. Previously, I’ve shared with you how to download, install and configure Microsoft’s on-premises Multi-Factor Authentication Server, while using the old Portal Experience. Now, let me show you how to download, install and configure it with the ‘New’ Portal.

In this blogpost, we’ll follow the Simple Deployment scenario.

 

Step 1 Create an MFA Provider

Log onto the Azure Portal.

In the left navigation menu, click Azure Active Directory.

In the navigation menu of your Azure AD tenant (just to the right of the main navigation menu) scroll down until you reach MFA Server in the SECURITY area.

Click MFA Server.

the MFA Server blade in the Azure Portal (click for original screenshot)

In the MFA Server blade, click on Providers in the feature’s navigation menu.

No Providers for MFA Server in the Azure Portal (click for original screenshot)

Click + Add.

Add a Provider for MFA Server in the Azure Portal (click for original screenshot)

In the Add Provider blade, fill in the values for:

  • Name
    This is the name for the Multi-factor Authentication Provider. This is only shown in the Azure Portal. Make sure to create a name that corresponds to your organization’s naming convention.
  • Usage Model
    Choose between Per Enabled User or Per Authentication. The usage model cannot be changed after the Multi-Factor Authentication Provider is created. For more information, refer to Option 3 in the How to Get Azure MFA section of the What is Azure Multi-factor Authentication documentation.
  • Subscription
    Select the subscription you want to have your authentications or enabled users to be billed to.

When done, click the Add button at the bottom of the blade.

You have now successfully created the MFA Provider.

 

Step 2 Download MFA Server

Double-click the MFA Provider you just created.

In the MFA Provider’s navigation menu, click Server Settings.

Server Settings for the MFA Provider in the Azure Portal (click for original screenshot)

Click the Download link.

The Download page for Multi-Factor Authentication Server opens in a new tab, by default. Click the Download button on the page and save MultiFactorAuthenticationServerSetup.exe to disk.

Do not close the web browser, just yet.

 

Step 3 Install MFA Server

After you downloaded MultiFactorAuthenticationServerSetup.exe, open it.
Walk through the prerequisites and screens to install Multi-Factor Authentication Server.

The Welcome screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Welcome screen, click Next >.

The Activate screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Activate screen, we need to enter the activation credentials. You generate the activation credentials in the Azure Portal, so let’s switch back to the Azure Portal in our web browser:

The Generate Credentials link in the MFA Provider feature in the Azure Portal (click for original screenshot)

Click the Generate link.

This will show two more fields below the link, consisting of an e-mail address and a password. Copy these two values in the Multi-Factor Authentication Server’s Activate screen. Click Next > and close the browser screen.

The Join Group screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Join Group screen, click Next >.

The Enable Replication Between Servers screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Enable Replication Between Servers screen, click Next >.

The Select Applications screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Select Applications screen, select the applications, services and protocols you want the Multi-Factor Authentication Server to provide. At least one application needs to be selected. Click Next > when done and walk through the steps to configure the application, protocol or service.

The Finish screen of Multi-Factor Authentication Server version 7.3.0.3 (click for original screenshot)

In the Finish screen, click Finish.

You have now successfully installed and configured Multi-Factor Authentication Server.

 

Concluding

Many people I talked to about the transition of the old PhoneFactor Web Portal (PFWEB) and the old Microsoft Azure Management Portal to the new Azure Portal, were worried about not being able to select the Per Authentication licensing option, or reusing their previously configured MFA Provider settings.

The above steps show that all these options are still available.

Although Multi-Factor Authentication Server has been ‘renamed’ in the Azure Portal and the Microsoft Forums, the latest version of the product still refers to itself as the Windows Azure Multi-Factor Authentication Server… Let’s name it MFA Server, from now on.

Further reading

Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal

Related blogposts

Azure Multi-Factor Authentication is now in the new Azure Portal (in Public Preview)
Ten Things you need to know about Azure Multi-Factor Authentication Server
Azure Multi-Factor Authentication Server 7.3.0.3 with lots of improvements
Azure Multi-Factor Authentication features per license and implementation
Azure Multi-Factor Authentication Methods per Supported Protocol
Connecting to Azure MFA Server’s Web Service SDK using certificate authentication
Things to know about Billing for Azure MFA and Azure MFA Server
Supported Azure MFA Server Deployment Scenarios and their pros and cons

2  

I’m co-presenting a second webinar on tracking changes in Hybrid Identity

Free Webinar

On Wednesday January 24, 2018 I’m co-presenting a webinar on tracking changes in Hybrid Identity environments, based on Active Directory Domain Services (AD DS) and Azure AD. The session is sponsored by Netwrix, who I think have a stellar solution for tackling this challenge.

This expert webinar is scheduled for a convenient time for my European and African friends, at 3PM CET. This is a rerun of the previous webinar with Netwrix.

 

About Netwrix

NetwrixNetwrix is a private IT security software company, which offers IT auditing solutions for systems and applications across your IT infrastructure. Netwrix  specializes in change, configuration and access auditing software with its Netwrix Auditor solution. Netwrix is a partner of Microsoft, VMware, EMC, NetApp and HP ArcSight.

If you’ve worked in highly-secure highly-regulated IT environments, you’re probably familiar with the Netwrix brand, because their Active Directory auditing solution is one of the best out there.

 

About the webinar

For many organizations, Active Directory is the cornerstone of their network infrastructure. However, as cloud adoption among businesses increases IT teams are posed with more and more security challenges by these hybrid environments. It’s a daunting struggle to manage both Active Directory and Azure AD, let alone ensure the security of such deployments. How can you monitor critical changes? Or comply with the certifications your organizations need?

In this webinar, you’ll learn how you can monitor privileged account activity, stay on top of critical changes and a slew of security threats in hybrid environments with Netwrix Auditor. You will get an abundance of ready-to-go recommended practices, so you’ll be able to start with Netwrix Auditor 9.5 the right way, immediately.

I’m co-presenting the webinar with Russell McDermott, systems engineer at Netwrix. This way, you get the best practices from the field and expert analysis tips, directly from the guys who build the Netwrix Auditor product.

 

Join me! Glimlach

The webinar is offered free of charge.
You only need to register in advance to become part of the fun!

Of course, if you can’t make January 24, 2017 3PM CET, you can also register for viewing the webinar on-demand , after we’ve finished up.

0