Audit fails when using a gMSA on a network share

  • I have a test server (SQL 2017) on which i changed the service accounts for the Engine and the Agent to a gMSA. I made sure the accounts have the same group memberships as the original domain accounts, so they can access the SQL backup share on the network.

    I tested several things, including making a bacup. That all works fine. However, my Audits no longer function. The error i get is:

    Audit <audit> failed to start: For more information blahdiblah...

    The sys.dm_os_ring_buffers gives me "File: file create or open failed (last error: 161)".

    The audit file and the backup reside on the same network share, so that leads me to think it isn't a rights issue. The audit also will not work on a clean SQL Server installation using a gMSA and the network share.

    Any ideas how to get this working?

    Oh, when i put the audit file on a local drive on the sql server, it works. It's just the network share that doesn't work.

     

  • gMSA accounts are known to give errors when it comes to permissions on a network share. Do you think you could create a proxy account and use that instead

  • Cebisa wrote:

    gMSA accounts are known to give errors when it comes to permissions on a network share. Do you think you could create a proxy account and use that instead

    have thousands of these and never any issue with GMSA accounts and permissions.

  • To me this sounds like the audit is running as a different account than the backup.

    When you create the audit file on the local drive, who is the "owner" of the file and is it the same owner as the backup file?  Generally, the owner is the person who creates the file.  If they match, then I would be stumped on that.  If they don't match, that may explain why your backup succeeds but the audit fails.

    The above is all just my opinion on what you should do. 
    As with all advice you find on a random internet forum - you shouldn't blindly follow it.  Always test on a test server to see if there is negative side effects before making changes to live!
    I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.

  • Thanks for the answers everyone.

    I did some more testing and found that the issue occurs on my SQL 2017 servers. SQL 2016 is not affected. When i change to a gMSA there, my audits keep working, regardless of the audit file residing on a local drive or a network share.

    For now i keep the auditfiles on a local drive on SQL 2017

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply