EG Connection Linux sas server

[shoin]

While connecting to SAS server, repeatedly getting prompted for credentials.

work is 777

proc perm test is successful (after enabling PAM)

Metadata log shows the user connection rejected, Access denied, the same user could conduct a successful proc permtest.  The debug and auth logs show pam engaging and user authenticated.  

Object spawner re-started

sasauth-debug:

"Authenticated user xxxxxx (pam)."

sasauth-access

"Authenticated user xxxxxx (pam)."

Since I do not see the xxxxxx in objct spawner log, I am testing if firewall not an issue and could ping on ports from xxxxx desktop

Meanwhile, any and all insights are more than welcome!

[Kurt_Bremser]

Could it be that the password has expired? Or that the account has exceeded the failed login count?

[shoin]

Thank you Kurt, this is on Linux and user has had successful login and proc permtest.  I am going to do inttech tests plus turn on metadata debug, 

[SASKiwi]

This sounds like a problem better suited to SAS Tech Support - raise a track if you haven't already.

[SimonDawson]

Does the user have a home directory? If authentication is successful but the workspace is not starting then failure to allocate the SASUSER library because the home directory doesn't exist is something I see from time to time.

[shoin]

Hello Simon, the workspace server was connected to using the intech utility and work is 777.  One test user was successful and yes the /home/user is present same user had successful workspace server access test. 

While doing metadata connection test (intech utility) received this: "

Access denied.

When creating a connection to an IOM server, this error is typically caused by entering an invalid user name or password.  To correct this problem, verify that the user name and password you have entered are valid on the machine where your IOM server is running.  You may also need to qualify your user name with a valid domain if you are connecting to an IOM server running on a Windows domain.

Other possible causes for this error are the user's password has expired, the user must change their password on the next login, or the user account is disabled."

However, wrong ID/PWD is not an issue, we ensured no fat fingering either.

I will turn on debug on Meta and see, it is puzzling since PAM and proc perm test are all authenticating.  I will check again for the third time if the user registry in meta is correct too...

[shoin · Accepted solution]

Update:

1. We enabled debugging for metadata log which showed

TRACE [13145048] :sas - Unix OS auth provider called for user rfranklin
2018-05-23T10:40:44,555 INFO [13145048] :sas - Access denied.
2018-05-23T10:40:44,555 TRACE [13145048] :sas - bkAuthenticate failed 80BFD100
2018-05-23T10:40:44,556 DEBUG [13145048] :sas - Provider failed: 80bfd100

We checked 

/var/log/secure for any possible /etc/pam.d config file corruption (all ok)

sasauth.conf review (ok)

Looked in AD, no group based limitation and testing IDs were all good and what we expected

Light bulb: When we enabled PAM based authentication, we did not restart the metadata ... sigh!  (Just like my professor said, before diving in, look whether the machine is plugged in 🙂 )

The authentication is working properly, life is good.

Thank you to all friends who gave their time and shared their knowledge, it is much appreciated!