using "opsys: windows" in machine definition causing USERNAME environment issues

Products

• Autosys Workload Automation

Issue/Introduction

Jobs requiring kerberos authentication not working when "opsys: windows" defined in machine record as USERNAME variable in agent environment is being upper-cased by Autosys agent when jobs are launched. Removing that entry in machine record returns expected behavior.

Workload Automation AE Manual says its best practice to have this defined for windows hosts though.

Can you provide information on the impact of removing this from the windows host. What else does "opsys: windows" do? or is it just uppercasing USERNAME environment?

 

Environment

Workload Automation AE (AutoSys)

Resolution

The assumption is/was that the windows domain users case is insensitive.  And the product sends the user details in all upper case, when opsys is set to Windows.

This is the only part of the product that makes use of "opsys: ", when the job goes to run.  If all your jobs can run without needing opsys set then you can remove it from the machine definition.  If you feel more comfortable leaving it as is then we recommend using the envvars: to override the USERNAME as needed on a job by job basis.

NOTE 
An advantage that "opsys: windows" appears to give is if it is set and the job is defined with a owner that does not exist in autosys_secure autosys will fail it on the scheduler side, never sending anything to the agent.  With opsys not set autosys sends the job to the agent without the id/password and the agent will fail it.
So a potential issue could be a risk of some id getting locked on an agent host if the autosys_secure entries are not present and someone tries to run a job with ownerXYZ as the agent would try to switch to that account and fail multiple times... The number of times it could potentially try to login and fail (possibly locking the account) would be determined by your MaxRestartTrys set in the %AUTOUSER%/config.$AUTOSERV% file.