Message from QZSOSIGN that userid is disabled

55 pts.
Tags:
AS/400
QZSOSIGN
How do you find out or trace what job is trying to connect to the AS400 that is disabling a userid? I can't find it in the job logs or history logs anywhere, but I can see that the userid has been disabled at least twice now around the same time. We are on version/release 6.1.
ASKED: October 24, 2011  7:11 PM
UPDATED: March 17, 2012  7:14 AM

Answer Wiki

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

If you go the QSYS/QSYSMSG route you could use a monitor program similar to
<a href=”http://www.as400pro.com/tipView.php?cat=iSeriesTools&key=3780″>Monitors the QSYSMSG queue for disabled User profiles</a>.

This program is set to Enable the profile after a wait period, which you may/may not want to do. A flaw in this program is that it uses a delay for the wait period and during that time it appears that any critical messages would not be processed. Would work better to Spawn a separate job to Wait and Enable the profiles.

Discuss This Question: 10  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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    If you have message queue QSYS/QSYSMSG created on your system, you should be able to locate message ID CPF1393 in it fairly easily. By looking at the message details, you can get the fully-qualified job name. (Any other means of getting the fully-qualified name is just as good.) 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
    125,585 pointsBadges:
    report
  • CindyD1106
    Unfortunately it does not look like we have an auditing file created on this system... Thanks for your answer- but do you have any other ideas??? Cindy
    55 pointsBadges:
    report
  • wpoulin
    CindyD1106, 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
    2,480 pointsBadges:
    report
  • CindyD1106
    HI, 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!!!
    55 pointsBadges:
    report
  • TomLiotta
    Unfortunately it does not look like we have an auditing file created on this system… 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
    125,585 pointsBadges:
    report
  • TomLiotta
    Also, once you know the fully-qualified name of the QZSOSIGN job from looking at the history log or QSYSMSG, you could review its joblog to find the CPIAD06 message that should result from an incorrect password. Just before that message, there should be a CPIAD0B message that identifies a remote IP address. Tom
    125,585 pointsBadges:
    report
  • CindyD1106
    Going to see if auditing is an option as I do not have access to turn it on- Thank you so much for your responses and will keep you posted... Don't want to fool around with possibly messing up IP communication, so hopefully I will be able to get auditing started... Thanks again!!! Cindy
    55 pointsBadges:
    report
  • CindyD1106
    OK- so I am able to start auditing- but what should I audit for? Not sure what will capture what I am looking for. I tried to decipher the diferent options, but still not really sure what will capture which job is coming in that is disabling the user profile... 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!
    55 pointsBadges:
    report
  • TomLiotta
    I think *SECURITY and *AUTFAIL should help- 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
    125,585 pointsBadges:
    report
  • CindyD1106
    GREAT! Thanks for your responses! Hopefully will have this in place by the next time the userid gets disabled... Cindy
    55 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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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

Following