Invalid Sign-ons

pts.
Tags:
AS/400
DataCenter
Security
We are running V5R3 on an i5 520 Enterprise iSeries. Within the last two weeks I?ve noticed invalid sign-on attempts occurring on the user profile report for several disabled users. However, when I examine the history log, I can find no evidence of failed log-ins by the users in question. I have performed tests in which I have purposely entered bogus log-in info and each case, the invalid log-ins listed on the user profile report have corresponded with entries in the history log. Additionally, I?m not aware of any scheduled batch jobs which refer to the disabled profiles. But if there were, wouldn?t those error conditions show up on the log? Consequently, I have no idea how this situation could be occurring. Are there any other scenarios where invalid sign-on attempts would show on the user profile report but not on the history log? Any help would be greatly appreciated.
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

complete shot in the dark here. could it be SQL connections, or, I think some client programs can store a login/password to check for updates when they’re initially loaded. Anything else I can think of would be throwing messages at the user which would likely get you a call.

A while back, I noticed a bunch of attempts to log in as “ADMIN” (the account doesn’t exist) When we finally tracked it down, it was a user connecting to the AS400 from an access database. No idea how or why it was trying to connect as “ADMIN” and it never gave the user any message other then a standard ODBC login box.

hope that helps,
Kevin

=================================================================

The invalid logon attempts that you logged came from what kind of attempts? Most likely, those were terminal access (e.g., telnet signon panel) attempts.

Did you try FTP also? Remote commands (REXEC)? iSeries Access Navigator? Remote database/ODBC? Windows Explorer (NetServer)?

In general, the only source of “history log” messages of failed logon attempts will be from terminal/telnet signon panel attempts. Perhaps the only reason those still show up is because IBM can’t stop the sending of them; too many customers are looking for those messages.

There’s not much point in looking at them. For quite a few years, the system audit journal is where you should look for invalid logon attempts. All of the servers as well as the various APIs are logged there rather than in the history log. It’s a much more secure object to store the attempts in.

The disabled users are probably running Windows functions in their jobs. Their workstations probably have iSeries Access that is running automated network logons during startup. The attempts are made and they fail. They don’t affect anything as long as the users don’t need to actually get in to anything on your 520.

That’s just a possible scenario. A number of others might exist. Review your system audit journal if you need a detailed history. (Of course, auditing must be appropriately enabled first.)

Tom

Discuss This Question: 2  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • jinteik
    check out gosecurity. at that place you can set the parameter on how many days a user that hasn't login ID will be disabled. at the audit journal, all you can see is the profile that is changed from enabled to disabled...from there you can see who is the person who actually change the user profile to disable.
    18,995 pointsBadges:
    report
  • mcl
    You can get LOTS of information from the Audit Journal, depending on how you have set up auditing. You just have to know where to look. Go SECTOOLS. There is an option to set up auditing. You need to have the *AUDIT special authority to use this. You want at a minimum to set QAUDCTL to *AUDLVL and set QAUDLVL to *AUTFAIL (QAUDCTL and QAUDLVL are system values - you can also change them directly but the SECTOOLS menu gives you an easier way. Look at the "PW" audit records. You'll have to copy the audit journal entries to do this. Somewhere around column 311 you'll find the IP address. Simple enough from that to track down the source. Regards Mike
    2,740 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: