Hi Jose,   I haven't tried using -serverparms myself and cannot find any additional documentation other than the brief descripion you get from the -help option (as you posted).    I'd suggest contacting SAS Tech Support to see if there's any extra usage/example information available. Please post back to this thread with any additional information you do get 🙂   Cheers Paul ... View more

No problem. Great to hear you got it working. ... View more

I get the same error when, logged in as the SAS Administrator (sasadm@saspw), I try to launch a SAS Workpsace Server that has been configured for SAS Token Authentication when the launch credentials are inaccessible to the metadata identity used by the SAS Object Spawner. The following is also seen in the SAS Object Spawner log file:   2017-08-10T16:33:01,079 ERROR [00000993] :sasadm@saspw - 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.   To replicate this I did the following as SAS Administrator (sasadm@saspw) in SAS Management Console: In User Manager, for a user identity in metadata (Alice), I made sure a valid user id and password were specified in the Accounts tab (demoalice + password). In Server Manager, modified the SAS Logical Workspace Server to select SAS Token Authentication In Server Manager, modified the SAS Workspace Server to select demoalice as the Launch Credentials In Server Manager, expand Object Spawner, Connect to the host and Refresh Spawner. Validate the SAS Logical Workspace Server - it fails with Bart's error (and the above in the object spawner log file). The problem lies in the fact that the SAS Object Spawner logs into the SAS Metadata Server as the SAS Trusted User (sastrust@saspw) identity which doesn't have access to any credentials that are not in it's identitiy hierarchy (SAS Trusted User, SAS System Services, SAS General Services, SASUSERS, PUBLIC) - i.e it cannot get acess to the credentials on the Alice user identity.   Move the credentials to the SAS Trusted Identity and it works. As SAS Administrator (sasadm@saspw) in SAS Management Console: In User Manager, edit the Alice user identity in metadata and remove the credentials from the Accounts tab (demoalice + password). In User Manager, edit the SAS Trusted User identity in metadata and add the demoalice credentials in the Accounts tab (demoalice + password). In Server Manager, modify the SAS Workspace Server to (re)select demoalice as the Launch Credentials. In Server Manager, expand Object Spawner, Connect to the host and Refresh Spawner. Validate the SAS Logical Workspace Server and it now works with the following seen in the SAS Object Spawner log file: 2017-08-10T16:36:28,494 INFO [00001059] :sasadm@saspw - New client connection (116) accepted from server port 8591 for SAS token user sasadm@saspw. Encryption level is Credentials using encryption algorithm AES. Peer IP address and port are [192.168.22.1]:40096 for APPNAME=ConnectionService 904400. 2017-08-10T16:36:28,510 INFO [00001059] :sasadm@saspw - Created process 9170 using credentials demoalice for user sasadm@saspw (child id 32).   Of course, with this config it also means that if someone logs into metadata using the demoalice user id and password then they take on the SAS Trusted User identity, a highly privileged user. It is safer to put the demoalice credentials on a group that the SAS Trusted User is a member of, such as SAS General Servers.   Bart, does this help describe the issue?   Cheers Paul ... View more

