Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

PowerShell: Testing if the Logged On User is Really Admin


Since the introduction of User Account Control (UAC) with Windows Vista/Server 2008, scripter have to deal with detecting if the user executing commands or scripts is effectively granted the necessary privileges, ie. is running with elevated privileges.

While you can find plenty of snippets and functions on the Internet to achieve this goal. The reasons why I use this one hereunder are the following:

  • It is compatible with all (decently recent) Windows versions
  • It works with all languages since no names are used
  • It is fairly fast: the speed directly depends on the user’s token size

Function IsCurrentUserElevated()
[bool]$IsElevated = $False
If ([System.Environment]::OSVersion.Version.Major -lt 6)
{$IsElevated = [bool]((whoami /groups /SID) -match “S-1-5-32-544”)}
{$IsElevated = [bool]((whoami /groups) -match “S-1-5-32-544”) -and [bool]((whoami /groups) -match “S-1-16-12288”)}
Return $IsElevated

Note:  If someone has a native PowerShell replacement for fetching a user token please let me know ;).

Additional information’s:

Windows: The Confusion over DisableLoopBackCheck, DisableStrictNameChecking and Kerberos

Windows Logo


I’ve been answering technical questions in Forums and at customers for a while now and in the recent years there were many related to issue related to DisableLoopBackCheck and DisableStrictNameChecking security features from Windows. I also regularly noticed a lot of confusion and misinformation about these. This post is a modest attempt to explain them more in-depth.


LoopBackCheck is, like its name says, a security feature applicable to connection established to the loopback address ( It applies to NTLM authentication only. It allows protecting a Windows computer against threat exploiting connections to the loop back adapter specifically. This extra protection level applies to all incoming connections and protocols

What is often misleading with LoopBackCheck is the error message making believe invalid credentials have been provided while it is actually not the case. Example with IIS: HTTP 401.1 – Unauthorized: Logon Failed.

Why isn’t it applicable to Kerberos authentication? Simply because Kerberos authentication is so strongly linked to names (host and service names) that is does actually need this security feature.

When will you experience this issue? Usually, in a test/dev environment when you redirect services such as IIS web sites or SharePoint to the loopback address. It might also affect production SharePoint when the crawler process is configured to crawl from the locally-deployed WFE role thanks to a modification of the HOSTS file. You may also experience this problem when the server’s are part of an NLB cluster or when an IIS-based application accesses a SQL Server instance located on the same server using the loopback address together with Windows Authentication.

This feature was originally implemented with Windows Server 2003 Service Pack 1 and is therefore present in all recent versions of Windows


Note: MS KB Article states you have to disable Strict Name Checking as well; this is not true or at least not true if you don’t plan to use file & print sharing over the loopback adapter (see below)

Note2: My field experience tells not to use the loopback adapter anymore for SharePoint crawler because it may also generate other issue related on security software (anti-virus, local firewall…) adding their load of security checks to the communication channel to the loopback adapter.


Strict Name checking is a security feature specific to the Windows implementation of the SMB protocol (File & Print sharing). It will prevent connections from being stabled to a network share or to a shared printer if the host name used is not the server’s real one. The error message might also be considered as misleading: System error 52 has occurred. A duplicate name exists on the network.

The feature has been originally brought by Windows 2000 and is implemented is all subsequent versions of Windows.


Kerberos and how it is related to Names

Like I stated upper in this post, Kerberos authentication protocol integrates name checking in its foundation since the secret exchanged between the client and the service are partially based on the name the service is accessed by. If the name of the service is missing or incorrectly configured in the Kerberos database (Active Directory in the Windows world), the authentication will fail with the internal error KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and is likely to fall back in NTLM authentication, which will ultimately lead to a successful authentication with a less secure protocol

Therefore, if one or multiple alternate names are used to access a service, the appropriate configuration must be associated with the user account (or computer account) running the service, using, for example SETPSPN or NETDOM like in the example above. Note: While some software offer the possibility to auto-magically register Service Principal Names in AD, very few do that actually)


Windows Server: Memory Pressure on Windows Server 2008 R2 File Server due to System Cache

Recent questions in TechNet Forums reminded me of an issue faced when building large file servers running on Windows Server 2008 R2. By large I mean serving a lot of files, from thousand to millions or more.

To improve performance, Windows Server makes intensive use of file system cache. With files located on an NTFS-formatted partition, this also means caching the additional information associated to the file or folder such as attributes, permissions and so on. Since with NTFS everything is a file, those information’s are stored under the form of metafiles, which are hidden to the user. For each file/folder, the matching metafile entry can have a memory footprint equivalent to at least 1K. Multiplied by the number of files cached, it starts counting on larger file servers. Thanks to Sysinternal’s RAMMap Utility, you can witness this behavior by looking at the line Metafile from the tab Use Counts:


There is very little you can do to work around this issue except adding more RAM to the server. Since the amount of memory used depends on the size of files served and the number of files (Metadata), the amount of RAM needed can be relatively easily although roughly calculated.

While you can control the amount of memory used by the file system cache, you can’t prevent the metafiles from being cached.

Finally, a safe way not to get caught by surprise by this behavior once your file server is running in production is to benchmark it beforehand using the File Server Capacity Tool (FSCT).

[UPDATE] While File Servers are the most likely to be affected by this issue, web servers serving large amount of files or workstations used for large development projects might be too…

More Information

Leave a comment

Windows: LSA Lookup Cache

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])

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:

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: Definitely a must read!


Leave a comment

Windows Server 2008 R2: CIFS/SMB 2.x in Details

While Windows Server 2008 and Vista introduces the version 2.0 of the Server Message Block protocol (aka File and Printer Sharing in humanly readable words), Windows Server 2008-R2 and Seven both bring a refreshed version, the 2.1. Instead of drilling down right-here into the protocol’s details, I found more useful to post links to the most interesting resources on the Web.

Protocol Specification and Details

Tuning and Optimization

Support and Troubleshooting

Extra Goodies: Multi-threaded Robocopy and GUI

Although not directly related to SMB 2.1, Robocopy was also updated with the recent version of Windows. The main improvement is the support for multi-threaded operations, particularly interesting when massive file copy operations must take place against small files over WAN connections. I will cover this in details in a coming post. See for details. Important to note that this option is NOT compatible with the inter-packet gap option (copy using throttling).

Not so new, for those reluctant to learn and exploit all Robocopy command-lines params, there are cool GUI’s available out there, RichCopy being, like its names says it all, the richest one.


Leave a comment

Windows Server 2008 R2 and Windows 7: System Services Configuration Details

I am usually reluctant to mirror other blogger’s contents or just post links but in this case I decided to make an exceptional exception. “Black Viper” (sounds like a gamer tag isn’t it?) published a comprehensive guide over Windows Server 2009 R2 and windows Seven System Service configuration covering all OS flavors. Have a look at it prior starting any optimization or hardening work!

Previous Windows versions are also available btw.

From Hervé Schauer Consulting you might also find this (blast from the past, read “up to XP/Server 2003”) set of information useful: