BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
bheinsius
Lapis Lazuli | Level 10

Hi,

 

I have setup SAS Token Authentication on my workspace server.

I can't find it in the SAS documentation but it looks like the launch credential must be a metadata group's account.

when i set it to a metadata user's account, i get the message:

 

The application could not log on to the server "sasserver01:8591".
The user ID "sasadm@!*(generatedpassworddomain)*!" or the password is incorrect.

 

Can someone confirm this?

 

regards,

Bart

1 ACCEPTED SOLUTION

Accepted Solutions
Madelyn_SAS
SAS Super FREQ

The launch credential is not required to be a group account. I would suggest reviewing the bullet points for selecting a login under the topic " Criteria for a Designated Launch Credential. "

 

http://support.sas.com/documentation/cdl/en/bisecag/69827/HTML/default/viewer.htm#p18wh3fg2jlhegn0zm...

 

 

 

View solution in original post

20 REPLIES 20
PaulHomes
Rhodochrosite | Level 12

Hi Bart,

 

The launch credentials need to be available to the SAS Trusted User (sastrust@saspw) because that is the identity that the SAS Object Spawner uses for its connection to the metadata server. As with any user in metadata, the SAS Trusted User has access to any shared credentials on any of the groups it is a member of. In a standard SAS deployment the SAS General Servers group acts as a credential container for the SAS Trusted User. The SAS Trusted User is a member of that group (and usually the only member). You will find the sassrv userid and password already stored in that group (as used to launch stored process and pooled workspace servers). I would suggest you add the new launch credential to the SAS General Servers group as that will then make it available to the SAS Trusted User.

 

I hope this helps.

 

Cheers

Paul

bheinsius
Lapis Lazuli | Level 10

Hi Paul,

 

Thanks for your explanation.

So that means it can't work with a metadata user's account, right?

 

Reason I am looking into this is that i want to use lasradm as the launch credential for the SASApp Workspace Server but i also want to run SAS VA autoload scripts and scheduled visual data builder scripts under the lasradm linux account.

To run the linux scripts under the lasradm linux account, lasradm must be able to bind to the metadata server as a sas metadata user that has the lasradm@defaultauth account specified. but token authentication does not work with this.

 

Do you have a way to get this working with just lasradm?

 

regards,

Bart

 

 

PaulHomes
Rhodochrosite | Level 12

The lasradm would have to be an account that is known to the operating system (so cannot be a SAS internal account) as it will be the process owner of your SAS Token Authentication configured workspace servers. It can still be used to sign in to metadata but will take on a group identity rather than a user identity. This is the same as the pooled workspace servers and stored process servers - when they initialize they connect to the metadata server as sassrv, are identified as the SAS General Servers group, and have that group's access during initialization to pre-assign metadata libraries etc (later on in their life the connecting user identities will used for access but sassrv is used early on). The identity for sassrv has to be group (instead of a user) so that the SAS Trusted User can be a member of the group to get the necessary access to the same metadata-stored credentials to start the servers.

 

You can try this out yourself if you know the password for sassrv. Log in to SAS MC using sassrv and, looking on the status bar at the bottom of the window, you will see you are identified as SAS General Servers (group not user). You can do the same with lasradm. Create your lasradm account in the operating system (or AD/LDAP), add the user id and password to the SAS General Servers group, restart/refresh the SAS Object Spawner, then log into SAS MC as lasradm and you will see the same.

 

One potential reason to use a group other than SAS General Servers is the shared group metadata identity with sassrv. When you grant the necessary metadata permissions for lasradm (via SAS General Servers) you will also be granting access to sassrv. If this is not what you want then consider creating another group similar to SAS General Servers just for lasradm then make SAS Trusted User a member of that group so it has acess to the credentials. Then ensure that group has appropriate effective permissions as required for lasradm. 

bheinsius
Lapis Lazuli | Level 10

SAS best practice is to use lasradm as the OS account for the VA Data Administrators group and use that as the launch credential for token authentication.

But like i wrote before, if i do this i can no longer use lasradm on the OS to run autoload or visual data builder scripts, since not every VA Data Administrator is allowed to load all LASR data anywhere. hm..

 

PaulHomes
Rhodochrosite | Level 12

If you already have lasradm on the Accounts tab of the VA Data Administrators group, then if you test a login with lasradm using SAS MC then you should see it identified as the VA Data Administrators group. If this is how you have it configured, when you run jobs in the OS as lasradm and connect to metadata as lasradm then that metadata connection will be identified as the VA Data Administrators group (for access control purposes).  Furthermore, if the lasradm account is on the Accounts tab of the VA Data Administrators group and also has it's password stored there, if the SAS Trusted User were made a member of the VA Data Administrators group, then the SAS Object Spawner through the SAS Trusted User (along with everyone else who is already a member of that group) would have access to those credentials. That would enable the SAS Object Spawner to start SAS Token Authentication configured workspace servers using those lasradm credentials. I just tested it and it works for me.

 

