Thursday, December 11, 2008

Changing the application pool identity for Sitecore

Though the Sitecore installer does not support Windows authentication yet, it is possible to reconfigure the system manually after the installation.
In production environments where security considerations represent a major concern, using a SQL user as well as having username and password specified as clear text in the connection string might be undesirable.
Production SQL Server boxes generally reside on a different machine that do not have access to the account the Sitecore application process in authenticated. That’s why the same domain user should be used for both Windows authentication on the SQL Server box and the application pool identity on the web server where Sitecore is running.

Here are the steps to configure this:

  1. Find the application pool that your Sitecore is running under. Open Properties and set the identity to the domain user on the corresponding tab.
  2. On the SQL Server box register the domain user and grant security permissions on Sitecore databases for the domain user according to the section “3.7.2 Creating a Database Account for Sitecore CMS Databases on SQL Server 2005” of the Installation Guide.
  3. On the machine that hosts Sitecore add this domain user to the IIS_WPG group.
  4. Adjust the permissions for the IIS_WPG group according to this section of the Installation Guide “3.6 Configuring Folder Permissions”.
  5. Edit the /App_Config/ConnectionStrings.config file and replace the user id and password parameters with the trusted_connection=yes option:
  6. <?xml version="1.0" encoding="utf-8"?>
        <add name="core" connectionString="Data Source=.\sql2008;Database=Sandbox6_Core;Trusted_Connection=Yes" />
        <add name="master" connectionString="Data Source=.\sql2008;Database=Sandbox6_Master;Trusted_Connection=Yes" />
        <add name="web" connectionString="Data Source=.\sql2008;Database=Sandbox6_Web;Trusted_Connection=Yes" />
  7. Prepare your identity so it can be used as a service account with “aspnet_regiis.exe” and the -ga switch.
  8. Adjust your global.asax so two methods are executed on Application_Start:
    public void Application_Start()
       System.Security.Cryptography.RSACryptoServiceProvider.UseMachineKeyStore = true;
       System.Security.Cryptography.DSACryptoServiceProvider.UseMachineKeyStore = true;

- Anonymous access to the website is still enabled, using the IUSR account. Also the impersonation is still disabled in the web.config as by default.
- ASP.NET cannot send NT credentials over network if SQL server name is resolved using HOSTS file though accessing the same server using NetBIOS name or IP address works fine.


Mark Cassidy said...

Excellent post. I've not tried doing this on Sitecore 6 myself, but I can see there's definitely more steps involved than I would have first thought.

One for the bookmarks :-)

Martin said...

Thanks Alex. Step 7 did the trick.

dmead said...

This worked for us too. We aren't using domain accounts, just a local machine account, and we continued to use SQL auth. In other words, all we did was change the app pool identity to a local account instead of Network Service. We had previously gone through general ASP.NET steps - aspnet_regiis etc, but then after performing step 7 it worked. Thanks for the post!

alex said...

Thanks for posting this.

You helped another typical vendor with poor database security priorities.