Announcing Active Directory Identity Improvement on AKS on Azure Stack HCI
Published May 20 2021 08:05 PM 9,053 Views

We’re very pleased to announce that Group Managed Service Account (gMSA) for Windows containers with non-domain joined host solution is now available in the recently announced AKS on Azure Stack HCI Release Candidate!


The Journey

Since the team started the journey bringing containers to Windows Server several years ago, we have heard from customers that the majority of traditional Windows Server apps rely on Active Directory (AD). We have made a lot of investments in our OS platform, such as leveraging Group Managed Service Accounts (gMSA) to give containers an identity and can be authenticated with Active Directory. For example, this blog showcased improvements in the Windows Server 2019 release wave: What's new for container identity. We have also partnered with the Kubernetes community and enabled gMSA for Windows pods and containers in Kubernetes v1.18. This is extremely exciting news. But this solution needs Windows worker nodes to be domain joined with an Active Directory Domain. In addition, multiple steps need to be executed to install webhook and config gMSA Credential Spec resources to make the scenario working end to end.


To ease the complexities, as announced in this blog on What’s new for Windows Containers on Windows Server 2022, improvements are made in the OS platform to support gMSA with a non-domain joined host. We have been working hard to light up this innovation in AKS and AKS on Azure Stack HCI. We are very happy to share that AKS on Azure Stack HCI is the first Kubernetes based container platform that supports this “gMSA with non-domain joined host” end-to-end solution. No domain joined Windows worker nodes anymore, plus a couple of cmdlets to simplify an end-to-end user experience!



“gMSA with non-domain joined host” vs. “gMSA with domain-joined host”

gMSA with non-domain joined host gMSA with domain-joined host
  • Credentials are stored as K8 secrets and authenticated parties can retrieve the secrets. These creds are used to retrieve the gMSA identity from AD.
  • This eliminates the need for container host to be domain joined and solves challenges with container host updates. 
  • Updates to Windows container host can pose considerable challenges.
  • All previous settings need to be reconfigured to domain join the new container host.





Simplified end-to-end gMSA configuration process by built-in cmdlets

In AKS on Azure Stack HCI, even though you don't need to domain join Windows worker nodes anymore, there are other configuration steps that you can't skip. These steps include installing the webhook, the custom resource definition (CRD), and the credential spec, as well as enabling role-based access control (RBAC). We provide a few PowerShell cmdlets to simply the end-to-end experience. Please refer to Configure Group Managed Service Account with AKS on Azure Stack HCI.


Getting started

We have provided detailed documentation on how to integrate your gMSA with containers in AKS-HCI with non-domain joined solution.

  1. Preparing gMSA in domain controller. 
  2. Prepare the gMSA credential spec JSON file (This is a one-time action. Please use the gMSA account in your domain.)
  3. Install webhook, Kubernetes secret and add Credential Spec.
  4. Deploy your application.


If you are looking for this support on AKS, you can follow this entry on AKS Roadmap [Feature] gMSA v2 support on Windows AKS · Issue #1680.


As always, we love to see you try it out, and give us feedback. You can share your feedback at our GitHub community Issues · microsoft/Windows-Containers , or contact us directly at





Version history
Last update:
‎May 20 2021 08:21 PM
Updated by: