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:

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.

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:

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!

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:

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

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

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

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:

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:

• Full Technet article on how to configure Kerberos authentication for SharePoint 2010. Very comprehensive. It talks about SPNs and how to add them in Active Directory. This is a good place to start: http://technet.microsoft.com/en-us/library/gg502602.aspx
• SharePoint 2010 and Kerberos: http://www.harbar.net/archive/2010/03/31/sharepoint-2010-and-kerberos.aspx
• Using Kerberos with SharePoint on Windows Server 2008: http://www.harbar.net/archive/2008/05/18/Using-Kerberos-with-SharePoint-on-Windows-Server-2008.aspx
• Very detailed walkthrough on how to enable Kerberos for ANY Web application: http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx
• Configuring Kerberos Authentication in SharePoint 2010: http://blogs.msdn.com/b/russmax/archive/2009/10/20/configuring-kerberos-authentication-in-sharepoint-2010-part-1.aspx
• <windowsAuthentication> element in IIS 7: http://www.iis.net/ConfigReference/system.webServer/security/authentication/windowsAuthentication
• How to use Group Policy to configure Internet Explorer Security Zones: http://www.grouppolicy.biz/2010/03/how-to-use-group-policy-to-configure-internet-explorer-security-zone-sites/

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

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:

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:

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”.

At this time we are not aware of any attacks using this vulnerability and we encourage customers to review the advisory for mitigations and workarounds.

Oh yeah, add the fact that the article starts with:

Today we released Security Advisory 2416728 describing a publicly disclosed vulnerability in ASP.NET that affects all versions of the .NET Framework.

If those lines don’t get your attention, I don’t know what will!

A detection script was made available also at the TechNet article “Understanding the ASP.NET Vulnerability”. The script is ran as a VBScript and will report all Web app configurations that are vulnerable. If your apps are not vulnerable, the script will report “OK” on the app. The report looks like the following:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Enumerating possible paths with ASP.Net configuration that have custom errors turned off.

C:\inetpub\wwwroot\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp1\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\2639\wpresources\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\wss\VirtualDirectories\4444\web.config: ** Vulnerable configuration found **
C:\Inetpub\wwwroot\TestApp2\web.config: ok

If your app shows “Vulnerable configuration found”, then the Security Advisory is applicable for that app. You want to see “ok” like in the last line of the example above.

The vulnerability is called “Padding Oracle Exploit”. The attacker will attempt to send tampered data to the web server and the web server will generate error messages. As more error codes get returned to the attacker for the tampered requests, the attacker can learn what the encryption is. Once the encryption is compromised, the exploit beings. This vulnerability will allow an attacker to read data, even encrypted ones such as data stored in the View State, and even download files such as the web.config file from the target server. (But requests for web.config files cannot be served by IIS, right???) Scott Guthrie explains in his blog how this vulnerability works. Scott also explains how to workaround this issue. Before a patch or security update appears, this is the best tool against the exploit provided by Microsoft.

You say “But I never store sensitive information in the View State!” Well, read on. In the Microsoft TechNet Security Advisory (and even Scott’s blog post), the workaround’s main theme is homogenizing the error page. The TechNet security advisory says “Homogenizing errors is a crucial component to help protect against this attack.” This means turning customErrors to “On” and explicitly specifying the defaultRedirect page. For full details, please read Scott Guthrie’s blog post.

Now, you might say, this is just another over-hyped, exaggerated propaganda by the Microsoft haters. Well you can throw that argument out the window since it is Microsoft itself that is telling its customers about the vulnerability. There is also a Common Vulnerabilities and Exposure entry for this. The CVE entry says it just has a “candidate” status on it right now and may even be “rejected in the future”.  Is that grounds for ignoring it because it’s just a “candidate” CVE entry? Is it really worth ignoring because the probability and severity of the exploit has not been fully established yet? For public-facing sites, I recommend you implement the workaround as soon as possible. The workaround is fairly cheap to implement—just do it! There will be many apps that will be fine and no workarounds would be necessary (their customErrors configuration is already protected against this exploit). But if the detection tool above says “vulnerable” on your site, and the site is public facing, all I can say is “Wow!” should you decide to ignore it.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

The WSS 2.0 environment has “moved around” a lot. The front-end and SQL backend has been toasted at least once and the environments had to be recreated from scratch. The only backups they had were SQL backups. The SQL backups were okay.

Now, he wants that WSS 2.0 upgraded to WSS 3.0. I thought, well, this should be easy–only one Web front-end and one SQL server. Also, he had no intention of keeping WSS 2.0. So, just do an in-place upgrade, and it should be done, right?

Well, I ran into problems when I did the pre-upgrade scan prior to running the WSS 3.0 Configuration Wizard. You’re supposed to run the pre-upgrade scan tool prior to upgrading WSS 2.0 sites to WSS 3.0. Otherwise, if you run the Configuration Wizard without running the prescan tool, you will get:

Configuration Failed.
One or more configuration settings failed. Completed configuration settings will not be rolled back. Resolve the problem and run this configuration wizard again.

To run the prescan tool, go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Bin and execute the following command:

prescan.exe /all

(For more details, see the Microsoft KB article 938216. )

When I ran the prescan tool, I encountered errors and it says on the log file:

Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit. The most likely reasons for Prescan to skip a list are covered in the Knowledge Base article at: http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409 (http://go.microsoft.com/fwlink/?linkid=69958&clcid=0×409) For more information about the lists that are not upgraded, see the upgrade log file.

It seemed like there were orphaned objects. I told you, this WSS 2.0 had been recreated a few times and they used SQL backups to restore the contents. Things have been orphaned or convoluted along the way. Oh yeah, the Web front-end server also had several (non-WSS) virtual sites that were running on port 80; they were differentiated only via the use of host-headers. I couldn’t find the orphaned objects to drop and realized that the I’m stuck and couldn’t proceed with the upgrade. I spent an hour performing the recommendations on how to repair/remove orphaned lists and then I stopped.

So here’s what I did instead:

1. Backed up the WSS 2.0 site collection using stsadm
2. I restored the WSS 2.0 site collection in a different environment/farm. I used my home lab environment for this.
3. I then upgraded my home lab WSS 2.0 to WSS 3.0.
4. I backed up the WSS 3.0 site collection using stsadm. Now I have the site upgraded to WSS 3.0.

Only thing I have left to do is cleanup the Web front end server at my customer’s site and re-install WSS 3.0 without the upgrade option. Once WSS 3.0 is installed and configured, I can restore the site collection. I’ll do that tomorrow.

Sometimes, you just have to do what you have to do to get the job done.