Contents. Supported Platforms. Event Viewer. User Identification Using the Domain Controller Security Log. SonicOS

(1)

SonicOS

_{User Identification Using the Domain Controller Security Log}

Supported Platforms

This solution has been tested on a Windows 2003 or higher server configured as the Domain Controller. Client or workstations are PCs with Windows OS 9x or later.

Note: This feature is only supported in a Windows environment.

Event Viewer

Using the Event Viewer function, administrators can view and set logging options for event logs in order to gather information about hardware, software, and system problems. By default, a computer running an operating system in the Microsoft Windows Server 2003 family records events in three kinds of logs:

• Application log: The application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. Application developers decide which events to log.

• Security log: The security log records events such as valid and invalid logon attempts, and events related to resource use such as creating, opening, or deleting files or other objects. For example, if logon auditing is enabled, attempts to log on to the system are recorded in the security log.

• System log: The system log contains events logged by Windows system components. For example, the failure of a driver or other system component to load during start-up is recorded in the system log. The event types logged by system components are predetermined by the server.

A computer running a Windows Server 2003 operating system and configured as a domain controller records events in two additional logs:

• Directory Service log: The directory service log contains events logged by the Windows Active Directory service. For example, connection problems between the server and the global catalog are recorded in the directory service log.

• File Replication Service log: The File Replication service log contains events logged by the Windows File Replication service. For example, file replication failures and events that occur while domain controllers are being updated with information about system volume changes are recorded in the file replication log.

(2)

Configuring Group Policy to Enable Logon Audit

By default, the audit logon is disabled on Windows Server 2003. To enable logon audit, follow the specified steps:

1. Start the Group Policy Management Console. 2. Browse to the following location:

