Using the Anonymous Job Setting

[Legacy User]

Hi Community!

I wanted to share some information on the Anonymous Job setting available through the Automation Engine. This setting allows the Automation Engine to use the Agent's OS user to execute jobs instead of the user specified in the Login object. There are few scenarios where this would be necessary but it is an important feature to share. The setting can be found within the User Interface on Client 0000 and is valid for all clients within the Automation Engine. Within the UC_HOSTCHAR_DEFAULT variable located in the HOST_VARIABLES folder you can find the ANONYMOUS_JOB key which can be changed to 'Y' or 'N'. You can find all the details within our documentation in the link below.

https://docs.automic.com/documentation/webhelp/english/AWA/11.2/AE/11.2/All%20Guides/help.htm#ucaabu.htm?Highlight=ANONYMOUS_JOB


Note: Even with Anonymous Jobs enabled, the Automation Engine still always checks at the beginning of a job's execution whether a Login object is available including an entry for the particular platform. If there is no corresponding entry, the job will abort. This means you will still need Login Objects to execute jobs but the credentials will not be used during job execution.

I hope this is helpful!

[Legacy User]

Hi Andrew_Garland_7890,

I was trying the Anonymous_JOB feature in v12.02, and had a question. If have the Anonymous_JOB enabled in client 0, and the default agent on AE server configured with the logon=0 option, can I assume that this change will only impact jobs running on the default agent? There should be no potential impact on other agents, if they are configured with logon=1, correct?

Also, I do see a warning that AE does not recommend the logon=0 setting in the documentation. Are there any known issues with this approach?
https://docs.automic.com/documentation/WEBHELP/English/ARA/11.2/AE/11.2/All%20Guides/Content/ucaabu.htm 

Thanks,
Latha Vijayagopal

[laura_albrecht_automic]

I have to say that I find this a little confusing.  I've got a very strange environment here - multiple organizations (2 companies merged) and different security settings for each.  Also within each org - there are different requirements / needs for the various agents.

I'd love to have all my agents configured the same, but it's near to impossible at the moment.  So I've got a variety of settings configured, multiple UC_HOSTCHAR_* variables, some with ANONYMOUS_* = Y and others to N.  And some agents (UNIX) with login_check=yes and some agents (Windows) with login_check=no.

Additionally, just ran into another scenario where I have a UNIX agent installed on a JDE server - but the only reason to date we needed that agent was for a GET_FILESYSTEM call.  No jobs were actually running on the agent, so for security reasons, we left the agent owned by the OS user, not root.  This worked fine, but now I DO want to run jobs as the OS user.  I still don't have to have the agent owned by root, but it appears I have to have ANONYMOUS_* set to N and login_check=no to get jobs to run.

 :s 

So confused on what the best practice here and the implications of all these things.  I want to have the most secure system as I can, but honestly, this is a lot of trouble.   :)   

Anyone else have a complex environment like this and how to you handle / manage?  I don't want to have a UC_HOSTCHAR_* variable for each agent, but seems like I need to have more than the DEFAULT for sure.

If anyone has any thoughts / comments specifically on this topic and/or the security aspects of the various settings - I'd love to hear it.

TIA.