Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
10 replies Latest Post - ‏2011-03-25T13:19:36Z by emilyt
owkrina
owkrina
15 Posts
ACCEPTED ANSWER

Pinned topic The 3 options of Audit service provider don't work as InfoCenter says.

‏2011-02-23T09:43:43Z |
Hello, everyone

We're testing security auditing. The environment is as below.

*Deployment Manager
*Node Agent
*Server1
*IHS
All components are in the same machine, AIX..
I configured Audit service provider as below.

1. WRAP
2. Maximum size of audit log files as 1 MB
3. Maximum number of audit log files as 1

First, I found that an audit log generated in Deployment Manager's log directory exceeded 1 MB. It was about 2MB.(Figure 1 in the attached file)
Then another audit log with a timestamp was also generated in the same directory.
I think that as the maximum number of log files is set as 1 and the maximum size is set as 1MB, when an audit log was generated and reached to the maximum size, the audit log should be overwritten from the first line in the file and 2nd log will not be generated.

Second, I found a similar phenomenon in server1's log directory.
That is, another audit log with a timestamp was generated in the directory in spite of the setting above. However one difference is that in this case, the log hasn't reached to the maximum size at all, about 16KB. (Figure 2)

Next,

The second setting is as below

1. NOWRAP
2. Maximum size of audit log files as 1 MB
3. Maximum number of audit log files as

When an audit log reached to the maximum size, another audit log with a timestamp was generated same as the WRAP case above. As overwriting is not allowed in this setting, this behavior seems to be right, but as the maximum number was set as 1, I thought the audit service would stop because the system can't generate a new log anymore, and that a notification would be sent to SystemOut.log, the application server would stop, and another audit log would NOT be generated.
However, those actions(to stop audit service and ap server, to send a notification) were not taken, and another log was generated in DM and server1 log directory.

Besides, the audit logs in server1 log directory seems to be overwritten. (Figure 3-5)
In Figure 3, a log without a timestamp and another log with a timestamp are generated. The former is newer and the latter is older.
Then in Figure 4, both of the logs are renamed with different timestamps. I think the two logs were overwritten.
Then in Figure 5, one log with the timestamp of 11.02.22_16.11.41 which is older, is renamed without a timestamp, and the file size is decreased. I thought this log is completely overwritten with new contents (so the file is low). The log with the timestamp of 11.02.22_16.12.45 remains as the same but the timestamp was renamed in a few minutes later. This actions repeats.
Next,

The last setting is as below

1. SILENT_FAIL
2. Maximum size of audit log files as 1 MB
3. Maximum number of audit log files as

The behaviors are almost the same as the NOWRAP case, except that ap server didn't stop and no notification was sent even if the maximum size of the audit log was reached in DM (correct behavior in this setting)
Suspect of overwriting as above and continuation of audit service are the same as NOWRAP case above.