Forest - Domain Name > Domains > Domain Name > Group Policy Objects (replacing "Domain

Name" with your domain).

3. Right-click on Group Policy Objects, and then select New.

4. Name the Policy, and click OK.

(3)

6. Browse to the following location:

Policy Name > Computer Configuration > Windows Settings > Security Settings > Local Policies >

Audit Policy.

Left-click on Audit Policy. The policy settings will be displayed in the right-hand window.

7. Double click on Audit account logon events. Select the Success and Failure checkboxes. 8. Click OK.

9. Double click on Audit logon events and select Success and Failure. 10. Click OK.

(4)

Events in Security Log

The Security Log, in Microsoft Windows, is a log that contains records of login/logout activity and/or other security-related events specified by the system's audit policy. If the audit policy is set to record logins, a successful login results in the user name and computer name being logged as well as the user name they are logging into. Depending on the version of Windows and the method of login, the IP address may or may not be recorded. Windows 2000 Web Server, for instance, does not log IP addresses for successful logins, but Windows Server 2003 includes this capability.

The categories of events that can be logged are: • Audit account logon events

• Account management • Directory service access • Logon/Logoff events • Object access • Policy change • Privilege use • Process tracking

Logon/Logoff Events

The logon/logoff category of the Windows security log gives you the ability to monitor all attempts to access the local computer.

Event IDs 528 and 540 signify a successful logon on server 2003 (event id 4624 on server 2008), event ID 538 for server 2003 (event id 4634 for server 2008) signifies a logoff and all the other events in this category identify different reasons for a logon failure. However, just knowing about a successful or failed logon attempt does not fill in the whole picture. Because of all the services Windows offers, there are many different ways you can logon to a computer, such as interactively at the computer’s local keyboard and screen, over the network through a drive mapping or through terminal services (aka remote desktop), or impersonation in application or through IIS.

Following are some of different Logon types for event ID 540: Logon Type 2 – Interactive

This is a logon at the console of a computer. You see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. Logon Type 3 – Network

Windows logs logon type 3 when you access a computer from elsewhere on the network. Logon Type 4 – Batch

When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4.

Logon Type 5 – Service

Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account, resulting in a Logon/Logoff event with logon type 5.

Note that these events are generated regardless of actual log in/log off actions. These are generated for every access to directory services, such as to get group policies, authorization, and ticket generation. They do not actually reflect the user sessions.

(5)

Audit Account Logon Events

Account logon events are generated when a domain user account is authenticated on a domain controller. The event is logged in the domain controller's security log. Logon events are generated when a local user is authenticated on a local computer. The event is logged in the local security log. Account logoff events are not generated.

The following table includes descriptions of the Account Logon Events:

Event ID Description

672 An authentication service (AS) ticket was successfully issued and validated.

673 A ticket granting service (TGS) ticket was granted. 674 A security principal renewed an AS ticket or TGS ticket.

675 Preauthentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password.

676 Authentication ticket request failed. This event is not generated in Windows XP or in the Windows Server 2003 family.

677 A TGS ticket was not granted. This event is not generated in Windows XP or in the Windows Server 2003 family.

678 An account was successfully mapped to a domain account.

681 Logon failure. A domain account logon was attempted. This event is not generated in Windows XP or in the Windows Server 2003 family.

682 A user has reconnected to a disconnected terminal server session.

683 A user disconnected a terminal server session without logging off. *Windows server 2008 has AUDIT ACCOUNT LOGON EVENT with ID 4768.

Directory Service Access

(6)

Events Generated on Domain Controller Security Log Upon Logon

• Machine establishes trust with domain: Kerberos AS request (Event 672 on the DC), Kerberos TGS request for AD (DC, 673)

• Machine gets policy: Kerberos TGS request for access to Netlogon share on DC [group policy] (DC, 673) (DC, 540, 538, maybe more than once)

• User logs on: Kerberos AS request (DC, 672), Kerberos TGS request for AD (DC, 673), Logon session created (workstation, 528, 576)

(7)

Event 672

Operating Systems Windows Server 2000 Windows Server 2003

Category Account Logon

Type Success Failure Corresponding events in Windows 2008 and Vista 4768 , 4772

This event gets logged on domain controllers only. When a user sits down at his or her workstation and enters the domain username and password, the workstation contacts a local DC and requests a TGT. If the

username and password are correct and the user account passes status checks, the DC grants the TGT and logs event ID 672 (authentication ticket granted), as shown in the following figure.

The User field for this event (and all other events in the Audit account logon event category) does not help you determine who the user was; the field always reads SYSTEM. Instead, you need to look at the User Name and Supplied Realm Name fields, which identify the user who logged on and the user account's DNS suffix.

(8)

Event 673

Whereas event ID 672 lets you track initial logons through the granting of TGTs, this lets you monitor the granting of service tickets. Service tickets are obtained whenever a user or computer accesses a server on the network. For example, when a user maps a drive to a file server, the resulting service ticket request generates event ID 673 on the DC.

Note the following:

• User Name and User Domain identify the user.

• Service Name corresponds to the computer name of the server the user accessed.

• Client Address specifies the IP address where the user resides.

Category Account Logon

(9)

Events Generated on Domain Controller Security Log Upon Logoff

It is normal that many logon/logoff events are logged because one logon/logoff procedure can generate several events. The logon/logoff procedures are always performed by service startup/shutdown, shared file accessing, network accessing, users' logon/logoff etc. Event 540 indicates a successful logon; event 538 indicates a successful logoff and event 565 indicates a successful special privilege assigned.

Event 565

Category Directory Service

Type Success

Failure Corresponding events

in Windows 2008

4661

Event 565 allows you to track changes to Active Directory objects down to the property level. While Account Management provides more useful auditing for changes to users, groups and computers, Directory Service Access events are the only way to monitor potentially far reaching effects of changes to organizational units, group policy objects, domains and site related objects.

You will only see event 565 on domain controllers.

Whenever a user performs logoff (interactive logoff) gracefully, events 540, 565 and 538 are generated on the Domain Controller.

(10)

The SAM_USER object type is shown below:

(11)

(12)

Using Events to Find User Logon and User Logoff on Server 2003 & 2008

Logon Logoff

Windows Server 2003 673 565 with corresponding 538 and 540.

Windows Server 2008 4769 4661 with corresponding 4624 and 4634. For RDP connection on server 2003 673 (same as logon) No logoff event generated.

For RDP connection on server 2008 4769(same as logon) No logoff event generated.

NOTE: Work is still in progress on securing user logoff on Windows Server 2003 as in the above mentioned events (565 with corresponding 538 and 540), as well as ensuring directory server access events are logged after successful interactive logon.

Known Issues

Generated logoff events are not reliable – We cannot use events 538-user logoff and 540-user logon as it does not represent actual interactive user logoff and user logon.

It is normal to see many logon/logoff events in the security log of domain controllers when auditing of logon events is enabled and a lot of that activity is for authentication traffic and accessing sysvol for Group Policy. For network connections (such as to a file server), it will appear that users log on and off many times a day. This phenomenon is caused by the way the Server service terminates idle connections.

If a user turns off his/her computer, Windows does not have an opportunity to log the logoff event until the system restarts. Therefore, some logoff events are logged much later than the time at which they actually occur.

Sometimes Windows simply does not log event 538.

Microsoft's comments: This event does not necessarily indicate the time that a user has stopped using a

system. For example, if the computer is shut down or loses network connectivity it may not record a logoff event at all.

When user does not properly logoff – When the domain user does not click logoff or shutdown interactively, no logoff events are generated.

Service access from different machines providing authentication details – When a user accesses service from a different machine by providing different authentications than his logged in account (for network connections, such as to a file server), the events 672 and 673 are generated with username (for

authentication) and client address (machine IP).

(13)

Existing Solution: Using WMI / NETAPI Queries

(14)

Proposed Solution : Using Domain Controller Security Logs

The SonicWALL SSO Agent uses impersonated WMI queries to read filtered event logs from the Domain Controller’s security log. WMI offers the capability to read filtered event logs from remote machines using WMI query language.

For Windows Server 2003:

It uses EVENT ID 673 for user logon identification. To detect user logoff, it keeps track of the events 565, 538, and 540.

For Windows Server 2008:

It uses Event ID 4769 for user logon identification. To detect user logoff, it keeps track of the events 4661, 4624, and 4634.

NOTE:This solution works in a fully trusted domain environment where all users are domain users using domain accounts to access Windows workstations.

To support user identification from non-domain Windows PCs or Domain PCs using local accounts, NETAPI or WMI hybrid solutions will be provided along with Windows Security Log (WSL) method. This will help provide robust solutions with WMI/NEAPI fall-back options as [WSL+NETAPI] or [WSL+WMI].