View Active Directory (AD) Event Logs and what they track, will get you insights into AD’s health status.
AD event logs also help you identify potential security threats before they happen.
Audit Policy Categories:
1- Audit account logon events
2- Audit logon events
3- Audit account management
4- Audit directory service access
5- Audit object access
6- Audit policy change
7- Audit privilege use
8- Audit process tracking
9- Audit system events
to check configuration using CMD run auditpol /get /category:*
1- Audit account logon events (Event Logs 4768,4771,4769)
When enabled in the Default Domain Controllers Policy:
The Domain Controller records the event whenever it authenticates a user, computer, or service account on the domain.
Microsoft should have named the Audit account logon events policy Audit authentication events.
This event is logged on domain controllers only and both success and failure instances of this event are logged.
When a user enters a correct username and password, the DC logs a successful event ID 4768 as you can see below (A Kerberos authentication ticket (TGT) was requested), with Keywords: Audit Success
Important fields: {Account Name, Supplied Realm Name, Client Address, Keywords}
But what if a user enters a bad password? In this case, Kerberos pre-authentication catches the problem at the DC, and Windows logs event ID 4771 (Kerberos pre-authentication failed), with Keywords: Audit Failure
When a computer in the domain needs to authenticate to the DC typically when a workstation boots up or a server restarts. In these instances, you'll find a computer name in the User Name and fields. Computer generated Kerberos events are always identifiable by the $ after the computer account's name.
After obtaining a TGT, the workstation attempts to obtain a service ticket from the DC. Windows reports a successful attempt as event ID 4769 (A Kerberos service ticket was requested), with Keywords: Audit Success.
You’ll always see this instance of event ID 4769, which you can ignore, after an instance of event ID 4768.
The workstation next must obtain a service ticket for itself (i.e., a service ticket that authenticates a user to his workstation and allows him to log on). This event shows up as another instance of event ID 4769. The Service Name field in event ID 4769 identifies the service for which the ticket was granted.
—in this case, the workstation’s name. This instance of event ID 4769 is useful because it identifies the workstation by name; the earlier instance of event ID 4768 provided only the workstation's IP address.
That isn’t the end of event ID 4769. You’ll see additional instances for each server that user accesses after logging on to his workstation.
Imagine that user's logon script or persistent drive mappings initiate connections to a Files shared folder on a File server.
The DC will log event ID 4769 when user workstation obtains a service ticket to File Share.
2- Audit logon events
Audit Account Logon events VS Audit Account logon
The Audit logon events policy records all attempts to log on to the local computer, whether by using a domain account or a local account.
If the policy enabled On Domain Controller, this policy will record attempts to access the DC only.
The policy does not track a user who uses a domain account to log on at a workstation.
The Audit account logon event policy On DCs, tracks all attempts to log on with a domain user account, regardless of where the attempt originates.
If you enable this policy on a workstation or member server, it will record any attempts to log on by using a local account stored in that computer’s SAM.
Audit logon events records access to after the user was authenticated (after audit account logon events)
Audit logon events records a lot more information (like when the user disconnected from the server and when logged off) .
Events logs..
| 4624 | A user successfully logged on to a computer. |
| 4625 | Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password. |
| 4634 | The logoff process was completed for a user. |
| 4647 | A user initiated the logoff process. |
| 4648 | A user successfully logged on to a computer using explicit credentials while already logged on as a different user. |
| 4779 | A user disconnected a terminal server session without logging off. |
| Logon type | Logon title | Description |
|---|---|---|
| 2 | Interactive | A user logged on to this computer. |
| 3 | Network | A user or computer logged on to this computer from the network. |
| 4 | Batch | Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention. |
| 5 | Service | A service was started by the Service Control Manager. |
| 7 | Unlock | This workstation was unlocked. |
| 8 | NetworkCleartext | A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext). |
| 9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections. |
| 10 | RemoteInteractive | A user logged on to this computer remotely using Terminal Services or Remote Desktop. |
| 11 | CachedInteractive | A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials. |
Logon Type 3 - Remote logon - from IP172.21.200.248, port 59134
3- Audit Account Management (Event Logs 4720 to 4780)
When enabled in the Default Domain Controllers Policy:
The Domain Controller records the changes make to users, computers or groups in Active Directory by admin
* Creates, modifies, or deletes a user account or group.
* Sets or changes a password.
* Enables, disables, or renames a group or user account.
4- Audit Directory Service Access
When enabled in the Default Domain Controllers Policy:
The Domain Controller records the attempts by users to access Active Directory objects.
Types of objects in Active Directory
Container objects: These objects can contain other objects within them {ex: Groups and organizational units (OUs)}
Leaf objects: These objects cannot contain other objects. These objects are only representations of resources in the AD network. {ex: Users, computers, and printers}
Audit Directory Service Access is a low-level auditing for all types of objects in AD. Directory Service Access events not only identify the object that was accessed and by whom but also document exactly which object properties were accessed.
How to activate?
First, enable the audit policy at the system level.
1- Open AD Users and Computers MMC (DSA.MSC).
2- Right-click the Domain or the target AD Object > click Properties
.png)
3- Click the Security tab > Click the Advanced button
.png)
4- Click the Auditing tab
5- Click Add to begin adding SACL entries
6- Click the Object tab
.jpg)
7- Click the Prosperities tab
Second, Configure audit policy at GPMC.
.png)
AD Service Access has four subcategories:
* Directory Service Access: (Event Logs 4661&4662)
Directory Service Access allows you to track read-only operations on AD.
{changing the permissions on an OU such as for delegating administrative authority requires the WRITE_DAC permission which would get logged by this event.}
((Recommend disabling the "Directory Service Access" in your audit policy))
* Directory Service Changes. (Event Logs 5136,5137,5137,5139&5141)
Directory Service Changes tracks modifications to AD objects and their properties.
((Recommend that you enable only the Directory Service Changes subcategory.))
User attribute Modified
* Directory Service Replication and Detailed Directory Services Replication.
These two services have nothing to do with security.
These two subcategories just provide diagnostic information about AD DC replication, ((Recommend disabling them unless you get into a troubleshooting situation)).
5- Audit object access
You can use the Object Access Security log category to audit any and all attempts to access files and other Windows objects like(track Success and Failure access attempts on folders, services, registry keys, and printer objects).
The only auditable objects not covered by this category are AD objects (OU, User, Group and Computer), which you can track by using the Directory Service Access category.
Activating Object Access auditing is a two-step procedure.
First, enable the Audit object access policy on the system that contains the objects that you want to monitor.
Second, select specific objects and define the types of access you want to monitor. Make these selections in the object’s audit settings, which you’ll find in the object's Advanced Security Settings dialog box.
Event ID Title
-------- -------------------------------------------------------------
4656 A handle to an object was requested
4658 The handle to an object was closed
4660 An object was deleted
4663 An attempt was made to access an object
Open a file
Write data to file or add a file
Delete a file
6- Audit policy change
Audit Policy Change events allow tracking changes to important security policies.
Because policies are typically established by administrators to help secure network resources, any changes or attempts to change these policies can be an important aspect of security management for a network.
Audit Policy Change records changes in user rights assignment policy, audit policy, account policy, or trust policy.
Subcategories Comment
1- Audit Policy Change Audit Policies
2- Authentication Policy Change Logon rights assignments Polices
3- Authorization Policy Change Privilege (rights) assignments
4- MPSSVC Rule Level Policy Change Firewall Policy Changes
5- Filtering Platform Policy Change Firewall used Windows Filtering Platform
6- Other Policy Change Events One Windows Filtering Platform event
Event 4950 (MPSSVC Rule Level Policy Change), Windows Firewall setting changed.
7- Audit privilege use
This audit category, privilege refers to most of the user rights that you find in the Local Security Policy under Security Settings\Local Policies\User Rights Assignment
8- Audit process tracking (Detailed Tracking)
Audit process tracking helps track any program that is executed, either by the system or by end users.
By associating this with other policies such as Audit logon and Audit object access policies, we can get a detailed picture of users' activities in the domain.
Subcategories Comment
1- Process Creation New or child process
2- Process Termination Process ending
3- DPAPI Activity Data Protection API
4- RPC Events Remote Procedure Call
You’ll find process IDs in many other security events, giving you the ability to determine the program and person that generated the event.
To determine the logon session during which a process started, look at the Logon ID description field in event ID 4688, then find the preceding event ID 4624 instance that has the same Logon ID.
Check the Logon Type and Logon Process fields to determine whether the process was started during an interactive or Remote Desktop session (or some other type of logon session).
9- Audit system events
Audits when a user restarts or shuts down the computer or when an event that affects either the security log or the system security occurs.
Advanced security audit policy VS Basic security audit policy
1- Basic security audit policy have 9 different policies that we can enable, but Advanced security audit policy have 10 sections in total there are over 60 different advanced audit policies.
2- Basic Audit policy is more simplistic, so there are fewer options available (Success or Failure), but Advanced auditing policies are advanced, so They allow you to define a much higher level of auditing.
Policy Conflicts
Microsoft advises organizations not to use both the basic audit policy settings and the advanced settings simultaneously for same category.
Because when advanced audit policy is configured, it will always override basic audit policies, which in result can cause “unexpected results in audit reporting”.
When using Advanced Audit Policy settings, be sure to enable Force advanced audit policy settings in order to override audit policy settings. To do so, go to Local Polices > Security Options, and enable Force audit policy subcategory settings.
Adjust Security Event Log Size and Retention Settings
You must configure the security event log to ensure that Active Directory events remain in the event log until it written to the Long-Term Archive and the Audit Database, otherwise it will overwrites and some audit data may be lost..
To prevent overwrites, you can increase the maximum size of the Security event log and set retention method for this log to “Overwrite events as needed”.
Group Policy Management console → Default Domain Controllers Policy→ Edit→ Computer Configuration → Policies → Windows Settings → Security Settings → Event Log →
* Maximum security log size policy →set maximum security log size to"4194240" kilobytes (4GB).
* Retention method for security log policy→ Retention method for security log Properties→ Overwrite events as needed.
No comments:
Post a Comment