Complicated Catch 22 with ServiceManager Services and Engine/Agent

[Alexander Kaplan]

So this is a fairly complex issue in terms of possible solutions and why they are not working. First, we are doing a clean install of Workload Automation 12.1. The issue in a nutshell is that, when we run the ServiceManager service under the Local System Account, we can run the agent service, but not the engine services. The error we receive in the engine logs states that the engine is attempting to log in to the database using the Local System Account, instead of the Windows service account that is hardcoded in the config ini. I believe that this is because our environment strictly uses Windows Authentication to SQL databases, so our ODBC connection on the engine server is set to Integrated Windows Authentication. I have attempted doing the SQL authentication and simply typing in the domain account and password, but this causes the ODBC to fail.

 

This, in itself, would not be an issue. Simply set the ServiceManager service to run under the Domain service account and the engine services will run. This is true, but, when the ServiceManager service is set to run under the Admin account the agent service will not run. We receive error 1314', error description: 'A required privilege is not held by the client.' I have reviewed the required permissions for the account multiple times and I believe all are granted by the Local Admin membership of our account.

 

In summary: When SM service runs as SYSTEM, the agent works fine and can run jobs, but the engine tries to hit the database as the SYSTEM and so cannot run. When the SM service runs as our admin service account, the engine works fine, but we receive error 1314', error description: 'A required privilege is not held by the client.' 

 

The reason we want an agent on our engine is for the transport case, because our utilities are installed on the engine servers for dbload and unload. Two solutions we are pursuing is supporting two different SM services, one using SYSTEM and the other using the admin account, which works, but come on.... And the other is installing the utilities on agent servers, separate from the engine servers, which we have yet to test.

 

Ideally, I would like to get the admin account to have the correct permissions to the server, or find a way to pass the windows account id and password without using integrated authentication that passes the SYSTEM id to the database.... 

 

Any help is appreciated.

[Chandru.Venkataraman]

I suppose this is for Automic Workload Automation?

[Chandru.Venkataraman]

I have moved the question to CA Automic WA Community.

Please ensure the admin account starting the Agent has the following user rights and privileges assigned:

 

• Act as part of the operating system
• Adjust memory quotas for a process
• Allow log on locally
• Back up files and directories
• Logon as batch job
  
• Logon as service
• Replace a process level token
•  Restore files and directories

[LuuLe]

Hey alexanderkaplan602718,

 

Were you able to resolved the issue with the 1314 error with Chandru suggestion? Or let us know if it ended up being something else that resolve the issue or if you still have the issue.

Thanks,
Luu

[Alexander Kaplan]

Predictably, it was a security issue. We had the account in the admin group, but it was being overridden by group policy at the windows admin level. We had to have security create a new group policy for AWA and apply it to the servers in the environment. Everything is now working off of the admin account.

 

Thanks

[LuuLe]

Awesome to hear that you were able to resolve the issue and thank you for sharing your finding with the Community