Azure-pipelines-agent: Agent installer does not support group managed service accounts (gMSA)

[michael-baker]

Agent version and platform

2.117.2 (from https://go.microsoft.com/fwlink/?linkid=851123) on Windows.

OS of the machine running the agent?

Windows Server 2016

VSTS type and version

On-Prem TFS - TFS 2017 Update 2

What's not working?

I am attempting to use a gMSA (group managed service account) for my build agent but the unattended install progress does allow me to install the agent as a Windows service as it the installer does not understand that gMSA users do not need to provide a password.

My PowerShell install script invokes config.cmd thus

.\config.cmd --unattended --url $tfsHost --auth Integrated --pool $agentPool --agent $agentName --windowslogonaccount "domain\buildservice$" --runasservice --work "$workingDirectory" --replace

This fails with Invalid configuration provided for windowslogonpassword.
If I provide a blank value for --windowslogonpassword the same error occurs.

If I provide a " " (space) the install will fail due to invalid credentials.

My work around is

1. remove --runasservice and --windowslogonpassword
2. Register AgentService.exe with SC.exe manually
3. Profit! The agent successfully connects to TFS and everything works.

Logs of failure

Agent: stoic_tiger Working directory C:\B\641
Installing agent stoic_tiger

>> Connect:

Connecting to server ...

>> Register Agent:

Scanning for tool capabilities.
Connecting to the server.
Successfully added the agent
Testing agent connection.
2017-11-13 04:43:53Z: Settings Saved.
Invalid configuration provided for windowslogonpassword. Terminating unattended configuration.

It would be good to have the installer understand gMSA so I do not need to call SC.exe myself.

[bryanmacfarlane]

The agent uses OAuth tokens per build to access resources. Is there a specific reason you need the service to run as a gMSA account instead of network service or local system? Our goal is the account the agent runs as is mostly irrelevant. I'm interested in your scenario.

[michael-baker]

Our build has many integration points. In some of these points we need login to various services or access resources a valid Windows user account (not machine like Network Service), so for us the agent needs to run as a Windows user.
gMSA lets us achieve this without having to worry about passwords in scripts which setup the agents on the machines in the build farm.

[bryanmacfarlane]

Thanks. We will add to our backlog and leave this open so you can track progress

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Michael Baker [e-mail]
Sent: Sunday, December 10, 2017 3:00:03 AM
To: Microsoft/vsts-agent
Cc: Bryan MacFarlane; Comment
Subject: Re: [Microsoft/vsts-agent] Agent installer does not support group managed service accounts (gMSA) (#1294)

Our build has many integration points. In some of these points we need login to various services or access resources a valid Windows user account (not machine like Network Service), so for us the agent needs to run as a Windows user.
gMSA lets us achieve this without having to worry about passwords in scripts which setup the agents on the machines in the build farm.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvsts-agent%2Fissues%2F1294%23issuecomment-350534326&data=04%7C01%7Cbryanmac%40microsoft.com%7C95ac0b134f874afd3beb08d53fac67e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636484932070898081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=cjG17NnrHtKFuvcUd9hx7XCtJp6L44IuAsp%2BVdMoSNQ%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA4IDOelBZaIG43aVqreATJWvpLmMYKMks5s-52TgaJpZM4QbZGr&data=04%7C01%7Cbryanmac%40microsoft.com%7C95ac0b134f874afd3beb08d53fac67e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636484932070898081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=JolGjCmZ92QgIpRX1WzOCpHqiD%2BUOwhWaSTmfMp4Z3w%3D&reserved=0.

[jabbera]

gMSA are also great for on prem release agents that are in deployment groups. No one need to know the password of the deployment account then.

[TingluoHuang]

@michael-baker @jabbera any of you would like to can help me testing some private bits about gMSA support, since i don't have an environment for testing? :D

[jabbera]

Sure but it would have to be compantible with TFS 2018z

[TingluoHuang]

@michael-baker @jabbera can you share an agent diag log that failed to configure the agent as service using GMSA? i want to see what is the current error we have, you can send me as email. tihuang @ microsoft.com

[TingluoHuang]

I have create a branch with my changes that might enable GMSA support. :)
https://github.com/Microsoft/vsts-agent/tree/users/tihuang/gmsa

Steps to test:

1. git clone the repository
2. git checkout users/tihuang/gmsa
3. run cd src/
4. run ./dev.cmd layout
5. run cd ../_layout
6. run config.cmd to configure the agent.

the _layout folder is the agent folder, if needed, you can zip it and copy across machines.

please share with me the diag log after attempt to configure.

Thanks for help me testing this.

[DHowett-MSFT]

Has there been any movement on this?

[michael-baker]

Hi

Wonderful work, I will get my team to pickup this branch and see if this works for us. Sorry for the very long delay in getting back to you.

[TingluoHuang]

@michael-baker @DHowett-MSFT
I tested the branch myself and i am hitting windows api error while configure the windows service as gMSA account. the only way i find was configure the windows service as network service first, then use SC.exe to change the running account. :(

[tastyeggs]

Would be really nice to get this working. Currently the only service that requires a domain user in my entire cluster are these build agents.

I tried applying the workaround above, but the agent didn't come online (I probably did something wrong).

But as a security best-practice, would be really nice to get first-class support for MSAs.

[michael-baker]

I currently do the same workaround as @TingluoHuang
.\config.cmd --unattended --url $tfsHost --auth Integrated --pool $agentPool --agent $agentName --windowslogonaccount "domain\tfsbuildservice$" --work "$workingDirectory" --replace

Then

$command = "sc create `"VSTS Agent (tfs.$agentName)`" binpath=$agentInstallationPath\bin\AgentService.exe obj= `"domain\tfsbuildservice$`" start= delayed-auto"
& cmd /c $command
net start "VSTS Agent (tfs.$agentName)"

[tlofreso]

Thanks. We will add to our backlog and leave this open so you can track progress Get Outlook for iOShttps://aka.ms/o0ukef
…

On the topic of tracking progress... how's this coming?

[Justin-DynamicD]

Following up/echoing this:

It's a pretty common scenario for build agents to need to "reach out" and grab artifacts or even run test frameworks as a domain-authenticated account. Being able to use a gMSA account seems rather ideal here.

[avivanoff]

How come the support for gMSA has not been added after more than two years it was asked for? If I am not mistaken, it should not be harder then allowing to specify no password during configuration.

My workaround is to configure the agent service to run as NETWORK SERVICE, and then use sc.exe to reconfigure the created service:

sc.exe config vstsagent.Org.Pool.Name obj= [email protected] password= ""

Next, remove NETWORK SERVICE from VSTS_AgentService_XXXX group and add [email protected] instead.

[gabrielmccoll]

Another plea for making this easier to implement without workarounds.

[jeremymcgee73]

I just want to add this is a feature we would like to use as well.

[peterbarendse]

Would love to have this feature implemented!

[github-actions[bot]]

This issue has had no activity in 180 days. Please comment if it is not actually stale

[gabrielmccoll]

Not stale.

[tastyeggs]

Not stale

[gabrielmccoll]

What the deuce. People commented not stale. Bad bot.