Phidiax Tech Blog

Using Group Managed Service Accounts with BizTalk Server 2016

Managed Service Accounts (MSAs) are managed domain accounts that provide automatic password management. However, MSAs are limited to a single computer account. They cannot be used as the service account for a SQL Server failover clustered instance which can run across multiple Windows servers.

The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. gMSAs for services such as SQL Server, remove the overhead of service account password management.

SEE: Group Managed Service Accounts (gMSA) and SQL Server 2016 and Group Managed Service Accounts Overview

Background on BizTalk Security

After reviewing the basics about gMSAs and security from the preceding links, you might feel prepared to move forward with implementing BizTalk Security. Before we delve into the technical details about the implementation, some background is necessary.

BizTalk is an early implementation of a hosting service system. This cloud-like, self-contained environment can run numerous processes simultaneously, distributing the workload across participating servers based on their ability to handle the work. This means that we must use some system of isolating that work so that cross-process access is not allowed.

Microsoft BizTalk Server isolates these systems in two levels: process level and SQL Server level.

At the process level, the outer security group is called a Host. Hosts are configured to align with Groups in the system (Local or Active Directory). Processes that are running under those hosts, are aligned with Service Accounts (Local or Active Directory). Service Accounts running on each physical server prevent accounts from the other BizTalk Services from accessing their in-process memory. Host Instance services accounts should be different for each Host.

At the SQL Server level, the Host Groups are assigned to Database Roles and those Database Roles only have access to the tables and data through stored procedures for their data processes. Each Host gets isolated objects in the database. Only that Host and no other Host has access to the data in the other tables in the database.

The key to runtime security is Hosts for database isolation and Host Instances for process isolation. 

BizTalk Server groups and accounts

• Use accounts with minimum permissions and user rights.
• Use different accounts for different functions.
• Use different hosts for different functions.
• Change passwords periodically.

SEE: Security Recommendations for a BizTalk Server Deployment

You should set up a fairly large number of groups and accounts in Active Directory for the BizTalk Server production environment. BizTalk implements security via these Groups and Accounts. These aren’t like SQL Server or IIS environments, where they use a limited number of accounts. BizTalk must isolate processes using these groups and accounts.

Setting up these accounts requires the support of the infrastructure team, which might cause some friction when they question the requirement for the large number of accounts and groups.

One of the primary issues for an infrastructure team is password management of those services accounts. Some of the areas of contention are:

• Service account passwords need to be tracked somewhere, creating a risk that the passwords could be stolen. The passwords must be logged, shared, and controlled in a secure manner.
• Service account passwords should be updated on a regular basis, causing frequent and risky service outages.
• Service account password updates could cause a system outage, when the account update incorrectly causes the service account to get locked out.

The group Managed Service Accounts address these issues and enable your team to increase system security significantly.

• Automating the process within Active Directory for password management. The generated passwords are very complex and can be changed automatically as often as you want (by default every 30 days). The passwords are cryptographically random and 240 bytes long. In addition, they cannot be used to interactively log on to any account.
• Service account passwords are never under the control of the team members. They are automatically generated and not visible to users; therefore, not susceptible to discovery.

NOTE: The managed password can be extracted by an administrator using custom tooling. This is not recommended because the actual value will change, and saving the managed password somewhere reduces the value of this feature significantly.

• Service accounts cannot be locked out.
• The BizTalk service does not have to be restarted after an automatic service account password reset, which prevents system downtime.

Implementing group Managed Service Accounts

This is a step-by-step implementation of Group Managed Service Accounts (gMSAs) for use as the service account for BizTalk Server 2016.

This implementation is performed using Windows Server 2012 Active Directory domain controllers, all servers running Windows Server 2012 or later and BizTalk Server 2016.

Prerequisites

To use gMSAs, there must be at least one Windows Server 2012 or later domain controller in the domain. There is no forest or domain functional level requirement.

• If deploying a Windows Server 2012 R2 domain controller, be aware of the following hotfix that resolves a problem with connecting after a password change: gMSA-based services can't log on after a password change in a Windows Server 2012 R2 domain
• There are more details on prerequisites located here: Getting Started with Group Managed Service Accounts
• The Key Distribution Services (KDS) Root Key must be created before a gMSA can be created. This is done via a PowerShell command and requires Domain Administrator or Enterprise Administrator level privileges. For details and steps, see Create the Key Distribution Services KDS Root Key

