Posted by: Gabe Hilado in Security,SharePoint on May 26th, 2011

There are two options when configuring SharePoint 2010 security in “classic mode” (as opposed to claims-based). You can use Basic (NTLM) or Negotiate (Kerberos). If you use NTLM, you may run into double-hop issues. This is why you will probably want to use Kerberos over NTLM (this assuming you’re not yet moving towards claims-based authentication).

So, you want to use Kerberos. During the configuration of SharePoint after installation,  in the Configuration Wizard, you will be asked to choose which security setting you want to use. If you choose Negotiate (Kerberos), and then click Next button on the wizard, you will get a prompt like the following:

SP Configuration Wizard - Kerberos or NTLM?

What this message tells you is that you or your domain administrators must configuration Security Principal Names or SPNs in Active Directory.

In case you’re wondering, here’s a summary of my SharePoint lab environment:

  • Windows 2008 Server R2 OS on all servers. AD is compatible with Windows Server 2003 features.
  • Microsoft SQL Server 2008 R2
  • SharePoint Server 2010

You can use use SetSPN tool to configure the SPNs for your SharePoint environment. Or, if you’re curious to see  what SPNs “look like” in Active Directory, you can use ADSIEdit. If you use ADSIEdit, login to the domain controller or use a server that has the Active Directory tools installed in it. When you open up ADSIEdit, expand the CN=Users tree and look for the domain account you want to setup SPNs for. The domain account that you want to setup SPNs for is typically the identity of the SharePoint Web site application pool. In the example below, I was adding SPNs to the “SP Web App Pool” account, which will be the service account used by the SharePoint Web site. Right-click the domain account in ADSIEdit and click Properties. In the Attribute Editor tab, look for servicePrincipalName.

ADISEdit - Add SPNs

Edit it and you can then add the SPNs for the domain account.  I have included a link in the Resources section on the bottom of this article to a Technet article that explains in full detail how to add SPNs in Active Directory.

In addition to adding SPNs to the service account, you must also enable delegation for the service account. Go to Active Directory and look for the service account. If you have setup SPNs for the domain account, you should see a Delegation tab on the user properties:

Service Account allowed for delegation

Check “Trust this user for delegation in specified services only”. And then select “Use any authentication protocol”. Finally, add the SPNs to the “Services to which the account can present delegated credentials” list. Links on the resources list will show you how to do this in full details.

In MOSS 2007, you have to setup SPNs for the service account and choose Kerberos as authentication mode and your SharePoint is good to go to use Kerberos. Setting up SPNs for SharePoint service accounts is nothing new. Well, in my lab environment, my SharePoint 2010 is running on Windows Server 2008 R2 with IIS7. The expected behaviour after adding SPNs was that the user (me) was prompted 3 times by the SharePoint site and only to render nothing after the 3 prompts for login. No matter how carefully I typed-in a domain account into the login prompt, I couldn’t get in!

Apparently, in IIS7, there are new settings that you have to configure in addition to setting up SPNs for the service account. You have to edit the applicationHost.config file in order to enable WindowsAuthentication. This IIS.NET article explains that IIS7 installs with windowsAuthentication disabled by default. But I have to give credit to Spence for his SharePoint article on how to enable Kerberos. Spence’s article was what actually got me moving in the right direction.

So I enabled windowsAuthentication (list of resources at the bottom of this article). When I tried to connect to the SharePoint site, I was being prompted to login!! Why?? So I typed-in domain account. On the first attempt, I was able to get into the SharePoint site.

It felt like challenge-response (NTLM) because I was prompted to login. I look at the Security Event Log of the SharePoint Web server. I see that the user logged-in using Kerberos!

Event 4624 in Security Event Log

Event 4624 showing it was Kerberos

So what now? Why was I still getting prompted to login? I forgot something–Internet Explorer security settings! I have to add the URL to my SharePoint 2010 portal in Intranet Zone sites. Also, you have to configure the “Custom Level” of the Intranet zone such that “Automatic logon onl in Intranet zone” is selected:

Internet Explorer Security Settings for Intranet Zone

If the SharePoint site is not detected as an Intranet zone, you will notice in IE status bar:

SharePoint Portal - Internet Zone

If you have admin rights to the workstation, you can probably edit the list of sites in Intranet Zones in IE Security settings and enable automatic logon in Intranet sites Well, in my setup, the workstation–what a user can change and cannot change–is controlled by group policies.

