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

Transcription

1 SonicOS User Identification Using the Domain Controller Security Log Contents Supported Platforms... 1 Event Viewer... 1 Configuring Group Policy to Enable Logon Audit... 2 Events in Security Log... 4 Events Generated on Domain Controller Security Log Upon Logon... 6 Events Generated on Domain Controller Security Log Upon Logoff... 9 Known Issues Existing Solution: Using WMI / NETAPI Queries Proposed Solution : Using Domain Controller Security Logs 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. A computer running a Windows Server 2003 operating system configured as a Domain Name System (DNS) server records events in an additional log. The DNS server log contains Windows DNS service events.

2 Configuring Group Policy to Enable Logon Audit By default, the audit logon is disabled on Windows Server 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. 5. Expand the Group Policy Objects folder, and find your new policy. Right-click on the policy and select Edit. 2

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. 11. Close the Group Policy Window. 3

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. About Event ID 528 and 541: These events are generated only on a local machine. They are not present in the Domain Controller s event log for any remote sessions. 4

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 Directory Service Access The event tracks the same activity as Audit account management events, but at a much lower level. By using this event, you can identify exactly which fields of a user account or any other AD object were accessed. Event 565 (Event ID 4661 on server 2008) 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. 5

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) User gets policy: Kerberos TGS request for DC\Netlogon [logon scripts, group policy] (DC, 673), Network logon (DC, 540, 538, usually 2-3 rounds) 6

7 Event 672 Operating Systems Windows Server 2000 Windows Server 2003 Category Type Corresponding events in Windows 2008 and Vista Account Logon Success Failure 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. The next field of interest is Client Address, which identifies the IP address of the workstation from which the user logged on. 7

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. Operating Systems Windows Server 2000 Windows Server 2003 Category Type Corresponding events in Windows 2008 and Vista Account Logon Success Failure 4769,

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 Operating Systems Windows Server 2000 Windows Server 2003 Category Type Corresponding events in Windows 2008 Directory Service Success Failure 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. The event 565 is generated for three object types, SAM_USER, SAM_DOMAIN, and SAM_SERVER. 9

10 The SAM_USER object type is shown below: In object type SAM_DOMAIN we can find privileges assigned for forcelogoff, that we can use as user logoff. 10

11 As event 565 is a Directory Service Access event, and gives the privileges assigned for a user, it does not give the client address from which it was generated. To get the client address, you must keep track of corresponding 540 events. 11

12 Using Events to Find User Logon and User Logoff on Server 2003 & 2008 Logon Logoff Windows Server with corresponding 538 and 540. Windows Server with corresponding 4624 and For RDP connection on server (same as logon) No logoff event generated. For RDP connection on server (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). No logoff events are generated for RDP connection -- Whenever the user connects to any machine using RDP, a LOGON event is generated (audit account logon event 672 and 673). However, even if the user properly performs a LOGOFF, there are no LOGOFF events generated on the domain controller. User logoff on server 2003 In Windows Server 2003, Event 540, 565, and 538 are generated in the Domain Controller when the user properly performs an interactive logoff. The event 565 is generated for three object types, SAM_USER, SAM_DOMAIN, and SAM_SERVER. In object type SAM_DOMAIN, privileges assigned for force logoff exist that can be used as user logoff. Because the directory server access event 565 also generates after interactive user logon, there is still work being done to secure user logoff on Windows Server

13 Existing Solution: Using WMI / NETAPI Queries SonicWALL Directory Connector version or lower provides two options for logged in user identification: NETAPI and WMI. Within both options, the SSO Agent communicates with the workstation directly through NETAPI or WMI to fetch the logged in user information. 13

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 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]. Last updated: 7/15/ Rev A 14