Overview of Access Control


Every user and computer has a specific role and purpose in an organization. In order to accomplish their goals, each user and computer must be able to access certain resources and perform specific tasks. However, allowing users and computers unlimited access to system and network resources and functionality can compromise an organization s security and stability. The access control infrastructure of Windows XP Professional functions to balance the resource access and system security needs of an organization.

For example, Alice works in Accounting and needs to be able to view but not create or modify certain Personnel Department files that are off limits to other users in the organization. The Personnel department, which controls these files, uses access control to define which users can have Read-only access to Personnel files, which users can have Write and Modify access, and which users have no access to the Personnel share. Alice is given Read-only access to the Personnel files. Similarly, IT determines that prohibiting users such as Alice from making significant changes to their systems can reduce costs and improve security and supportability. IT makes Alice and other users members of the Users group, thus limiting their ability to install applications and reconfigure their operating system environments. In this way, Alice has the access to resources that she needs, the security of the organization is enforced, and the stability of the network is maintained.

Important Terms

In order to understand the basic principles of access control, it is necessary to understand how the following terms are defined in the context of the access control model for Windows XP Professional.

Security principal

In Windows XP Professional, any entity that can be authenticated. A user, group, computer, or service can be a security principal. Security principals have accounts. Local accounts are managed by the Local Security Accounts Manager (SAM) on the computer. If the account is in a Microsoft Windows 2000 Server domain, it is managed by Active Directory. If the account is in a Microsoft Windows NT version 4.0 domain, it is managed by a SAM database on the primary domain controller.

Security identifier (SID)

A value that uniquely identifies a user, group, service, or computer account within an enterprise. Every account is issued a SID when it is created. Access control mechanisms in Windows XP Professional identify security principals by SID rather than by name.

Security context

Information that describes a particular security principal s identity and capabilities on a computer. In Windows XP Professional, all users in an organization exist in a specific security context that is redefined every time they log on. All activities, such as installing or running applications, take place in this security context. The security subsystem uses the security context to determine what a process and its threads of execution can do to objects on the computer, and who will be held accountable for what they have done.

Access token

A data structure containing the SID for a security principal, SIDs for the groups that the security principal belongs to, and a list of the security principal s rights on the local computer. An access token is created for every security principal that logs on locally at the computer or remotely through a network connection. Each process has a primary access token that it inherits by default from its creating process. The access token provides a security context for the security principal s actions on the computer. It also provides a security context for any application threads that act on the security principal s behalf.

Object

Any resource that can be manipulated by a program or process. Objects include resources that you can see through the user interface, such as files, folders, printers, registry subkeys and entries, Active Directory objects, and the Microsoft Windows desktop. They also include resources that you cannot see, such as sessions, processes, threads, and access tokens. An object can function as a logical container for other objects.

Inheritance

A mechanism for propagating access control information down through a tree of objects. In Microsoft Windows NT , an object (such as a file) inherits access control information from its parent object (such as a folder) only when the object is first created. In Windows XP Professional, objects inherit access control information not only when they are created, but also when the parent object s access control list changes.

Owner

The only security principal who has an inherent right to allow or deny permission to access an object. An object s owner can give another security principal permission to take ownership. By default, the built-in Administrators group on a computer is assigned a user right that allows this group to take ownership of all objects on the computer.

Security groups

Groups that can be used to organize users and domain objects, thus simplifying administration. Security groups allow you to assign the same security permissions to a large numbers of users, such as employees in a single department or in a single location, ensuring that security permissions are consistent across all members of a group.

Security descriptor

A data structure containing the security information associated with a securable object. A security descriptor identifies an object s owner by SID. If permissions are configured for the object, its security descriptor contains a discretionary access control list (DACL) with SIDs for the users and groups that are allowed or denied access. If auditing is configured for the object, its security descriptor also contains a system access control list (SACL) that controls how the security subsystem audits attempts to access the object.

Access control list (ACL)

