Archive for March 2009


WSS on Server 2008

We have some unique challenges installing WSS on Server 2008.

First of all there's some chatter about WSS being offered as a Server 2008 Role. The assertion being that you can just go into Server Manager and run the Add Roles wizard to select the WSS role and then the configuration is straightforward. Then there's some dissenting voices that suggest it may be more complicated than that.

Second, there's also a number of issue that arise from the User Access Control (UAC) issues. This technology is covered in detail on TechNet  here.

The Microsoft Instructions are here where we get this:

… if you installed the 64-bit version of Windows Server 2008 and then modified the Enable32bitAppOnWin64 registry key so that Internet Information Server (IIS) is running in 32-bit emulation mode, you cannot install Windows SharePoint Services 3.0. To install either 32-bit or 64-bit Windows SharePoint Services 3.0 you must run IIS in 64-bit mode.

Remember in SQL Server 2005, you had trouble with remote connections that had to be addressed in the Surface Area Configurator which no longer exists in SQL Server 2008. Now you just need to look at the server instance properties and make sure " allow remote connections is ticked. Then in the Configuration Manager, enable the protocols you need. Also, we need the SQL server browser serivce to be running.

Also, here we see that when SQL Server 2008 is running using a domain account it must be configured to support Kerberos authentication. Now, nobody knows more about Kerberos authentication than we do so maybe this is as easy as running SetSPN to establish an SPN for the domain user.  We get some help here explaining how to configure our service account to use Kerberos.

 This may take a while…

More to come…


The Uninstall

Okay, I've stepped into it.

I started a post yesterday about how to back out of an install when you've got it wrong. What I did was select Kerberos Authentication for the Central Adminstration website and once the Configuration Wizard completed, I couldn't open CA and I didn't want to take the time to configure the SPNs for my service accounts just now so I wanted to do a "post-config" uninstall.

So I just deleted the databases, the web site and the app pool and thought I'd just run the wizard again.

Not such a great idea.

The wizard remembered the old farm, but, without the configuration database available, it couldn't "unprovision" it. The WSS entry in Programs and Features wouldn't uninsall either; It offerred a Remove or a Repair option but neither would run to comletion; they would both start and then just quit and go away.

Eventually, I ran Setup.exe again and it offered a Repair option. Once it finished, I ran the wizard again and it gave me a dialog box that said "Error connecting to existing configuraiton database" and I said "really?" My only option was to cancel and when I did, I was able to run it a second time and it was happy to allow me to create a new farm.

So, what we've learned is the Proper "Post-Config" Uninstall Procedure.

  1. Run the Configuration Wizard and, on the second page, select Disconnect from this server farm and click Yes on the warning dialog. This will delete the IIS web site and the application pool.
  2. Then, run the uninstall from the Control Panel's Features and Programs application and click Yes on the warning dialog. This will take a reboot.
  3. Then, if you really want to get rid of it all, go to the database server and delete the Config and Admin Content databases.


PSConfig.exe v. The Configuration Wizard

In certain circles, you’ll hear them say “There’s no option to running the Configuration Wizard after you install the SharePoint Binaries.

In another, in particular, the blog of our new friend, Alpesh, you’ll hear that PSConfig.exe can replace the Configuration Wizard.

So I’ve installed WSS and I have two new menu options under Administrative Tool, SharePoint Central Adminsitration and the SharePoint Configuration Wizard.  When I try the Central Adminstration link, I’m told I need to run the wizard. So our question is, can we replace the configuration wizard with a suitable set of PSConfig.exe commands.

First, Let’s take a look at what the wizard does.

  1. It warns you that we’ll be restarting some services including IIS.
  2. Select between an existing farm or a new farm. Let’s presume at this point that we’ll be creating a new farm. If we need to work an install script for additional server, we’ll look at it after.
  3. Configuration DB Settings – You add the server name, database name, username and password. This is your “DBAccess Acount” and will be the App Pool identity for the Central Administration web site.
  4. Central Admin Configuration – This step inludes your opportunity to select a port number for your CA web site (I always select 63999) and your selection of NTLM or Kerberos.

That’s if the the Configuration Wizard until you click Advanced Settings. Here you’ll get to select Active Directory Account Configuration mode where you can specify the domain and organizational unit where the new users will get created. Let’s call this a complication we can look at later.

So that’s it.

