Adding a gMSA acct to an AD group for directory access

[Mike Leone]

OK. We use gMSA (Group Managed Service Accounts) to run our SQL servers. I have that all set up and working correctly. Now, I've had a request from my DBA to add the acct that runs the SQL Agent service to the NTFS security on a folder, so that he can write a job for SQL Agent to move the data to a 2nd server. (basically, he writes a Powershell command that moves some data to a separate server

robocopy "D:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\Elite" //dc2fil007\Elite_DC2DDB008_Backup /mov /NFL /NDL /NJS /NJH /NS /NC

Now, rather than just add the gMSA of the SQL Agent directory to the NTFS security of both locations (source and destination), I'd like to put the gMSA into an AD group, then use *that* group on the NTFS security. (reason: I might need to add more gMSAs to that AD group).

That didn't seem to work. oh, I can add the gMSA to an AD group OK. And even assign that group to the NTFS security. But the gMSA doesn't have rights in that folder, when I try to view "Effective Access" in that folder for that account.

(I temporarily got around the issue, but explicitly listing the gMSA on the NTFS security. But I would prefer to use an AD group - I don't like using specific accts, gMSAs or users, in NTFS security. Too easy to forget to clean up the security, if you have to get rid of the gMSA or user account in future).

So how do I get around this? I've been googling, and i see references to add the new AD group to the gMSA using the -PrincipalsAllowedToRetrieveManagedPassword. But I'm not trying to add

other computers to the service account (I have a group that has the

computer account of the hosts where the service account runs, and that group

was used in the -PrincipalsAllowedToRetrieveManagedPassword when I

created the account.

So:

1. Can I do this - add a gMSA to an AD group, then use the group in NTFS security?

2, If so .. how? LOL

If I Get-ADServiceAccount, I see that it thinks its a member of the AD group I want

to use for NTFS security:

MemberOf                                   : {CN=NonProd_SQL_Server_Agent_Service_Accts,OU=Servers,DC=wrk,DC=ads,DC=pha,DC=phila,DC=gov}

So how come checking the security had all those red Xs, as if it had no access? I added it to the group yesterday, so it should have refreshed it's AD memberships by now. I haven't stopped and restarted the SQL service (or host); do I need to do that?

Thanks

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

[Mayo, Bill]

We do this all the time and don’t have any issues. My first guess would be that the problem is that the gMSA was not in the group when it “logged in”—when the service started. Restart the service and I would assume that would fix it.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Wednesday, October 29, 2025 12:33 PM
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] Adding a gMSA acct to an AD group for directory access

 

EXTERNAL EMAIL: This email originated from outside of Pitt County Government. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2Bgf%3DPLikcYO_s7fs8wAkFi_XODnVbMyua27w1m84pHrWA%40mail.gmail.com.

[Mike Leone]

On Wed, Oct 29, 2025 at 12:38 PM Mayo, Bill <Bill...@pittcountync.gov> wrote:

We do this all the time and don’t have any issues. My first guess would be that the problem is that the gMSA was not in the group when it “logged in”—when the service started. Restart the service and I would assume that would fix it.

Yeah, I *thougth* I was doing it right, but you never know. LOL I did ask if I could at least bounce the service, if not the whole host (which would effectively accomplish the same thing). But I hadn't heard back, so I needed to get the copy finished, so I bulldozed ahead and added the gMSA to the NTFS security explicitly.

Once I can bounce either the service or the host, I'll remove the explicit entry and try again,

Thanks for the partial confirmation, anyway. Thanks! 

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/8cac7638e9564ff1802432a716e11ea0%40pittcountync.gov.

[Mike Leone]

On Wed, Oct 29, 2025 at 12:47 PM Mike Leone <tur...@mike-leone.com> wrote:

On Wed, Oct 29, 2025 at 12:38 PM Mayo, Bill <Bill...@pittcountync.gov> wrote:

We do this all the time and don’t have any issues. My first guess would be that the problem is that the gMSA was not in the group when it “logged in”—when the service started. Restart the service and I would assume that would fix it.

Yeah, I *thougth* I was doing it right, but you never know. LOL I did ask if I could at least bounce the service, if not the whole host (which would effectively accomplish the same thing). But I hadn't heard back, so I needed to get the copy finished, so I bulldozed ahead and added the gMSA to the NTFS security explicitly.

Once I can bounce either the service or the host, I'll remove the explicit entry and try again,

Nope, didn't work. I bounced the whole SQL server, but the job wouldn't run unless the SQL Agent was explicitly in the NTFS Security, not the AD group I put the SQL Agent into.

[Stan Gobien]

I'm not sure about this topic, haven't used gMSA much (plan to when I get some reinforcement).

Maybe you need to add computer account of dc2fil007 also to the  PrincipalsAllowedToRetrieveManagedPassword (or the group you've set for that).

But if adding  dc2fil007 to the group, you might need to restart the dc2fil007 host before it sees its updated group memberships.

Best Regards,
Stan

Op woensdag 29 oktober 2025 om 20:42:43 UTC+1 schreef Mike Leone:

[Mike Leone]

On Thu, Oct 30, 2025 at 3:30 PM Stan Gobien <stan....@gmail.com> wrote:

I'm not sure about this topic, haven't used gMSA much (plan to when I get some reinforcement).

Maybe you need to add computer account of dc2fil007 also to the  PrincipalsAllowedToRetrieveManagedPassword (or the group you've set for that).

That's what I was trying to avoid. And others say they didn't have to do that, just add the service account to an AD group.

I'm just leery of screwing it up, and instead of adding an extra host, I would be *removing* the existing hosts... which would be Bad.

LOL

 

But if adding  dc2fil007 to the group, you might need to restart the dc2fil007 host before it sees its updated group memberships.

Best Regards,
Stan

Op woensdag 29 oktober 2025 om 20:42:43 UTC+1 schreef Mike Leone:

On Wed, Oct 29, 2025 at 12:47 PM Mike Leone <tur...@mike-leone.com> wrote:

On Wed, Oct 29, 2025 at 12:38 PM Mayo, Bill <Bill...@pittcountync.gov> wrote:

We do this all the time and don’t have any issues. My first guess would be that the problem is that the gMSA was not in the group when it “logged in”—when the service started. Restart the service and I would assume that would fix it.

Yeah, I *thougth* I was doing it right, but you never know. LOL I did ask if I could at least bounce the service, if not the whole host (which would effectively accomplish the same thing). But I hadn't heard back, so I needed to get the copy finished, so I bulldozed ahead and added the gMSA to the NTFS security explicitly.

Once I can bounce either the service or the host, I'll remove the explicit entry and try again,

Nope, didn't work. I bounced the whole SQL server, but the job wouldn't run unless the SQL Agent was explicitly in the NTFS Security, not the AD group I put the SQL Agent into.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/1dbf97a1-36f8-49a2-a283-6b7d998cdd08n%40googlegroups.com.

[Mayo, Bill]

This is definitely not necessary. The only computer accounts that need to be given permission to the gMSA are the ones where it is actually logging on, either via a service, scheduled task or whatever. From there, it is just passing credentials like any other account.

 

I am not sure why it is not working for Mike, but I have recently seen some weird issues with our scheduled tasks (which I have migrated to gMSAs) where I had to give some list permissions on grandparent directories for some things to work. I used Process Explorer to sort that all out.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Stan Gobien
Sent: Thursday, October 30, 2025 3:31 PM
To: ntsysadmin <ntsys...@googlegroups.com>
Subject: Re: [ntsysadmin] Adding a gMSA acct to an AD group for directory access

 

EXTERNAL EMAIL: This email originated from outside of Pitt County Government. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

I'm not sure about this topic, haven't used gMSA much (plan to when I get some reinforcement).

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/1dbf97a1-36f8-49a2-a283-6b7d998cdd08n%40googlegroups.com.

[Aakash Shah]

Another thing to consider:

 

I seem to recall that gMSAs being used for SQL services need SPN setup when accessing another server. The easy way to do this is to allow the account to register its own SPN by granting "Write servicePrincipalName" permission to “Self” on the gMSA itself. This will allow the gMSA to register what it needs. Then reboot the server to see if that helps.

 

-Aakash Shah

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/d73c4b5ca26e43de9fd9000927012f05%40pittcountync.gov.

[Aakash Shah]

I also seem to vaguely recall this being a “Double Hop” problem where you may need to set up Kerberos constrained delegation. I’m not sure about this though but may be something to look into as well, or others may be able to chime in with more information.

 

-Aakash Shah

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DM4P221MB15686E485FB6776583A97687F2F8A%40DM4P221MB1568.NAMP221.PROD.OUTLOOK.COM.

[Mike Leone]

On Thu, Oct 30, 2025 at 8:02 PM Aakash Shah <aakas...@uci.edu> wrote:

Another thing to consider:

 

I seem to recall that gMSAs being used for SQL services need SPN setup when accessing another server. The easy way to do this is to allow the account to register its own SPN by granting "Write servicePrincipalName" permission to “Self” on the gMSA itself. This will allow the gMSA to register what it needs. Then reboot the server to see if that helps.

That would be the advanced permission setting "Validated write to service principal name" on the security for "Self" of the gMSA? Mine are unchecked, which I guess is the default. I know I've never had to choose that setting before, although I've never used gMSAs before. I'm leery of changing anything advanced in there. And while this is a gMSA for a development SQL Server Agent, the thing is apparently in constant use, so I'd have to schedule a reboot. And if changing that broke anything, I would hope it would be just a matter of unchecking to restore functionality ...

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DM4P221MB15686E485FB6776583A97687F2F8A%40DM4P221MB1568.NAMP221.PROD.OUTLOOK.COM.

[Aakash Shah]

We grant the permissions "Read servicePrincipalName" and "Write servicePrincipalName" in the Properties section of Advanced Permissions (it’s about 3/4 way down on the right side for me).

 

To undo this, you would not only need to remove the permission, but also change/clear any ServicePrincipalNames that may have been automatically registered to the gMSA using either SetSpn.exe or Set-ADServiceAccount in PowerShell.

 

You could also consider manually adding the SPNs in which case you wouldn’t need to grant this permission.

 

Here is a MS site that references setting up this permission or adding the SPN manually:

Register a Service Principal Name for Kerberos Connections - SQL Server | Microsoft Learn

 

Here are 2 third party sites that reference this (I don’t recall where I originally read this information but just came across these):

SQL Server Group Managed Service Account Setup: Preventing SPN Registration Errors

 

(referenced from the site above)

Configure Managed Service Accounts for SQL Server Always On Availability Groups

 

-Aakash Shah

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BiQ4SDyAD4kciKnMaxwrX6_XaRMUaAQ5Kuou-SyuPqgFw%40mail.gmail.com.