A logon is an event in Windows that shows a user account being granted some access to a workstation/server/computer. This article will explain the basics of Windows logon types, how authentication plays a role, and then describe the various types of logons built into Windows.
As IT pros, we’ve all ‘logged onto computers’, servers, network devices, etc. But, what exactly does logging on mean in Windows? Are there many types of logins supported in Windows? There sure are, probably more than you realize.
As I alluded to earlier, there are a plethora of login types in Windows. However, logging on and being authenticated in Windows are separate functions/events.
A Windows logon occurs on the workstation a user is attempting to access. However, Windows authentication is performed by the computer where the user account is stored. Yes, it’s a subtle difference, especially when you get into local, interactive, and network logons and authentication.
In Windows-based computers, all authentications are processed as one of the logon types below. This is true regardless of which authentication protocol or authenticator is used.
An interactive logon is a logon whereby a user uses a local keyboard and mouse to enter credentials in the logon screen in Windows. They can log on with a local account against a local SAM (Security Accounts Manager) account database using the computer name in the ‘domain’ field.
Users can log on with a domain account by either choosing the Active Directory domain in the domain field or typing in their UPN in the username field. Smart cards and biometric devices can also be used as authentication methods to log in interactively.
When you initiate a Remote Desktop Protocol (RDP) session to another workstation or server, this is a remote interactive login. You are logging in interactively with the remote machine, but you are doing it remotely. It is NOT the computer you are using to start that connection.
This distinction is relatively simple on paper, but there are many nuances in how they are reported, logged in various security event logs, and how they can be exploited or compromised without your knowledge.
A network logon is when a user logs on to a machine over the network. This is commonly for accessing shared network resources. For example, accessing a shared folder, connecting to a machine via WinRM (Windows Remote Management protocol), or a printer.
By default, domain controllers will generate a logon event when a domain computer is logged onto. However, there are more robust events that can be logged: Audit account logon events and Audit Logon events. You can accomplish this on your domain via Group Policy or on a specific member server or workstation via their respective local security policy.
Here are some basic instructions to enable logging with Group Policy in an Active Directory domain environment:
I’m now going to detail the most common Windows logon types. For each of them, I’ll include the types of authenticators that are able to initiate a logon of this type, as well as practical examples.
This type of logon is generated when a user logs on to the console of a machine. Again, a user can also use a smart card or biometric methods besides the traditional keyboard and mouse.
You can use the keyboard and mouse, smart cards, and biometric devices. There are new device types introduced in recent years including FIDO2-compatible security devices (Yubikey, etc.).
A local logon gives a user permission to access resources on the local computer. A local logon requires a user account in the local SAM on the computer.
This logon type describes a computer being accessed across the network (LAN/WAN). This is typically used to access file servers, printers, and other network devices.
You can use a keyboard and mouse (password), a Kerberos ticket, and NT hashes are all accepted authenticators for this type of logon.
A network logon gives the user permission (via token) to access said resources. Local authentication does need to be completed first.
This logon type typically relates to scheduled tasks. Logon type 4 events are usually rather benign, however, a malicious user could try to guess the password of an account here.
A password is the only accepted authenticator as it is local.
When Windows executes a scheduled task, the service creates a new logon session for the task so that it has the necessary permissions to complete it.
If you go back in time a good number of years, you may remember the ‘at’ command. Yes, for nostalgia purposes, read this documentation link from Microsoft during the Windows 2000 days!
The next type is called the service logon. When Windows starts a service that is configured to log on as a user, Windows creates a new logon session. Each service is configured to run as a specified user account.
Like batch logons, the service logon type only accepts a password that’s usually stored as an LSA secret.
When setting up a local Apache Tomcat server to host a website, you could configure the Tomcat service to log on as the Administrator (not a good idea), or preferably a domain service account with a very strong password.
When a user leaves a workstation for a period of time, Windows will lock the computer. This is to protect the workstation, its data, and other potential remote network data from attackers or local hackers. When a user unlocks the computer, this logon type is logged in the local Security event log.
Again, only a password is accepted for this logon type.
As stated above, after returning to a computer that has been locked by policy, unlocking the computer, by re-entering the password, describes this event.
This type is similar to a network logon (Type 3), but here the password was sent over the network in cleartext. The password was passed to the authentication system on the remote system in its unhashed form. Windows always hashes passwords typed in before transmitting them over the LAN.
You guessed it…passwords.
The only traditional example of this was IIS (Internet Information Services) anonymous logins, but even those have become scarce due to the ever-increasing security landscape we live in today.
Another example is within an ASP (Application Service Provider) script using the ADVAPI logon process.
This logon type describes using RunAs to start a program under a different account than the logged-in account. You use the /netonly switch in Windows to accomplish this.
Only passwords are accepted as authenticators for this logon type.
When you want to open Computer Management as a different domain administrator, you can hold Shift down while you right-click the tool in Administrative Tools, then click Run As another user. Here, you are accessing this logon type to open the program under a different account than the one you used to log in to the workstation.
This logon type sometimes referred to as “RemoteInteractive,” details using Remote Desktop Protocol (or terminal services) to access a remote workstation or server. This type is similar to #2 (Interactive), but again, we are coming from a remote location.
Because we are using RDP, we have similar authenticators possible. We can use smart cards and biometric devices, as long as they are passed through with appropriate settings in the RDP client software.
The only main example again is using RDP to connect to a remote computer over the network.
Our final type describes when a user logs on to the machine via cached credentials. This is very similar, again, to #2 (Interactive), but instead of a ‘live’ authentication to a domain controller, Windows locally uses previously entered (cached) credentials to grant the user access permissions to the workstation.
In this instance, only passwords are possible. There are no ways to use a cached smart card token, for obvious reasons.
The most common example here is when your computer or workstation does not have a network (LAN/WAN) connection. Because Windows can’t do a real-time authentication request to a domain controller, as long as ‘x’ number of days haven’t passed since your workstation did talk to a domain controller, local cached credentials are used to grant local authentication.
Again, group policy can specify the number of days your computer can stay in a ‘grace period’. Typically, this is 30 or 90 days. But, with a security mind, the lower the better.
Having a good knowledge of the various logon types in Windows helps IT pros in understanding and troubleshooting issues with various logon events in Event Viewer. And from a security standpoint, you will very likely be analyzing your domain controller Security event logs when trying to track down malicious activity in your Windows domain.
Thank you for reading. Please leave a comment below!