| Downloads |
|---|
| 46870.zip |
The Windows access-control subsystem, the system that determines which users can access which resources and how they can access these resources, is rooted on the concepts of permissions and user rights. Permissions are related to objects--for example, permissions to print a file, create folders, and add a user object to Active Directory (AD). User rights are related to a Windows system as a whole--for example, the user right to log on to a Windows system or to change the system clock.
Windows user rights comprise two categories: user privileges and logon rights. User privileges, such as Change the System Time and Shut down the System, let you control access to system resources and system-related operations. Logon rights control which user accounts can log on to a Windows computer and how a user account can log on to a system. (For more information about user accounts and Windows logon procedures, see "A Matter of Trust," July 2005, InstantDoc ID 46591.) Here, I discuss how to use Windows logon rights as an access-control tool, and I offer an explanation of the different logon rights and tips for using them.
Logon Rights: The Big Picture In Windows Server 2003 and Windows XP, Microsoft defined 10 different logon rights, which you can use to control different types of local- and domain-level user-authentication attempts to Windows systems. Logon rights also cover user-authentication actions such as logging on to a Windows-rooted FTP service. To enable a user account to log on to a Windows-rooted FTP service, for example, you must give the account the Log on locally right on the Windows machine hosting the FTP service. Microsoft introduced the "deny" logon rights in Windows 2000. Windows 2003, XP, and Win2K Service Pack 2 (SP2) and later support the logon rights related to Terminal Services.
Web Table 1(http://www.windowsitpro.com/windowssecurity, InstantDoc 46870) lists Windows logon rights along with each logon right's corresponding API name and shows which built-in groups receive the logon rights assigned by default on a domain controller (DC), a member server, and a standalone machine. The API names are the internal names that Windows uses to refer to logon rights. You might need to specify them when using the command-line tools that I'll discuss later or when viewing Security log events. Let's look at each logon right in a little more detail:
The Deny logon rights can be handy in large Windows setups. For example, say you want to give everyone except for two specific accounts the Access this computer from the network right. In this case, it's much easier to grant the Authenticated Users group the Access this computer from the network right and the specific accounts the Deny access to this computer from the network right, instead of determining all the accounts that should have access, putting them in a special group, then giving this group the Access this computer from the network right.
Managing Windows Logon Rights
To assign and manage Windows logon rights, you can use either the Local Security Policy tool (for standalone machines only) or the Microsoft Management Console (MMC) Group Policy Object snap-in (for standalone or domain-joined machines). The Windows 2003 and Win2K resource kits also contain two command-line tools that can help with managing logon rights: NTRights (ntrights.exe) and ShowPriv (showpriv.exe).
You can access the Local Security Policy tool from the Control Panel Administrative Tools applet (Start, Settings, Control Panel, Administrative Tools, Local Security Policy). In the Local Security Settings window, you assign logon rights by expanding the Security Settings, Local Policies, User Rights Assignment containers, as Figure 1, page 12, shows.
To access the Group Policy Object snap-in, start the MMC, then load the snap-in. For managing logon rights on standalone machines, select the Local Computer Group Policy Object (GPO); for managing logon rights on domain-joined machines, select the Default Domain GPO; for managing logon rights on DCs, select the Default Domain Controllers GPO. In the Group Policy Object snap-in, you can assign logon rights by expanding the Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment containers, as Figure 2, page 12, shows.
You can use the NTRights utility to grant or revoke Windows user rights (both logon rights and privileges) to users and groups on a local or remote computer. For example, to grant ServiceAccount1 on computer MyComputer the Logon as a service right, you'd run the following command:
Ntrights +r SeServiceLogonRight -u ServiceAccount1 -m \\MyComputer
(Commands wrap to several lines here because of space constraints. You should actually type the command on one line.) To revoke the Authenticated Users group's right to Access this computer from the network, run the command
Ntrights -r SeNetworkLogonRight -u Everyone
You can use the ShowPriv utility to display which users and groups have been assigned a particular user right on the local system only. For example, to find which users and groups have been assigned the Log on locally logon right on your system, run the command
Showpriv SeInteractiveLogonRight
Best Practices
To facilitate Windows access-control administration, Windows supports the concept of groups. Instead of assigning permissions and rights to many individual users, you'll find it much easier to organize these users into groups, then assign the permissions and rights to the groups. Doing so also makes administering logon rights easier.
Another best practice is to assign user rights to domain accounts and not to local accounts. A user could use a local account to bypass the central security policy enforced on the Windows domain level. As I mention in "A Matter of Trust," you should always try to use a Windows domain setup, regardless of the size of your IT environment.
It's also a good idea to assign service accounts the Deny logon locally, Deny access to this computer from the network, and Deny logon through Terminal Services rights whenever possible. Always remember to honor the principle of least privilege. In the context of logon rights, this means you should give a service account only the logon rights it needs to do the job.
You might find that the default logon rights assignments that Web Table 1 lists aren't restrictive enough. To lock down the logon rights assignments, I suggest you take the following measures:
Logon Rights in Event Logs
The Windows event log lists logon audit events that reference the logon rights I've discussed. Viewing logon audit events can be useful when you're troubleshooting Windows authentication problems. To tell Windows to generate logon audit events, you need to enable Audit account logon events (both for success and failure) in the auditing policy of your standalone machine or domain.
The logon event field that you'll be most interested in is the Logon Type field. Figure 3 shows an example of a logon event with event ID 540, which indicates a successful logon. In the Description field, you can see the Logon Type field, which contains the value 3, indicating that the successful logon was a network logon. The Logon Type field can contain the value 2 (interactive logon), 3 (network logon), 4 (batch logon), or 5 (service logon). The most frequently occurring Logon Type values are 2 and 3. When you see a Logon Type 2 in the Event Viewer logs, you know that someone logged on interactively to your machine. When you see a Logon Type 3, you know that someone tried to access a resource on your computer from the network. When you see a Logon Type 4, you know that the Task Scheduler service ran a script or program in batch. When you see a Logon Type 5, you know that a Windows service has started by using a specific user account.
Powerful Access Control
As you've seen, Windows logon rights are an important Windows security feature. Along with user privileges, they provide a powerful method for controlling user access to Windows systems. By using the techniques I've described here to set up logon rights and using the event log to identify authentication problems, you'll be well on your way to securing access to your Windows systems.
