!!! Overview
[{$pagename}] ([LSA]) is a [Microsoft Windows] protected subsystem that is part of the [Windows Client Authentication Architecture] which [authenticates] and creates logon [Session] to the [Local Computer|Local device].

[Windows Server 2003] (and later) [Windows Server] [Operating System] include a set of security components that make up the [Windows Client Authentication Architecture]. These components ensure that [applications] cannot gain access to [resources] without [authentication] and [authorization]. [1]

In addition, LSA maintains information about all aspects of local security on a computer (these aspects are collectively known as the __local security [policy]__), and it provides various services for translation between names and [Security Identifiers] ([SIDs]).

The security subsystem keeps track of the security policies and the [Digital Identities|Digital Identity] that are in effect on a computer system. In the case of a [Domain Controller], these policies and accounts are the ones that are in effect for the [AD DOMAIN] in which the [Domain Controller] is located. These policies and accounts are stored in [Microsoft Active Directory] as [Group Policy Object].

The local security policy identifies the following:
* Which [AD DOMAINs] are "[trusted|Trust]" to authenticate logon attempts.
* Who can have access to the system and which [Windows Logon Type] is permitted.
* Who is assigned what [Privileges].
* What security [auditing] is performed.
* What the default memory quotas are for paged and non-paged memory pool usage.

[{$pagename}] provides services for validating access to [Resources|Response], checking user rights, and generating [Auditing] messages. A [Local Procedure Call] ([LPC]) occurs between components on the same system and a [Remote Procedure Call] ([RPC]) occurs between components on different systems, as do [LDAP] communications. The [{$pagename}] (Domain Policy) Remote Protocol is dependent on [RPC], which is used for communication between domain members and [Domain Controllers]. This [protocol] and the [Security Account Manager] ([SAM]) Remote Protocol (Client-to-Server) [MS-SAMR] access the same abstract data Server Role Information.
This [protocol] and the Workstation Service Remote Protocol [MS-WKST] access the same Domain Name from the abstract data Account Domain Information.
This [protocol] depends on [Server Message Block] ([SMB]) protocols for sending messages on the wire. It also has the prerequisites specified in [MS-RPCE] as being common to protocols that depend on RPC.

In general, the [{$pagename}] performs the following functions:
* Manages local [security] [policy].
* Provides interactive user authentication services.
* Generates or obtains [MSFT Access Tokens].
* Manages the [Auditing] [policy] and settings.

! How the [{$pagename}] is Used
Some [applications] integrate use of the [Security Support Provider Interface] into their [authentication] designs. When such [applications] need to [authenticate] a user, they ask the [Security Support Provider Interface] to complete the [authentication] by using specific parameters, such as the user’s name and [Secret-key] (if they were not cached from a previous logon), and the service that the user wants to access. The [Security Support Provider Interface] receives the request, examines its contents, and passes the request to the [Security Support Provider] specified in the request. The [Security Support Provider] handles the details of the authentication and sends a success or failure message back to the [Security Support Provider Interface], which relays the message back to the application that initially requested authentication. [Security Support Provider Interface] enables an application to use various security models available on a computer or network without changing the interface to the security system.

For example, if a client has a service ticket for a server for which the preferred authentication protocol is [Kerberos], and the client wants to issue that server a remote procedure call (RPC), the client’s [Kerberos SSP] generates a request message based on standard [GSS-API] ([RFC 1964]) calls, which the application sends to the server. When the server receives the request, the server passes the ticket to the [Kerberos SSP]. The client routes the reply token to its [Security Support Provider], which then evaluates and manages the contents of the reply. The server and the client know nothing about the contents of the token that is used to enable secure communication, because this information is handled by the [Security Support Provider]. The details of[authentication] are handled behind the scenes, and the results of the authentication process are passed back to the applications.

!! [LSA Protection]
[LSA Protection] allows you configure additional protection for the Local Security Authority (LSA) process to prevent code injection that could [Compromised Credentials].

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]

----
[#1] [http://technet.microsoft.com/en-us/library/cc780455%28WS.10%29.aspx]