But as you say, that would mean (at the metadata layer) the lasradm identity could not have any more access than any other members of the VA Data Administrators group - because it is the group. I haven't had a need to try it myself, but in this situation I would consider moving lasradm credentials into another group (with SAS Trusted User as a member) and making that group a member of VA Data Administrators. The lasradm account keeps the access it had before because of its VA Data Administrators group membership but now has it's own identity which could be granted additional access beyond the VA Data Administrators group. It does however mean that the existing members of VA Data Administrators would lose access to the lasradm credentials which they might be using for other purposes. Alternatively perhaps those existing members of VA Data Administrators that need less access could be extracted into a different lower privileged group?

 

I'm only throwing ideas out there. I don't know if they will work for you or cause problems for you because I don't have a deep understanding of your implementation and usage patterns (which is beyond the scope of this thread). However, I hope it still helps in some way.

 

ravi15
Calcite | Level 5

Hi Paul, 

 

I am trying to setup LDAP direct authentication and when i try to validate the workspace server  i see the same error as described in this track.

 

SAS General services have the sassrv account and SAS Trusted user is part of the Member for it. 

As you said i cannot add sastrust@saspw to the SAS General services. 

 

I am missing anything here. can you help me on this.

PaulHomes
Rhodochrosite | Level 12

I assume you have configured direct LDAP authentication with the SAS metadata server and want to use SAS Token Authentication for the SAS Workspace Server because you don't want to, or cannot, setup the operating system to do LDAP authentication.

 

In that case you will need to ensure that 1) the logical workspace server configuration is changed, in metadata, to SAS Token Authentication; 2) appropriate launch credentials (such as sassrv) are stored in metadata so that the SAS Trusted User has access to them (usually by adding the userid and password to the SAS General Servers group); 3) the workspace server is configured to use those launch credentials; and 4) the SAS Object Spawner is restarted or refreshed.

 

More information is provided in the How to Configure SAS Token Authentication section of the SAS 9.4 Intelligence Platform: Security Administration Guide.

Madelyn_SAS
SAS Super FREQ

The launch credential is not required to be a group account. I would suggest reviewing the bullet points for selecting a login under the topic " Criteria for a Designated Launch Credential. "

 

http://support.sas.com/documentation/cdl/en/bisecag/69827/HTML/default/viewer.htm#p18wh3fg2jlhegn0zm...

 

 

 

PaulHomes
Rhodochrosite | Level 12

Noted, however I do notice that the SAS documentation has:

You can choose to configure variations (for example, create a group other than the SAS General Servers group to hold logins for launch credentials). In general, such variations are not recommended because they unnecessarily increase complexity and reduce consistency.

I only recommend adding any additional launch credentials to the SAS General Servers group on the basis that, being consistent with the pre-configured setup of a new SAS installation, it would be immediately familiar to many SAS administrators.

ravi15
Calcite | Level 5
Thank you very much issue solved.
bheinsius
Lapis Lazuli | Level 10

The message that was marked as a solution should not be marked as a solution because it is not the solution to the original question.

I have seen the documentation but when I set the launch account to a metadata user account; it does not work.

I get the error:

 

The application could not log on to the server "sasserver01:8591".
The user ID "sasadm@!*(generatedpassworddomain)*!" or the password is incorrect.

 

Please unmark the message as a solution.

Madelyn_SAS
SAS Super FREQ

It looks like you are trying to use sasadm@saspw to launch the workspace server. Internal accounts cannot be used for that purpose.

PaulHomes
Rhodochrosite | Level 12

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:

  1. 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).
  2. In Server Manager, modified the SAS Logical Workspace Server to select SAS Token Authentication
  3. In Server Manager, modified the SAS Workspace Server to select demoalice as the Launch Credentials
  4. In Server Manager, expand Object Spawner, Connect to the host and Refresh Spawner.
  5. 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:

  1. In User Manager, edit the Alice user identity in metadata and remove the credentials from the Accounts tab (demoalice + password).
  2. In User Manager, edit the SAS Trusted User identity in metadata and add the demoalice credentials in the Accounts tab (demoalice + password).
  3. In Server Manager, modify the SAS Workspace Server to (re)select demoalice as the Launch Credentials.
  4. In Server Manager, expand Object Spawner, Connect to the host and Refresh Spawner.
  5. 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

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
  • 20 replies
  • 7469 views
  • 4 likes
  • 7 in conversation