Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


UAG2010: Configuration Lost after Installing Service Pack 4

ForeFront UAG

Introduction

In this post I will modestly relay a problem experienced by a customer that was hopefully resolved by MS product Support.

After Installing the Service Pack 4 of UAG 2010, the complete configuration was missing. It was impossible to restore a backup taken prior installing the Service Pack because the schema of the database storing the configuration evolved. We were in a rather uncomfortable position…

Solution

Hopefully, the solution to this problem is rather simple:

  1. From the Control Panel, uninstall the Service Pack 4 and reboot once prompted
  2. After rebooting, open the UAG console and verify the current build version of the product. Due to the prerequisites for SP4 installation, it should be 4.0.3206.10100, which means Service Pack 3 + Update Rollup 1. You can refer to this page if you need MS product build versions, it covers UAG2010 as well
  3. “Normally”, the configuration should be back as well. If not, restore it from a previous backup. Since build versions are identical, it should work fine
  4. Activate the configuration then reboot the server again. The situation should be stable from this point. For safety, take a new backup before going any further
  5. From now you can attempt to install the Service Pack 4 again
  6. After successful installation, activate the configuration again and take a backup

Proactive Action

In order to prevent this problem from occurring on other Service Pack 4 deployments, proceed as follows:

  1. Make sure Service Pack 3 and Update Roll-up 1 are installed
  2. Activate the configuration with the current build level
  3. Reboot the server
  4. Take a backup
  5. Deploy Service Pack 4
Advertisements


Leave a comment

SharePoint: Removing HTTP Headers for Security Reasons

SharePoint 2007 SharePoint 2010 SharePoint 2013</

Introduction

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: 14.0.0.6109 . 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:

when HTTP_RESPONSE {
   # 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">

<MANIPULATION>

<HEADER_CHANGE>

<REQUEST>

<APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<URL>

<URL_NAME/.*</URL_NAME>

<DELETE>

<HEADER>

<NAME>X-Powered-By</NAME>

</HEADER>

</DELETE>

</URL>

</REQUEST>

</HEADER_CHANGE>

</MANIPULATION>

</APP_WRAP>

Conclusions

  • 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

Marc


Leave a comment

UAG 2010: Incorrect Redirection after Successful Authentication

ForeFront UAG

Today, a little UAG-related gotcha I wanted to share with you. Consider the following:

  1. Multiple SharePoint web applications are published under the same trunk
  2. All web applications are served by the same back-end SharePoint servers (the ones you define in the “web servers” tab for each published application)
  3. AAM and other required configurations were made according to best practices

Then you’re likely to face the problem described below:

  1. Through the UAG, you attempt to directly access to http://webapp02.mydomain.com/sites/mysiteonwebapp02/
  2. You’re redirected to the portal for authentication
  3. You authenticate successfully
  4. Alas, you are redirected to http://webapp01.mydomain.com/sites/mysiteonwebapp02/ and a naughty 404

Why such a behavior? Well the explanation we received from the support is the following: When compiling and activating its configuration, UAG builds a list of unique web servers on a per-trunk basis instead of per-web application. Therefore, it is likely that although you’re trying to access the correct web application directly and authentication happens successfully, you may be redirected to the first web app in the list that has the same web servers defined.

I did not have time to test but it is likely to face the same issue when publishing any type of web application (IIS…) as long as they meet the configuration stated above.

Fortunately, the MS support proposed 2 workarounds:

  1. Publishing each web applications under different trunks. Wow, heavy isn’t it? No to mention possible problems with DNS domain conflicts…
  2. Creating a DNS alias (or entry in the HOSTS file of the UAG) for each web server hosting each web application such as webapp01-srv01, webapp01-srv02, webapp02-srv01, webapp02-srv02 and so on in a way that each entry is actually perceived as globally unique for the trunk

Apparently, this behavior considered by design, is unlikely to be fixed in a coming update or service pack.

Marc

PS: Big thanks to @jlebutte for his help!