Re: Runaway QTVDEVICE job -- MIDRANGE-L

Great research, I have experienced the same issue with profiles in the
past. I couldn't get to this point that you have. Hands in too many
things. I saw many of the same things you identified. Would love to know
what happened.

My thought was that these users mapped an IFS location to their PC and
configured it to log in with their Windows Password. Which was against my
step by step instructions. :-) I wasn't able to get it cleared up even
after disconnecting the map.

In the end, we deleted the profile and created them a new know. One user
had a new profile created, while the other was recreated with the same
name. Neither user has had an issue sense. I know its not the answer you
are looking for, its just what we did. I would love to know what happened.

On Tue, Apr 16, 2019 at 7:57 AM Rob Berendt <rob@xxxxxxxxx> wrote:

I had two users get disabled over the weekend due to too many invalid
signon attempts. We do NOT have QMAXSGNACN set to disable profiles, just
devices. Apparently non 5250 jobs don't care about the device and they'll
disable the user profile anyway.

I used the api's at http://ibm.biz/DB2foriServices to search the history
log for the date time when they were disabled (same minute in two different
countries, Mexico and Texas!!! On a Sunday...) Then I used another API at
that site to search the audit journal to find out the exact IP address
which disabled each profile. This also showed me the job. Both were using
a different QTVDEVICE job. This is not the actual interactive session but
a companion job which supports the device.

One user had 397,221 invalid sign on's. The other user had 359,365
invalid signon attempts.

I'm still gathering what version of what product they are using for 5250
before opening the ticket with IBM.

Trying to determine how this could happen. Might it be that both those
PC's down south were trying to reconnect to the IBM i lpar here in Indiana
after a comm drop or some such thing? Funny thing is both users have a
"last password change date" greater than their "previous sign on date". So
maybe it kept trying to reconnect using the old passwords? A comm drop
between El Norte and them would be the most likely explanation as to why
they both got disabled in the same minute.

Person "O"
Previous sign-on . . . . . . . . . . . . . : 03/29/19 10:04:22
Date password last changed . . . . . . . . : 04/04/19 10:49:26
Person "A"
Previous sign-on . . . . . . . . . . . . . : 04/04/19 17:41:31
Date password last changed . . . . . . . . : 04/05/19 09:48:42

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com