Bagikan melalui

What Are Security Principals?

  • Artikel

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Are Security Principals?

In this section

  • Accounts and Security Groups

  • Technologies Related to Security Principals

  • Related Information

Security principals include the following:

  • Any entity that can be authenticated by the system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.

  • Security groups of these accounts.

Every security principal is automatically assigned a security identifier (SID) when it is created.

In Windows Server 2003, security principals are a foundation for controlling access to securable resources.

Accounts and Security Groups

Accounts and security groups that are created in an Active Directory domain are directory objects, and they can be used to manage access to domain resources.

Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are stored in and managed by the Security Accounts Manager (SAM) on the local computer.

User Accounts

A user account uniquely identifies a person using a computer system, thereby allowing the system to enforce the appropriate authorization to allow or deny access to resources. User accounts can be created in Active Directory and also on local computers. User accounts are used to:

  • Represent, identify, and authenticate the identity of a user. A user account enables a user to log on to computers and domains with a unique identity that can be authenticated by the computer or domain.

  • Authorize (grant or deny) access to resources. After a user has been authenticated, the user is authorized (granted or denied) access to resources based on the permissions that are assigned to that user on the resource.

In addition, the actions that are carried out by a user account can be audited.

Security Groups

A security group is a collection of user accounts, computer accounts, and other groups that can be managed as a single unit from a security perspective. Groups can be either Active Directory based or local to a particular computer. In Windows Server 2003, there are several built-in security groups that are preconfigured with the appropriate rights and permissions to perform specific tasks. Additionally, you can (and, typically, will) also create a security group for each unique combination of security requirements that applies to multiple users in your organization.

You use groups in Active Directory to manage rights and permissions to domain resources.

Local groups exist in the SAM database on local computers (on all Windows-based computers) except domain controllers. You use local groups to manage rights and permissions only to resources on the local computer.

Using security groups to manage access control solves the following problems. Using security groups:

  • Simplifies administration. You can assign a common set of rights, a common set of permissions, or both to many accounts at one time, rather than assigning them to each account individually. Also, when users transfer jobs or leave the organization, permissions are not tied to their user accounts, making permission reassignment or removal easier.

  • Allows you to implement a role-based access-control model for granting permissions by using groups with different scopes (local, global, domain local, and universal) for the appropriate purposes.

  • Minimizes the size of access control lists (ACLs) and speeds security checking. A security group has its own SID; therefore, the group SID can be used to specify permissions for a resource. In an environment with more than a few thousand users, if the SIDs of individual user accounts are used to specify access to a resource, the ACL of that resource can become unmanageably large, and the time needed for the system to check permissions to the resource can become unacceptable.

Security principals are closely related to the following components and technologies in Windows Server 2003.

Authorization and Access Control Components

  • SIDs. Each security principal is automatically assigned a SID when it is created.

  • Access Tokens. After a user logs on and is authenticated, the system creates an access token for the user that contains the SID of the user, the SIDs of all the domain and local security groups that the user is a member of, and some well-known SIDs. Every process the user creates inherits the user’s access token, which is then used to determine whether to grant that user access to a system resource in a given logon session.

  • Security Descriptors and ACLs. A security descriptor is a data structure that is associated with each securable object. The security descriptor contains a discretionary access control list (DACL), with SIDs for the user’s and groups that are allowed or denied access to that object.

  • Permissions. Permissions to access securable objects such as Active Directory objects, files, and registry settings are granted to security principals.

Authentication

A user account enables a user to log on to computers and domains with an identity that can be authenticated by the computer or domain.

Active Directory

Accounts and security groups that are created in an Active Directory domain are stored in the Active Directory database and managed using Active Directory tools.

The following diagram shows the Windows Server 2003 authorization and access control process. In this diagram, the subject (a thread in a process that is initiated by a user) attempts to access an object, such as a shared folder. The information in the user’s access token is compared to the access control entries (ACEs) in the object’s security descriptor, and the access decision is made. The SIDs of security principals are used in the users access token and in the ACEs in the object’s security descriptor.

Authorization and Access Control Process

Authorization and Access Control Model

The following resources contain additional information that is relevant to this section: