Authentication
Authentication |
|
On some operating systems, applications are required to implement their own mechanisms for determining the level of a user's authorization. Applications often do this by maintaining private lists that contain the names of users who are authorized access. Database applications, for example, often maintain private authorization tables to control the fields in a record that a particular user can view or change. This kind of access control mechanism can be integrated with Kerberos authentication simply by ensuring that the authorization data field of a session ticket carries some form of the security principal's name.
Unfortunately, private authorization mechanisms are just that — private. A database application is powerless to prevent an unauthorized user from running another application and using it to edit the data file. On Windows 2000, access to resources is controlled by the operating system itself. Applications can implement their own private authorization mechanisms, but whether they do or not, the Windows 2000 operating system's access control mechanism protects all files and other objects that can be shared by two or more processes.
The header of every securable object includes a security descriptor with an ACL. The ACL is maintained by the object's owner, who decides which security principals can have access to the object and how they can gain access to it. The operating system enforces the owner's decisions by performing an access check whenever an application requests a handle to a protected object. Before the operating system returns the handle, it examines the object's ACL to see whether the security principal that is using the application is authorized access. If the security principal is not authorized access, the application is denied access.
Another important difference from other access control mechanisms is that security principals are not identified by name, either by the operating system or in ACLs. Instead, each security principal is assigned a unique security identifier (SID), an alphanumeric value with a structure similar to a telephone number. Like the country/region code used in international calling, the first part of a SID identifies the domain where the SID was issued. Like the number for a specific telephone within a country or region, the second part of a SID identifies an account within the issuing domain. The value for a domain is unique within an enterprise, and the value for an account is unique within a domain. Unlike telephone numbers, however, SIDs are never reused. There is no possibility that a user might be assigned a SID that once belonged to another user.
A third important difference from name-based access control is that authorization is determined by not only the user's identity but also the user's membership in one or more security groups. In fact, the preferred method of controlling resources is to grant access to groups rather than to individuals, adjusting the level of a group's authorization according to the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on networks that have thousands of users and millions of objects. Group membership can be managed centrally by administrators, who can change a particular user's level of authorization for many resources simply by adding or removing the user from a group.
Windows 2000 makes resource security still easier to manage by allowing groups to be nested. A group created in one domain can be added to the membership of a group created in another domain or to the membership of a universal group used throughout a tree of trusted domains. As a result, when employees change jobs, their level of authorization can be changed throughout the enterprise without touching the ACLs on specific objects.
Like individual security principals, Windows 2000 security groups also have SIDs. A user's level of authorization is determined, then, by a list of SIDs — the SID for the user and the SID for each security group to which the user belongs.
For more information how the operating system determines a user's level of authorization, see "Access Control" in this book.