Some users unable to remote submit after security group changes

[stateworker1]

Our office recently made some extensive security group updates and changes of permissions on the server where SAS sits.  Some of us can still remote submit work as always while others (in different security groups with more restrictive permissions) cannot.  Because several security group permission changes were made at once, we haven't been able to track down just where permissions were removed that need to be put back.  We know it is a permissions thing because those who can remote submit are able to do so from a local SAS session of someone who isn't (just signing on as ourselves).  All users have modify/read-execute permissions to SAS Work, and adding full permissions to SAS Home doesn't seem to fix the issues.  So we are thinking there must be something buried somewhere that we need to figure out where it might be.  Any ideas of where to look?

signon rhst user=_prompt_ pass=_prompt_;

Error message:

We use a spawner, if that helps.

[Tom]

Looks to me like they have lost the ability to signon to the target machine where they are trying to start the remote session.

Are your SAS servers running under Windows or Unix or something else?

[stateworker1]

Windows.

[SASKiwi]

Check if the users who can't sign-on have the "log-on as batch job" capability set for your SAS App server.

Edit: I also suggest you review the SAS/CONNECT spawner log.

[Sajid01]

Hello @stateworker1 
The error clearly indicates authentication failure to the remote host RHST.
This is something the   OS administrators , IT Security , identity management etc. depending upon your setup need to look at.
One easy way is to compare the groups of those who can connect and those who cannot connect and take remedial action based upon the differences.
Do look at the connect spawner logs as suggested by @SASKiwi 

[stateworker1]

SOLVED!  We found where the permissions had been originally set with a separate security group.  That group had been decommissioned which caused the problem, under the Log On as a Batch Job local security setting.

[SASKiwi · Accepted solution]

@stateworker1  - Please update your post as answered in that case.