Hello,
We have a fresh installation on a Unix cluster of SAS.
We need to use Enterprise Guide with LDAP and data restriction for some groups of users.
We changed the "host authentication" for the SASApp Logical Workspace Server in SAS Token authentication and we have created some Unix service users(foreach groups and each workspace server) .
The unix users credential are stored in General Servers Group and we have created some metadata groups to private access to workspaces.
With an HideServer ACT and the spwaner refreshed everything works fine.
The LDAP users in a Group can use the unix identity to open a workspace server with no problem.
Until here everything works fine.
The problem: if an user change the metadata Group, when Enterprise Guide try to open the workspace it gives this error:
"A connection could not be made to the requested resource."
If we restore the old Group of the user the workspace starts with no problems.
To make the changes to take effect with no issue we have to refresh the object spwaner every time the user change a Group.
After this, the user can open a workspace in EG with the new unix identity associated with its new metadata Group.
Is it normal refresh the spawner each time we change the Group of an user?
Please help nedeed.
@AsSASsin wrote:Could I use host authentcation with a system identity stored inside a metadata Group with an authentication domain?
This seems similar to SAS Token auth, but I could workaround the problem with the spawner.
Solved with this last solution.
Thank you all.
Your setup is a bit confusing, you said:
So you have more than one application server with SAS Token Authentication enabled? Why did you create multiple UNIX service accounts? Have you had any specific reasons for that? Why can't you use sassrv user for all of them? Where are you controlling access to the workspace server? On the workspace server object or somewhere else?
1. So you have more than one application server with SAS Token Authentication enabled?
No, it is only one, but the logical workspace server has a workspace server for each Group of users.
2. Why did you create multiple UNIX service accounts?
Because I need a workspace server foreach Group of users.
3. Have you had any specific reasons for that?
Yes, the phisical data that you see in EG cannot be shared between groups.
4. Why can't you use sassrv user for all of them?
Because, it is a tecnical service unix identity used by other processes and I cannot share the data between groups.
5. Where are you controlling access to the workspace server?
In management console, with metadata restricted access using an Access Control Template.
6. On the workspace server object or somewhere else?
On each workspace server.
We applied this note:
http://support.sas.com/documentation/cdl/en/bisecag/61133/HTML/default/viewer.htm#a003280630.htm
It is for SAS 9.2 but I think it is good also for 9.4 M4 that is the version that we use.
Thanks for your response.
Is it normal refresh the spawner each time we change the Group of an user?
With your current setup - yes.
But from my point of view, rather than complicating SAS configuration, just configure PAM authentication on the OS and switch to PAM authentication in SAS. In this case, you do not need to create multiple workspace servers and you can manage access to physical data based on your LDAP/AD groups. Please note in order to configure PAM on the OS level, your LDAP schema has to be UNIX enabled. This means that your LDAP schema should contain information about user's UID, GID and so on.
Thank you for the reply.
We will look for antoher configuration.
This problem with the spawner refreshing with a change in the users metadata configuration should be underlined in the public SAS support notes.
Thanks a lot.
Could I use host authentcation with a system identity stored inside a metadata Group with an authentication domain?
This seems similar to SAS Token auth, but I could workaround the problem with the spawner.
@AsSASsin wrote:Could I use host authentcation with a system identity stored inside a metadata Group with an authentication domain?
This seems similar to SAS Token auth, but I could workaround the problem with the spawner.
Solved with this last solution.
Thank you all.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.