SAS Management Console Setup - SAS App Credentials Required Prompt in Enterprise Guide 9.4

[cjsummers]

Wondering if anyone might know the answer to this question. We're setting up a new SAS server, we have a service account with "Login as batch job" permission setup for the connection to SASApp. Under User Manager I have multiple users and groups setup for access. My problem is, while the service account can be used to connect to SAS App and the user accounts can be used to make the initial connection to the server, the users don't want to have to enter in the credentials of the service account each time they open up SASApp. Other than using the SASApp account for both the initial connection, I can't think of any other way to cache those credentials (if that's even possible). Additionally, is there any way users who can connect to the server can use SASApp without having that "Logon as batch job" permission? We have a multitude of users who will be using this server (along with many who will be added on down the road), so the availability to request such a change through our security department is unlikely.

[nhvdwalt]

@cjsummers

If I understand your question correctly...you are referring to the connection to SASApp when starting a Workspace server e.g. running code in Enterprise Guide.

You could add the service account's credentials under the Accounts tab for the SASUSERS group with an Authentication domain of DefaultAuth, assuming your SASApp - Workspace Server is also DefaultAuth. When a user opens the SASApp Workspace server, SAS will retrieve the credentials for the service account and forward to the Workspace server. This way, your users won't be prompted for any credentials unless the service account is not able to start a workspace server instance for whatever reason e.g. expired password

[cjsummers]

Hey nhvdwalt, that's correct, I'm attempting to the connection to SASApp when starting a workplace server. I followed your recommendation and added that service account onto the accounts section in SASUSERS, but I'm afraid its still prompting for credentials. Is there any restriction if even though I'm using defaultauth as the authentication domain (which matches the service account), I'm using the login as mydomain\serviceaccountID? (mydomain being my work domain that is).

[nhvdwalt]

1.) If you enter the credentials in the pop up screen, does the connection then succeed ?
2.) What is the Authentican config of the workspace server in SMC ?
3.) Are there any messages in the Object Spawner log ?

[cjsummers]

1) Yes, entering the service account credentials allows the connection to succeed.

2)  Host

     Security Package: Username / password

3) Here are the results from the object spawner log: (modified for confidentiality)

Service Account login (successful)

New client connection ($$$$) accepted from server port $$$$ for user Serviceaccount@DOMAIN

Encryption level is Credentials using encryption algorithm SASProprietary. Peer IP address and port are $$$$$$ for APPNAME=SAS Enterprise Guide.
2017-10-20T13:39:39,321 INFO [00039222] :serviceaccount@Domain - Created process 25388 using credentials serviceaccount@domain (child id 5).

2017-10-20T13:39:39,325 INFO [00039230] :SYSTEM@SERVERID - New out call client connection ($$$$) for launched server (child 5). Peer IP address and port are $$$$$$$.

2017-10-20T13:39:39,328 INFO [00039235] :SYSTEM@SERVERID - Launched process 25388 (child id 5) is now running as process 828.

Bad login:

User DOMAIN\$$$$ probably does not have the right to log on as a batch job.
Error authenticating user DOMAIN\$$$$ in function LogonUser. Error 1385 (Logon failure: the user has not been granted the requested logon type at this computer. ).
New client connection (3270) rejected from server port $$$$ for user DOMAIN\$$$$. Peer IP address and port are $$$$$ for APPNAME=SAS Enterprise Guide.

[nhvdwalt · Accepted solution]

You know what ? The userid and the service account probably both have DefaultAuth, so SAS first forwards the user’s account, when it fails and you enter the service account, if works.
Humour me, change the workspace server to xyzAuth and set the service account also to xyzAuth, to try and force xyzAuth as the first selection. You’ll need to restart the Object Spawner after making the change.

[cjsummers]

Sorry if this seems like a simple question, my experience with SAS is limited to say the least. I know how to change the authentication on the service account, but I'm not sure how you change the workspace's server authentication? I see you can choose to enable security and whether to use username/password or negotiate, but don't see anywhere where I can choose the authentication.

[nhvdwalt]

No problem.

I think its under the properties for the connection to the workspace server. So click on the workspace server on the lefthand of Management Console and then the connection will appear on the righthand side. Right click on the connection and go properties.

[cjsummers]

Thank you very much, nhvdwalt, that worked like a charm!

[nhvdwalt]

Great stuff.

I think in the same spot where you set the auth domain, you can also ‘hardcode’ an id to use for the workspace server. It might be in the workspace config. Try that as well, then you can decide which one works best at your site. With this one, you can leave the default config of DefaultAuth in place.

[PaulHomes]

Of course, another way to always use a service identity to launch workspace servers is to switch the SAS Workspace Server over to SAS Token Authentication. The credentials used to spawn these servers then only need to be accessible to the SAS Trusted User identity (usually by adding them to the SAS General Servers group). For more info see the SAS Token Authentication and How to Configure SAS Token Authentication sections in the SAS® 9.4 Intelligence Platform: Security Administration Guide.

I would also suggest looking into the underlying problem/requirement that is sending you down this path of configuring a single service identity to launch the servers (and losing the option for using file system access controls based on the requesting user). It is completely understandable that users would not like being asked for credentials each time they connect to SASApp. When I have seen this outcome in the past it has sometimes been a sign of a non-optimal configuration, examples including non-aligned authentication domains for the cached credentials for the initial metadata connection and subsequent compute server connections, or Integrated Windows Authentication connections to the SAS metadata server without configuring IWA support for the workspace server. Of course sometimes, with things like mixed-authentication providers, SAS Token Authentication may become a more optimal configuration. @cjsummers - it would be interesting to know the background behind the requirement to use a single service identity for your SAS Workspace Servers. Having a better understanding of the environment and constraints can lead to more tailored advice and options. 

Cheers

Paul

[cjsummers]

Good afternoon Paul, thanks for the reply, I will definitely look into that and see if using another method would be possible. The biggest hang-up seems to be the group policy that controls the "Log on as a batch job" permission the users need to open SASApp. Otherwise, I would have put in a request to have the 30-40 users added for that permission (but for my company they need an elevated account to do so and at that point it becomes messy). But considering the restrictions on using a single point of entry, file access control limitations aren't going to work either, so I think we will have to pursue getting users that access (we have 5-6 groups that can't use each other's libraries / files).

[PaulHomes]

It seems that if you use IWA then you don't need the "Log on as a Batch Job" privilege. See the Windows Privileges section of the SAS® 9.4 Intelligence Platform: Security Administration Guide.

... (users who authenticate by Integrated Windows authentication or SAS token authentication do not need this privilege)

... plus you get the benefit of single-sign-on and workspace server instances running as the requesting user so file system access controls become more relevant (to use in conjunction with metadata access controls).

However, you will most likely find you need to get your domain admins to make the compute tier machines "Trusted for Delegation" - at least that is a few machines compared to many users.

IWA can be a little tricky to configure but it's very nice when it's all running ok.