Re: Disabled Userids

Haven't hit it yet - The application is being migrated from mainframe to
iSeries and they are concerned that their application will go down if
these two specific non-interactive userids get disabled somehow. I need
to check the effect of setting the password to *NONE on the batch
process and also the invalid password attempts. I've told them I doubt
there is a solution to this inquiry, but I needed to say I've researched
it.

Like they say on the TV show The Office, "I'll check wikipedia.com. If
everyone in the world can contribute to it, you know you're only getting
the best answers...."



-----Original Message-----
From: security400-bounces@xxxxxxxxxxxx
[mailto:security400-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Wednesday, May 09, 2007 8:24 AM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Disabled Userids

The system value rules for # times bad password and what action
are global. But you can in the profile set this "batch-only" profile
to not expire to avoid an expire problem.
Set password to expired . . . . *NO
If it is "batch-only", then how did you hit this problem?
jim

----- Original Message -----
From: "Neeland, Steve" <Steve.Neeland@xxxxxxxxxxxxxx>
To: "Security Administration on the AS400 / iSeries"
<security400@xxxxxxxxxxxx>
Sent: Wednesday, May 09, 2007 9:14 AM
Subject: [Security400] Disabled Userids

Is anyone aware if a way exists to exempt a userid profile from
switching to a *DISABLED status when too many invalid passwords may be
entered? We have some special userids used for batch-only

applications,

and if they happened to get disabled the applications would return
abends.

Thanks!
Steve

_______________________________________________
This is the Security Administration on the AS400 / iSeries

(Security400)

mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.