Hello SAS folks,
A few customers at my client location are experiencing issues while logging into SAS Studio. The way it works is, if the user logs first into IE (after desktop bootup) and then Chrome/Edge, the experience is seamless. But if the user logs first into Chrome/Edge (after desktop bootup), then he gets this error:
"Connection Error to Workspace: Unable to connect to the current workspace server. Select a different workspace error. org.springframework.web.client. Http client error exception: 400 bad request."
and sometimes this error:
"Connection Error to Workspace: the native implementation for the security package could not be found in this path".
Even after logging using the correct sequence, the user is complaining of involuntary timeout sessions after 4-5 hours.
Troubleshooting done so far -
1. Clear the browser cache and reattempt to login to SAS Studio
2. Clear the browse cache, reboot desktop and reattempt to login to SAS Studio
3. Add registry entries for Chrome/Edge to delegate user authentication and authorize SPNEGO as per this SAS article
4. Change settings for firefox browser as per the article mentioned in #3.
5. Uninstall chrome/edge and reinstall browsers
did not help.
These steps were also done in order to ensure metadata privileges were correct
6. User was added to 2 SAS Studio related groups (SAS Studio usage and SAS report consumer roles).
These steps were also done as mentioned in the article in #3.
setspn -F -Q HTTP/hostname.example.com
SASHOME\SASPrivateJavaRuntimeEnvironment\9.4\jre\bindirectory on Windows and in the
/usr/bindirectory on UNIX systems.
kinit -k —t keytab-filename-and-path.keytab user-principal-name -J-Djava.security.krb5.conf= path-to-Kerberos-file.conf
We opened a SAS support ticket but they kept going back to the link in #3.
i also tried to 1) restart object spawner and 2) clear spawner credentials cache using SAS MC but to no avail
I wanted to see if my client already installed hotfixes A4R004pt but the viewregistry file (in deploymentreg folder) will not run (for some reason) either from the command prompt or manually.
I ran the code (shared by @kalindpatel) from this thread https://communities.sas.com/t5/Administration-and-Deployment/Find-all-User-Accounts-with-an-Internal...
but it did not return any internal services account (sassvcs@saspw). I only saw sastrust@saspw, webanon@saspw, sasadm@saspw,sasevs@saspw among others . I am scratching my head as to how the existing users were using SAS Studio previously.
The OS is Windows NT 2012 R2 Standard. Metadata, compute and midtier are on 3 separate servers. SAS is v9.4m3 and sas studio is v3.6.
When I peeked under the hood on the Windows servers,I did check for two things -
1. Which of the groups/accounts/users need to be allowed to 'log on as a batch user' privileges?
2. Which of the groups/accounts/users need to be listed in the Windows NT Users?
Could someone list the correct scheme for the above 2 questions regarding user privileges?
Some insights with the symptoms you have described.
If users are able to successfully start a SAS/Studio session via IE - I assume here that users have to logon in the browser a second time using their Windows credentials rather than using single sign-on - then there is nothing wrong with the way those users are defined in SAS metadata and at the OS level in Active Directory. They will have the correct "logon as batch job" setting.
Check the metadata server log to see if there are any errors with the users having sign-on problems. Please report what you find.
The 4-5 hour involuntary timeout is most likely caused by firewall rules. Check with your IT security folks.
@SASKiwi Thank you for your inputs. Could you tell me if the internal SAS account (sassvcs) also need to have 'Logon as a batch job' privileges? I was told so at a previous engagement that both the users and the internal account need to have 'logon as a batch job' privilege.
I shared the middle-tier logs and object spawner logs with SAS support. We were able to identify atleast within the object spawner log the records for the error-
2020-MM-DDT08:21:20,536 INFO  : (USERID) - New client connection (98361) accepted from server port 8591 for SAS token user (USERID). Encryption level is Everything using encryption algorithm RC2. Peer IP address and port are [someipaddress]:someipaddress for APPNAME=Web Infra Platform Services 9.4 - SAS Studio Mid-Tier 3.6.
2020-MM-DDT08:21:20,536 ERROR  :(userid) - 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.
2020-MM-DDT08:21:20,536 INFO  :SYSTEM@myserver - Client connection 98361 for user USERID closed.
2020-MM-DDT08:21:20,536 INFO  :SYSTEM@myserver - Client connection 97113 for user USERID closed.
How do I check the metadata logs?
@saspert - You can find the metadata logs in: \\MySASMetadataServer\MySASInstallFolder\SAS\Config\Lev1\SASMeta\MetadataServer\Logs
Regarding sassvcs - What are you using that for? If it is just running OS-level commands then it would need to be an OS account as well with access to the SAS servers. Probably doesn't need logon as batch permissions.
@SASKiwi My client still has this issue. Now the client's IT team might do away with IE completely (without giving us enough time to upgrade to the latest version of SAS 9.4M7). Any other ideas that I can try (besides checking the metadata logs)? I have attached a screenshot now.
When we hit the URL of SAS Studio for login into it, it redirects to other URLs internally. While trying to access it through Chrome, try copying and pasting the exact URL of the SAS Studio and then do the login. I used to get errors while trying to use the SAS Studio URL saved in Chrome history. The errors stopped when when I started using the the exact URL saved in the favorites. You might be facing similar issues.
Okay. Just to let you know that we recently started facing some problems in accessing SAS Studio, whereas SAS EG was connecting fine, after every instance of complete reboot of SAS services. It turned out to be an issue in the SAS Deployment Backup not completing in time and taking more than usual. So, sometimes the deployment of web services (SASServer1_1, which plays a major role in running the SAS Studio) was not happening completely after the reboot of the SAS Services. We excluded the backup deployment xml file (SASDeploymentBackup.xml) in the location: ../Lev1/Web/WebAppServer/SASServer1_1/conf/Catalina/localhost, and then the deployment of configurations started happening in time without issues, which fixed the SAS Studio login issue too.
It might be helpful to try following these steps in your case too. You need to first stop the SAS Web services, remove the file, and start the services again to do this.
The error message "The native implementation module for the security package could not be found in the path." is typically related to the configuration of Kerberos delegation.
In the User Managment Console in Active Directory > Delegation Tab, for the SPN entry is the "trust this user for delegation to any service (kerberos only)" check box selected?
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.