AD Account is locked at SAS Server

[jakarman]

Michael, with the omaconfig you have reviewed the internal account definitions
With that you can validate passwords against LDAP/Kerberos/AD but there is no immediate connection to the OS security itself.

It is a kind of working in ignoring security at het data/os-level and combine those to a shared grouped account that is maintained and owned by SAS. I hope SAS institute is not responsible or if they are. Anyway that way of working should be described well as losing auditablity traceablity by normal tools for that. --- high profile user, hurts ----

For unix security technical way of working, there are many options:
http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf review PAM / sasauth.
Getting into LDAP/AD depending on the size of the company there can be many LDAP/AD servers.
Updating the password in a windows environment and expecting it immediately active can be frustrating. At windows you get the immediate response of the update password as you are being connected to that one.
https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/   Normally it should be implemented well but you never know.

There is an other weird behavior of the sasauth module. It is that module checking the password while runnig at root-level.
What will happen when validating a user/password  combination when there are delays/lock wait policies being activated at the AD origin. Will the user account behave als normal Windows or will there happen something different?
The latter having seen happening. Trying a locked out user several times and the delay time went ever up never being reset by a correct login. You must be very patient and confident to see the login happening after an hour or so.     
     
 
   

[mfab]

Hello all,

thanks for the suggestions so far.

I think I might be onto the issue (at least in my case):

Our sasauth.conf is configured as follows:

maxtries=5

maxtriesPeriod=60

maxtriesWait=300

So there should be a maximum wait of 5 Minutes. However I have seen longer wait times. My best guess is that the wait time of 5 minutes (in this example) is prolonged or refreshed everytime the user tries to login within the 5 minutes of the maxtriesWait.

So:

login attempt 1

login attempt 2

login attempt 3

login attempt 4

login attempt 5

maxtriesWait set to 5 minutes

login attempt within the 5 minutes

maxtriesWait set to 5 minutes

login attempt within the 5 minutes

maxtriesWait set to 5 minutes

etc...

But then again this is just my guess. The maxtriesWait could also be accumulated for each unsuccessful login attempt while maxtriesWait is still active.

It would be good to know, how sasauth works when the maxtriesWait has been reached and another login attempt is made. The documentation (Configuration Guide for SAS® 9.4 Foundation for UNIX Environments) might be more helpful with a few explaining lines. Or am I searching in the wrong place?

Also it says that authentication might be

sasauth => Unix OS => /etc/passwd

or

sasauth => /etc/passwd

Our sasauth.conf says "method = pw". Does this mean we go through the Unix OS and then /etc/passwd or does this mean sasauth does the check versus /etc/passwd? This might be good to know in order to tighten the search, whether the OS might be involved at all in this process or if it a behaviour of sasauth.

Cheers,

Michael

[jakarman]

Michael, yep that is the terrible thing we struggled quite a lot on that.
The updates time-outs on the OS and the SAS were done seperately not aligned to each other.

The pw checking was calling the OS and the OS being redirected to LDAP (AD) for only normal users as service accounts being local.

When this is also you case testing / validating will get more easy. Have at least two accounts availiable.
One being getting locked and at every attempt increasing the time (accumulating). The other as normal user just logging in an measuring the time in responding for normal usage.
Having a test for infra validation of a sas installation available you can try those settings in the sasauth.conf on that scenario changing values and just replay the user-locking and changing passwords. That environment should be very similar to the real one. A stand alone one on a desktop will not do that job.         

[NZ_Hockey_Mum]

I had the SAS server locking my AD account repeatedly. It was tracked it back to when I tested the SAS studio installation after which I had then changed my password. I did not logon to SAS studio again. The password was changed in the my profile from within SAS EG but somehow SAS would still pick up my old password stored by SAS studio run that against the SAS server and lock my AD account.

Removing the password from the SAS studio saved information worked for me.

Hope that helps.

[JuanS_OCS]

Thanks a lot @NZ_Hockey_Mum ! Hope it can help many others.