Automic V24 windows agent & windows job: Either a required impersonation level was not provided, or the provided impersonation level is invalid'.

[James Ebaynor]

Hello & Happy New Year Community,

     V24 windows agent starts up fine via SMGR and using admin credentials defined in SMGR.

      When running simple windows job using the same admin credentials in LOGIN object, job Faults-Other w/ "Either a required impersonation level was not provided, or the provided impersonation level is invalid'.

      If I remove the admin credential from SMGR and try starting the agent - it doesn't start & doesn't create a log - making me think its not finding java.

     Any help or guidance much appreciated!

     SMGR-Dialog definition for agent:

Last few lines of agent log:

[Leon Carroll]

Theres a series of additional rights to be added for a defined user to run the agent - 

https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/24.3.0/Automic%20Automation%20Guides/Content/InstallAgents/InstallAgentWindows_Java.htm?tocpath=Installing%7CInstalling%20the%20Agents%7CInstalling%20On-Premises%20Agents%20Manually%7CInstalling%20the%20Agent%20for%20Windows%20(Java)%7C_____0

See additional rights required here.

[James Ebaynor]

Hi Leon,

     Thanks for the quick response. 

     Indeed - I recall those extra rights that must be added, remember them from back in V9.

     I added them - but still getting the error.

• Act as part of the operating system
• Adjust memory quotas for a process
• Back up files and directories
• Log on as a service
• Replace a process level token
• Restore files and directories

   In looking at the error message, it seems that the agent can't write the temp job report file (OAACHEME.TXT in this case), to the agent temp folder.   I have adjusted that folder and given full access.

[Peter Daransky]

Hi,
it's bit complicated :-) So few questions before:

1.) How is the Smgr started ? Is it started, as service "Local System" ?
2.) What is the Job setup you're trying to start ? (Interpeter Type/Batch Mode/View Job on Desktop/Use Windows OS Job)?

BR p 

[James Ebaynor]

Hi Peter,

     As seen in services, the Service-Manager is being started as Local System (in the "log on as" field).

     The job is defined as "batch", but I have tried several of the other options such as 'command' and 'logon as batch user', etc. - but same error is the result - Either a required impersonation level was not provided, or ...

[Peter Daransky]

Hm, 
think now we reached the point where I'll need a trace to take a look :-(
But other question (just curious), why you want to use it in this way ? 
I mean, the "Logon As" option in Smgr comes from Win95 era where the jobs can interact with desktop. But this is meanwhile very specific and restricted use case, at least since Windows Vista (where UAC and service isolation was introduced).  If the Agent is running as Service, it runs in isolated Session so there is no desktop. So it do not make any sense to me ... 

Concrete, through the Local System the Smgr is started as "super user", but then through the "Logon User As", the Smgr starts the Agent as particular user (in interactive mode - probably also UAC will apply). So and finally if the Logon=1 in INI is set, the agent will try to start the tasks (Job/FTs) as different user which will require all the "superuser" permissions again. 

Anyway, back to your case. Based on the screenshot (Agent log) it looks like, the Job is done (Process completed) and the AE is trying to transport the Report? The message in log does not really complains about permissions on file, I think the Agent tries to switch to the particular user and this, what's not working ? 

[James Ebaynor]

Hi Petar,

    So - I removed the credentials (which was my local User account & an administrator) from the windows-agent Smgr entry, biunced the agent, ran the job, and now get:  Error code '2', error description: 'The system cannot find the file specified.'.  Based on prior message, I would think it is the temp job-report file it can't find.

[James Ebaynor]

Still unable to figure this out. User who starts agent is an administrator. Have granted all rights to the agent \temp folder where the job report temp file wants to be written. Also tried pointing log file to elsewhere via INI logging parameter. 
added the 6 required agent rights via local security policy. 

[MesutAydin]

Hi James,

Could you check an antivirus program on the server? We had a similar problem with Mcafee.

[James Ebaynor]

Thanks for replying,, Looks like only Microsoft Defender is active, but the virus protection is off,,

[MesutAydin]

Hi James,

I see the Trellix application in the screenshot you showed. Trellix was formerly known as Mcafee. Could you look at the logs of the Trellix application? 

[James Ebaynor]

Hi Mesut,

    I think you nailed it! Check out the screenshot.

[MesutAydin]

Hi James,

If I were you, I would ask the Mcafee admin to exclude these directories. Because we solved this problem ourselves by excluding folders it :)

also could you look at arcticle https://knowledge.broadcom.com/external/article/103750/windows-agent-suspicious-double-file-ext.html

[Leon Carroll]

Just out of interest, does the processes work if you roll back to an Automic V21.0.12 agent?  

On some servers, not all, I find that python pip installs don't work on V24.3 but do with a V21.0.12 agent.  I think this is to do with how the agent starts up under java.  I'm using the defaults, starting up with the service manager without a user specified, the user to run the job has log on as batch allowed and the job is set to log on as batch.  

Elsewhere python keychains aren't accessible with V24.3 but work with 21.0.12 agents.

[James Ebaynor]

Hi Leon,

    I did indeed try connecting a v21 windows agent (not the java one, but the older c++ one) to v24 engine. I gave up when I had certificate issues, "Unexpected error on connection '*SERVER' (socket handle = '1'), reason '"category: 'asio.ssl', (167772294) certificate verify failed (SSL routines)"'.

   Thanks for that thought and idea though. I think Mesut has isolated the root issue - which is "Trellix endpoint security" blocking what is sees as a threat - the temp job report file in the agent temp directory - "\windows\temp\JAACJHFI.TXT.BAT, violating the rule "Suspicious Double File Extension Execution", and was blocked

    Interesting, as it appears the agent want to rename the temp file and add .BAT to it.

[James Ebaynor]

Hi Mesut,

     Thanks for your expertise. The Admin team is tweaking Trellix (McAfee) exception, and I see different flavirs of the same message - so I know we are getting close. Appears their exception is for "C:\AutomicV24\Automation.Platform\Agents\windows" and I suggested to them they take it down to the temp folder, "C:\AutomicV24\Automation.Platform\Agents\windows\temp"

[MesutAydin]

Hi James,

Can you request an exclude for the "ucxjwx6.exe" process? 

[James Ebaynor]

Hi Mesut,

     That worked. The exception was applied to Trellix and now I can run windows jobs on agent. Thanks for all your valuable insights.

[Mladen Ilisinovic]

Hi,

Just wanted to say that I had almost identical error in my  log  but  it seems that there was  other issue:

despite fact I gave all permissions to the user I used for windows , I needed to add  this :

• Agents running on Windows Server 2012 and higher versions: To avoid problems while executing actions (access denied), you should change the value of User Account Control: Run all administrators in Admin Approval Mode to Disabled in the Security Settings / Local Policies / Security Options section of the Local Security Policy application (secpol.msc). This ensures that the Windows Agent using the local Windows administrator account (although in the administrator group) can execute actions properly.

After that policy was applied, I lost errors from my log.

best regards,
Mladen