Using gMSAs for Agent-Less Network Discovery

Now, this is going to be the final blog article about gMSAs – hopefully. In fact, it’s been a JDisc customer that asked if JDisc Discovery is supporting gMSAs. At that time, I responded to the question with another question: “What are gMSAs?” In this blog article, I’ll walk you through what’s required for using gMSAs for Agent-Less Network Discovery.

Getting Started with gMSAs

Initially, I only wanted to explore the subject and shed some light on it – as I didn’t know much about gMSAs. I investigated gMSAs in the following days and wrote the initial article Boost Security Using Group Managed Service Accounts with my findings.

Based on my findings; I figured out some obvious use for gMSAs like running the JDisc Discovery Zero-Footprint Agent service. It turned out to be a good fit for combining How to discover Windows computers with non-admin access which is a blog article that has been around for quite some while.

Deepening The Understanding of gMSAs

As there were now two articles about gMSAs and another one related to privilege elevation for Windows discovery, I condensed and linked those into a single new blog article Boosting Windows Security & Discovery with Non-Admin and gMSAs. I did that to make it easier for you to read and apply to your IT infrastructure. This was the time when I thought, the topic is covered well enough.

Exploring gMSAs for Agent-Less Discovery

Still, I wasn’t completely satisfied with the results — mainly because JDisc Discovery is an agent-less solution, and gMSAs didn’t appear to be usable directly as access credentials for Windows systems.

For Microsoft LAPS, we successfully integrated with Active Directory to use LAPS-managed accounts as access credentials for JDisc Discovery. This led me to wonder whether we could do the same with gMSAs, which are automatically managed at the domain level — including password rotation — unlike LAPS, which manages accounts only at the local machine level.

Once more, I began exploring whether gMSAs can be authenticated over the network in a Windows domain environment. It turns out they can — if certain conditions are met. So, what does it take to get gMSAs working for agent-less discovery?

Requirements for Enabling gMSAs with Agent-Less Discovery

For gMSAs to function properly, your Windows Active Directory domain environment must:

• Utilize the Kerberos authentication protocol. You may already be aware—Microsoft is gradually retiring the NTLM (NT LAN Manager) protocol in favor of more secure options like Kerberos. Switching to Kerberos is a smart move, regardless of whether you plan to use gMSAs or not.
• Have proper DNS name resolution—both forward and reverse lookup. You probably are aware of that and have your DNS configured correctly.
• Every computer must have a Service Principal Name (SPN) for the Host or RestrictedKrbHost service class, which is normally automatically assigned to computer accounts in Active Directory.

Now that you know how to prepare your Windows Active Directory domain environment for gMSAs, the next step is to create a gMSA and link it to a global Windows domain group.

Create a gMSA and Global Windows Domain Group

A Group Managed Service Account (gMSA) is a type of managed service account used within a Windows domain. As the name implies, it also involves a global Windows domain group, which includes a set of Windows computer accounts that are permitted to retrieve the gMSAs password. Moreover, a gMSA must be installed on a computer to enable that computer to authenticate using the account.

The figure below illustrates a typical gMSA Windows ecosystem:

It’s time to get some hands-on experience with gMSAs. This blog article walks you through all the required configuration steps: Boost Security Using Group Managed Service Accounts.

Please follow the guidance provided in the blog article, ensure that the “msa-Discover” gMSA is installed not only on your discovery server but also on every Windows computer you intend to discover using the “msa-Discover” account.

Finally: After installing the gMSA on all the Windows machines where it will be used, ensure that the gMSA is added to the local administrators group.

You are now prepared to using gMSAs for agent-less network discovery and to incorporate it into the discovery configuration. Let’s move on to the JDisc Discovery Configuration.

Add the gMSA to the Discovery Configuration

Including the gMSA in the directory discovery configuration is the simplest approach.

Navigate to the Scope > Directory tab and select the directory objects where the gMSA should be configured as the access credential for the discovery.

After making your selection, click the Change Account button to open the Modify Directory Object Account dialog-box.

Specify the gMSA in the User name field, appending a dollar sign ($) to ensure it is interpreted correctly as a gMSA by the discovery process.

Leave the Password field blank, as the gMSA password is fetched dynamically by the system during authentication.

Install the gMSA on all machines within the selected directory objects for everything to work properly.

And that’s it—you’ve successfully configured a gMSA for agent-less discovery. Go ahead and run your discovery job to see it in action!

Running a Discovery Job

When you run a discovery job, the “JDISC-INTERNAL\MSA-DISCOVER$” Group Managed Service Account (gMSA) is automatically used for authentication and to establish connections with Windows computers that belong to the “Computers” and “Domain Controllers” directory objects within the “JDISC-INTERNAL” domain.

Now, let’s examine an individual computer that was discovered using the “JDISC-INTERNAL\MSA-DISCOVER$” (gMSA).

The Change Accounts context menu item brings up the Modify Accounts dialog-box.

As you can see, the “JDISC-INTERNAL\MSA-DISCOVER$” (gMSA) is displayed in the User Account but also Admin/Root Account sections. This is the locally cached account that was used during the discovery process to authenticate and establish the connection to the Windows computer.

Most importantly, there’s no sign of a password, which is expected since none exists.

With this final article on Group Managed Service Accounts (gMSAs), the journey comes full circle—from initially encountering the concept through a customer question to successfully implementing gMSAs as access credentials in JDisc Discovery. What began as a straightforward inquiry evolved into a deep exploration across several blog posts, covering the essentials of gMSAs, their security advantages, and their use in agent-less discovery. Throughout this process, I examined the necessary prerequisites, domain configurations, account setups, and practical deployment steps.

Today, JDisc Discovery is fully capable of securely authenticating to Windows systems using gMSAs—eliminating the need for manual password management. I hope this series has provided valuable insights into the potential of gMSAs and empowered you to enhance the security and efficiency of your Windows discovery process.

Cheers Thomas