Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Local Security Authority (LSA)

The component that controls user logon and access permission. It is made up of user mode services, the Local Security Authority Subsystem (LSASS), Winlogon, and other kernel mode components. The local security authority can also be thought of as the database of password rules, system policies, and trust accounts for the computer.

Local Security Authority Subsystem (LSASS)

Hosts the Kerberos KDC on a domain controller, the NTLM security support provider, the Security Account Manager (SAM), Netlogon, IPSec, and Protected Storage.

Security Support Providers (SSP)

These are protocols such as Kerberos, NTLM, Digest, Schannel, basic authentication (Clear text password authentication), and Passport support. SSPs manage credentials, determine access, protect data, and secure client-server communications.

Winlogon

Obtains credentials from users interactively.

Netlogon

Obtains credentials over the network.

Security Support Provider Interface (SSPI).

Provides the interface between the SSPs and the application processes (IPSec, CIFS/SMB, LDAP, and so on).

Security Reference Monitor (SRM)

The arbitrator of access on the system. The SRM examines SIDs in the access token and security descriptors placed in an ACL on an object to determine whether requested access should occur.

Security Descriptors

Data structures that contain the discretionary access control list and system access control list for an object.

Discretionary Access Control Lists (DACLs)

Sometimes referred to as access control lists (ACLs), these are linked to objects. The DACL provides information including the security principals that have explicit permission to access the objects and those that are explicitly denied. This information is included in Access Control Entities and is used during authorization.

System Access Control List (SACL)

Contains information that specifies the type of audit records that should be recorded during access attempts. The information is contained in ACEs, which contain the SID of the security principal and the type of audit record that should be produced if the SID is used to access the object.

Access Control Entities (ACEs)

Contains a user or group SID, a permission (such as read or write), and the Allow or Deny designation. Figure3-2 displays the Permission page of the Advanced Security settings property page. The first three columnstype, name, and permissionrepresent the ACE. The ACEs of an SACL are sometimes referred to as audit control entries and are composed of a user or group SID, the type of access (read, write, and so on) that should be recorded, and whether or not the access was successful.

Access Token

Built by the LSASS when a user logs on. It contains the user's SID, the SIDs for any groups of which the user is a member, and security policy settings, including the rights assigned to the user. The access token is built on the local machine when the user logs on. Another access token is built when the user attempts to access a network resource. During authentication, the list of information necessary to build an access token is collected and stored in the authentication material produced. When Kerberos is utilized for network authentication, the SIDs and other authorization information are stored in the authorization field of the TGT and session tickets. NTLM authentication returns this information when the user is authenticated at logon and when a server confirms a user's credentials after the user requests access. Access tokens are built for each unique computer on which the user requests access. Access tokens do not traverse the network. After an access token is created, it is attached to every process that the user runs so that the process has it available when it needs to request access to resources or exercise a right.