An ordered list of access control entries (ACEs) that define the permissions that apply to an object and its properties. Each ACE identifies a security principal and specifies a set of access rights allowed, denied, or audited for that security principal.

Security settings

Security configuration settings that can be applied to individual computers. These settings can be configured locally on the computer by using the Local Security Policy administration tool, the Microsoft Management Console (MMC) Security Configuration and Analysis snap-in, or, if the computer is a member of an Active Directory domain, through the Security Settings extension to Group Policy.

Key Concepts

The security systems in Windows XP Professional are based on technologies originally developed for Windows NT. The access control models in Windows NT, Microsoft Windows 2000, and Windows XP Professional share the same key concepts and characteristics, which are described in the following sections.

Discretionary access to securable objects

The user who owns an object has ultimate control over who has permission to use it and in what way. An object s owner can give permission for different kinds of access to particular users or groups of users. For example, the owner of a file object can give Read and Write permission to all members of one group while denying Write access to members of another group. In Windows XP Professional, owners can Allow or Deny other users access to individual properties of certain types of objects as well as to the entire object. The properties that can be delegated include permissions that Allow or Deny other users access to the object.

Inheritance of permissions

You can control permissions for new objects created in a container object by setting inheritable permissions on the container. The permissions that you set on a container are inherited by existing objects in the container, as well as by newly created objects. For example, the permissions that are set on an NTFS file system folder are inherited by new subfolders and files created within the folder.

Auditing of system events

You can use the auditing feature to detect attempts to circumvent protections on resources or to create an audit trail of administrative actions on the system. For example, you can audit failed attempts to open a file. You can also set security policy so that failed logon attempts are recorded in the security event log. If another administrator changes the auditing policy so that failed logon attempts are no longer audited, the log can record this event as well. In Windows 2000, you can use Group Policy to centrally control who is allowed to manage security logs on computers joined to a domain.

Rights and Permissions

Access control involves the configuration of rights and permissions, which apply to both the objects on the local computer or network and the potential users (including individuals, computers, and services) of those objects.

A right, which is also commonly referred to as a privilege, is authorization to perform an operation. From an administrator s point of view, there are two types of rights: privileges and logon rights. In Windows XP Professional, only one user right is inherent the right to allow or deny access to resources that you own. All other user rights must be granted, which means that they can also be withdrawn.

A permission is authorization to perform an operation on a specific object, such as a file. Permissions are granted by owners. If you own an object, you can grant any user or security group permission to do whatever you are authorized to do with it.

When permission to perform an operation is not explicitly granted, it is implicitly denied. For example, if Alice allows the Marketing group, and only the Marketing group, permission to read her file, users who are not members of the Marketing group are implicitly denied access. The operating system will not allow users who are not members of the Marketing group to read the file.

Permissions can also be explicitly denied. For example, Alice might not want Bob to be able to read her file, even though he is a member of the Marketing group. She can exclude Bob by explicitly denying him permission to read the file. In fact, this is exactly how explicit denials are best used to exclude a subset (such as Bob) from a larger group (such as Marketing) that has been given permission to do something.

Each permission that an object s owner grants to a particular user or group is stored as part of an ACE in a DACL that is part of the object s security descriptor.

User-based Authorization

Every application that a user starts runs in the security context of that user.

When a user logs on, an access token is created. The access token contains key security-related information, including the user s SID, the SIDs of the groups to which the user belongs, and other information about the user s security context. This access token is then attached to every process that the user runs during that logon session.

An application runs as a process with threads of execution. When an application performs an operation on a user s behalf, one of the threads performs the operation. For example, when Alice opens a Word document, Microsoft Word, and not Alice, actually opens the file. More precisely, one of the threads of execution performs the operation.

In order for a thread to gain access to an object such as a file, it must identify itself to the operating system s security subsystem. Threads and applications do not have a security identity, so they must borrow one from a security principal, such as Alice. When Alice starts an application, it runs as a process within her logon session. When one of the application s threads needs to open a file, the thread identifies itself as Alice s agent by presenting her access token. Alice is therefore ultimately responsible for anything that the thread does to the file or system on her behalf.

