BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Gkrause
Fluorite | Level 6

Hi All,

 

I am confronted with a project specific Web Application written with SAS AppDev Studio on a Java-developer client. A couple of people use this Web Application to start Macros and/or look at Reports. When they log-in to the application they use individual accounts with individual user names. I am interested if a technical user (unix) is invoked by the application to collect the data or write results in libs if the user does something on the application. All data and programms are stored in an unix-server. The Users do also have different Unix-UserIDs to manage permissions of views/data/programms etc.

Is there a way to check if a technical user (unix) does everything which is invoked from the Web application or if somehow the Web application transfers jobs to the unix-userIDs of the person who is logged into the Web application?

 

Any help is much appreciated! Smiley Happy

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
SASKiwi
PROC Star

Its my understanding that SAS web applications use the Pooled Workspace Server for running SAS programs. If you look in SAS Management Console at the properties of your SASApp Pooled Workspace Server you will see that it runs under a SAS service account called something like sassrv. This user name  is decided upon and set up when SAS is installed so it may be different at your site..

 

This means that SAS web applications are run under the service account and not the account of the user used to log into the web application.  

 

 

View solution in original post

11 REPLIES 11
jakarman
Barite | Level 11

There is something build in house with "SAS AppDev studio" htat is build java applications like SAS-VA / SAS-Pportal. That part is running in the java app-container normaaly by a generic service account. For there it is connecting to a SAS environment that coudl be metadata-server manged or by it basic part SAS integrations Technologies (eg Workspace services).

You will have to investigate that the most easy approach would be having a weel known user starting something (running at for at least apx 20 seconds) and moniotoring wiht a Unix shell acces what is happening. Do you see different Unix user being used that that is probably coded in your java code. You could also look for the objectspawner to be found and whether it has readable loggings. The objectspawner is the one that is always used as it is the logical SAS-SSH similiarty gthat is spawing SAS processed.
Al lot of the Unix user-settings is inhirited form the user (service account)  running that  object spawner and not the expected onese as a normal SSH session does.  

---->-- ja karman --<-----
Gkrause
Fluorite | Level 6

Thank you for your reponse!

 

I checked the log-files of the ObjectSpawner but I am not sure how to interpret them. When I logIn with a User it says:

 - <User> - Request made to cluster SASApp - Logical Pooled Workspace Server 

- <User> - Redirect client in cluster SASApp - Logical Pooled Workspace Server -  to server SASApp - Pooled Workspace Server at <server.name>

-  sas - Client connection 656 for user <User> closed.

 

how do I interpret these results? Does sas function as a technical user or is my personal user active on the unix server?

 

Thanks.

Gunnar

SASKiwi
PROC Star

Its my understanding that SAS web applications use the Pooled Workspace Server for running SAS programs. If you look in SAS Management Console at the properties of your SASApp Pooled Workspace Server you will see that it runs under a SAS service account called something like sassrv. This user name  is decided upon and set up when SAS is installed so it may be different at your site..

 

This means that SAS web applications are run under the service account and not the account of the user used to log into the web application.  

 

 

jakarman
Barite | Level 11

Agree with SASkiwi if this is you userid your are looking for it is swichting by SAS (like a su command) to that generic key.
The reason for this choice could be:

- it saves th startup time (typical 1-2 second) for the starting of user-workspace.

- the sas installer guy did see it too difficult to alsing wiht user access management policies

- the Lunix/Unix guys where/are a blocking facto not allowing personal access on the machines
The choice can be acceptable for approved checked programs with a knowing behavior. The monitoring can be made part of the in house build application. For free user code there could be other requirements that now are failing. Just re-evaluate those...

---->-- ja karman --<-----
Gkrause
Fluorite | Level 6

Thank you very much.

 

One last question to be sure:

Is there a possibility to check if sassrv is the technical User when Pooled Worspace Server is started?

The Log-Files of the ObjectSpawner do not give me any answers, are there other Log-Files to check which user is in use?

 

Thanks.

 

Gunnar 

jakarman
Barite | Level 11

Gunnar, there are a lot of logfiles and even more can be configured. Having many of those you have to manage them. Saving in those managing costs it mostly ends in not being traceable auditable.

At start of the objectspawner you will find the information it reads from the metadata using a metdataserver connection. Runnig an objectspawner for very lang time you can lose those startup messages.  (rollover by day)
The metadataserver (service process) will generate its own logging. When it is on the same server (machine/os) you can find it aside that of the objectspawner. The metadataserver can be located on his own machine (very advisable). 
Every SAS proces could generate the ARM logging as configured by APM/eventmanager. Seeing those one you have the owner (the process it has been run by) and the contents events.

The best thing would be to audit the SAS metadata. The SMC is no storage location although often being told by SAS sales, but just a handy tool to manage the SAS metadata. With a well defined metadata security there is room for audit level (read access for all) with na access to run real processes. That kind of requirement altough rather sensible is a rather difficult one at SAS institute guys. 

How far do you need to go for your reviewing?

---->-- ja karman --<-----
SASKiwi
PROC Star

Check the most recent log under: \SAS\Config\Lev1\SASApp\PooledWorkspaceServer\Logs (might be a bit different under Unix)

 

I can only see the sassrv user listed.

 

The whole point of the pooled workspace server is that it runs under one service account and not under individual users' accounts.

Gkrause
Fluorite | Level 6

Thank you guys!

 

I am asking because the company I am working for has problems with its ACL structure. Therefore they want to delete all ACLs on their Unix servers and just work with one technical user with rwx-rights. I was not sure if the users on the SAS WebApp can still do their regular jobs then, but with sassrv as the only technical user I think this is possible.

Should I highlight this topic as solved or should I wait until I have results from the tests?

Smiley Happy

 

Gunnar. 

SASKiwi
PROC Star

I think we have answered the question. If there is a problem implementing your changes then that would be a different problem.

 

BTW there are several service accounts used by SAS, not just sassrv. Be careful not to remove others that might still be used. 

jakarman
Barite | Level 11

Your answer seems to be answered. Thanks for being more more descriptive on the situation.
I was expecting a move in the other direction, being more strict in security, in the era of data-breaches and privacy concerns.

As you are metnioing the Unix guys are having problems wiht ACL-types that one os bothering me and being more curious about that. ACL usage in Unix is the adoption of the Windows (microsoft) security model not using the Unix DAC (HFS) way.

Unix adepts are always making the statements about how powerfull and marvelous their system is. Obviously by your experiences this is not true and they falling back on generic service/accounts as root-like approaches because of issues. What kind of issues? 
I am curious because the ACL (not DAC) is also mentioned as the way to go in my area.

---->-- ja karman --<-----
Gkrause
Fluorite | Level 6

Hi ja karman
the problem is basically that two different companys are working on the same servers. One company is responisble for the SAS Applications and one for the Unix system (as root). It is just to much effort to communicate every change the right way therefore the companys want to be as autark as possible hence getting rid of the ACLs.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 11 replies
  • 2298 views
  • 3 likes
  • 3 in conversation