Folks, What actually happens is that there is a configuration setting for the server that indicates at what interval a user should be "reauthenticated".
When you first login, we go and authenticate the user. Then, we have this user as a valid user in the system and subsequent API calls check this user instance. If that instance is ever lost, we simply go an authenticate the user and the user. The instance is rarely lost (only when something like the server is recycled) so generally that instance record is present for a long time. The configuration setting allows you to indicate how long since the last time you did an authentication you want to repeat the authentication check even if there is an active instance record. I am not sure what the default setting is but I think the ar.conf line that controls the value is External-Authentication-Sync-Timeout: I suspect the value specified is in seconds, but it could be minutes. OK, since I was coming up with a bunch of I am not sure, I did the unheard of and just checked the documentation -- what a concept. This is indeed the setting. The value is in seconds. The default is 300 seconds. (older version of server so this may have changed) Setting the value to 0 causes it to never recheck. What this means is the following: On a change to the password (or rights or any other characteristic being returned by AREA), there is no immediate affect, the user remains logged in and active. However, when the sync timeout comes around -- this may be immediate if the last sync was over the interval or may be up to the full interval -- the user is rechecked. If their password was changed, they are no longer a valid user and will get an authentication error and the error should be returned to the user. Now, the issue reported by Anne can occur if the re-check tries with a bad password and gets an error and the user tries some other things, well, more bad password tries occur and that can cross the threshold of maximum bad password attempts. If the user cleanly relogins in on the authentication error, they will likely not have an issue -- but remember they already have a strike or two from the bad attempts so they have to get things right quickly. Best is to have the user log out of all systems -- because other systems may have a similar recheck to the AR System so now you potentially have multiple systems "re-checking" with bad passwords and it doesn't take long to hit that bad password limit. The recheck is to accomplish several things: 1) Pick up new data -- like new rights or email address or other information you are getting from the AREA source 2) Make sure that a user cannot just stay in with an old session forever and to force them to supply the new password within a configured time if the change was a password change. I hope this helps address the question and gives a bit of background on why things are working the way they are. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Ramey, Anne Sent: Monday, November 29, 2010 8:40 AM To: [email protected] Subject: Re: AREA LDAP In our system, it does not prompt them for the login again--but the application re-authenticates them as they do things, so they end up locking their login accounts. We tell our people to close Remedy before changing their password. Anne Ramey -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of John Baker Sent: Friday, November 26, 2010 3:37 AM To: [email protected] Subject: AREA LDAP Hello, They will not be prompted to login again until they login again, at which point they will need to use the new password. John -- Single Sign On for AR System http://www.javasystemsolutions.com/jss/ssoplugin _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties by an authorized state official. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