Now if you look at the PSConfig.exe reference on TechNet you’ll see we can get all this into it’s commands but first, let’s agree on some sample values for the required inputs.

  • Our domain is called OurDomain.
  • Our DB server is called OurDBServer.
  • Our Configuration DB name will be SharePoint_Config, the Wizard’s default.
  • Our DB Access account is called OurDomain\SPDBAccess and its password is SPDBAPassword.
  • Our farm administrator account is called OurDomain\SPFarmAdmin and his password is SPFAPassword.
  • Our CA port number is going to be 63999 and we’ll use Kerberos authentication.

And let’s review the PCConfig.exe syntax: PSConfig.exe -cmd <command> [<parameters>]

Now, I’m not trying to rewrite the reference but let’s see if we can get our farm built.

Our first venture into PSConfig activity will be to use the ConfigDB command to create the configuration database. Let’s try:

PSConfig.exe -cmd configdb -create -server OurDBServer -database SharePoint_Config -dbuser OurDomain\SPDBAccess -dbpassword SPDBAPassword -user SPFarmAdmin -password SPFAPassword -admincontentdatabase SPAdminContent

So, I try this and I get this error:

You do not have the appropriate permissions to use the SharePoint Products and Technologies Configuration Wizard.  This application requires Administrator privileges.

I’m logged in to the server as SPFarmAdmin and, sure enough, I’m already a local box admin. The problem seems to be Windows 2008 and its stinginess with permissions. When you start a command prompt in Server 2008, it does not automatically provide that session with administrator privileges; to run the configdb command, you have to right-click on the command prompt menu option and select Run as Administrator.

Also you may run into another problem burried in your database server. The SQL Server Browser service must be running if your not running a single, default database instance on your server.

Yet, still, I am not able to run the configdb command. The PSConfig.exe program creates a log called PSCDiagnostics_xxx everytime you run it and puts it in the 12Logs folder. Here, when I start to get errors, it tells me that the login for my dbuser fails:

Login failed for user ‘OurDomain\SPDBAccess

So for right now, the Configuration Wizard seems to be a requirement.


Kerberos: Threats and Countermeasures

Now the assignment is to brief our security group on the impact of our Kerberos configuration might have "downstream" specificially relating to "threats and countermeasures."

I guess the theory is that by trusting accounts and servers for delegation, security holes may arise in unexpected ways. Also, the specific configurtations may impact non-SharePoint web applications that are hosted on servers alongside SharePoint web applications.

Also, when we last looked at Kerberos, we were operating in our spiff new Server 2003 domains and, this being 2009, those domains look considerably less spiffy. So, to maintain sufficient spiffiness, we'll be working in our spiffy new Server 2008 domains.

We have the TechNet content re: Server 2008 here:

Here we find a link to download a document titled: Threats and Countermeasures: Security Settings in Windows Server 2008 and Windows Vista

The only relevant content here relates to providing permission to set the "Trusted for Delegation" property for user and computers in the Active Directory domain.

The main point of this content is that if you provide this permission to a user then you have the possibility that user can be hacked and some nefarious agent can then set the permissions, and establish authentication that will be trusted by the coputers that use this permission.

One excellent point it make is "Delegation of authentication is a capability that multitiered client and server applications use. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, both client and server must run under accounts that are trusted for delegation.

The impact here is that user account that get hacked can create a problem that would extend to data sources that trust the account even if that datasource itself is not hacked. The countermeasure is to use "constrained delegation" to llimit the access of trusted delegates.

As I see it, this means I log into Windows and I'm me. I visit my team site and SharePoint interacts with the content database using its service account and renders my selected page. On my page, there's a web part that queries an extenal datasource; since the service account is trusted for delegation and the web server is trusted for delegation, the service account and the web server are able to carry my ID to the external datasource and, essentially, log me it. As a result, the query result will be security trimmed for me. Obviously, if I can establish users and computers that are trusted for delegation, I can make the service account and the web server carry my credentials to an external datasource and gather the answer to a query that the service account itself may not have permission to see.

Second, elsewhere on TechNet ( tells us: Misuse of this user right, or of the Trusted for Delegation setting, could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.

Third, Kerberos Authentication uses Active Directory and our new best friend, Tim, has two great posts on the way Kerberos works in AD here:

Tim gives us this clever tidbit:

The T2A4D setting has no actual check box or radio button which is intuitively titled “Click Here for Trust To Authenticate for Delegation”.  Instead the setting is integrated with the constrained delegation settings interface on a computer account.

So, if we want to boost our credibility with the security team, we might suggest that we are, in fact, addressing the constrained delegation countermeasure we mentioned above.