Re: ARS 7.5 User Cache Gremlin

[Kelly Deaver]

**

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

kdea...@kellydeaver.com (ARSlist mail)
kelly.ctr.dea...@faa.gov (Business mail)

 

 

-------- Original Message --------
Subject: Re: ARS 7.5 User Cache Gremlin
From: strauss <stra...@unt.edu>
Date: Fri, March 26, 2010 11:18 am
To: arslist@ARSLIST.ORG

**

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:arslist@ARSLIST.ORG] On Behalf Of Rick Cook
Sent: Friday, March 26, 2010 10:57 AM
To: arslist@ARSLIST.ORG
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 <stra...@unt.edu>

Date: Fri, 26 Mar 2010 10:41:05 -0500

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"_

_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_

_attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_