Hopefully will have this in place by the next time the userid gets disabled…

Cindy

The one you want for your specific question is *AUTFAIL. The *SECURITY value is, of course, also highly recommended; but I’m not aware of it giving what you need here.

will the journal be automatically created once auditing is turned on- or will I have to create it myself?

No. And yes.

If you do it directly, you must (1) create a receiver, (2) create journal QSYS/QAUDJRN with the receiver attached that you previously created, then (3) set the enabling system values.

If you do it indirectly, it will all be done for you. But I’m not going to describe that method due to significant potential side-effects that you really ought to understand before doing it. It really should only be done that way when an initial system setup is also being done.

Tom

I think *SECURITY and *AUTFAIL should help- but not sure if any of the communication ones will be helpful…

It has been quite a while since I have done anything with auditing on the AS400, so now I have one more question- will the journal be automatically created once auditing is turned on- or will I have to create it myself?

Thanks again in advance for your input!

Thanks again!!!

Cindy

Tom

If auditing isn’t set up and enabled, the system has effectively been told not to keep the information.

Is there a way to trace communications into the system because it seems that we have narrowed down the time and possibly the days that it is happening…

I suppose you could use STRCMNTRC, but you’ll really want someone experienced with communications programming to make good sense of it. A reasonably sized trace, perhaps set as *WRAP, might be started. When CPF1393 shows up, the trace could be ended and analyzed. There are other tracing options, but more people have seen basic comm traces. (You could also run various traces on your network, e.g., Ethereal and/or Wireshark, etc.)

You could also use iSeries Navigator and drill down into Network-> IP Policies-> Packet Rules, select Rules Editor. Create a set of rules that journals IP packets. Make sure that the final default rule allows everything. I think you’d want the inbound CLIENTACCESS_8476_TCP_FC and CLIENTACCESS_9476_TCP_FC services set for JRN = FULL.

But if the system has never had anyone working successfully with these rules, I sure can’t recommend it. You can block TCP/IP access real quick with packet rules, and it can take some tricky footwork to dance around them if you’re not prepared.

IMO, the best choice is simply to start auditing. Let the system do what it’s already capable of doing.

Tom

Yes I was able to find the CPF1393 message within the history log- but it does not give me any indication as to what job is trying to access the system that is disabling the user profile. That gives me the time the userid is disabled and information about the qzsosign job, but not where the incoming job is coming from. This is coming from a remote job or server or user…

But thank you for your input.

Is there a way to trace communications into the system because it seems that we have narrowed down the time and possibly the days that it is happening…

Thanks!!!

You could also look in the system log. Use DSPLOG PERIOD((*AVAIL *BEGIN) (*AVAIL *END)) MSGID(CPF1393). This will isolate when profiles are being Disabled. Then use DSPLOG to see if you can identify the job they were using to attempt to sign on.

Hope this helps,
Bill Poulin

Thanks for your answer- but do you have any other ideas???

Cindy

With the fully-qualified job name, use DSPJRN over QAUDJRN to list any T/PW entries that came from that fully-qualified job name. The list should be reasonably small when filtered that much. Look at the journal entry header data to find the remote address of the client.

From there, you’ll have to look at whatever the client is doing to try to sign on. One common problem is a cached password.

Tom