There are five different ways you can log on in Windows called “logon types.” The Windows Security Log lists the logon type in event ID 4624 whenever you log on. Logon type 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:

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.

In addition to knowing the session type in logon events, you can also control users’ ability to logon in each of these five ways. A user account’s ability to logon is governed by five 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 lists each logon type and its 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. 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: BUILTINUsers

Access Granted:

Access Right: SeNetworkLogonRight

One consideration is that 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, a topic I’ll cover in the future.