NOTE: There is a 10-hour lag between the time the KDS Root Key is created and the time a gMSA can be created. This is to allow full replication between the Windows Server 2012 DCs to allow password retrieval to work as necessary. The preceding reference contains steps at the above reference to allow the use of the root key immediately for testing purposes.

• This requires a 64-bit environment, but only must be done on one Windows Server 2012 R2 domain controller.

gMSA Implementation for BizTalk Server 2016

This section is based on the following blog posts:

• Group Managed Service Accounts (gMSA) and SQL Server 2016
• Windows Server 2012: Group Managed Service Accounts

• Create the BizTalk Host Users group to contain the service account. 
• NOTE: There is a reboot requirement for the member servers added to this Security Group.
• In Active Directory Users and Computers, under the domain where the gMSA is to be created, right-click Computers, New and Group. The New Object – Group dialog box opens.

• Enter a Group name. Group scope should be Global and Group type is Security. In this demo, we will use BizTalk Application Users, the default BizTalk Host Group.

• Double-click the newly created Security Group, and go to the Members tab. Or right-click the Security Group and go to Properties. Then click the Members tab.

• Click Add. Add the domain member servers that will host the BizTalk Server instances that will use the gMSA. In this example, add all the member servers that will be running BizTalk Server.
• NOTE: These servers will require a reboot for their tokens to pick up membership in the group.

This group will be given specific rights for its members that will enable the member servers to retrieve the gMSA password.

• Create the gMSA account.
• This must be done with a PowerShell script in a PowerShell session that also has the Windows Server 2012 AD cmdlets available (it does not need to be done on a DC). See Active Directory Administration with Windows PowerShell for guidance on installing the AD PowerShell module.
• The command that creates the gMSA will also grant the right to retrieve the accounts password to the members of the Security Group created earlier.
• This is the PowerShell command used:
  New-ADServiceAccount -name "gMSABTSService" -DNSHostName gMSABTSService.domain.com -PrincipalsAllowedToRetrieveManagedPassword "BIZTALKSERV1"

• Configure and validate the gMSA service account on the member servers.
• This step might not need to be done. The accounts may already be configured on the member servers when they were rebooted. However, the steps are quick, and validating the account should be considered necessary. These commands also require the AD module for Powershell.
• To configure the gMSA account, run the following PowerShell command on the member server:
  Install-ADServiceAccount "gMSABTSService"
• To validate the gMSA account, run the following PowerShell command on the member server:
  Test-ADServiceAccount "gMSABTSService"
  • This should return True.
• Add the Service account to the Host Group and SSO Affiliate Administrators for the Host for the server.

USE [master]
GO
CREATE LOGIN [domain\gMSABTSService$] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO 

• Configure BizTalk Server to use the gMSA service account
• Start the Services Application on each server
• Locate the BizTalk Service that needs to be updated. Right-click and select Properties
• Click the Log On Tab
• In the This Account username box, enter: domain\gMSABTSService$
• NOTE: The $ at the end of the account; this is the actual account name.
• Do not enter a Password. The password will be retrieved automatically from AD.
• Start or Restart the BizTalk Host Instance.
• NOTE: The BizTalk Server Admin console doesn’t support editing gMSAs. Only use the Windows Service application to edit gMSAs.
• Start the Local Security Policy Editor (secpol.msc) on each server, Under Local Policies, User Rights Assignment, locate Log On as a Service, and add domain\gMSABTSService$ to the list.

Using gMSA accounts during BizTalk Server 2016 installation

You cannot use these accounts during installation. Instead, use a temporary account and update the account after installation.

Returning to Non-gMSA Service Accounts

To return to using non-gMSA service accounts, use the BizTalk Server Administration Console to set the new service account and password. A BizTalk Server Host instance restart will be required.

Summary

With the release of BizTalk Server 2016, managing BizTalk Server Host Instance service accounts becomes much easier with group Managed Service Accounts (gMSAs). The tedious and time-consuming planning and implementation phases of changing accounts and/or passwords, requiring BizTalk Server service restarts, and then troubleshooting when things go awry.

If your goal is to reduce management and administrative overhead and reduce security vulnerability, gMSA service accounts might be worth the  effort of implementation.