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