Are all these behaviors correct or wrong?
Updated on 2011-03-25T13:19:36Z at 2011-03-25T13:19:36Z by emilyt
  • emilyt
    emilyt
    8 Posts
    ACCEPTED ANSWER

    Re: The 3 options of Audit service provider don't work as InfoCenter says.

    ‏2011-02-23T15:28:54Z  in response to owkrina
    Hopefully can clarify some things with respect to audit:

    The maximum number of audit log files specifies the maximum number of binary log files to create before the oldest is replaced.

    Note: The maximum number of logs does not include the current binary log that is being written to. It is a reference to the maximum number of archived (timestamped) logs. The total number of binary logs that can exist for a server process is the maximum number of archived logs plus the current log.

    So you should be expecting to see 2 logs in the instances you're describing below.

    Logs will also be timestamped when the server process is restarted.

    For option 1, WRAP, the dmgr timestamped log should not have exceeded 1 MB; we can enable some tracing to determine what this issue is.

    Auditing is available only at the cell level. Hence, in option 2, when the maximum size and number of archived audit logs on the DMGR is reached, the dmgr should have stopped and you should have seen a message in SystemOut indicating that the DMGR proess was stopping because the NOWRAP option was selected and the maximum number of logs had been reached.

    For option 3, SILENT_FAIL, again since this is at the cell level, the dmgr should have stopped but you would not have received a notification of that.
    • owkrina
      owkrina
      15 Posts
      ACCEPTED ANSWER

      Re: The 3 options of Audit service provider don't work as InfoCenter says.

      ‏2011-02-24T01:45:08Z  in response to emilyt
      Thank you for your clarification.
      So the 2 logs I saw in each instance are correct.That's good.

      Last night I set Audit service provider as NOWRAP again, and now I found that Dmgr has been stopped and this action was written in SystemOut.log.So I guess WRAP option should work right.

      As for SILENT_FAIL, InfoCenter says that "This option does not rewrite over the oldest audit log. It also stops the audit service, but does allow the WebSphere process to continue. Notifications are not posted in the SystemOut.log. " So,when I set this option, the dmgr didn't stop and no notification was sent to SystemOut.log.But it didn't seem to stop the audit service since audit logs were still being generated at that time.

      >we can enable some tracing to determine what this issue is.
      Could you please do so.
      And if possible, could you please check if auditing service would stop when maximum size is reached in NOWRAP and SILENT_FAIL options.

      Thank you in advance
      • emilyt
        emilyt
        8 Posts
        ACCEPTED ANSWER

        Re: The 3 options of Audit service provider don't work as InfoCenter says.

        ‏2011-02-25T15:32:45Z  in response to owkrina
        Hi owkrina,

        I set up a Dmgr with 2 federated nodes, along with auditing enabled - one trial with NOWRAP, the other with SILENT_FAIL, 1 MB maximum file size and 1 maximum archived log.

        In both instances, when I reached the maximum threshholds on the Dmgr, the server did quiesce, and with the NOWRAP option I did see the message in my prior post in the Dmgr's SystemOut.log.

        If you are still seeing an issue, or an issue with the logs exceeding the maximum size, could you please enable and post traces from a server restart thru the time the issues are seen? The trace string would be: com.ibm.ws.security.*=all:com.ibm.ws.security.policy.*=off:com.ibm.ejs.ras.*=all and that should updated in the TraceSpecification object in the Dmgr's server.xml.

        Thank you,
        Emily
    • owkrina
      owkrina
      15 Posts
      ACCEPTED ANSWER

      Re: The 3 options of Audit service provider don't work as InfoCenter says.

      ‏2011-02-25T09:30:59Z  in response to emilyt
      Hello,

      Let me ask additional questions.

      >Auditing is available only at the cell level. Hence, in option 2, when the >maximum size and number of archived audit logs on the DMGR is reached,
      >the dmgr should have stopped and you should have seen a message in SystemOut >indicating that the DMGR proess was stopping because the NOWRAP option was >selected and the maximum number of logs had been reached.

      Does this mean the only Dmgr would stop when the maximum size of audit logs in Dmgr was reached? How about Node Agent and AP servers? Will the node agent and ap servers would also stop when maximum size was reached in each log directory?

      And as for the audit services for the node agent and ap servers, do they stop in NOWRAP and SILENT_FAIL options as the audit service for Dmgr would stop?

      In NOWRAP option,a notification will be sent to SystemOut.log. Is this notification about only that server processes were stopped? Will it be notified that audit services were stopped in SystemOut.log?

      Thank you in advance
      • emilyt
        emilyt
        8 Posts
        ACCEPTED ANSWER

        Re: The 3 options of Audit service provider don't work as InfoCenter says.

        ‏2011-02-25T13:54:57Z  in response to owkrina
        Hi owkrina,

        Thank you very much for trying out the audit logging and for providing some feedback.

        In answer to your questions:

        The audit configuration applies to cell level, but each process - dmgr, registered server, nodeagent - keeps track of when the maximum size and maximum number of archived audit logs is reached.

        So when the maximum size and archived number is reached, the Dmgr process will stop with the NOWRAP and SILENT_FAIL options, but not necessarily the registered servers or nodagents; they will stop when they have reached their maximum size and archived number of logs.

        With NOWRAP, the notification of the stopped process will be sent to that process' SystemOut.log and will only pertain to that process. The notification message output to the SystemOut.log log for that process will be similar to:

        2/23/11 20:18:02:031 CST 0000001a BinaryEmitter E SECJ6053E: The audit log wrapping behavior is set to NOWRAP and the maximum number of audit logs has been reached. Quiescing the server.

        I hope that helps clarify things a bit.
        • owkrina
          owkrina
          15 Posts
          ACCEPTED ANSWER

          Re: The 3 options of Audit service provider don't work as InfoCenter says.

          ‏2011-02-28T08:09:31Z  in response to emilyt
          Hello,emilyt,

          Thank you for your reply.

          I tested again with SILENT_FAIL option.1MB for the maximum size and 1 file for the maximum number of logs.
          It was successfully working as design this time. That is, when the the maximum size and the number of logs were reached in DM, the auditing service was stopped and DM was still on. And no description about this was written in the SystemOut.log.

          One more question to clarify:(I'm a bit confused)
          In WRAP option with maximum size 1MB and maximum number 1, when the first log was reached to the maximum size, why will this log be archived and a new log will be generated? This option should overwrite the log so I thought there should be no archived log.Or is it the archived log that will be overwritten? (but it exceeded the maximum size completely as I wrote at first)
          You wrote that you tested NOWRAP and SILENT_FAIL, if possible could you please test with WRAP option? Maximum size exceeding issue happened in WRAP as I wrote before.

          Thank you in advance
          • emilyt
            emilyt
            8 Posts
            ACCEPTED ANSWER

            Re: The 3 options of Audit service provider don't work as InfoCenter says.

            ‏2011-02-28T15:56:24Z  in response to owkrina
            Hi owkrina,

            The maximum number of audit logs refers to the maximum number of archived - or timestamped - logs. So there will always be the curret log + (maximum number of timestamped logs) present in the process's audit log location.

            In the scenario you describe below, let me describe the behavior from server startup. On startup, we are writing to the current audit log, that is one that does not have a timestamp on it. When we reach the 1MB size, we timestamp that log off and begin writing (again) to the current log . When logB reaches the 1MB threshhold, logA is removed, and logB is timestamped, becoming the "new" logA. We then continue writing audit records to the new curent log, the "new" logB. We repeat this behavior each tme the current log reaches it's maximum size threshhold.

            Let me know if that explaination is still not clear.

            We should never exceed the maximum size of an audit log. I'll retest the WRAP option, using your configuration parameters. If possible could you also enable trace and provide the trace output for the scenario where you are seeing the maximum size exceeded? The trace string would be: com.ibm.ws.security.*=all:com.ibm.ws.security.policy.*=off.

            I'll repost my results with the WRAP option.

            Emily
            • owkrina
              owkrina
              15 Posts
              ACCEPTED ANSWER

              Re: The 3 options of Audit service provider don't work as InfoCenter says.

              ‏2011-03-01T01:55:02Z  in response to emilyt
              Hi Emily

              Thank you for your reply.

              I finally understood the behavior.Thank you very much for your detailed explanation.

              >If possible could you also enable trace and provide the trace output for the scenario where you are seeing the maximum size exceeded?

              I enabled trace with the string and watched if the maximum size would exceed but I could not see that phenomenon again, so there should be no suspicious log in the trace. It might not be a repeatable behavior but I'd appreciate it if you'd retest this issue.

              Thank you in advance
              • owkrina
                owkrina
                15 Posts
                ACCEPTED ANSWER

                Re: The 3 options of Audit service provider don't work as InfoCenter says.

                ‏2011-03-25T07:40:33Z  in response to owkrina
                Hi, Emily

                Have you tested this issue? Since this problem hasn't occur but at least audit logs can be logged, I guess this issue could be disregarded.

                Thank you
                • emilyt
                  emilyt
                  8 Posts
                  ACCEPTED ANSWER

                  Re: The 3 options of Audit service provider don't work as InfoCenter says.

                  ‏2011-03-25T13:19:36Z  in response to owkrina
                  Hi owrkrina,

                  Yes, I have been testing all 3 options periodically as we publish new drivers, and have not seen it behave as you described, i.e., the logging is working as described in the Infocenter.

                  I will continue monitoring the logging issue to ensure we have no regressions, but to date, have not seen any unexpected behavior.

                  Emily