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
Re: ARS 7.5 User Cache Gremlin
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
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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARS 7.5 User Cache Gremlin
Christopher, If you turn on user-logging, you will get a row for each bad-password-attempt. It is then easy to search the log to find the time of your problem. The string to search for is LOGIN FAILED with (password) at the end of the line. Maybe you will see another suffix when the account is INVALID:ated. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. 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 -- This message was scanned by ESVA and is believed to be clean. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 -Original Message- From: strauss stra...@unt.edu Date: Fri, 26 Mar 2010 10:41:05 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/ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARS 7.5 User Cache Gremlin
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:arsl...@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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 DeaverL-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 GremlinFrom: strauss stra...@unt.eduDate: Fri, March 26, 2010 11:18 amTo: 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 ManagerUniversity of North Texas Computing IT Centerhttp://itsm.unt.edu/ From:Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick CookSent:Friday, March 26, 2010 10:57 AMTo:arslist@ARSLIST.ORGSubject: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 ManagerUniversity of North Texas Computing IT Centerhttp://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"_
Re: ARS 7.5 User Cache Gremlin
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:arsl...@arslist.org] On Behalf Of Kelly Deaver Sent: Friday, March 26, 2010 12:48 PM To: arslist@ARSLIST.ORG 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 kdea...@kellydeaver.com (ARSlist mail) kelly.ctr.dea...@faa.govmailto: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:arsl...@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_
