Endpoint Administration Guide for Windows › Monitoring and Auditing › What CA ControlMinder Audits

What CA ControlMinder Audits

For security auditing, CA ControlMinder keeps audit records for intercepted events according to the audit rules defined in the database and the enforcement mode it operates in. The records in the audit log accumulate according to these audit rules.

Full auditing provides audit records for all intercepted events of any of the following:

• File access (FILE class)
• Program execution (PROGRAM class)
• Registry access (REGKEY and REGVAL classes).
• Impersonation control (SURROGATE class)
• Network control (CONNECT, TCP, HOST, GHOST, HOSTNET, and HOSTNP classes)
• Log in (TERMINAL class)

  Note: Intercepted login events are not cached; they always follow the auditing process for interception events.

• Service protection (WINSERVICE class)
• Password verification failure (PASSWORD class)
• Process termination (PROCESS class)

The decision whether to log an event depends on the CA ControlMinder interception mode.

Login Interception Limitations

Login interception on Windows is supported only by CA ControlMinder sub-authentication method.

You cannot set login interception through the kernel. As a result, you should consider the following:

• Since the sub-authentication component works on the Domain Controller (DC) level, and it is up to the OS to decide which DC authenticates the user's login events (and triggers the CA ControlMinder sub-authentication module), in a Windows domain environment, CA ControlMinder needs to be installed on every DC.
• When working in a Windows domain environment, CA ControlMinder login policy (TERMINAL rules) need to be located on the DCs and not necessarily on the target server.

  For example, if you would like to protect or audit login events made by domain users on a file server, which is part of the Windows domain but is not a DC, the CA ControlMinder login policy needs to be defined on the DC and not on the target file server. This is because when a domain user accesses the shared file directory, a login authorization occurs on the DC, not the file server.

• When there is more than one DC, CA ControlMinder login authorization could be processed on any one of the DCs. As a result, we recommended you synchronize CA ControlMinder login policy between all DCs.

  You can implement this through either the Policy Model mechanism, where all DCs are subscribers to a PMDB, or by adding all DCs into a host group and deploying a common policy using advanced policy management.

• Some user properties, which correspond to login events, are updated at runtime-during event authorization. These properties might be out-of-sync because the login authorization happens only on one of the DCs. These properties are Gracelogins, Last accessed, and Last access time.

  That said, it is possible that, for example, the user's property Last access time value will be different between DCs because CA ControlMinder sub-authentication was triggered on one of the DCs, not on all of them.

• To enforce local users (that is, not domain users) login events, CA ControlMinder needs to be installed on the local computer that the local user needs access to. This is because the local computer is used as the domain computer (the domain is the local computer).
• Remote Desktop Protocol (RDP)/Terminal Services login events are enforced on the target server as it was in previous CA ControlMinder versions. However, for RDP login events, CA ControlMinder login policy should be defined on the target server.