All Certificate Services auditing is reported to the security log in Event Viewer. Any attempt to back up or restore the CA database is logged to the Windows security log. Any attempt to modify CA configurations is logged.
Any attempt to modify CA permissions is logged. This can include adding CA administrators or certificate managers. Logs any attempt by a certificate manager to approve or deny certificate requests with subject approval pending. Right-click any other event category that you want to audit, and then select Properties. The changes that you make to your computer's audit policy setting take effect only when the policy setting is propagated or applied to your computer. Complete either of the following steps to initiate policy propagation:.
If you are either a domain or an enterprise administrator, you can enable security auditing for workstations, member servers, and domain controllers remotely. After you configure an audit policy setting, you can configure auditing for specific objects, such as users, computers, organizational units, or groups, by specifying both the types of access and the users whose access that you want to audit. To configure auditing for specific Active Directory objects:.
Right-click the Active Directory object that you want to audit, and then select Properties. Select either the Successful or the Failed check box for the actions that you want to audit, and then select OK.
The size of the Security log is limited. Because of this limitation, Microsoft recommends that you carefully select the files and the folders that you want audit. Also consider the amount of disk space that you want to devote to the Security log. The maximum size is defined in Event Viewer. Skip to main content.
This browser is no longer supported. You could then review the audit log to see who had trouble logging in to the network. If a user's name appears only once in the security log, then you could probably assume that the user simply typed their password incorrectly. If you discover that a particular user has tried to log in unsuccessfully a number of times--especially after business hours--then you may want to investigate the invalid login as a possible hack attempt.
If you make such a discovery, you can take steps to counteract the hack attempt. These steps might include things like creating a policy that disables user accounts after three bad login attempts within a few minutes.
If the hack attempts continue, you might look at what time the attempts are made each night and try to catch the hacker red-handed. Now that you have a basic idea of what auditing is and how it works, it's time to begin building an audit policy. I'll start by showing you how to audit an event. Once I've done so, I'll explain which events that I recommend auditing. As I mentioned earlier, auditing is configured through the use of an audit policy.
You can set an audit policy to be applied to domain controllers, member servers, stand-alone servers, or workstations. If you apply a non-local audit policy to a domain controller, all other domain controllers within the domain will share that audit policy.
I strongly recommend auditing all domain controllers because they are so crucial to your organization's security. It's also not a bad idea to audit member servers or stand-alone servers too if they contain any sensitive or confidential data. I don't recommend auditing Windows XP Professional workstations, unless you have a very specific reason for doing so.
It's simply too time-consuming and inconvenient to constantly review the audit logs on every single workstation. Before you begin to build an audit policy, I should point out that to do so you must have the Manage Auditing And Security Log user right. The Administrator account has this right by default, but if you want a nonadministrator to manage the auditing, you'll have to grant them the appropriate permissions.
In actuality, having a nonadministrator to do the auditing isn't a bad idea. You can remove the Manage Auditing And Security Log user right from the administrator's group to ensure that only one person has rights to the audit log. This is one way to keep administrators honest, since they won't be able to clear the security log after a misdeed. The process of enabling auditing is similar for domain controllers and non-domain controllers.
The biggest difference is that you use a different tool to get the job done. To set up an audit policy for your domain controllers, open the Active Directory Users And Computers console and navigate through the tree to Domain Controllers. Right-click Domain Controllers and select the Properties command from the resulting context menu. When you do, you'll see the Domain Controllers properties sheet.
Now, go to the Group Policy tab, select the group policy that you want to audit, click Edit, and Windows will load the Group Policy console. You're now at a point where the basic auditing technique is the same for both domain controllers and non-domain controllers. To set up auditing for a non-domain controller, open the Local Security Policy console and navigate through the tree structure to Security Settings Local Policies Audit Policy.
You can see an example of this screen in Figure B. From this point, the technique is the same whether you're on a domain controller or not. Let's audit an event. For demonstration purposes, we'll audit failed login attempts. As you can see in Figures A and B, Windows lists several different types of events that can be audited. One of these events is Audit Account Logon Events. To audit a logon failure, right-click Audit Logon Events and select the Properties from the resulting context menu.
When you do, you'll see a dialog box that will allow you to audit the events. The dialog box will vary slightly depending on whether or not you're auditing a domain controller.
0コメント