PreviousNext

Initializing the Audit Records

Audit records can be initialized by using the dce_aud_start_*( ) functions. This function has five variations, and the use of each variation depends on the available information about the server. In general, if you have the RPC binding information about the server, use the dce_aud_start( ) function. If not, use the other four variations of this function, depending on the available information. The five variations are as follows:

· dce_aud_start( )

For use by DCE RPC-based server applications.

· dce_aud_start_with_server_binding( )

For use by DCE RPC-based client applications.

· dce_aud_start_with_pac( )

For use by applications that do not use DCE RPC, but use the DCE authorization model.

· dce_aud_start_with_name( )

For use by applications that use neither DCE RPC nor the DCE authorization model.

· dce_aud_start_with_uuid( )

For use by RPC-based applications that know their client's identity in UUID form.

The dce_aud_start_*( ) functions determine if a specified event must be audited based on the subject identity and event outcome that were defined for that event by the filters.

If the event specifics match the event filters (that is, the event has to be audited), these functions return a pointer to an audit record buffer. If it is determined that the event does not need to be audited, a NULL pointer is returned, and the application can then discontinue any auditing activity. If it cannot be determined whether the event needs to be audited (because the event needs to be audited based on a specific outcome(s) but the outcome is not yet known) these functions return a non-NULL pointer.

When an audit record is initialized, the identification of the audit subject (that is, the client of the distributed application) is recorded.

You can use the dce_aud_start_*( ) functions to specify the amount of header information in the audit record. You can specify any or a combination of the following:

· Information on all groups and addresses

· Information on groups only

· Information on addresses only.

Using these functions, you can bypass the filter altogether and log the event to the audit trail file or display it on the system console. This option is useful for applications whose events require unconditional audit actions.

In our example, each of the bank server routines (acct_open( ), acct_close( ), acct_withdraw( ), acct_deposit( ), acct_transfer( )) will make a dce_aud_start( ) function call. In the acct_transfer( ) routine, the function call is made as follows:

acct_transfer()

dce_aud_start (evt_vn_bank_server_acct_transfer,

h, aud_c_evt_all_info,

aud_c_esl_cond_success, &ard, &status);

where h points to the RPC binding of the client making the call. The aud_c_evt_all_info option means that all information about the client's groups and addresses are included in the audit record header. The aud_c_esl_cond_success event outcome means that the event completed successfully.