Active Directory SQL Authentication and the Scan Engine Service

Owned by Conor McCann
Last updated: Dec 09, 2022 by Andy Trayler
2 min read

Problem

At install, the iQSonar Scan Engine service is always configured to run as the Local System account.

When the user specifies Windows Authentication for SQL Server during the installation process, the following is what happens.

  1. The Windows credentials (username, domain and password) are encrypted and written to the app.config file.
  2. When the service starts, if these additional settings are present in the app.config file it extracts the values and impersonates that user.
  3. If the impersonation attempt fails or subsequently stops – which we have seen a couple of times – the error will be caught, written to the service log and the service will continue on it’s merry way.
  4. The service will not be able to connect to the database after this (to pick up jobs etc..) because the Local System account – which the service is now running as – will not have permission.


What all this means is, if the customer uses Windows Authentication,  even though the service appears to be up and running, it could be dead inside (like Nicholas Cage).  To be sure the service is running – check the Server State in the database using the following query.

select s. ServerId, s.Hostname, ss.Name as State
  from config.t_Server s
inner join config.t_ServerState ss on ss.ServerStateID = s.ServerID

If the service is listed as Stopped in the database, restarting the service may resolve the issue. However, you should also check the service log and event viewer for a clue as to what caused the issue – we can’t simply attribute it to the customer’s environment.

Solution


  • If authentication fails on service start it will be caught, handled, written to the log and the service will fail to start. 
  • If impersonation stops working after start up, that’s when the lights are on but there is nobody home.