Hi Bart,   If you turn on debugging for the SAS Object Spawner and launch a SAS Workspace Server you will see there are several additional parameters and environment variables passed to WorkspaceServer.sh to make it behave like a workspace server. Here is an example:   2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - Command being used is /opt/sas94m3/config/Lev1/SASApp/WorkspaceServer/WorkspaceServer.sh. 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >noterminal< (Standard options) 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >noxcmd< (Standard options) 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >netencryptalgorithm< (Standard options) 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >SASProprietary< 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >metaserver< (Standard options) 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >sas94m3lnx01.corp.example.com< 2017-08-04T07:51:33,779 DEBUG [00260251] :sasdemo - >metaport< (Standard options) 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >8561< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >metarepository< (Standard options) 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >Foundation< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >locale< (Client requirement) 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >en_AU< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >objectserver< (Standard options) 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >objectserverparms< (Standard options) 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >protocol=bridge spawned spp=42875 cid=122 dnsmatch=sas94m3lnx01.corp.example.com pb classfactory=440196D4-90F0-11D0-9F41-00A024BB830C server=OMSOBJ:SERVERCOMPONENT/A53NPRYA.AZ00000C cel=credentials recon< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - Environment variables are: 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >METAUSER< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >sasdemo@!*(generatedpassworddomain)*!< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >METAPASS< 2017-08-04T07:51:33,780 DEBUG [00260251] :sasdemo - >********< 2017-08-04T07:51:33,975 INFO [00260251] :sasdemo - Created process 10308 using credentials sasdemo (child id 122).   Notice the METAUSER and METAPASS environment variables? I believe that these are a single use SAS token used for the spawned SAS Workspace Server process to connect to the SAS Metadata Server for pre-assigning libraries etc. If you look in the SAS Metadata Server log around the same time you can see a SAS Token Authentication connection:     2017-08-04T07:51:34,105 INFO [17675655] :sasdemo - New client connection (356460) accepted from server port 8561 for SAS token user sasdemo. Encryption level is Credentials using encryption algorithm SASPROPRIETARY. Peer IP address and port are [::ffff:192.168.92.25]:34946 for APPNAME=SAS Workspace Server. 2017-08-04T07:51:34,105 INFO [17675655] :sasdemo - Request made to cluster SASMeta - Logical Metadata Server (A53NPRYA.AX000001). 2017-08-04T07:51:34,105 INFO [17675655] :sasdemo - Redirect client in cluster SASMeta - Logical Metadata Server (A53NPRYA.AX000001) to server SASMeta - Metadata Server (A53NPRYA.AZ000001) at sas94m3lnx01.corp.example.com:8561.   I am wondering if those environment variables are being inherited by the additional spawned process you are launching and because the single-use SAS token has already been used you are getting an authentication error due to it's replay (trying to use a token again).   When you launch WorkspaceServer.sh -sysin from a console none of these additional parameters and environment vars are being added so it is essentially similar to sas -sysin to run a batch job (but with all of the platform configs and autoexecs being used).   To confirm this, you could try creating a wrapper shell script and unsetting METAUSER and METAPASS before calling WorkspaceServer.sh.   I hope this helps. Like @LinusH I am wondering what you are trying to achieve here? Are you trying to spawn an additional "true" workspace server from within a workspace server? Or are you just trying to run a batch job from a workspace server?   Cheers Paul ... View more

In that case I would suggest you log on to the server and attempt to run the sas_u8 command line, with all of the parameters as shown in the SAS Object Spawner log, as a user that it fails for, to see if you get any additional details are provided to explain the failure (make sure you omit any -noterminal parameter for an interactive test).   If that doesn't highlight the issue then I'd suggest the next course of action would be to contact SAS Technical Support. ... View more

It should have been created when SAS was installed. Has somebody deleted it? This is the diff between my SAS 9.3 sas_en and my sas_u8:   100c100 < SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/en/sasv9.cfg, !SASROOT/sasv9_local.cfg, $SASCFGPATH" --- > SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/u8/sasv9.cfg, !SASROOT/sasv9_local.cfg, $SASCFGPATH" 102c102 < SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/en/sasv9.cfg, !SASROOT/sasv9_local.cfg" --- > SASCFGPATH="!SASROOT/sasv9.cfg, !SASROOT/nls/u8/sasv9.cfg, !SASROOT/sasv9_local.cfg"   You should be able to use that the recreate a sas_u8 script from the sas_en script (if you don't have one available from a backup). Of course there may also be other things missing in which case I would contact your SAS installer and/or SAS tech support and look into re-installing any missing components. ... View more

It looks like you are missing the unicode SAS launch script (and possibly wider unicode support) from your SAS Foundation installation.  Are you missing the unicode directory too? e.g. /opt/sas93/sashome/SASFoundation/9.3/nls/u8/ ... View more

