user ID or password is not valid SAS EG

[sathya66]

All,

when a user try to login to SAS EG, the  user is getting "user ID or password is not valid" ERROR.

this is happening to only few users rest of the users are accessing fine

tried to delete the user in AD and in SMC and recreated the user again and getting the same ERROR.

SAS version is 9.3

note: password and ID is correct

see the metadata log below

2021-01-27T11:10:10,048 INFO [09088446] 1014671:sas - Client connection 1014671 for user sastrust@saspw closed.
2021-01-27T11:10:11,593 INFO [09088449] :sas - Access denied.
2021-01-27T11:10:11,593 WARN [09088449] :sas - New client connection (353039) rejected from server port 8561 for user test_user. Peer IP address and port are [::ffff:11.990.188.95]:61110 for APPNAME=SAS Enterprise Guide.
2021-01-27T11:10:11,593 INFO [09088449] :sas - Client connection 353039 closed.

[SASKiwi]

What OS do your SAS servers run on? Test a known good user ID on the same PC or test the problematic user ID on a different PC. That will prove if it is a PC problem or not.

[gwootton]

An access denied message typically occurs when the supplied user ID / password is being rejected by the authentication provider.
If UNIX, does that user/pass combination succeed via PROC PERMTEST on the Metadata Server host?

https://support.sas.com/kb/39/891.html

[sathya66]

Thanks,

we are on UNIX so we can test this.

As I said ,it is happening to only few users (who are created post November) . The IDs which are created are able to access the UNIX server(ie: though WINSCP or putty )  however the same ID and Passwords get denied by the SAS Application with an error. we tried recreating the ID from the scratch but that did not help either .

[Kurt_Bremser]

Look at the logs of your metadata synchronization program (importpw or importad).

[sathya66]

Thanks, Where can I find these logs in the server?
hope you are talking about these "/SASFoundation/9.4/samples/base/importad.sas" and "/SASFoundation/9.4/samples/base/importpw.sas"

[Kurt_Bremser]

---

@sathya66 wrote:

Thanks, Where can I find these logs in the server?
hope you are talking about these "/SASFoundation/9.4/samples/base/importad.sas" and "/SASFoundation/9.4/samples/base/importpw.sas"

---

Yes, these two programs are the blueprints for automatically synchronizing users from an authentication source.

importpw.sas reads from the "standard" UNIX files /etc/passwd and /etc/group, while importad.sas reads from Active Directory, but it can be adapted to any LDAP source.

One of these programs needs to be adapted to your environment, and then run regularly to keep your metadata up to date. The script with which you run that program will determine where the logs end up (-log parameter on the SAS commandline). If you never ran such a program, but always added your users manually, that's a recipe for problems. Users will stay in metadata even after being removed from the system, and you open yourself up to typos and whatnot.

[sathya66]

Thanks,We are using this sytem for more than 8~ years and we are looking after this for the past one month and they siad that they never had this issue so that means users are automatically synchronizing from an authentication source.not sure what happened saddenly 🙂 now .

This 9.3 platform users are not using any AD. All users are setup in local AIX box and in sas metadata. Any idea Why these users (only new users) are rejecting by the SAS application(they can login to AIX server via putty/WinSCP).

[Kurt_Bremser]

Ouch. You were just lucky, but any IT-experienced person can tell you that such a setup causes problems sooner or later.

Besides that, I would be MUCH too lazy to burden myself with the work of manually keeping metadata up-to-date. We're having computers for such menial tasks.

And your manual entries do not create logs for you to inspect, so now you have an issue and not much in the way of helping to find the cause.

The only help I can give you: compare a working user with a non-working user, both in SAS metadata and in the authentication source.

How is the DefaultAuth authentication domain defined? Does it work against the operating system, or does it authenticate against the LDAP source directly?

(see some examples for LDAP here )

[Kurt_Bremser]

What I meant in particular:

If your metadata tries to directly authenticate against the LDAP source, then the fact that somebody can log on to the system itself is quite meaningless. If the metadata server cannot retrieve the information from the LDAP source, you'll get the Access denied.

In our case here, the system authenticates against LDAP, and SAS authenticates against the system (no LDAP references in the config of the metadata server).

BUT the SAS metadata is synchronized directly against LDAP, using a variant of the importad program.

[sandeeppajni2]

Hi,

Just to ensure, whether the users added after November have a different domain? Also, I hope you are adding their user account IDs correctly in user records being created in the metadata, i.e. through SMC User Manager plugin.

[AnandVyas]

Hi @sathya66 

As suggested by @gwootton "PROC PERMTEST" is the best way to diagnose and troubleshoot login issues.

[DanielKaiser]

Do you use PAM? Maybe the users are not in the required unix-group that adds the required permissions

[sathya66]

I have checked the sasauth.conf. there is no setting for "methods=pam" so there is no AD
users are setup locally in the AIX server and in SMC.
We tried cloning already existing user groups but no luck.

[DanielKaiser]

Maybe checking Chapter 3 of the Config Guide might help.
https://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf 

I'd bet the UNIX-Admins might have changed something like the default group for your UNIX-System