I had to create a new group policy and link it to my domain (or you can edit the default group policy for the domain if it’s just a lab environment) When editing the GPO, the path to add SharePoint sites to Intranet Zone is:

Computer Configuration>Administrative Templates>Windows Components>Internet Explorer>Internet Control Panel>Security Page>Site to Zone Assignment List

IE Site to Zone Assignment List in GPO

When you edit the Site to Zone Assignment list, you’ll be presented a dialog box. You can add the sites (typically just make it “http//*.yourFQDN” so that all sites in your lab environment are detected as Intranet sites):

Enter zone assignments in GPO

After editing GPO, propagate the new policy by restarting the workstation. After the workstation restarts, I hit the SharePoint site again and no more login prompts!! Also, notice on the status bar that the SharePoint site is detected as an Intranet site:

Portal Intranet Zone

Hopefully, this article demonstrated to you how to configure Kerberos for SharePoint 2010. Yes, claims-based authentication is supposed to be the “preferred” mode these days in SharePoint but plenty of organizations out there will stick with Kerberos (Windows integrated security) for a little while. If anything, this article serve as a jump point to other great articles out there on how to accomplish Kerberos in SharePoint. List of links below.

Resources:

Posted by: Gabe Hilado in ASP.NET,Security on September 29th, 2010

Microsoft came out today with an out-of-band security update for the ASP.NET Padding Oracle Attack Vulnerability. If you didn’t perform the recommended workaround last week (when this vulnerability was disclosed) because you thought the Microsoft update was going to come out soon–well, I think you got lucky today now that the update is out. BUT, I hope your public ASP.NET sites didn’t get exploited during all that time! Now that the update is out, you should look into the following Microsoft Security Bulletin as soon as possible:

http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

Posted by: Gabe Hilado in ASP.NET,IIS,Security on September 22nd, 2010

Yesterday, I blogged about the newest ASP.NET Vulnerability. As of this writing, there is still no patch for the ASP.NET Security Advisory 2416728. If the detection tool as part of the workaround provided by Microsoft reports that your apps are okay, then you don’t have nothing to worry about—just wait for the security update (what else can you do?).

Now, if the detection tool reports that your apps are vulnerable, and the apps are public-facing (on the Web), you will really want to consider the workaround.

The emphasis of the workaround is to “homogenize the error codes”. The exploit relies on error codes returned by the application to an attacker. The more differentiated the error codes, the more it learns about the encryption, and the better chance it has on cracking the encryption (read-up on “Padding Oracle Attack”).

I created a stripped-down test ASP.NET Web application project that initially has customErrors=”Off”. Within the project, I created pages that will deliberately throw errors. I have a “Divide by Zero” page, a “Throw Error” page, a “View State Exception” page, and a link from the default page to a non-existent page. I used Fiddler to monitor the traffic to and from the app while customErrors=”Off”. Next, I apply Scott Guthrie’s ASP.NET workaround for this vulnerability. I set customErrors=”On” and initially, I use redirectMode=”ResponseRedirect”. The HTTP 500 response codes disappeared but there are still HTTP 302 (redirect) responses. See the evolution of the response codes as I changed the customErrors section:

Fiddler Screenshot of Mixed Error-Codes

customErrors=”On” starts at line 13 in the screenshot above. No more HTTP 500 once customErrors was turned on. However, there are still HTTP 302, which may clue-in the attacker that an error occurred and hence the redirect to a generic page.

So we change the customErrors element once more time. I set redirectMode=”ResponseRewrite”:

   

<customErrors mode="On" defaultRedirect="fatwhale.htm" redirectMode="ResponseRewrite" />

(By the way, in case you’re wondering what the “fatwhale.htm” page is, it is in reference to the twitter whale whenever twitter service gets overloaded.)

After setting redirectMode=”ResponseRewrite”, the traffic captured by Fiddler shows that everything is consistently HTTP 200, even though we know that run-time errors were occurring on the individual pages:

Fiddler Screenshot - All HTTP 200 Response

Scott responded to some of the comments in his blog post and he strongly encouraged people to homogenize the response/error codes. The Fiddler screenshots I showed above is what I think Scott Gu means by “homogenizing the codes”.

Newer Posts »