No, we looked at that. The User record “looks” fine, and was not updated (since the manual pwd change the previous day). It is the user_cache record that is being invalidated.
Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kelly Deaver Sent: Friday, March 26, 2010 12:48 PM To: [email protected] Subject: Re: ARS 7.5 User Cache Gremlin ** just a thought.. Does the Demo user record have the change password on next login flag set? Is it maybe getting set by a gone crazy password management rule of 1 day. Kelly Deaver L-3 Stratis / FAA Contractor [email protected] (ARSlist mail) [email protected]<mailto:[email protected]> (Business mail) -------- Original Message -------- Subject: Re: ARS 7.5 User Cache Gremlin From: strauss <[email protected]> Date: Fri, March 26, 2010 11:18 am To: [email protected] ** Wouldn’t matter – there is no “Demo” account in LDAP, and LDAP is only consulted when the password is blank. There are no groups defined in LDAP, either, nor is AREA mapped to look at groups. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Rick Cook Sent: Friday, March 26, 2010 10:57 AM To: [email protected] Subject: Re: ARS 7.5 User Cache Gremlin ** I would ask if anything on the LDAP side changed. Would a new group policy on that side override your password? Rick ________________________________ From: strauss <[email protected]> Date: Fri, 26 Mar 2010 10:41:05 -0500 To: <[email protected]> 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"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
