Re: possible to never disable specific user?

[Hoteltravelfundotcom <hoteltravelfun@xxxxxxxxx>]

we have a reporting tool that has an i user id to login to the system. So
that some developers have to enter the password when they are in the
report. So it happens that they enter it wrong 3x. Now that it gets
disabled the tool will not allow the scheduled report to run. So if we can
know on a daily basis - most reports run at night so 6pm to know if the id
is disabled would be good we can have someone get notified.

On Wed, Jan 21, 2015 at 2:00 PM, Kendall Kinnear <
Kendall.Kinnear@xxxxxxxxxxx> wrote:

> Be careful with the IP address on the T-PW entry. We have a RadWare device
> that concentrates our IP traffic for DR purposes. Unfortunately it also
> makes all IP traffic look like it is coming from a single IP address. I
> have absolutely no visibility to the "real" IP address of any device in the
> company.
>
> Respectfully,
> Kendall Kinnear
> System Analyst
> Standard Motor Products, Inc.
> Work: 972-316-8169
> Mobile: 940-293-7541
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> Monnier, Gary
> Sent: Wednesday, January 21, 2015 12:24 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: possible to never disable specific user?
>
> Rob,
>
> You have a point there.  The T-PW can carry the remote IP address which
> you can track back to.  If the IP address can't be traced back to an
> individual it can be traced to a location.
>
> If you don't have an IP address?  Well, it happens and you do your best.
>
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> rob@xxxxxxxxx
> Sent: Wednesday, January 21, 2015 10:06 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: possible to never disable specific user?
>
> Gary,
>
> If it's not an intentional CHGUSRPRF ... STATUS(*DISABLED) then all that
> audit log should show you would be someone trying to sign on as that person
> with no clue who that was.  If you're lucky it might store the IP address
> of the workstation who failed to sign on.
>
>
> 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
>
>
>
>
>
> From:   "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   01/21/2015 12:45 PM
> Subject:        RE: possible to never disable specific user?
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> You could use exit points to check the user's status.  If the profile is
> disabled notify "someone", this "someone" can then enable the account.
> This would be similar to Rob's MessengerPlus example.
>
> Auditing the user profile in question will provide the T-PW entries needed
> to track down who disabled the profile.  I've seen times where such
> profiles are deliberately disabled to halt work for one reason or another.
>  Placing the one who disabled the profile in the limelight, so to speak,
> can go a long way to ensuring disabling is really an accident.
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> rob@xxxxxxxxx
> Sent: Wednesday, January 21, 2015 9:14 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: possible to never disable specific user?
>
> Let me guess, 27 people know the password for QSECOFR.  When you change
> that password someone screws it up and disables that account.  Effectively
> doing a Denial Of Service attack against QSECOFR.  So you are trying to
> prevent this DOS attack.
>
> This fear of a DOS attack against your security accounts is why some
> people only have QMAXSGNACN vary off the device and not disable the user
> profile.
>
> Of course, I feel your pain.  But, expect someone to reply that your
> security accounts should be the ones which get disabled the fastest upon
> incorrect sign on.  They have a point also.
>
> Or, instead of QSECOFR, you have a 'generic' account for shop floor
> personnel or some such department?
>
> For that case, the message monitoring is probably the desired solution.
>
>
> 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
>
>
>
>
>
> From:   Hoteltravelfundotcom <hoteltravelfun@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   01/21/2015 10:37 AM
> Subject:        possible to never disable specific user?
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> we have disabling of any user if failed password 3x,
>
> can this be changed for specific user to never be disabled?
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
> ________________________________
>
> Please consider the environment before printing this email.
>
> The content of this e-mail (including any attached files) is confidential
> and may be privileged and protected by law. It is intended solely for the
> purpose of the person to whom it is addressed. If you are not the intended
> recipient of this message, please notify the sender immediately and delete
> the message (inclusive of any attached files). In addition, if you are not
> the intended recipient of this message, any disclosure, copying,
> distribution or taking any action in reliance of the contents of this email
> is strictly prohibited.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.