Support for Group Managed Service Accounts

We’ve recently just reinstalled ADFS using a Group Managed Service Account as per Microsoft’s recommendation. This means that the deployment job fails because the local account doesn’t have permission to change the certificate.

Is there any chance of having a new credential type that supports Group Managed Service Accounts?

HI Marty,

So are you using the built-in Deploy to ADFS task? That script is intentionally basic, here is the code:

param($result, [switch] $restartServices = $false, [switch] $alternateTlsBinding = $false)

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint $result.ManagedItem.CertificateThumbprintHash -Confirm:$false

Set-AdfsSslCertificate -Thumbprint $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop -Confirm:$false

# primary AD FS with Alternate TLS binding
if ( $alternateTlsBinding -eq $true) {
    Set-AdfsAlternateTlsClientBinding -Thumbprint $result.ManagedItem.CertificateThumbprintHash -ErrorAction Stop -Confirm:$false

if ( $restartServices -eq $true) {

    Restart-Service WinHttpAutoProxySvc
    Restart-Service W3SVC
    Restart-Service adfssrv

You could adapt or replace this script for something completely different if required. Our background service runs as Local System and has a basic impersonation feature to use other windows or domain credentials however as you know we don’t specifically support a Group Managed Service Account.

This feature is not yet planned but assuming there is demand for it I’m sure we will add it in future, however for now you would need to find an alternative workflow.

I believe you could instead create a windows scheduled task to run as the gMSA which turn would be a script (powershell etc) running as that account. You would then need that script to perform any subsequent deployment required and a common technique for that is:

  • in Certify The Web, create a deployment task which writes out the temporary information you need to a local folder or share. This could just be a copy of the certificate PFX, or other information you need. At the end of your task, consider writing out a file to indicate the content is read for pickup such as ready_to_deploy.txt (if the information consists of multiple files).

  • In your scheduled task (which can optionally run very frequently): check for the existence of the content, perform your deployment using the provided information, then delete the temporary content.

Although this approach sounds a little circuitous it does unlock many scenarios for scheduled deployment (e.g. maintenance windows only) and running as specific users.

Thanks for the quick reply.
It seems there’s a setting in federation service properties in ADFS that allows the Local System account to have service admin permissions. Enabling that solved the problem but I’ll keep your suggestion in mind for the future.

1 Like