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

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!

1 ACCEPTED SOLUTION

Accepted Solutions
shoin
Lapis Lazuli | Level 10

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!

View solution in original post

6 REPLIES 6
shoin
Lapis Lazuli | Level 10

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
PROC Star

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

SimonDawson
SAS Employee

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
Lapis Lazuli | Level 10

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
Lapis Lazuli | Level 10

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!

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
  • 6 replies
  • 2467 views
  • 0 likes
  • 4 in conversation