Archive for the ‘SharePoint’ Category

PowerShell SharePoint Site Collection Backup Script March 14th, 2010

Mike

I have been meaning to write a script in PowerShell to do SharePoint Site Collection backups for a while but not got round to it. I did do a quick and functional one at the tail end of last year, but it wasn't particularly elegant. This script I am much happier with: it will backup all Site Collections at the specified Web Application and place them at the given location in a folder constructed from the day's date. It also writes to a log file and can clean up folders containing backups that are older than a predetermined number of days.

Simply copy the script below and save it to a .ps1 file of your choice. Please retain my comments at the top and, as always, use at your own risk! The deletion portion is quite destructive :) . You may also have to set your Execution Policy to a less strict setting, such as RemoteSigned, e.g.:


Set-ExecutionPolicy RemoteSigned

I have tested the script with Microsoft Office SharePoint Server 2007 SP2 and Windows SharePoint Services 3.0 SP2 running on Windows Server 2003 R2 SP2 (PowerShell 1.0). It should work fine for MOSS and WSS running on different Windows Server operating systems.

Here is the script:

# SharePoint Site Collection Backup Script
# Author: Michael Cox
# Version: 1.0
# Date: March 2010
# Contact: http://www.betteritsolutions.co.uk/
# Use at own risk, please retain these comments

# Create alias for STSADM
Set-Alias -Name exeStsadm -Value ($Env:CommonProgramFiles + "\Microsoft Shared\Web Server Extensions\12\BIN\stsadm.exe") -Option Constant
# Specify maximum age in days for backup files
New-Variable -Name maxFileAge -Value 14 -Option Constant
# Get todays date, formatting as yyyyMMdd e.g. 20100224
New-Variable -Name todaysDate -Value (Get-Date -Format yyyyMMdd) -Option Constant
# Specify backup location and set log file location, folder must exist and be writable by account running script
New-Variable -Name backupLoc  -Value "S:\Backups" -Option Constant
New-Variable -Name logFileLoc -Value "$backupLoc\site_collection_backups.log" -Option Constant
# Specify Web Application
New-Variable -Name webApplication -Value "http://mossintranet/" -Option Constant

# Change to backup location and create folder, suppressing notification
Set-Location $backupLoc
New-Item $todaysDate -type directory | Out-Null
Set-Location $todaysDate