Before allowing the thread of execution to proceed, the operating system performs an access check to determine whether the security principal associated with the thread has the degree of access that the thread has requested. This access check involves the following steps:

  1. The security subsystem checks the file object s DACL, looking for ACEs that apply to the user and group SIDs referenced in the thread s access token.

  2. If a DACL does not exist, access is granted. Otherwise, the security subsystem steps through the DACL until it finds any ACEs that either allow or deny access to the user or one of the user s groups.

  3. If a deny is found at the user or group level, the access is denied.

  4. If the security subsystem comes to the end of the DACL and the thread s desired access is still not explicitly allowed or denied, the security subsystem denies access to the object. Therefore, if a DACL exists, but is empty, access is by definition denied.

At the conclusion of this process, access is either allowed and the file is opened, or access is denied, in which case the file remains closed and an Access Denied message is generated.

Figure 16-1 illustrates this process.

click to expand
Figure 16-1: Validating a request for access

In the case of the Personnel files, Alice s administrators set a DACL on the folders and files that she needs to work with to explicitly define the extent (Read) or limits (not Create or Write) of access that she as an individual or member of a security group has to those files.

Every computer and service on the network also has a security context that governs the resources that it is permitted to access and the actions that it is permitted to take.

Security Descriptors

Access control information is first written to an object s security descriptor when the object is created. Then, when a user tries to perform an action with the object, the operating system examines the object s security descriptor to determine whether the user is allowed to do what the user wants to do.

The information that is included in a security descriptor depends on the type of object in question and how it was created. In general, security descriptors can include the following information:

This information can later be modified. In both cases, the information that goes into a security descriptor is supplied by one of the following:

When a subject creates a new object, it can assign the object a security descriptor. If the subject does not assign a security descriptor, the operating system uses access control information inherited from the parent object to create one. If no information is available to inherit, the operating system uses default access control information provided by the object manager for the particular type of object that the subject wants to create.

After an object is created, the object s owner or any user who has the permission to change permissions can change information in the object s security descriptor. The owner can assign the permission to change permissions to other users. Changes can also come from the parent object when that object s owner modifies its security descriptor. This process is called inheritance. Every time the security descriptor on a container object is changed, the object manager propagates any changes marked as inheritable to all objects in the container, as long as those objects are not protected. For more information about managing inheritance, see Modifying Inheritance of Permissions later in this chapter.

Planning for Effective Access Control

Managing security groups, ACLs, and security settings requires careful planning. Developing an access control plan can help to prevent basic security problems, such as inadequately protected resources, users granted greater rights and permissions than they need to do their jobs, or ad hoc security configurations that are not based on a well-thought-out, manageable security plan. Ad hoc security management might provide adequate protection for small organizations, but will quickly break down as the organization grows.

Although Windows XP Professional incorporates highly advanced security features, effective access control must combine the proper use of Windows XP Professional based technologies with good planning. Security features are only as good as the methods used to employ and manage them.

Tip 

To improve the security of your network, provide each user, computer, and service with the least number of privileges needed to perform their tasks and run their applications. Windows XP Professional includes improved features including well-defined default security groups, Restricted Software settings, and the Secondary Logon Service (SLS) to make this possible. For information about SLS, see Logon and Authentication in this book. For information about Restricted Software settings, see Software Restriction Policies later in this chapter.

Consider developing an access control plan that describes how you will use Windows XP Professional features to establish a secure, usable environment. A typical access control plan might include the following sections:

Your access control plan can contain additional sections, but these are suggested as a starting point. If possible, test and revise all aspects of your access control plans using a test laboratory that closely resembles your organization s computing environment. Also, conduct pilot deployments to further test and refine your access control plans.




Microsoft Windows XP Professional Resource Kit 2003
Microsoft Windows XP Professional Resource Kit 2003
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 338
BUY ON AMAZON

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net