GMSA Support

Problem/Justification
Group Managed Service Accounts are becoming the standard, instead of managed service accounts, in Windows servers.

Impact
In a windows server environment, services can run under a Group Managed Service Account, where passwords aren’t known, and rotated regularly. These are usually defined as DOMAIN\gmsa-account$ and do not require the entry of a password.
When services need to access SMB shares, TrueNas doesn’t have the support for the gmsa, so access is denied.

User Story
When selecting AD or LDAP users for ACL, having the ability to choose a gmsa that a service is running under on a windows machine would give access to those stores. This eliminates the need to change service account passwords on multiple machines (domain controller, TrueNas, etc) and affords a more secure system, especially where ACL is concerned.

Example:
Running a document storage system such as FileBound or DocMgt, the service requests the document images. The images are then served to the user through a web interface, with the service (whether it be a windows service or an IIS app pool) then serves the document images to the end user.

The service can run under a GMSA, however, that GMSA account currently can’t be a “user” in TrueNas.

Can’t you just add the GMSA to a normal security group that has access to the files?

@Greg_Baughman Did you get this to work? I’m looking for a solution to this problem. We would like to use gMSA accounts on a windows server to be able to write files to a smb share on our truenas server.

I am also very interested in this question. Please tell me, is there any solution to this question? I need to give the gMSA user access to the SMB share TrueNas Scale. It seems that if you include gMSA in the group and then give the domain group access to the TrueNas network resource, it does not work

That is exactly how it currently works. I created a gmsa account, added it to a security group, and then added the security group in TrueNas.