Re: Generic Accounts, finding what PC, device, or session caused the device | *usrprf to become disabled
- From: CRPence <crpence@xxxxxxxxxxxx>
- Date: Fri, 04 Jan 2008 13:39:38 -0600
Review the following example of Display History Log, where the time-frame specified is appropriate for the situation; i.e. the example spans four minutes over a time in which I forced the condition on my own system:
dsplog qhst ((130600 010408) (131000 010408))
msgid(cpf2200 cpf1300 cpc2600)
IMNSHO the first and biggest problem is failure to qualify each individual to their own authentication, to ensure that any activity can be tracked to a person, rather than only being able to track activity to any one of several persons sharing a generic signon. IANAL but shared signons in some environments may violate some internal, external, and/or governmental regulations.
That aside, activate QAUDCTL to allow for auditing (i.e. add *AUDLVL to the Audit Control system value). A T-PW entry will be logged with the IP address and device ID, corresponding to the CPFF2234 logged in the history. The following requests run after an incident mimicked on a system, to review results:
DSPJRN JRN(QAUDJRN) JRNCDE((T)) ENTTYP(PW) OUTPUT(*)
FROMTIME(010408 130600) TOTIME(010408 130600) /* interactive */
5=Display entry
F10=Display only entry details
CPYAUDJRNE ENTTYP(PW) JRNRCV(*CURCHAIN)
FROMTIME(010408 130600) TOTIME(010408 130600)
runqry *none qtemp/qauditpw *display /* interactive */
Regards, Chuck
--
All comments provided "as is" with no warranties of any kind whatsoever and may not represent positions, strategies, nor views of my employer
grokik_wow@xxxxxxxxx wrote:
I work at an internal helpdesk for a company. Multiple employees use.
various generic accounts to log into our AS/400. From the support
side, this causes problems. If one person puts in the wrong password,
then the account is disabled and they have to call the helpdesk.
Often, the person that calls the helpdesk is not the person that
caused the lock. I enable the generic account for the caller, but the
person that locked it is still trying bad passwords. Luckily we only
allow PCs to connect with specific devices. So eventually the person
that doesn't know the password has locked themselves out of all the
sessions on the PCs they have access to and eventually stop. In our
environment accounts are disabled after 3 bad password attempts.
Sessions are also varied off after 3 bad password attempts or 3
correct passwords to a disabled account.
I would like to be proactive and find out who is causing the lock and
educate them. To start this process, I would need to know what IP
Address, device, or Session caused the lock. In wrkusrprf I can see
'Previous sign-on' and 'Sign-on attempts not valid'. Is there a way
to see what Device/Session/IP address caused an account to become
disabled?
- Follow-Ups:
- References:
- Prev by Date: Re: Is there has "Signoff Exit Point"
- Next by Date: Re: Generic Accounts, finding what PC, device, or session caused the device | *usrprf to become disabled
- Previous by thread: look at QHST for details
- Next by thread: Re: Generic Accounts, finding what PC, device, or session caused the device | *usrprf to become disabled
- Index(es):
Relevant Pages
|
