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.
Docking Stations
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.
