Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

Leave a comment

SharePoint: MS15-022 (Critical) Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (3038999)

Once again, SharePoint Server 2007, 2010 and 2013 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution. The matching Office suite version are affected as well.

More information:

Important: SharePoint Server 2013 updated with March PU or Service Pack 1 can receive this security update through Windows Update.

Leave a comment

SharePoint: MS14-081 Vulnerabilities in Microsoft Word and Microsoft Office Web Apps Could Allow Remote Code Execution (3017301)

Both SharePoint 2010 and 2013 versions are affected by a vulnerability categorized as Critical by MS that can allow remote code execution.

More information:

Leave a comment

.Net: Vulnerabilities in .NET Framework Could Allow Remote Code Execution (MS14-057) – Critical

.Net Framework versions from 2 to 4.5.2 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution.

More information:

Leave a comment

SharePoint 2013: MS14-050 Vulnerability in Microsoft SharePoint Server Could Allow Elevation of Privilege

This vulnerability applies to SharePoint Foundation 2013 and SharePoint Server 2013 with and without SP1. More information:


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:

SharePoint: Web Parts vs. MS13-052 with a Fix!

SharePoint 2013

Description of the Problem

After installing the security update KB2844286 for the .Net Framework 3.5.1 on Windows 7 SP1/Windows Server 2008 R2 SP1, some web parts will cease functioning and display the error message hereunder:

Error while executing web part: System.NullReferenceException: Object reference not set to an instance of an object.

If you enable debug mode, then the output will be:

Error while executing web part: System.NullReferenceException: Object reference not set to an instance of an object.
at System.Xml.Xsl.XslCompiledTransform.Load(MethodInfo executeMethod, Byte[] queryData, Type[] earlyBoundTypes)
at Microsoft.Xslt.STransform.GetCompiledTransform()
at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.LoadXslCompiledTransform(WSSXmlUrlResolver someXmlResolver)
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.GetXslCompiledTransform()
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)


  • Install the Update from this KB2872441 on the SharePoint server(s). Note: This will require a restart


  • Uninstall the KB2844286 from the SharePoint(s)

More Information

Happy patching! (?)


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)


Leave a comment

SharePoint: Removing HTTP Headers for Security Reasons

SharePoint 2007 SharePoint 2010 SharePoint 2013</


Virtually any decent web security guide will recommend to obfuscate HTTP header revealing technical information’s over the technologies used to host and operate an internet-facing web site or application. In the case of SharePoint, each HTTP response is likely to include at least the following headers:

  • Server: Microsoft-IIS/7.5: Generated by IIS, it indicates the version of IIS SharePoint runs on
  • X-AspNet-Version: 2.0.50727. Generated by ASP.Net, it reports the ASP.Net version using on the IIS site
  • X-Powered-By: ASP.NET: The text says it all 🙂
  • MicrosoftSharePointTeamServices: . Supposedly reports the SharePoint Build Number. Refer to my article Retrieving the Current Build Version Number and to the one from Wictor Wilén: SharePoint Mythbusting: The response header contains the current SharePoint version
  • SPRequestGuid: 11ca6867-9228-455b-a8d9-ddd3e367de86. Implemented from SharePoint 2010 for diagnostics purpose to identify request in order to map them to entries in the ULS logs
  • X-SharePointHealthScore: 0. Indicates to the client the health status of the server on a scale from 0 to 10. The lower the better

SharePoint actually comes with many more headers, they are documented on MSDN: [MS-WSSHP]: HTTP Windows SharePoint Services Headers Protocol Specification.

Removing ASP.Net and MVC Headers

This article from 4 Guys from Rolla covers the topics comprehensively.

Removing SharePoint Specific Headers

SharePoint does not come with a configurable way to remove its own custom headers.

My Recommendation

While it’s always funny to play around with custom .Net HTTP module or even ISAPI filters, I would definitely not recommend this solution to remove HTTP headers since it may break SharePoint functionalities and place a certain load on SharePoint server(s). Not to mention additional hassle in case you have to troubleshoot something in the IIS/SharePoint pipeline. I also attempt, as much as possible, to reduce customization at SharePoint level to improve manageability and lower service costs.

The same logic applies to ASP.Net or MVC configuration changes but with a lower importance.

Instead and if you’re minimally serious about SharePoint infrastructure security on the Internet, you will not expose it directly but place a security gateway or reverse-proxy in front. Those security devices or servers usually come with the capability to alter HTTP headers easily and with a near-zero footprint.

This way, you keep your SharePoint fully functional while another device does the actual security job.

Removing Headers using F5 BigIP

With BigIP, it’s a no-brainer with the command http::header with iRule, example:

   # loop through and remove all instances of the unwanted
   # headers from the server response
   # (Server, X-Powered-By in this example)
   foreach header {Server X-Powered-By} {
      log local0. "Removing $header: [HTTP::header value $header]"
      HTTP::header remove $header

Removing Headers using Forefront UAG 2010

Using AppWrap, it’s a little more complex but in a nutshell, a rule similar the one hereunder can be used:

<APP_WRAP ver="3.0" id="WhlFiltAppWrap_HTTPS.xml">



















  • Do not mess around with custom HTTP Module, ISAPI or other configuration change unless you have no other way.
  • Like best practices usually recommend it, place you internet-facing SharePoint behind a security device such as ForeFront UAG and use that security device to do the response obfuscation work
  • Note1: Removing headers is only one step in the direction of securing Internet-facing SharePoint
  • Note2: While it gives a feeling of security, it will only prevent robots, probes or scripting kiddies to identify the underlying technologies. Real hackers use superior method insensitive to this countermeasure
  • Note3: But at least, the security audit will not blame you for exposing those headers on the Internet 🙂

More Information’s


Unable to Attach the Process when Debugging Server Applications in Visual Studio

Recently I was debugging custom SharePoint-based application and timer jobs. Unfortunately and although my account was member of the local administrator’s group on my development server, Visual Studio refused to attach to the process I wanted to debug throwing out the error Unable to Attach the Process. Visual Studio has insufficient privileges to debug the process. To debug this process, Visual Studio must run as an administrator to my face.

The root cause is fairly simple to find: in environments where Windows (Server) high security is a concern, the privilege Debug Programs (SeDebugPrivilege), granted by default to the Administrators built-in group, is removed in order to prevent admins from getting their hands on passwords from other users (as well as other data stored in memory) or service accounts using tools similar to LSADUMP to name juste one.

Unfortunately, the consequence of this is the inability for an administrator to attach to a program in order to debug it live. The problem is not typical to VS but to any debugging program willing to attach to a live process.

3 possible solutions/workarounds:

  • Get your security administrator to restore that privilege. This it can be done on a per computer-basis, it should not be too harmful on a dev computer
  • Run your server application with your own user account (the one you log on with). Obviously against best practices and not always possible in highly secure environment since other privileges might not be granted (log on as service, log on as batch…)
  • Try running Visual Studio through the PSEXEC tool with parameters –s –I and –a. really tricky, has some limitation and, like the workaround above, not always possible in highly secured environments…

To list the privileges your account has been granted, just use the command whoami /priv.

Additional Information’s

Happy debugging!


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!