Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

Windows: LSA Lookup Cache

Leave a comment

In a Windows world, security is often linked to security principals (user, group, computer or domain name) and SID (Security Identifier). There are multiple programmatic ways translate names to SID and vice-versa. In a nutshell:

  • LSA Lookup Functions: LsaLookupSids, LookupAccountSid, LsaLookupNames, LsaLookupNames2 and LookupAccountName. They exclusively map names to SID or SID to Name and expose extra contextual information’s (domain, SID type, etc…). In many case, using this functions does not require the caller to be authenticated. This greatly eases its usage under most of circumstances.
  • DSCrackName Function/IADsNameTranslate : to be considered as the Swiss Army Knife of name translation, it allows to translate almost any type of name (SAM Account Name, User Principal Name, Canonical Name or even Distinguished Names…) to and from SID/SID history or GUID (Active Directory only). The only downside is that it strictly requires the caller to be authenticated and authorized to do so. It’s the API behind the well-known NameTranslate COM interface accessible from scripting languages such as VBScript or PowerShell
  • “Other” means such as LDAP Lookups

In this post, I am covering the cache implemented by LSA Lookup functions since other methods do not expose any built-in caching mechanism

How LSA Lookups Work

An application wishes to translate a user name to a SID using LSA Lookup Function. It will pass the request  to the LSA process located on the computer the application runs on. Depending upon the domain information contained in the name, it will resolve the name locally (COMPUTERNAMEUSERNAME) or against a domain controller of the domain the computer belongs to (as depicted in the schema below).

LSA Lookup Schema

Hereunder a PowerShell snippet borrowed to MS TechNet’s article Windows PowerShell Tip of the Week – Working with SID’s demonstrating translation. This example will trigger the LsaLookupNames4 function on a Windows Seven computer:
$objUser = New-Object System.Security.Principal.NTAccount("kenmyer")
$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value

How to know if an application makes use of those function

It’s pretty straightforward assuming the application wants to resolve names belonging to domains other than the local machine, start a network capture tool like  Wireshark or Netmon then let the application perform its tasks. Stop the capture and filter the results. In the case of Wireshark, apply a display filter equal to LSARPC. The result would like:

LSA Lookup Capture 
How Cache works

  • The cache is implemented on the computer where the function is used, not on the remote computer accessed to resolve names or SID’s
  • There is no negative caching implemented. If you retry multiple times querying for an unknown SID or user, it will trigger the whole process every time
  • When translating SID to name and the SID provided SID is returned as part of the of a SID History attribute then the cache is not incremented. Microsoft states it is by design in order to prevent cache pollution
  • Cache size (number of entries), expiration time (TTL) and refresh time are all configurable parameters

How and Where Cache is Configured

The configuration lies in the registry under the path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa and support the following control parameters:

  • LsaLookupCacheMaxSize (DWORD): The maximum number of entries in the cache. Default value is 128. Setting to zero will disable the cache
  • LsaLookupCacheExpireTime (DWORD). The time to live of an entry in the cache in minutes. The default is 10080
  • LsaLookupCacheRefreshTime (DWORD): The extension of the TTL in minutes in case the entry is fetched from the cache. The default is 10

Note: on a standard Windows installation, none of the entries above exist by default

From Windows Server 2008/Windows Vista, extensive logging can be enabled, refer to this MS TechNet Article for details: http://technet.microsoft.com/fr-fr/library/ff428139(WS.10).aspx#BKMK_LsaLookupSIDs.

Why It May Matter to You

Under specific workloads, increasing the cache’s size may be suitable if many names/SID’s must be resolves regularly:

  • SharePoint’s people picker
  • File server with lots of users and groups whose permissions are regularly checked or modified
  • Exchange server’s administration console

Note: the footprint of LSA Cache on system resource is really negligible compared to other system caches or optimizations. Therefore the risk associated with playing around with is is minimal. The only downside is you have to restart the computer every time you want to apply a modification.

On the other hand and under very specific circumstances, you may want to simply disable the cache in order to have the freshest information at hand:

  • On computers performing bulk account migration or modification (with the exception of names resolves using SID history attribute, see upper)
  • On computers running identity life-cycle management processes responsible for maintaining Windows principals

Additional Information

Finally, I would not do justice to Richard L. Mueller’s work if I did not mention hi outstanding work documenting the NameTranslate API: http://www.rlmueller.net/NameTranslateFAQ.htm. Definitely a must read!

Marc

Advertisements

Author: Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s