Q: How can I restrict Windows users’ capability to log on interactively to Windows from the Windows console in an Active Directory (AD) environment?
A: A Windows user can start an interactive logon process by pressing the Ctrl+Alt+Del key sequence, by requesting a secondary logon session using, for example, the runas command line utility, or by starting a connection to another machine using Terminal Services or Remote Desktop. In a Windows AD environment, you can centrally control interactive logon by using logon rights or using a set of AD user account object properties.
The “Log on locally” logon right controls who can log on interactively to a Windows machine using Ctrl+Alt+Del or by starting a secondary logon session. In Windows 2000, this logon right was also required to log on using Terminal Services or Remote Desktop. In Windows Server 2003 and Win2K Service Pack 2 (SP2) and later, Terminal Services- and Remote Desktop-based interactive logons are controlled using the “Allow logon through Terminal Services” logon right. In Win2K, Microsoft also introduced the “Deny log on locally” and “Deny Logon through Terminal Services” user rights.
- “Deny log on locally” denies a user the ability to log on at the computer’s console using Ctrl+Alt+Del or the Welcome screen or by starting a secondary logon session. It has precedence over the “Log on locally” right.
- “Deny Logon through Terminal Services” denies a user the ability to log on using Terminal Services or Remote Desktop. It has precedence over the “Log on through Terminal Services” right.
The Deny logon rights can be very handy in large Windows setups. For example, assume you want to give everyone with the exception of a couple of specific accounts the right to “Log on locally”. In that case, it's much easier to grant the Authenticated Users group the “Log on locally” right and the specific accounts the “Deny log on locally” right, instead of figuring out all the accounts that should have access, putting them in a special group, and giving this group “Log on locally” right.
In AD environments, you can assign and manage Windows logon rights from the Microsoft Management Console (MMC) Group Policy Object (GPO) snap-in. To access the GPO MMC snap-in, start the MMC, then load the GPO snap-in.
- For managing the logon rights on domain-joined machines, select the Default Domain GPO.
- For managing the logon rights on domain controllers (DCs), select the Default Domain Controllers GPO. In the GPO MMC snap-in, you can assign logon rights from the Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments container.
Another very efficient mechanism to restrict a user’s interactive logon rights is to restrict the machines to which a user can log on interactively. AD administrators can restrict to which domain machines a domain user can log on interactively by using the AD “Log On To…” user account property. You can assess this property from the Account tab of the user’s account properties (as Figure 1 shows) in the MMC AD Users and Computers snap-in. To restrict the machines a user can log on to interactively, select “The following computers” radio button. You can then add machines by typing their NetBIOS name in the Computer Name field and clicking Add. AD stores this data as a comma-separated list in the userworkstations user account AD attribute. The “Log On To…” domain user account property doesn't affect a user’s capability to log on locally to a machine using a local account.
The Account tab in the AD Users and Computers user account properties contains another feature that you can use to restrict a user’s logon behavior: the Logon Hours… button allows an AD administrator to restrict the hours a user can log on to the domain. These time restrictions apply to all logon types (not only interactive logon, but also network logon) and don't impact a user’s capability to log on locally to a machine using a local account.
The “Log On To…” and “Logon Hours…” domain user account restrictions also apply when a user starts a secondary logon session or when a user logs on using a Terminal Services or Remote Desktop connection.
