Christopher, What you are seeing here -- the word INVALID being the password in the user_cache record -- is a characteristic of the system disabling the account. This word will never hash from any password so the account is inherently disabled but we can find all accounts that have been disabled by searching for the word INVALID.
So, how does a user get disabled by the system? Generally, the cause of this is having a "maximum number of bad passwords" setting and there being a set of login attempts of that user with bad passwords that exceed the maximum count. Do you have user logging on during the night to see if there are attempts to login as this user and getting bad password attempts? There is a bad password attempt counter on the user_cache record. What is that number when you see the password as INVALID? Could there be an old integration somewhere that runs periodically that runs during the night that causes the buildup of bad passwords and you have changed the password? Maybe during the day, other integrations are running which are OK and they cause a reset so this bad password doesn't trigger except during quiet times when other things are not running? I don't know of another reason that the word INVALID is written to the user_cache record. A change on 1st login would not because you need your password to get in and then you are asked to change it. Marking a user as disabled or something leaves their password record there. So, I assume you have the setting for max bad passwords before invalidating the user feature active -- if not, I am very confused at this point how the word INVALID is getting in the user_cache. And, then, it is tracking down where the bad login attempts for the user Demo are coming from. I don't know if we are logging anywhere that a user is being invalidated for too many bad passwords. But, you may want to see if there is a note in the server error log. I hope this gives a pointer to help track down what is happening. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of strauss Sent: Friday, March 26, 2010 8:41 AM To: arslist@ARSLIST.ORG Subject: ARS 7.5 User Cache Gremlin ** This week we started seeing a brand new gremlin on our two ARS 7.5.00.004 - ITSM 7.6.00.001 servers. The Demo account gets flagged as having an "INVALID" password overnight. If you reset its password, it's good for the day, but the next morning it is not valid again. When you look at the actual record in the dbo.user.cache table on the SQL Server, the password value is "INVALID". When you look in the User form, there is a valid-looking encrypted value in field 102 (password), not an INVALID flag, so this is happening in the User cache!! Has anyone (a) seen this on their system, (b) located the obscene code or process that must be doing this, and (c) figured out how to kill it off? Needless to say, it's an unacceptable behavior, and we can't just blank out the password in SQL Server since we have the AREA LDAP authentication integration active. It's a good thing that we always have several other administrator-privileged accounts available. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
