Security, et al

Randy's Blog on Infosec and Other Stuff

«  Auditing File Shares with... | Using Dynamic Audit Polic... »

Pay Attention to System Security Access Events

Tue, 19 Nov 2013 13:15:50 GMT

There are 5 different ways you can logon in Windows.  We call them logon types.  The Windows Security Log lists the logon type in event ID 4624 whenever you logon.  Logon type is what allows you to determine if the user logged on at the actual console, via remote desktop, via a network share or if the logon is connected to a service or scheduled task starting up.  The logon types are:

Type

Description

Allow right

Deny right

2

Interactive (logon at keyboard and screen of system)

SeInteractiveLogonRight

Allow logon locally

SeDenyInteractiveLogonRight

Deny logon locally

3

Network (i.e. connection to shared folder on this computer from elsewhere on network)

SeNetworkLogonRight

Access this computer from the network

SeDenyNetworkLogonRight

Deny access to this computer from the network

4

Batch (i.e. scheduled task)

SeBatchLogonRight

Log on as a batch job

SeDenyBatchLogonRight

Deny logon as a batch job

5

Service (Service startup)

SeServiceLogonRight

Log on as a service

SeDenyServiceLogonRight

Deny logon as a service

10

RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)

SeRemoteInteractiveLogonRight

Allow logon through Terminal Services

SeDenyRemoteInteractiveLogonRight

Deny logon through Terminal Services

 There are a few other logon types recorded by event ID 4624 for special cases like unlocking a locked session but these aren’t real logon session types. 

Knowing the session type in logon events is great but you can also control users’ ability to logon in each of these 5 ways.  A user account’s ability to logon is governed by 5 user rights found in group policy under Computer Configuration/Windows Settings/Security Setting/User Right Assignments.  There is an allow and deny right for each logon type. In order to logon in a given way you must have the corresponding allow right.  But the deny right for that same logon type takes precedence.  For instance, in order to logon at the local keyboard and screen of a computer you must have the "Allow logon locally" right.  But if the "Deny logon locally" right is also assigned to you or any group you belong to, you won’t be able to logon.  The table below lists each logon type and it’s corresponding allow and deny rights.

Logon rights are very powerful.  They are your first level of control – determining whether a user can access a given system at all.  After logging in of course their abilities are limited by object level permissions.  Since logon rights are so powerful it’s important to know if they are suddenly granted or revoked and you can do this with Windows Security Log events 4717 and 4718 which are logged whenever a given right is granted or revoked respectively.  To get these events you need to enable the Audit Authentication Policy Change audit subcategory.

Events 4717 and 4718 identify the logon right involved in the "Access Granted"/"Access Removed" field using a system name for the right as shown in corresponding column in the table above.  The events also specify the user or group who was granted or revoked from having the right in the "Account Modified" field.

Here’s an example of event ID 4717 where we granted the "Access this computer from the network" to the local Users group. 

System security access was granted to an account.
Subject:
   Security ID:  SYSTEM
    Account Name:  WIN-R9H529RIO4Y$
    Account Domain:  WORKGROUP
    Logon ID:  0x3e7

Account Modified:
   Account Name:  BUILTIN\Users

Access Granted:
   Access Right:  SeNetworkLogonRight

There’s just one problem.  The events do not tell you who (which administrator) granted or revoked the right.  The reason is that user rights are controlled via group policy objects.  Administrators do not directly assign or revoke user rights on individual systems; even if you modify the Local Security Settings of a computer you are really just editing the local group policy object.  When Windows detects a change in group policy it applies the changes to the local configuration and that’s when 4717 and 4718 are logged.  At that point the user making the change directly is just the local operating system itself and that’s why you see SYSTEM listed as the Subject in the event above.

So how can you figure out who a granted or removed the right?  You need to be tracking group policy object changes is a topic I’ll cover in the future.

email this digg reddit dzone
comments (0)references (0)

Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015

Comments disabled

powered by Bloget™

Search


Categories
Recent Blogs
Archive


 

Upcoming Webinars
    Additional Resources