I have a set-up on RHEL that has both SASApp and SASAppVA in an integrated envionment. During installation and set-up there were issues with authentication and host authentication was implemented (rather than token). My admin account has no problems accessing all parts of both App servers. However, I'm now having trouble giving new users privelages for Visual Analytics Data Building (loading data into the LASR library).
New accounts are being set automatically by synching with new users in ldap. However, my account was set up manaully. The reason I mention this is despite giving a new user the same privelages as myself this user is also unable to upload to LASR library. On further inspection inside EG I see that while my account can access SASApp and SASAppVA when trying to access SASAppVA on the ldap synched user I get the error - user does not have permission to user server SASAppVA - Workspace Server. This is despite have the exact same privelages as my account.
I'm trying to get to the bottom of this but it's been driving me a bit crazy today. It's not that my account 'owns' any of these locations that would prevent another user from accessing. Anyone seen anything like this before? Thanks
that is a good question, and it is out there quite often.
I have to tell you, I see behind several topics, and, as such, there should be answered separately.
Before going into them, could you please share with us, details about your deployment, such as:
- SAS Solution (VA non-distributed, VA distributed, another solution that includes VAAR, etc)
- number of servers and distribution of each SASApp and SASAppVA on those server/s
- SAS Token authentication for both SASApp and SASAppVA? Host Authentication?
- account used for the Token authentication? sassrv, lasradm, another one...
- sassrv is in a group (SAS General Servers), but if you have another, as lasradm, ir the one used on SAS Token, are they part of a group as account, or are they just a user>
- What LASR server are you trying lo load data? I understand that to the "normal" LASR, not Public LASR
- If you to SASVisualAnalyticsAdministrator app, could you please let us know who (user) started the LASR servers?
With this information, we can track your situation better an help you. Thank you in advance!
Sorry it's been a long day! I meant user authentication (not host). Token authentication is not implemented. So access can be set at user level on the host OS.
Two servers - office analytics on one and visual analytics (non-distributed) on the other. SAS 9.4 and VA 7.3.
Using private (not public) lasr server.
The lasr servers (rivate and public) get started automatically when server starts so its using an ldap account (sasinst I think).
I'm not using a SAS account but my own account that has access to everything. But this account was created manually (as opposed the new accounts that get created by a ldap sync script). But even giving another user the same privelages as myself (for testing only) - this user get the error when trying to access the lasr server.
Ok, thank you. And nevermind, I know well long days as this one you got. Let's see if we can help you to ease your day.
When you ant to access a LASR server, please do not forget that, in the end, it is like a sas.exe that is running with the user as owner of the process. And it has metadata permisssions rulling its access. So, OS + metadata.
This means, that the user that will access LASR, it will have within the Data Administrator group, but also must be on same group as the user who started the server. Probably your user has the Data Admin group, but sasinst and the user are not in the same group.
Anyway, just a note: for Unix/Linux environments, I always recommend to use SAS token authentication, specially if it is a VA server (so, for SASAppVA).
Well, while the sas user and the sassers might be on the same OS group, what I meant is that they should be on the same metadata group.
About the SAS Token Authentication, the reason is basically that, if you force all your connections to be ruled by the SAS metadata (to the point, that you could even have just SAS internal users), you can LOCKDOWN (google it) or use Metadata bound libraries, and you will have a server completely secure. Of course, then you cannot share the password of the token user with nobody.
Another reason is that the connection to LDAP through PAM might have several issues and bugs (no SAS related), and it becomes easier to just delegate the LDAP authentication to the metadata server, not to your hosts.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
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.