Understanding Windows Logon Options
Introduction
There seems to be some confusion as to how Windows logons work. I can understand the issues, as the overall concepts are a bit confusing. Although the logon process, options, and features have been relatively the same for over 20 years, there still seems to be questions around them. So, I am going to take the time to explain the most common logons, how they work, details around them, and where things are stored. Hopefully, after you read this article, you will have a complete understanding on how logons function and a better view of what you are doing at the logon screen.
Ctrl-Alt-Del
When you walk up to a Windows computer you must first hit Ctrl-Alt-Del to logon. This is a security feature which helps protect your computer from certain types of attacks. You must perform this action on Windows NT, 2000, XP, 2003, 2008, Vista, and 7. Note that long ago, when Windows 95/98 was popular, you did not need to perform this action!
The Ctrl-Alt-Del is a security feature which will flush the buffer to that point, clearing out any Trojan horses. A Trojan horse will try to piggy-back on your logon to gain access to your system. The Trojan horse might also try to capture your logon credentials, then store them so the infected computer can send them back to some centralized location.
In any regard, the Ctrl-Alt-Del toggle is a necessary evil that helps protect your computer. From a truly security standpoint, I feel it is important to setup Ctrl-Alt-Del to be forced via Group Policy. You will find Ctrl-Alt-Del under:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Do not require CTRL-ALT-DEL Properties, which is shown in Figure 1.
Figure 1: In order to enforce the Ctrl-Alt-Del Group Policy Setting, you must Disable the policy
Please note that this policy must be set to Disabled in order for the Ctrl-Alt-Del function to be enforced. This is one of the many Group Policy settings that you must negate the negative (double negative) in order to enable the policy setting.
Local Logons
Every Windows computer has a local Security Accounts Manager (SAM). The SAM is responsible for a few functions. First, it is responsible for storing the local users and groups for that computer. By default, the only user account that is activated is the local Administrator account. Of course, this account is designed to be used for disaster recovery and rare administrative tasks. Additional user accounts should be created so the Administrator account is not used often. There are also many groups created by default, with the most notable being the Power Users and Administrators.
Second, the local SAM is responsible for authenticating logons. The key here is to know when the local SAM is performing the authentication and when another database of user accounts is being used. When a computer is not joined to a domain, the only option is to use the local SAM to perform the authentication. You can clearly see this when you logon by viewing the Options that are available on the Log On to Windows drop down box, shown in Figure 2.
Figure 2: Log On to Windows dialog box for logging on to your computer.
If the Options button is not available or it does not display the Log on to drop down box, the computer is not joined to a domain. Figure 2 illustrates a computer that does not show the Log on to drop down box, indicating that the only way this user can authenticate is to the local computer SAM.
If the Options button does display the Log on to drop down box, as shown in Figure 3, the user will have two or more options for authenticating to a database. Notice in Figure 3 the Log on to drop down box is available, indicating that the computer is joined to a domain. The option that is currently configured in the drop down list is the
Figure 3: Computer joined to a domain, but user logging in to local SAM on local computer
If the user were to logon to the local computer, there would be many features and functions that would not work correctly, compared to logging into the domain. For example, Group Policy for domain user accounts would not deploy to this user, network resources would not be available, and the user profile would be different than if the user would log on to the domain.
Domain Logons
A totally different type of logon is when a user selects the domain name instead of the local computer name during the logon. Figure 4 illustrates when a user selects the domain name, instead of the local computer name which was displayed in Figure 3.
Figure 4: Computer joined to the domain and user is selecting the domain for authentication
In this scenario, a domain controller for the BEYONDTRUST domain will authenticate this user. Domain controllers house the Active Directory database, which is similar to the local SAM in that the database stored users and groups, as well as authenticates logons. Of course, Active Directory is also much bigger and can control much more than the local SAM.
By using the domain option instead of the local computer option, the user now has “enterprise” wide access, instead of just local computer access. This means that the user can now access a resource (file/folder/printer/etc) on any server in that is also joined to the domain, where the user has been granted permission. Permissions can not be granted to an enterprise resource to a local SAM user account.
Domain users are also centrally managed, where local SAM users are managed on each and every computer. This makes overall management of user accounts and group accounts much more efficient, as there is only one instance of the account, not “X” number depending on the number of computers on your network.
The domain option also allows the user to logon to any computer in the entire domain, not just the one computer where their user account is stored in the local SAM. This feature allows for easy migrations, flexibility of users using any computer in the company, etc.
It is a best practice for corporate networks to not allow local user accounts in the local SAM of the desktops and servers. Instead, with no local accounts configured the user is forced to logon to the domain, ensuring that all configurations are deployed from domain controllers to the user environment at logon.
Summary
The logon process for Windows might seem a bit confusing, but when you look at the details of the logon screen, the landscape of where the logon is occurring becomes clear. The Ctrl-Atl-Del toggle might be a bit of a pain, but it is a necessary security feature for the log on process. When a computer is not joined to a domain, it is obvious that the only logon possible is to the local SAM. However, when a computer joins the domain, the user can either logon to the local SAM or to the domain via a domain controller. Knowing what options are available and how to limit the logons to the local SAM is key to ensuring a centralized management of user accounts, as well as ensuring security and other settings are enforced from the domain controllers.