Although Windows 2000 has most of the same user rights as Windows NT 4.0, several new rights can help you control some of Win2K’s new functions and handle logon restrictions. This week, I’ll introduce you to these new rights and show you where they are important to security. Remember that in Win2K, you assign rights using Group Policy, as Screen 1 shows.
Deny Logon Rights
NT includes four logon types (Log on locally, Access this computer from the network, Log on as a batch job, and Log on as a service) and four corresponding rights that grant authority for each of these. Log on locally lets you log on to a computer interactively (i.e., at its local keyboard and screen). Access this computer from the network is just the opposite; it lets you log on to a system remotely from across the network. An example of a network logon is when you access a shared directory of another system on the network using a drive mapping. Log on as a batch job lets batch job schedulers execute tasks under a specified user account. Programs that run as a background service must use Log on as a service.
Win2K includes these four logon rights and adds four corresponding deny rights: Deny access to this computer from the network, Deny logon as a batch job, Deny logon as a service, and Deny local logon. Despite the fact that these actually provide explicit denial of authority, Microsoft chooses to refer to them as rights. If you assign both logon and deny rights to a user, perhaps through different group memberships, the deny right overrides its corresponding logon right.
So how are these new deny rights useful? Just like NT's No Access object permission that you've used for years to implement exceptions to other permissions, these new rights make it easier to state the underlying business rule governing a system policy as a negative. For instance, perhaps you need to grant everyone in your domain, except contractors, the right to access a certain file server. Instead of figuring out exactly who needs access, you can more easily grant Access this computer from the network to the Users group and then assign Deny access to this computer from the network to the Contractors group.
Another new Win2K user right has to do with using laptops with optional docking stations. As long as you have the new Undock a laptop right, a motor in the docking station automatically undocks your laptop when you click Eject PC from the Start menu. Some confusion surrounds the purpose of this right. Supposedly, this right deters theft of laptops. One Microsoft contact said, "Some of these docking stations have physical security options that let you anchor the station to the desk and are motorized." With the right hardware and physical security, this right might let you configure the system so that some users can undock the workstation and take it with them and others can't. However, remember that this feature is only effective if you configure unattended systems with a password-protected screensaver.
Enable Accounts to be Trusted for Delegation
In a multi-tier client/server environment, a server program often needs to access another server on behalf of the client using that client’s credentials. For instance, many Web applications require that a server running Microsoft IIS contact a server running SQL Server to complete the Web user’s request. The server running IIS usually connects to the server running SQL Server as the same account for all transactions, regardless of the requesting user, which works well for Web applications that enforce the business logic. However, for applications where the database enforces the business logic, it would useful if the server running IIS could connect to the downstream server running SQL Server as the user back on the client. Although NT 4.0's Server service has long used this concept, known as impersonation, when accessing files on behalf of a remote user, Win2K's impersonation functionality is much more enhanced.
In Win2K, when a client program connects to a server, the client can delegate the use of its credentials to the server process, letting the server act on the client user’s behalf. Services often run under the domain account of the computer where they reside or sometimes under a service-specific user account. Regardless, user and computer accounts have a special property called "Account is trusted for delegation," as Screen 1 shows. For the server process to take advantage of delegated credentials, you must set this property to true—this is where the Enable accounts to be trusted for delegation right comes into play. To enable the Account is trusted for delegation property on a given account, you must not only have write permissions to that user account, but possess this new right as well. Confused? It helps if you remember to separate the trusted for delegation account property, which the server process requires, from the Enable accounts to be trusted for delegation right that lets you enable that property on accounts.
Microsoft could have controlled access to the Account is trusted for delegation property through the typical Active Directory (AD) permissions that govern other modifications to user accounts. However, according to the Win2K documentation, misuse of the Account is trusted for delegation property "could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources." Therefore, Microsoft lets you further restrict who can enable that property by providing the new Enable accounts to be trusted for delegation right.
One other account property called "Account is sensitive and cannot be delegated" is also worth noting. Whereas Account is trusted for delegation applies to server accounts, the Account is sensitive and cannot be delegated property applies to client accounts. If you set Account is sensitive and cannot be delegated on a user’s account, any service that user connects to can't impersonate the user, even if you've set the service to be Account is trusted for delegation.
Synchronize Directory Service Data
At the time of this writing, Microsoft has discontinued the Synchronize directory service data right, although it still shows up in build 2183. Instead, object permissions handle authority for directory synchronization, which brings me to a final thought. I'm happy to see that Microsoft has added only a minimum of new rights. Wherever possible, Microsoft has wisely used object permissions instead of rights to control access to new features. This effort makes it possible for you to delegate authority to users in a much more granular fashion. Don’t forget that although you control rights assignments centrally through Group Policy, they are still computer specific—each computer stores its list of rights assignments in its local SAM.