Question :
I’m thinking about using MSA (or gMSA) as proxies inside my SQL Server instances. This proxies would be used for example for running SSIS packages or xp_cmdshell command.
But based on what I’ve gathered there was a problem with using managed accounts inside credentials, because there was no way of providing password during creation of such credential.
Here is an old thread about SQL Server 2014:
SQL Server 2014: Using gMSA for xp_cmdshell Proxy Account?
Few years have passed since then and I wonder if anything has changed and is there a way of creating proxies with managed accounts?
And if there isn’t a way – what is currently considered “best practice” in creating such proxies? Does use of domain user instead of MSA is a good idea? Or maybe there is a way to abandon proxies altogether?
I don’t know if I’m correct in my thinking but after an extensive search in world wide webs it seems like integrating SQL Server with a domain is looked over by most and not much information can be found.
Answer :
Under the default configuration, SQL Agent uses a virtual account, and can access remote resources using the Computer Account (YourDomainYourServer$). If your server is dedicated to SQL Server, and you don’t need multiple identities with different network privileges, then you don’t need SQL Agent proxies at all. Just grant the Computer Account the required privileges.
If you do need different agent jobs to run with different network permissions, you must use a regular domain account for proxies. You don’t have access to the password for a MSA or gMSA, so you can’t create the credential required.
Very interesting question.
You made me dive into the magic world of internet till I found this article about xp_cmdshell security.
I found out a good guide for you about how to setup Proxy Accounts and make them work with SSIS.
Is a bit old but so is the feature you want to use 😉