What errors are you seeing in your SAS Object Spawner log file (e.g. /opt/sas93/config/Lev1/ObjectSpawner/Logs/ObjectSpawner_2017-07-11_hostname_NNNN.log)?   Does the sas_u8 file exist in your $SASROOT/bin directory? e.g. /opt/sas93/sashome/SASFoundation/9.3/bin/sas_u8 ... View more

If you have SAS EBI and VA sharing the same metadata environment (and the same SAS Logon Manager), then if they are already logged into the SAS Portal, I would expect a link that takes them into SAS VA (in the same environment) should not be presenting a logon form (as they are already logged into that environment). I don't have a combined SAS EBI+VA environment to test this on myself, as mine are independant environments, so perhaps someone from SAS or someone else who has this type of setup can confirm this.   If you are manually configuring users at the OS level and in SAS metadata, and you don't have mid-tier authentication configured for MySQL based trusted web authentication, then how do the users contained in the MySQL DB fit into this? Where is that MySQL database based authentication happening? ... View more

I'm guessing this is related to this previous thread? SAS VA User Authentication from Database  ... View more

OK, that's not a configuration you see very often 🙂   How do you currently have that SAS 9.4 platform authentication implemented?   User synchronization MySQL to SAS metadata via custom code using SAS %MDU macros? Trusted web authentication using something like Apache mod_auth_mysql or mod_authn_dbd? ... and how about the previous question "Do you have a combined EBI and VA platform (with a single metadata server) or, as is more common, independant EBI and VA platforms each with their own metadata servers?" ... View more

Hi,   I'm not sure what you mean by "users stored in the database". Do you mean SAS metadata, Active Directory, LDAP,  or another identity provider? How is authentication currently configured for your SAS platform(s)? Do you have a combined EBI and VA platform (with a single metadata server) or, as is more common, independant EBI and VA platforms each with their own metadata servers?   In that absence of more information, and assuming a commonly seen setup, I would suggest one way to achive the desired outcome would be to:   1) Configure Linux for Active Directory / Kerberos authentication similar to the example outlined in the blog post Active Directory Authentication for SAS on Linux (with realmd), possibly also with Auto Creation of Linux Home Directories for SAS Users if required.   2) Configure the SAS 9.4 EBI platform for Integrated Windows Authentication on the mid-tier so that Windows clients automatically log into the SAS Portal without having to explicitely provide a user id and password, optionally with fallback authentication, if required/appropriate. You will find some information on this in the blog post IWA with SAS 9.4 M2 on Linux as well as the linked posts, docs and papers.   3) Configure the SAS VA 7.3 platform for Integrated Windows Authentication on the mid-tier too so that Windows clients automatically log into VA without having to explicitely provide a user id and password, optionally with guest and fallback authentication, if required/appropriate. You can read about an example in the blog post SAS Visual Analytics Guest Access with IWA Fallback. Again I would encourage you to read the linked post, docs, and papers.   With a setup like this, users should be able to seamlessly open the SAS Portal and following links into VA with automatic login via SSO without seeing a login form. If you configure fallback authentication then in situations where IWA is not supported a login form will be provided.   Several of the blog posts I referenced above are getting a little bit dated now so it would also be worth looking for more recent papers on the topic. I would search Google and support.sas.com for keywords like SAS, IWA, Kerberos, mid-tier, & fallback and keep an eye our for papers by Stuart Rogers, Zhiyong Li & Mike Roda from SAS. A recent article that comes to mind is SAS 9.4 Middle-Tier Fallback Authentication with an Easy URL by Stuart Rogers. Finally, I should point out that, if you haven't done before, it is well worth getting help from SAS Professional Services or a local SAS Partner. There are lots of components that have to be precisely configured to work together in a setup like this and you can save a ton of time and frustration by getting help from someone who has done it before.   Cheers Paul ... View more