# Record backup start
Out-File -FilePath $logFileLoc -Append -InputObject $("Backup started at: " + (Get-Date -Format HH:mm` dd/MM/yyyy) + "`n")

# Enumerate Site Collections within chosen Web Application and store in a variable
[xml]$sitesXml = exeStsadm -o enumsites -url $webApplication

# Enumerates each site collection and performes an stsadm sitecollection backup against each site
$sitesXml.Sites.Site | ForEach-Object -Process {$backupFile = $_.Url.Replace('http://','').Replace('/','_') + ".bak"; exeStsadm -o backup -url $_.Url -filename $backupFile; Write-Host "Finished writing: $backupFile"; Out-File -FilePath $logFileLoc -Append -InputObject "Finished writing: $backupFile"}

# Remove folders that are older than the maxFileAge value
Set-Location $backupLoc
$tooOld = (Get-Date).addDays(-$maxFileAge)
Get-ChildItem | Where-Object {$_.PSIsContainer -and ($_.lastWriteTime -le $tooOld)} | ForEach-Object -Process {Remove-Item $_ -force -recurse; Write-Host "Folder $_ was deleted."; Out-File -FilePath $logFileLoc -Append -InputObject "Folder $_ was deleted."}

# Record backup end
Out-File -FilePath $logFileLoc -Append -InputObject $("`n" + "Backup ended at: " + (Get-Date -Format HH:mm` dd/MM/yyyy) + "`n")

Here is a screenshot of files created following a backup of a Web Application with two Site Collections and also the contents of the log file:

Screenshot after running script

Screenshot after running script

Please let me know if this is useful and also feel free to make suggestions for improvements or bug fixes, if you find any.

Continue reading...


 

Working With Kerberos Authentication Part 4 – Shared Services Provider November 2nd, 2009

Mike

In this part I will talk about configuring your SSP to use Kerberos.

The next step (if required in your environment) is to configure Kerberos for the Shared Services Provider. This includes root and virtual directory level Shared Services. A prerequisite for this step is the SharePoint Infrastructure Update (which was released post SP1).

Configuring the SSP Web Application is very similar to a normal Web Application, so we'll keep it brief. Assume we have the SSP's Web Application running on port 1234 not using a host header. Then, the commands to map the SPNs are as follows:


setspn –A HTTP/servername:1234 yourdomain\UserRunningAppPool
setspn –A HTTP/servername.yourdomain.com:1234 yourdomain\UserRunningAppPool

Turn on Kerberos authentication for the SSP Web Application as described for the content Web Application (previous post) and perform the same test, ensuring you see a successful Kerberos logon event in the Security log on the server hosting the SSP.

In order to fully configure Kerberos for the SSP and Excel Calculation Services, further SPNs must be set using a new, custom format. There are also STSADM commands to run and a change to be made to the registry of each server.

Map the SPNs with the following commands:


setspn –A MSSP/servername:56737/SSPName yourdomain\SSPServiceAccount
setspn –A MSSP/servername:56738/SSPName yourdomain\SSPServiceAccount

SSPName is simply the name you gave your SSP. It cannot contain extended characters so be sure to name your SSP with care at install time! You must also generate a pair of SPNs for each server in your farm. I.e. in a standard medium server farm (2 WFEs and 1 App server), you will set 6 SPNs, 2 for each server name.

Now run the necessary STSADM commands on a server in the farm:


stsadm –o setsharedwebserviceauthn –negotiate
stsadm –o set-ecssecurity –accessmodel delegation –ssp
stsadm –o execadmsvcjobs

In order, this sets the Shared Services Web Service to use Kerberos, Excel Calculation Services to use delegation and then forces the timer jobs to run immediately.

Lastly, each SharePoint Server will need a registry key adding to allow it to use the new custom format SPNs.

  1. Run regedit
  2. Go to the registry path HKLM\Software\Microsoft\Office Server\12.0 and right click 12.0 >> New >> DWORD Value
  3. For Name type in KerberosSpnFormat and change the value from 0 (default) to 1.

After this step, you must reboot your server.

There is some additional configuration required within Component Services. In order to prevent the occurrence of DCOM errors, all of your Application Pool service accounts should have Local Launch and Local Activation permissions on the IIS WAMREG Admin Service object, most easily achieved by giving the permissions to the local groups: WSS_WPG and WSS_ADMIN_WPG (this ensures that newly created Application Pool service accounts are granted the permissions, since SharePoint adds them to this group). This is well documented elsewhere.

However, there's also a modification to be made to the servers in the farm within Component Services. Click on Start > Administrative Tools > Component Services. Expand Component Services > Computers, right click on My Computer and select Properties. On the Default Properties tab, change the Default Impersonation Level to Delegate and click on OK.

My Computer Properties

My Computer Properties

References

There are a huge number of references for configuring Kerberos. Here is a useful selection:

That concludes my guide to Kerberos for SharePoint. I hope you have found it useful and if you have any queries, please send them to me.

Continue reading...


 

Working With Kerberos Authentication Part 3 – SharePoint Web Apps October 24th, 2009

Mike

This part of the four part series will look at configuring Kerberos on SharePoint Web Applications.

The first thing we need to do is to map some SPNs (again) and the SPNs themselves depend on whether you are using CNAMEs or A Records to resolve your web sites. If you are using CNAMEs, whose targets are servers with associated A Records, you construct the SPN using the CNAME's target (i.e. the hostname in the A Record). In the case of an A Record, it's much simpler; just use the hostname in the A Record. If you're unsure and don't have access to DNS (for whatever reason) then ping the DNS name and see if it resolves directly to an IP address or tells you it's pinging another address. The former result indicates an A Record is in use, the latter indicates a CNAME.

In the case of CNAMEs, it'll often be the case that the target is a machine which will mean constructing SPNs based on that computer's name. There's a further complication in that the same SPN cannot be assigned to more than one account so if you have a collection of CNAMEs for different Web Applications all resolving to the same A Record, each Web Application must use the same domain account for its Application Pool Identity to maintain a unique mapping of SPNs (this will become clear below).

As an example, I am creating SPNs for a site served on the host header kerbtest on port 80 with an appropriate A Record associated with it. The fully qualified SPN is optional (depending on whether the site is ever accessed using the FQDN), but I would always include it.


setspn –A HTTP/kerbtest yourdomain\UserRunningAppPool
setspn –A HTTP/kerbtest.yourdomain.com yourdomain\UserRunningAppPool

Note that HTTP in this case refers to the HTTP service, NOT the protocol. A common mistake is to mistype the above and start them with HTTP://, which is incorrect.

If your domain functional level is Windows Server 2003 or later, you will need to make some changes on the Delegation tab of the user account running the Application Pool. In Active Directory Users and Computers, locate the user object, right click on it and select Properties. Click on the Delegation tab and change the setting to either Trust this user for delegation to any service (Kerberos only) or Trust this user for delegation to specified services only.

Delegation Tab

Delegation Tab

Some guides will discuss enabling delegation for the computer account in Active Directory as well, but this is only necessary if the service process is running under the Local System account, which is not the case here.

If constrained delegation (the more secure and, therefore, recommended option) is required, I would suggest making sure everything works with unconstrained delegation first, before pressing on with constrained.

Kerberos can be enabled either at Web Application creation time, or later. I would usually implement it later, and make sure that the Web Application functions correctly with NTLM first.

To change the Authentication Provider to Kerberos, from SharePoint Central Administration (SCA), click on Application Management. Click on Authentication providers under Application Security. Make sure that the correct Web Application is selected and then click on the Zone that you wish to move to Kerberos. I will click on Default. The only change you should need to make is to alter the IIS Authentication Settings by changing the radio button from NTLM to Negotiate (Kerberos). Click OK when the warning dialogue box appears and then scroll to the bottom of the page and click on Save.

Edit Authentication

Edit Authentication

From another machine on the domain (not one of the SharePoint web front end servers), browse to the Web Application. On the Web Server that you hit you should see an event with ID of 540 in the Security log, containing the following kind of information:


Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 540
Date: 09/07/2009
Time: 14:10:52
User: domain\user
Computer:
Description:
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x2D996B)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {5dea6995-63c8-8ab0-0b1d-e80325461c16}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.11.12.2
Source Port: 1301

Again, computer, domain and user names have been deliberately removed.

This concludes configuration of Kerberos for a SharePoint Content Web Application. In the final part I will describe how to switch the Shared Services Provider to Kerberos and also add a list of useful references for further reading.

Continue reading...


 

Working With Kerberos Authentication Part 2 – Configuring (SQL) August 31st, 2009

Mike

What follows are the instructions for configuring Kerberos for various aspects of SQL (this part) and SharePoint (Part 3, coming soon). This is not necessarily a hard and fast set of instructions but a collection of steps known to prove working results for Microsoft Office SharePoint Server (MOSS) 2007 with SP1 and the Infrastructure Update running on Windows Server 2003 R2 with SP2 and connected to a Microsoft SQL Server 2005 Database Engine. Configuration may be slightly different for Windows Server 2008 (and therefore later versions of IIS than 6.0). Note that the infrastructure update for MOSS is necessary if you require all aspects of your Shared Services Provider (SSP) to use Kerberos. These instructions should also be fine if you are running MOSS SP2.

Enabling Kerberos for the SQL Server Database Engine

To enable Kerberos for SQL Server, it is simply a case of mapping the correct SPNs to Active Directory user accounts. Up to four commands should be run:


setspn –A MSSQLSvc/sqlserver yourdomain\SQLServerServiceAccount
setspn –A MSSQLSvc/sqlserver.yourdomain.com yourdomain\SQLServerServiceAccount
setspn –A MSSQLSvc/sqlserver:1433 yourdomain\SQLServerServiceAccount
setspn –A MSSQLSvc/sqlserver.yourdomain.com:1433 yourdomain\SQLServerServiceAccount

This is for a default instance on port 1433. If the port number has been manually changed or you are using a non-default instance then only two SPNs are required but you must use the two commands above containing the port number and substitute your non–default port number. Also ensure that the non–default instance is properly configured to use a fixed port number.

Two less SPNs are required in this case because clients can no longer connect by simply using the computer name, they must specify the port number so any SPNs without port numbers would simply never be passed.

We can check that Kerberos is now working by connecting to SQL using the Management Studio from another machine on the same domain. Open the Management Studio, connect to the Database Engine and look in the Security log on the SQL Server. You should see a 540 success event containing the following kind of information:


Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 540
Date: 09/07/2009
Time: 12:17:37
User: DOMAIN\UserName
Computer:
Description:
Successful Network Logon:
User Name:
Domain:
Logon ID: (0x0,0x3FF14)
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name:
Logon GUID: {cc8d6921-4c0d-e68c-8b1b-ba2fcdf4836f}
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.11.12.3
Source Port: 1150

Note that user, domain and computer names have been deliberately removed.

This is all that is required for the SQL Database Engine to use Kerberos. It always prefers to use Kerberos by default but if you manually choose the accounts used to run your services (which is usual) then you have to add the SPNs to Active Directory yourself for it to work. According to MSDN: For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account.

Using Kerberos with other SQL Components

In addition, if you wish to connect to other SQL components using Kerberos (such as Analysis Services) then you will require further SPNs. The commands for adding SPNs for use with Analysis Services are as follows:


setspn –A MSOLAPSvc.3/sqlserver:instance yourdomain\SQLServerAnalysisServicesServiceAccount
setspn –A MSOLAPSvc.3/sqlserver.yourdomain.com:instance yourdomain\SQLServerAnalysisServicesServiceAccount

Note that this is a little different to the SPNs for the Database Engine because, rather than a port number, you specify the instance name (if non–default, otherwise leave blank). SQL Server Analysis Services can only operate as a named instance in SQL Server 2005 (it is not supported in SQL Server 2000).

In the next part, I'll move on to talking about configuring Kerberos for SharePoint.

Continue reading...


 

Working With Kerberos Authentication Part 1 – Introduction July 23rd, 2009

Mike

I've had a few encounters with Kerberos so, as a result, I decided to collect what I have learnt together in a series of blog posts. Primarily my concern is with regards to enabling Kerberos Authentication for SharePoint, but I will add some general information, too.

Enabling Kerberos offers a few advantages over NTLM, it:

  • Is less susceptible to replay attacks because it includes a timestamp of when the network traffic was sent
  • Allows verification of servers through the use of Service Principal Names (SPNs)
  • Reduces authentication traffic because authentication is valid until the tickets expire (or are manually purged)
  • Allows authentication over multiple hops (via the use of delegation).

The last point is frequently the driving force in enabling Kerberos for SharePoint, although reduced authentication traffic and increased performance are also often cited. An example of where we might need authentication over multiple hops would be where we need to authenticate with a SharePoint Web Application, our credentials have to be passed on to a web service and this web service has to pass our credentials to SQL to retrieve data from a database. This is only possible if Kerberos is enabled and the intermediate accounts are trusted for delegation in Active Directory.

Concepts

There are some concepts key to Kerberos which are worth understanding. This is a very basic level understanding of them but hopefully will provide some insight.

What is a Service Principal Name?

An SPN is a string constructed using an arbitrary text name for a service, the computer name that the service is running on and the port. This then appears in the following format:

ServiceName/Computer:Port

An example would be MSSQLSvc/sqlserver01:1433

It is used to allow a client to uniquely identify an instance of a service.

To enable Kerberos we need to configure a mapping in Active Directory between SPNs and the account that the service is supposed to be running under. To do that, we either use ADSIEDIT or SETSPN (found in the Windows Server Support Tools or downloadable from Microsoft). You must at least be a domain administrator to perform these updates.

SETSPN

SETSPN is a command–line tool and has 3 switches that we're interested in:

–A to add an arbitrary SPN
–D to delete an arbitrary SPN
–L to list registered SPNs

The syntax we'll use is as follows:

setspn –A service/computer:port domain\user
setspn –D service/computer:port domain\user
setspn –L domain\user

Computer may be the NetBIOS name, Fully Qualified Domain Name (FQDN) or another DNS name – more about this later.

How Kerberos Works (very briefly)

Kerberos is an authentication service developed at MIT. The idea behind Kerberos is that both the user and service have a shared key and this is used to encrypt and decrypt something freshly created (for example a timestamp). If the wrong key is used at either end, decryption is not possible and authentication fails. In practise, what occurs is much more complicated, but this is the very basic idea.

When using Kerberos in a Microsoft environment, broadly speaking, the following occurs. A Kerberos authentication server will grant a ticket in a response to a client computer authentication request, as long as the request contains valid user credentials and a valid SPN (see above). This ticket can be used to access network resources. For the lifetime of the ticket (by default, it is 600 minutes, i.e. 10 hours) a new ticket does not have to be issued and this is how authentication traffic is reduced. For Kerberos to work, both the client and server must have a trusted connection to the domain Key Distribution Centre (KDC). The KDC distributes the shared secret keys to allow encryption to take place. Both computers also need to be able to access Active Directory directory services and the forest root domain is the centre of Kerberos authentication referrals.

In the next part I'll move on to talking about configuring Kerberos.

Continue reading...


 

SharePoint Permissions – Part 1 April 24th, 2009

Mike

After some hunting, I discovered that the information from Microsoft (and elsewhere) regarding the SharePoint Permission Levels was somewhat sparse and also a little conflicting. There are a few good articles (links at the bottom) but they disagree and don’t fully represent the number of Permission Levels. So, I did this the hard way and clicked through them all and made some tables.

Permission Levels

Permission Levels

The following tables show the permissions that comprise each out of the box Permission Level, correct for an out of the box Collaboration Portal on Microsoft Office SharePoint Server 2007 Enterprise as of Service Pack 1 and the Infrastructure Update.

List Permissions

Permission Level
Permission Full Control Design Manage Hierarchy Approve Contribute Read Restricted Read Limited Access View Only
Manage Lists X X X
Override Check Out X X X X
Add Items X X X X X
Edit Items X X X X X
Delete Items X X X X X
View Items X X X X X X X X
Approve Items X X X
Open Items X X X X X X X
View Versions X X X X X X X
Delete Versions X X X X X
Create Alerts X X X X X X X
View Application Pages X X X X X X X X

Site Permissions

Permission Level
Permission Full Control Design Manage Hierarchy Approve Contribute Read Restricted Read Limited Access View Only
Manage Permissions X X
View Usage Data X X
Create Subsites X X
Manage Web Site X X
Add and Customise Pages X X X
Apply Themes and Borders X X
Apply Style Sheets X X
Create Groups X
Browse Directories X X X X X
View Pages X X X X X X X X
Enumerate Permissions X X
Browse User Information X X X X X X X X
Manage Alerts X X
Use Remote Interfaces X X X X X X X X
Use Client Integration Features X X X X X X X X
Open X X X X X X X X X
Edit Personal User Information X X X X X

Personal Permissions

Permission Level
Permission Full Control Design Manage Hierarchy Approve Contribute Read Restricted Read Limited Access View Only
Manage Personal Views X X X X X
Add/Remove Personal Web Parts X X X X X
Update Personal Web Parts X X X X X

See also: Permission Levels and Permissions at Office Online and Permissions behind the permission levels in SharePoint at Sridhar's Blog.

I'm sure there’ll be more articles to come on SharePoint Permissions, hence this is Part 1 :)

Continue reading...