How can I use GMSA integrated security in an Azure DevOps pipeline to connect to SQL Server?

The key difference is that when you use integrated security (as in your ORQA tool connection string), the connection automatically uses the Windows account under which the process is running. In your Azure DevOps pipeline, you are explicitly providing a username (DOMAIN\GMSA$) in the connection string. This causes SQL Server to try to authenticate using that account, which isn’t working as expected.

Recommendations:

• Remove the Username Parameter:
  When using Windows Authentication (integratedSecurity), you do not specify a username (or password) in your connection string. Instead, the connection uses the identity of the process (in this case, the self-hosted agent) that is running the task. For example:

  XMLCopied
  <parameter name="connectionString" defaultValue="jdbc:sqlserver://dbserver:port;databaseName=dbname;integratedSecurity=true;encryption=true;trustServerCertificate=true;Persist Security Info=false"/>

• Run the Agent Under the Correct Identity:
  Ensure that the self-hosted agent is running under the desired GMSA account (or an account that has the necessary permissions on the DB server). With integrated security enabled and no username supplied, the agent’s identity will be used for authentication.

• Avoid Mixing Authentication Mechanisms:
  Do not combine integratedSecurity with an explicit username. If you need to use SQL authentication with an explicit username and password, remove the integratedSecurity parameter and supply the appropriate credentials. However, for GMSA and Windows Authentication, integratedSecurity should be used without a separate username.

Using these recommendations should resolve the login failure error because the connection will correctly use the managed service account from the running process.