First, what is a Global Managed Service Account (gMSA)?
Microsoft describes “A standalone Managed Service Account (sMSA) as a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators.”
“The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers.”
What’s the deal with BizTalk 2016 configuration and gMSAs?
Officially, Microsoft does not directly support gMSAs for configuring BizTalk 2016. gMSA configuration support is added in BizTalk 2020.
However, this is only a limitation of the BizTalk configuration tools. MSAs are just another form of domain account so are perfectly suited to running any service where a standard domain account is used, but with major security advantages.
Most BizTalk 2016 services can be switched to gMSAs manually after configuration.
Why not wait for BizTalk 2020?
Not every company is ready to move to BizTalk 2020. Perhaps an infrastructure upgrade is required but the budget is not yet available. Some companies prefer to wait until the first Service Pack or Cumulative Update is released (Update: the first CU was released July 28).
Considerations
Not all BizTalk services can use gMSAs. The Enterprise Single Sign-On Service, ENTSSO, must use a standard domain account. This is still a restriction in BizTalk 2020.
Using a gMSA for a Windows Service or IIS Application Pool requires a manual change post-configuration. These changes can be scripted to make the task easier.
Domain accounts
Several domain accounts are required when setting up BizTalk. Standard and Managed accounts are both needed.
The account used by the person installing and configuring BizTalk needs to be all-powerful. It is not recommended to use a personal account, but rather an account specifically created for the task. The account will have very high privileges and needs to be carefully controlled. The account can easily be disabled by a domain administrator after use. Another lesser reason for a special account is that the configuration account will always be displayed in the BizTalk Administration Console – even after host services are changed to gMSAs. You might want your name recorded for posterity, but perhaps not! The special account could be called something like BizTalkConfigurator.
Here are the memberships and rights required for the configuration account. Refer to official BizTalk installation documentation for full details.
The Global MSA accounts required (with sample names), are listed in the following table.
BizTalk configuration
Now you get into the gritty technical changes required for BizTalk configuration.
- BizTalk Configuration Wizard
- Use the all-powerful BizTalkConfigurator domain account when configuring BizTalk Runtime (non-gMSA). This account will be used for the default host instances – Windows services in the case of In-Process Hosts. The service account will be changed later to a gMSA.
- Rules Engine – once again, use the BizTalkConfigurator account. This will be also changed later to a gMSA
- BAM Portal web service accounts – BAM Management Web Service User and BAM Application Pool Account. You know the drill – use the high privilege BizTalkConfigurator account that will be changed later to a gMSA
- Change the following to use gMSA accounts after configurations is complete:
- BizTalk Host Instance Windows Services
- Rules Engine Windows Service
- IIS Application Pools
- BAM Portal Manual Configuration. Phew, BAM Portal configuration is a post in its own right, especially if configuring for high availability. But, for gMSAs, you need to do the following:
- Add gMSA BAM Management account as a login to the SQL node(s)
- Add SQL user mapping to BAMPrimaryImport database:
- Click on BAMPrimaryImport in the mapping list
- In the lower pane check BAM_ManagementWS
- In the BAMManagementService web.config, change identity impersonate to false
- To do this, add the identity element:
<trust level="Full" originUrl="" /> <identity impersonate="false" /> </system.web>
- To do this, add the identity element:
- Update BAMManagementService and BAMQueryService web.configs
- Comment out the identity section because now using gMSA on new app pool for authentication:
<identity impersonate="true" userName="registry:HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0\BAM\WebServices\identity\ASPNET_SETREG, userName"password="registry:HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0\BAM\WebServices\identity\ASPNET_SETREG,password" />
- Comment out the identity section because now using gMSA on new app pool for authentication:
- Start IIS Manager
- Change account on application pool BAMAppPool to the BAM application gMSA account
- Create a new App Pool for BAM Management and BAM Query Services. Reason: gMSAs do not work using identity auth from registry.
- In IIS, right-click on Application Pools and select Add Application Pool…
- Set the name to BAMAppPoolManagementService
- Set .NET CLR version to .NET CLR Version v4.0.30319
- Set Managed pipeline mode to Classic
- Open App Pool Advanced settings
- Set Enable 32-Bit Applications to True
- Change Identity to gMSA. No password required
- Change BAMManagementService and BAMQueryService web applications to use the new app pool
- ESB Tool Kit Configuration
- A couple of tips:
- Use the all-powerful BizTalkConfigurator account for configuration. App Pool accounts will be changed to gMSAs afterwards
- If you get error Exception calling “create” with “0” argument(s): “Create failed for Database ‘EsbExceptionDb’ then shrink the model database and try again. Ref: http://www.embersbiztalkramblings.com/2016/01/exception-calling-create-with-0.html
- If you get an error like The User doesn’t belong to the Administrators Group or domain\BizTalkIsolatedHostUsers then you need the BizTalkConfigurator account directly added to BizTalkIsolatedHostUsers group. This is because the creaky old ESB Toolkit configuration tool does not check membership more than one level deep.
- Once finished, change identity on the following app pool accounts to a gMSA
- CoreEsbAppPool
- CoreEsbWcfAppPool
- ExceptionEsbAppPool
- ExceptionEsbWcfAppPool
- A couple of tips:
- ESB Portal
- Like BAM Portal – sort of – not covered in this post.
- Encryption and Signing Certificates
- Normally encryption and/or signing certificates are installed in the BizTalk host account’s Personal Certificate Store. MMC cannot be “Run As” a gMSA (not that I know of, anyway) so a different approach is required – giving permission to the private key(s) installed in the Computer Account’s Local Computer Personal Store.
- Run MMC.EXE as Administrator
- Add Certificates Snap-In
- Select Computer Account and click Next then Finish then OK
- Go to Personal Store
- Right click on a private certificate and select All Tasks > Manage Private Keys…
- Grant Read rights to the In-Process and Isolated Host gMSA accounts e.g.:
- Restart IIS
- Normally encryption and/or signing certificates are installed in the BizTalk host account’s Personal Certificate Store. MMC cannot be “Run As” a gMSA (not that I know of, anyway) so a different approach is required – giving permission to the private key(s) installed in the Computer Account’s Local Computer Personal Store.
Gotchas/oddities
- BizTalk Administration Console will still show the original account used during initial configuration (BizTalkConfigurator). This is just an artifact and no doubt could be changed somewhere in the BizTalk management databases, but direct database changes like this are best left alone.
- A BizTalk 2020 in place upgrade wipes out the Backup and DTA BizTalk SQL Server agent jobs so make a backup of the jobs first.
What next?
Global Managed Service Accounts should be used wherever possible to strengthen security and simplify account management. Microsoft is updating BizTalk configuration tools so gMSAs can be applied directly in most areas, and these updates are available in BizTalk 2020.
Do you require a health check of your current BizTalk, or are you planning to upgrade to the latest version or move to the cloud? Adaptiv Integration has been implementing and supporting BizTalk and Microsoft Azure Integration Services for many years and we’re available to assist with configuring or transformation.
The opinions expressed in our blogs are those of the individual contributors, not necessarily those of Adaptiv Integration. We encourage our people to lead, not follow, and to add value by sharing their experience and unique insights.
