Authenticating with sasadm@saspw would not use sasauth. This is an internal account authenticated by the Metadata Server directly. The sasauth.conf file is read by the sasauth process when it starts. This process is a subprocess of the Metadata Server, Connect Spawner and Object Spawner. So, you could just restart those processes or in the past I have even just killed the sasauth process, triggering it to be relaunched. The middle tier does not use sasauth directly, SASLogon contacts the Metadata Server to authenticate. When you ssh to a server you are using sshd's pam file rather than sasauth, so this is not a direct comparison. PROC PERMTEST will test sasauth directly. It is normal when stopping the Web Application Server to see a lot of messages like this, they can be ignored: 2022-03-02 08:40:44,946 ERROR (localhost-startStop-9) [org.apache.catalina.loader.WebappClassLoaderBase] Found RMI Target with stub class class [org.apache.jackrabbit.rmi.server.ServerPropertyDefinition_Stub] and value [ServerPropertyDefinition_Stub[UnicastRef [liveRef: [endpoint:[<server>:41814](local),objID:[-6123eb5e:17f4b026755:-44f8, -4381670130249457555]]]]]. This RMI Target has been forcibly removed to prevent a memory leak. ... 2022-03-02 08:40:45,576 WARN (localhost-startStop-6) [org.apache.catalina.loader.WebappClassLoaderBase] The web application [SASWIPServices] appears to have started a thread named [Atomikos:6] but has failed to stop it. This is very likely to create a memory leak. The LDAP messages during startup are also normal and can be ignored. Access logs show the request and response, so if a response wasn't sent it wouldn't appear in the log. You'd need to try to match the requests from the browser trace with the access log to see if a response was shown in the access log but not in the browser if you were trying to determine if SAS sent a response the browser didn't receive (i.e. network issue). Did you look at the logs for SASLogon in Lev1/Web/Logs/SASServer1_1 I mentioned? You should not use sasadm@saspw to log in to Enterprise Guide, as sasadm@saspw is not a valid host account so cannot own the sas process on the server. Because if this, EG would prompt you for a valid host credential when you try to start a workspace server. This is why you are getting the prompt in scenario 1. Scenario's 2 and 3 sound like the Metadata Server's sasauth is failing as sasadm@saspw authenticates to Metadata successfully and server users do not. PROC PERMTEST run on the Metadata host can confirm this.
... View more