Conference vaxaxp::vmsnotes

   Apply the patches for the audit server -- there is a patch kit out for
   most releases prior to V7.1 or so -- and try this test again.

	http://www.service.digital.com/html/patch_public.html

	Hi,

on my test system AlphaStation 200 running V6.2-1H3,

I have the following error message :

sh audit/journ
List of audit journals:
  Journal name:           SECURITY
  Journal owner:          (system audit journal)
  Destination:            SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL
  Monitoring:             enabled
    Warning thresholds,   Block count:    100     Duration:    2 00:00:00.0
    Action thresholds,    Block count:     25     Duration:    0 00:30:00.0

%SHOW-W-NOAUDITING, security auditing disabled; no events will be logged  <====


I searched through VMS patches in
http://www.service.digital.com/html/patch_public.html and didn't find any
"audit_server" for V6.2.

The only patch which seems to have something to do with audit_server is
ALPLOAD02_070.

This one was already installed in my system.

Did I miss patch ?

What would the name of the "audit_server" patch for OpenVMS V6.2(-1H3)?

Any other idea ?


The problem seems to appear after the command $ set audit/server=new but I'm not
sure because I didn't do sh audit before the $ set audit /server=new command.

Maria.

   AUDIT_SERVER is likely too specific for a good search string. 
   Here are some of the patches relevent to AUDIT and SECURITY on
   OpenVMS Alpha V6.2:

	ALPSMUP01_070
	ALPLOAD02_070
	ALPSYS04_062

   Per a recent comment by the devo, the LOAD patch fixes all known
   problems in this subsystem.  If you've got the LOAD patch and have
   rebooted, it's QAR time...

   What is the output from SHOW AUDIT/ALL?

   The SET AUDIT/SERVER=NEW command does not cause SHOW AUDIT/JOURNAL
   to generate errors on a test on a local V7.1 system.

   It's worth logging a QAR on this regardless, as the NOAUDITING
   message is not present in the message database.

  I've seen this type of problem a few times. I've never been able to pin
  down a cause and effect, but there are 2 things which seem to fix it.

  1) Stop all AUDIT_SERVERs, make sure VMS$AUDIT_SERVER is defined
     /SYSTEM/EXEC across the whole cluster to point to the same
     physical file, then restart all AUDIT_SERVERs. Place the definition
     of the logical name in SYLOGICALS.COM for future reboots

  2) If 1 fails, Stop AUDIT_SERVERs, RENAME the VMS$AUDIT_SERVER.DAT file
     and restart AUDIT_SERVERs (a new file will be created). You will need
     to reapply any custom audit settings.

  I think the problem has to do with SET AUDIT/SERVER=NEW when there are
  multiple data bases, but I haven't any proof.

						John Gillings, Sydney CSC

	Hi,

.-1, my system is standalone. I got only one
SYS$COMMON:[SYSMGR]VMS$AUDIT_SERVER.DAT;1 file. No logical name.

.-2, ALPSMUP01_070, ALPSYS04_062. aren't installed in my system.

ALPLOAD02_070 is. I did reboot after this patch was installed.
I verified the checksums of every image.

Here is show audit/all

sh audit/all
List of audit journals:
  Journal name:           SECURITY
  Journal owner:          (system audit journal)
  Destination:            SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL
  Monitoring:             enabled
    Warning thresholds,   Block count:    100     Duration:    2 00:00:00.0
   Action thresholds,    Block count:     25     Duration:    0 00:30:00.0

Security auditing server characteristics:
  Database version:       4.4
  Backlog (total):        100, 200, 300
  Backlog (process):      5, 2
  Server processing intervals:
    Archive flush:        0 00:01:00.00
    Journal flush:        0 00:05:00.00
    Resource scan:        0 00:05:00.00
  Final resource action:  purge oldest audit events

Security archiving information:
  Archiving events:       none
  Archive destination:

System security alarms currently enabled for:
  ACL
  Authorization
  Audit:         illformed
  Process:       DELPRC
  Breakin:       dialup,local,remote,network,detached
  Login:         remote,network,detached
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached
  FILE access:
    Failure:     read,write,execute,delete,control

System security audits currently enabled for:
  ACL
  Authorization
  Audit:         illformed
  Process:       DELPRC
  Breakin:       dialup,local,remote,network,detached
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached
  FILE access:
    Failure:     read,write,execute,delete,control

%SHOW-W-NOAUDITING, security auditing disabled; no events will be logged

Maria.

:                                 -< QAR time >-

   Yes, it is.

   If you need to take this system down prior to receiving a response
   on the QAR, please use the documented node crashdump procedure, and
   write out a dump file.

re: .5

You should try SET AUDIT/SERVER=INITIATE and see if the audit server
comes on-line.  If so, you need to troubleshoot your environment and
figure out what's happening.
\john

From VMSNOTES V11 :

            <<< VAXAXP::NOTES$:[NOTES$ARCHIVE]VMSNOTES_V11.NOTE;1 >>>
               -< VAX and Alpha VMS - Digital Internal Use Only >-
================================================================================
Note 882.5  %SHOW-W-NOAUDITING, security auditing disabled; no events wi  5 of 5
STAR::DAVIDSON "Stu Davidson - OpenVMS Engineering"  14 lines  18-MAY-1995 08:19
                -< could you need "SET AUDIT/SERVER=INITIATE"? >-
--------------------------------------------------------------------------------
    
    Relatively early in normal system startup, the audit server process is
    started. Later, a "$ SET AUDIT/SERVER=INITIATE" command is executed.
    
    This allows the audit server process time be get initiailized, and
    allows initialization of object security support, before starting to
    audit activity. 
    
    If (as an example) you boot 'MIN', then start the audit server with
    "SET AUDIT/SERVER=START", you would need to also issue a 
    "SET AUDIT/SERVER=INITIATE".
    
    Perhaps this is your problem.
    

	hi,

-1, yes, set audit/server=initiate solved my problem.

But, I don't see where I have a configuration problem.

The auditing worked fine until I wanted to create a new security journal file.

But in fact, in my system, the following sequence is reproductible at will.

1) set audit/server=exit
2) set audit/server=start  ===> noauditing
3) set audit/server=initiate ===> all comes ok again

Perhaps I missed something in the documentation ? Is /server=initiate mandatory
after a /server=start ?

Before I find this workaround, I generated a sysdump, but I wonder now if it's
worthwhile doing a QAR. 

Same behaviour in OpenVMS 7.1.

Maria.

:Before I find this workaround, I generated a sysdump, but I wonder now if it's
:worthwhile doing a QAR. 

    This is either a bug in the audit server, or incomplete documentation.

    (Personally, I vote for `bug'.)

    Log the QAR.

re: .10

The documentation on V7.0 and V7.1 is improved over V6.2.  The nugget
you seek is under $ HELP SET AUDIT/SERVER=INITIATE

The recommended way to start the audit server is:

    $ @SYS$SYSTEM:STARTUP AUDIT_SERVER

\john