Microsoft pki infrastructure 2008 r2

Download Microsoft Edge More info. Contents Exit focus mode. In this article. Microsoft Business. Microsoft Enterprise. Browse All Community Hubs. Turn on suggestions.

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type. Showing results for. Show only Search instead for. Did you mean:. Sign In. Published Jan 24 PM Views. Version history. Last update:. Updated by:. Events that generate a security alert should contain the following:.

An example of the first type of event occurs if a user not authorized for interactive logon on a CA registers a logon event. An example of the second type of event is multiple failed access attempts from a user, which could be a sign of a brute force password guessing attack. For electronically collected events, develop a plan for continued storage of collected event data and retention of the events. For events recorded through manual processes, establish processes for archiving and reviewing event logs for abnormalities at regular intervals.

Changes to critical groups that control access to the CA. This would include any custom groups containing users with elevated rights in the PKI to manage CAs, RAs, or enroll for important certificate types. Changes to accounts that have privileged access to the PKI. When using additional software packages that act as a RA to a CA, include the service accounts used by these systems in this list. Because a CA is a high-value system, monitor it closely for abnormal activity.

The events to monitor closely can be broken down into two major categories:. Suspicious use of accounts belonging to registration authorities. For example, if a smart card management system uses a specific service account to request certificates from the CA and that account makes certificate requests from systems that are not part of the smart card management system.

In addition to monitoring CAs that are online and issuing certificates, it is also important to record and review other events that may impact PKI security. These events may not be captured electronically, but may rely on paper-based logs and require periodic review for anomalies. Below are some recommendations for additional activities to record and review:. Entry and exit to the secure area where PKI hardware is stored or operated.

This could include access to the secure CA cage, access to the server room where the CAs are located, review of camera footage, etc. This includes any transportation of HSMs or tokens when they are physically moved. Access to any secure storage locations containing PKI backups or sensitive data. Examples include access logs for a safe, access records to a document archive facility, etc. Subcategories allow auditing to be far more granular than it could be otherwise by using the main categories.

By using subcategories, portions of a particular main category can be enabled, and events for which there is no need can be eliminated. Each audit policy subcategory can be enabled for Success, Failure, or Success and Failure events.

To see the current audit policy for a system, type the following at the Command Prompt:. To configure this using auditpol. While audit policy can be configured per computer using auditpol. Set the subcategory to be enabled for Success and Failure. See the screenshot below. This data includes the exact command used to launch a process, including command line parameters. More information on configuring command line process auditing can be found here.