Overview#Local Security Authority (LSA) is a Microsoft Windows protected subsystem that authenticates and logs users on to the local computer.
Windows Server 2003 (and also Windows Server 2008) Operating Systems 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. 
The Local Security Authority (LSA) is a protected subsystem that authenticates and logs users on to the local computer.
Overview#Local Security Authority (LSA)
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 accounts 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 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 to authenticate logon attempts.
- Who can have access to the system and in what way (for example, interactively, over the network, or as a service).
- Who is assigned what rights.
- What security auditing is performed.
- What the default memory quotas are for paged and non-paged memory pool usage.
The Local Security Authority provides services for validating access to objects, checking user rights, and generating audit messages. A Local Procedure Call (LPC) occurs between components on the same system. A Remote Procedure Call (RPC) occurs between components on different systems, as do LDAP communications. The Local Security Authority (Domain Policy) Remote Protocol is dependent on RPC, which is used for communication between domain members and DCs. 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 Local Security Authority performs the following functions:
- Manages local security policy.
- Provides interactive user authentication services.
- Generates access tokens.
- Manages the audit policy and settings.
How the Local Security Authority 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 ofauthentication are handled behind the scenes, and the results of the authentication process are passed back to the applications.
More Information#There might be more information for this subject on one of the following:
- AD Password Filters
- Cached and Stored Credentials
- Security Account Manager
- Security Identifier
- Security Support Provider Interface