Guest VM Agent Installation Failure

I have the same issue, however it's only impacting the install on our domain controllers. I'd be curious to understand the fix or "workaround" for this.

The issue is that most environments use some type of domain policy (we use Microsoft Active Directory) and that service accounts used by the agent installer do not have 'logonasaservice' permissions. 

There are 3 service accounts that are needed for this supposed 'off-board' system. (Not sure how it is off-board if the solution uses 4 Windows services on each VM OS but that is another topic all together.)  :) 

The 3 service accounts needing 'logon as a service' rights are:

NT AUTHORITY\SYSTEM

NT Service\SGVMManagementService

NT Service\SGVMScanningService

You have 2 choices so far. You can wait for the agent install to fail, set the services to local system and then retry the install and it should succeed. For most larger environments, this is not feasible but should be good for initial function testing. 

I eventually had to modify our domain GPOs to give the logon as a service permissions throughout my domain to the accounts above. I understand modifying GPOs is not quick and easy in most environments but I am not sure of any other way, at least in my domain. 

The fact that there is no mention of this in the startup guide, Sophos support has yet to respond to a single question I have submitted relating these accounts tells me that it wasn't tested/QA'd properly and they are probably having internal discussions on the next agent version. I think most companies will have problems with this service account as they try to install the new agent. 

Tyler Caldwell said:

 

I eventually had to modify our domain GPOs to give the logon as a service permissions throughout my domain to the accounts above. I understand modifying GPOs is not quick and easy in most environments but I am not sure of any other way, at least in my domain.  

Based on Tyler's comment about GPOs I have figured out a crude way to get the install to go through and setup all the necessary service accounts.  Here are the steps I took:

1. Create an OU in AD and set GPO to block inheritance on that folder.
2. Create and apply a GPO to that folder: Computer Configuration>Windows Settings>Security Settings>User Rights Assignment>Log On as a Service
    Enable "Define These Policy Settings" and Add the "Everyone" Group (just type in Everyone).

3. Move DC to that OU. Force Update on DC (gpupdate /force).
4. Run installer and confirmed services are setup and running (with the correct Log On As service accounts created).
5. Test Eicar file.
6. Move DC back to original OU. Force Update on DC (gpupdate /force).
7. Restart DC (for good measure more than anything) - double-check services and Eicar file.

Obviously creating GPOs and moving DCs between sets of policies is NOT best practice but it's a workaround until Sophos figure it out.  Hope that helps someone!

IT Manager2 & Tyler Caldwell 

I will feedback the information and steps you took to the development team to see about making it easier for you.  

Thanks again!

Mark 

I had the same issue on our domain controllers but after it failed I changed the service to run as SYSTEM and it continued. I'll have to submit a change request if I have to do anything that requires a reboot but I like this option -- thanks!

I had the same issue on our domain controllers but after it failed I changed the service to run as SYSTEM and it continued. I'll have to submit a change request if I have to do anything that requires a reboot but I like this option -- thanks!