Learning DCOM

Audit Trail

It is important to leave an audit trail for security or application problems. Traditionally, you record this kind of audit information into a persistent file so that an auditor or administrator can review it to detect and track down system problems. On Windows NT, a common and secure place to record messages is the Windows NT event log. In this section, you’ll learn how to take advantage of this facility.^[99]

While in the ValidateCall function (discussed earlier), we verify whether the method invocation is fully encrypted by looking at the authentication level that the client had set. This must match RPC_C_AUTHN_LEVEL_PKT_PRIVACY or you’ll record this violation in the audit trail. To refresh your memory, here’s the relevant code from ValidateCall that performs the check:

if (dwAuthnLevel!=RPC_C_AUTHN_LEVEL_PKT_PRIVACY) {
   LogSecurityViolation(user);
   . . .
}

Notice that you call the LogSecurityViolation function to log a violation message and the user who issued the call into the Windows NT event log. You’ll write this function, but before you can to that, you must consider the following:

• Create a message file—Windows NT requires that event log messages be stored in a binary message file that it can read. If you don’t provide this message file, your messages will not be correctly formatted and will look strange in the Windows NT event viewer (eventvwr.exe). To get this binary message file, you must first create a source message file and then compile the message source file ...