Click to return to the Microsoft FrontPage home page    
Web Workshop  |  Languages & Development Tools  |  Microsoft FrontPage

The Microsoft® Windows NT® Security Model


Microsoft Corporation

Updated April 15, 1999

On Microsoft® Windows NT®, an administrator or a program can grant users and groups varying levels of access to system resources. Users with user accounts on Windows NT must present their credentials (user name and password) for identification before being granted access to a Windows NT resource. Group accounts are also available on Windows NT. They do not have passwords, but are a convenient way to grant privileges to several user accounts at once.

Windows NT runs special applications called services. Services are programs that start along with the operating system and run in the background, without any user interface. (IIS Web server is a service.) Services, along with all applications that run on Windows NT, must run in the context of a user account, represented by a token.

Tokens and security identifiers

A token identifies a user and the Windows NT groups to which the user belongs. It also contains the user's security identifier (SID) and the SIDs of all groups to which the user belongs. An SID uniquely identifies each user and group in Windows NT. Programs on Windows NT run in the context of a token. When a program starts another program, it passes its token to the new program.

Access control lists

An access control list (ACL) is a list of entries associated with a file or folder that specifies which users and groups have access to that folder or file. Each entry in an ACL assigns a user or group one or more of the following levels of access to files:

A similar set of privileges are set on folders:

Note   Windows NT and Windows 2000 supports two types of file partitions: NTFS and FAT file partitions. ACLs are only supported by NTFS. Because Microsoft® FrontPage® Server Extensions security is based on ACLs, you should use NTFS on a system on which you are hosting World Wide Web services using IIS and FrontPage.

User impersonation

When an application runs, it "impersonates" the user who has been authenticated to use that application. Then, when the application attempts to invoke another application or use a system resource such as the file system, access to the new application or system resource is granted or denied based on the permissions of the impersonated user. By forcing applications to run as a user, Windows NT ensures that applications only have access to system resources that are accessible to the user who is running those applications. Also, impersonation reduces the number of times a user is required to enter a password, because a variety of applications and system services can be invoked once the user has been authenticated.

Impersonation also works remotely. If a user has the proper privileges on a remote machine, an application on the remote machine will impersonate the user who is remotely invoking it. For example, when a user with authoring privileges on a remote Windows NT server attempts to author content on that server, the FrontPage authoring DLL will run as the impersonated user, guaranteeing that the user will only have access to files that are available to that user's account.



Back to topBack to top

Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!

© 1999 Microsoft Corporation. All rights reserved. Terms of use.