Unable to access SASApp Server from SAS EG

[AnandVyas]

Hi,

I am facing this issue in the following environment  SAS 9.4
SAS Workspace server is hosted on Red Hat Environment.

SAS EG I am using as windows client on 32 bit configuration.

I am able to connect to Metadata server using a inital profile while starting EG ( Again Metadata is hosted on Linux Box)

EG Prompts for an User ID/Pass to connect to Workspace server.

I have tried multiple ID's like Unrestricted role, SAS Installer account etc. but It does not connect.

I also tried to use an external user account (Say X) that was added as user in SMC with SAS EG Advanced role on that User account (X)

We do not USE PAM in our environment. Is there any way that I can launch the workspace server? Kindly advice.

Thanks,

Anand!

[SASKiwi · Accepted solution]

When EG is unable to connect you usually get a popup window with details of the connection errors - can you post these please?

One possible cause for the problem is that the SASApp object spawner service is not running on your server. Please confirm that all SAS services are running.

Also has this never worked successfully and you are just trying for the first time, or was it previously working OK but is not now?

[AnandVyas]

I checked and confirmed that the SASApp object spawner service is up and running and also the other services on the SASApp box. When I start the EG my profile gets successfully connected to Metadata so that means metadata is also up and running.
I am trying this for the first time. one thing that I could see logged was -  No host credentials exist to start this server.  Either the client needs to send in host credentials, or credentials need to be specified for the server.  This is when I tried using the sastrust internal account.
Is there any specific internal account that I need to use? or is there any privilege on that account I am missing that needs to be added using SMC. Thanks!

[jakarman]

The object spawner is the one that starts the workspace session, they should be on the same logical machine. That (WS) is what you can connect to with Eguide.
You could start the WS script manual in the Levx/  /Workspace subfolder using a X11 session with the intended user for Eguide. Any failure in the configuration/installation can be seen this way as some error may cause the blocking unnoticed.

As you do not have the PAM on the machine running the objectspawner the only possible account could be the key running the objectspawner

sasauth saselsrv should have root and setuid rights fore switching the usercontext and able to do validation passwords at low level system calls .      

SAS(R) 9.4 Companion for UNIX Environments, Fifth Edition  The best way fpr LDAP is not direct LDAP but the OS having solved that (host use) SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition.  In that case the Metadata will check host-ldap and objectspawner can start a host-ldap running an OS sas session.

With direct LDAP you can do the metadata authentication but the object spawner will fail as there is nothing at the os-level.

[Kurt_Bremser]

A user that can start a workspace server must be defined in the operating system. This means you should be able to log on to the server with ssh. If this is possible, try to start SAS from the commandline (you can extract the path to the SAS executable from the workspace server definition), as this might give you a clue.

UserIDs that are only defined in the metadata without a valid external account cannot start a WS.

[AnandVyas]

I agree to what you have said and that was likely which was causing this issue. After having and external authentication defined for the user using SMC connection to SASApp was successfull. Thanks a lot for your help.

[jakarman]

Kurt, there is a way to use Userids being defined in SAS-metadat wiht a completely not related generic external account. The approach is similar to a SP server or a PWS one.

You can define that as a shared account in WS definitions, the result is everybody will run at the OS level wiht that same global shared account. It is bypassing any user-access management and any rolebased acces guideline and policies for that. As you can implement that wiht no IT department and internal business security involved , the quick sales approach people are fond at that one.
No, it doesn't make sense when you are wanting to be compliant.  I am convinced some people at SAS do not care about those compliancy issues.

[AnandVyas]

Thank you all for the response. This issue is resolved.
Changes done - Updated external auth for the user trying to use WS via SMC.

Thanks!