Looks like perhaps a stray piece of test data someone forgot to strip out. It
isn't in the 7.6 WS or Filters I saw.
Rick
-----Original Message-----
From: strauss <stra...@unt.edu>
Date: Tue, 6 Apr 2010 10:01:08
To: <arslist@ARSLIST.ORG>
Subject: Re: ARS 7.5 User Cache Gremlin
I trapped an instance of it today on the ARS 7.5.00.004 - ITSM 7.6.00.001
server that has sample data loaded. Yesterday, at 15:20:29 the MidTier Service
logged in. Then it tried to login Demo (impersonated):
<USER: MidTier Service > /* Mon Apr 05 2010
15:20:29.4000 */ LOGIN MidTier Service
<USER: Demo > /* Mon Apr 05 2010
15:20:29.4000 */ LOGIN Demo (impersonated)
<USER: Demo-- Impersonated by MidTier Service -- > /* Mon Apr 05 2010
15:20:29.4050 */ LOGOUT Demo
<USER: Demo > /* Mon Apr 05 2010
15:20:29.4240 */ LOGIN FAILED Demo (user)
...followed by:
<USER: Demo > /* Mon Apr 05 2010
15:20:29.5110 */ LOGIN FAILED Demo (lockout)
The mid-tier logs show 25 lines of:
Apr 5, 2010 3:20:29 PM - FINE (com.remedy.log.INTERNAL) : Throw ARException -
ERROR (623): Authentication failed; ERROR (623): Authentication failed;
...followed by a crash:
Apr 5, 2010 3:20:29 PM - FINE (com.remedy.log.INTERNAL) : Throw Error - 9280
Apr 5, 2010 3:20:29 PM - SEVERE (com.remedy.log.DVMODULE) : Exception while
processing requestARERR [9280] Server not present in the configured servers
list - ldalvi-pun-02v75p2
at
com.remedy.arsys.stubs.ServerLogin.getServerInformation(Unknown Source)
(followed by 25 more lines of goat barfing)
...so, something is trying to connect thru the mid-tier to a server named
"ldalvi-pun-02v75p2" - wherever that came from.
So far the only time I have seen the impersonation of Demo by the mid-tier
service when I KNOW what triggered it, is when I launch the Atrium Core
Console. I can do so successfully on the same server with the appadmin
account, so the Console is configured correctly. It must be something else
trying to access something via the mid-tier, in the background, using Demo with
a blank password and pointing to that bizarre server name.
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:arsl...@arslist.org] On Behalf Of Mueller, Doug
Sent: Monday, March 29, 2010 1:21 PM
To: arslist@ARSLIST.ORG
Subject: Re: ARS 7.5 User Cache Gremlin
**
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"_
_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"
