Generic Accounts, finding what PC, device, or session caused the lock

[groki...@yahoo.com]

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?

[jacko]

The problem your going to have is identifying the user to the IP. I
know of a tool called SHOWIP, the problem is it is only going to be as
good as when your looking at the screen. I use the BSAFE software and
this software is capturing this information for me. I believe you
would need journaling and exit programs setup to get this to work.
Here is a snapshot of what it looks like.

Show Active IP
Addresses

System . . . . :
NP400

Type options, press
Enter.
5=Work with Device Status 8=Work with User
Job

Opt Device UserId IpAddress
HostName
BD7407S1 OMARCHUK 172.30.100.11 bd07407-
xp.city.northpor
BD7407S2 OMARCHUK 172.30.100.11 bd07407-
xp.city.northpor
BD7408S1 KROMANO 172.30.100.121 bd07408-
xp.city.northpor
BD7409S1 KROMANO 172.30.100.119 bd07409-
xp.city.northpor
BD7409S2 KROMANO 172.30.100.119 bd07409-
xp.city.northpor
BD7410S1 SignonDsp 172.30.100.144 bd07410-
xp.city.northpor
BD7742S1 KBOUDREAU 172.30.100.39
bdws07742.city.northport
BD7747S1 WBLACKMR 172.30.100.64
bdws07747.city.northport
BD7749S1 TLIFSEY 172.30.100.154
bdws07749.city.northport
BD7769S1 BUDKORTE 172.30.100.7 bd07769-
xp.city.northpor
BD7770S1 LSPERDUTO 172.30.100.48
bdws7770.city.northport

[prywante]

> 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.

Then must be trace in QHST log for that events. Search QHST log for CPF2234
or CPC2621 messages. Or review QSYSMSG message queue.

>
> 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?

Above two messages include device name for locked workstation and user
profile that was disabled.

best regards
Pegaz.

[CRPence]

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

[Graybeard]

An easy way to see what devices are disabled is to run
WRKCFGSTS CFGTYPE(*DEV) CFGD(*DSP) STATUS(*VARYOFF)

This will show all the sessions that are varied off, and may help you
identify the culprits.

[Stefano P.]

> 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 */

In my experience this is the only way to discover the ip address/pc from
which someone has disabled a user profile:
in our environment we receive a mail when one of our "AS/400" signals a
problem (we monitor QSYSMSG message queue) and we know almost
immediately when a user profile or a device gets disabled but the normal
message does not carry information about ip address/pc.

IMO at V5R4 the information put in QAUDJRN related to wrong passwords
are even more useful than in previous releases.

As in our environment normal users are *user class user profile, I
usually start to investigate when someone disables QSECOFR (this doesn't
happens often ;-) or other "power user" profile: almost always the
problem is caused by a colleague of mine but he does not want to admit
it until I discover the ip address ;-)

> Regards, Chuck

--
"Niuna impresa, per minima che sia,
può avere cominciamento e fine senza queste tre cose:
e cioè senza sapere, senza potere, senza con amor volere"
[Anonimo fiorentino, XIV sec.]

(togliere le "pinzillacchere" dall'indirizzo email ;-)

[Stefano P.]

Creating and monitoring QSYS/QSYSMSG message queue *may help* too:
among the various messages sent to this message queue (if present in the
systems), there are those related to user profiles and devices disabled.
There are also those related to disk problems and many others (memory
occupation etc. etc.) so *this is not the exact solution* for the
situation in the object.

Regards
Stefano P.

[Reeve]

Apart from the very useful advice above, you might like to consider
using a combination of distinct user profiles per user and EIM - not
as painful as it sounds and would go a long way to reducing the number
of service requests you're getting.

HTH Reeve