Implementing Persistent Cookies in SharePoint

2010 Products
This document is provided "as-is". Information and views expressed in this document, including
URL and other Internet Web site references, may change without notice. You bear the risk of
using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real
association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any
Microsoft product. You may copy and use this document for your internal, reference purposes.
2012 Microsoft Corporation. All rights reserved.

Implementing Persistent Cookies in SharePoint 2010 Products

July 2012

Implementing Persistent Cookies in SharePoint

Products
Microsoft Corporation
July 2012
Applies to: Microsoft SharePoint Server 2010, SharePoint
Foundation 2010, and Active Directory Federation Services
Summary: This paper describes best practices and scenario requirements for
implementing persistent cookies or session cookies within your organization
when using Microsoft SharePoint Products.

Authors and Contributors

Bassem Yacoube, Senior Consultant II, Microsoft Corporation
Steve Peschka, Principal Consultant, Microsoft Corporation

Content

Contents........................................................................................................................... 2
Overview of SharePoint 2010 persistent cookies..............................................................2
Session cookies........................................................................................................... 2
Persistent cookies........................................................................................................ 2
SharePoint authentication cookies.................................................................................... 3
Integrating with the Microsoft Office System..............................................................4
Workarounds to use with session cookies...................................................................5

Overview of SharePoint 2010 persistent cookies

A cookie is a small text file that a web site issues to help identify you to that
web site. Cookies are used to maintain state information as you navigate to
different pages on a web site or return to the web site at a later time. Cookies
are either stored in memory (session cookies) or on your hard disk (persistent
cookies).

Session cookies
Session cookies are used to store state information within a session. A browser
temporarily caches session cookies while a user is visiting the web site that
issues the session cookie. Session cookies are deleted from the cache when the
user closes the browser.

2012 Microsoft Corporation. All rights reserved.

To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 2

Implementing Persistent Cookies in SharePoint 2010 Products

July 2012

Persistent cookies
Persistent cookies are stored for a specified amount of time that is set by the
web server that hosts the web site when the web server passes the cookie to
the browser. Persistent cookies are used to store state information between
visits to a web site.
Persistent cookies outlast browser sessions. If a persistent cookie has its
lifetime set to one year, the initial value set in that cookie is sent back to the
server every time the user visits the site within that year. This functionality can
be used to record a vital piece of information such as how the user initially
accessed the web site. Because of this aspect of persistent cookie functionality,
persistent cookies are also called tracking cookies.

SharePoint authentication cookies

SharePoint supports both session cookies and persistent cookies. After a
SharePoint site validates a user's credentials, the web server creates a valid
authentication cookie and sends it to the browser with the originally requested
page. By default, SharePoint sites issue persistent cookies.
All applications that use the same cookie store share the persistent cookie, and
the cookie enables users to open documents in those applications without
entering user credentials again. SharePoint sites create persistent cookies with
a default time-out value of 10 hours for sites that use Windows claims or formsbased authentication claims. For SAML claims, SharePoint 2010 Products do not
have a default time-out value. When the cookie expires, client integration stops
working. At that point, if a user who is working on a document tries to save the
document, the user has to provide credentials again. If a browser is being used
to access the document, users might be prompted to re-enter their credentials.
If a SharePoint site is configured to use session cookies instead of persistent
cookies, the browser keeps the cookie in memory. Because session cookies are
stored in memory within the browser process, there are some inherent
limitations when you use session cookies, including:
The session cookie is retained only as long as the browser is open. When
the browser is closed, the cookie is destroyed along with everything else
in memory that the browser was using.
The session cookie belongs to the browser's application process and
cannot be shared with other processes. Office system applications run in
their own processes. Because of this, a session cookie that a user
generates when using a browser to log on to a web site cannot be shared
with Microsoft Word, for example.
A SharePoint on-premise authentication cookie stores the following attributes:
User Key
User Name
Expiry Date/Time
Is the Cookie Persistent
Audience Uri
2012 Microsoft Corporation. All rights reserved.
To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 3

Implementing Persistent Cookies in SharePoint 2010 Products

July 2012

Crypto Signature
A SharePoint online authentication cookie stores the following attributes:
User Key
User Name
Expiry Date/Time
Is the Cookie Persistent
Audience Uri
Is the cookie for a smart client
Crypto Signature
Using persistent cookies with SharePoint 2010 Products provides extended
functionality by supporting integration with the Microsoft Office system and
enabling features such as:

Open in Outlook

Export to Spreadsheet

Within SharePoint document libraries, persistent cookies enable features such as:

Edit in Word

Edit in Excel

Edit in PowerPoint

Connect To Outlook

Using persistent cookies with SharePoint 2010 Products also enables the following
enhancements:

If applications are using the same cookie store, multiple logon prompts are prevented.

Forms and sessions will continue to persist.

In some scenarios, session cookies might be preferred for security reasons. To configure a
SharePoint site to issue session cookies, use the following Windows PowerShell example:
Windows PowerShell Command
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
Iisreset

Integrating with the Microsoft Office System

SharePoint users who also have the Microsoft Office system applications installed experience a
high level of integration between the two products. However, many of these integration features
2012 Microsoft Corporation. All rights reserved.
To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 4

Implementing Persistent Cookies in SharePoint 2010 Products

July 2012

depend on persistent cookies. Without persistent cookies, some integration functionality does
not work.

Features that require persistent cookies:

Open in Explorer.

Connect to Outlook.

Connect to Office. Without persistent cookies, the SharePoint site folder on the file system
will not be populated.

Processes that have not implemented the Microsoft Office Forms Based Authentication
Protocol (MSOFBA) - the protocol that is used to establish a users identity with a remote
protocol server.
MSOFBA uses an HTML form to establish a users identity, without which browser access and
representational state transfer (REST) calls to SharePoint sites are not possible. Office client
applications (for example, Word and Excel) implement MSOFBA. For more information, see
[MS-OFBA]: Office Forms Based Authentication Protocol Specification
(http://msdn.microsoft.com/en-us/library/cc313069(office.12).aspx).

Any background job, for example a job that requires a login but cannot request credentials.

Workarounds to use with session cookies

As described, certain features only work with persistent cookies. If you use
session cookies, SharePoint users who try to access ribbon buttons or menus
that require persistent cookies might encounter errors. To reduce user confusion
about these issues, you can use workarounds to disable the features that are
not available. One option is to disable client integration. Another option is to
disable the display of ribbon components. If you disable client integration, users
will lose functionality beyond the scope of the limitations imposed by using
session cookies. For example, New Document functionality is supported if a
SharePoint site is configured to use session cookies but is not supported if client
integration is disabled. Therefore, disabling specific ribbon buttons or menus
might be preferable to disabling client integration.
Disabling Client Integration
One way to disable features that wont work when persistent cookies are not used is to disable
client integration. In the Central Administration web site, on the Authentication Provider page,
you can disable client integration by clearing the Enable Client Integration check box.
If the Enable Client Integration check box is cleared, the following functionality changes
occur:

Support for remote interfaces is turned off. That includes WebDAV, SOAP, and Microsoft
Office FrontPage remote procedure calls (RPC). Some functionality is not available, such as
web folders or the web services for accessing content in that site.
Some toolbar items are no longer displayed, including:

New Document

2012 Microsoft Corporation. All rights reserved.

To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 5

Implementing Persistent Cookies in SharePoint 2010 Products

Open in Outlook

Open In Windows Explorer

Export to Spreadsheet

Open with Database Program

The Explorer View option is hidden.

The Create an Access View option is hidden.

In picture libraries, the following functionality is removed:

Upload Multiple

Edit Picture

Download

Send To

July 2012

On the Edit Control Block (ECB) menu, the drop-down menu that appears when you click
items in document libraries, the following items are removed:

Edit in Word

Edit in Excel

Edit in PowerPoint

Discuss

Connect To Outlook

In slide libraries the following functionality is removed:

Publish Slide

Send to PowerPoint

Also, syncing SharePoint data with Microsoft Office Outlook no longer works.
When operating in this mode, users who work with documents in SharePoint libraries must rightclick items and choose to save a copy to disk. They can then edit and update the document, and
upload it and check it back in when they are finished editing.
Disabling ribbon options
The KB article, How to restrict SharePoint users from opening Document Libraries using
"Open in Windows Explorer" option (http://support.microsoft.com/kb/2285182) describes
how to disable the option that allows users to open a SharePoint document library folder in
Windows Explorer. The KB article also describes how to remove the "Connect to Outlook"
option. For sites that have already been created, a script similar to the one shown in the
following example will deactivate those options.
After installing the feature, as described in the following article: Install-SPFeature
(http://technet.microsoft.com/en-us/library/ff607825.aspx), use the following Windows
PowerShell command example to activate this feature on all existing sites under a specific URL:
Windows PowerShell Command
Add-PSSnapin "Microsoft.SharePoint.PowerShell"

2012 Microsoft Corporation. All rights reserved.

To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 6

Implementing Persistent Cookies in SharePoint 2010 Products

July 2012

$site = Get-SPSite -identity http://{siteurl}

$site | Get-SPWeb -limit all | ForEach-Object { Write-Host $_.Url; Enable-SPFeature
-Identity {featureid} -url $_.Url }
Where:

The featureid is the value that you specified in the id element in the Elements.Xml file of the
feature. In the previous example, the featureid would be RemoveRibbonButton. For more
information, see Enable-SPFeature (http://technet.microsoft.com/en-us/library/ff607803).

To ensure that newly created sites have these options disabled, you can use feature stapling to staple
the feature to site definitions. For more information on feature stapling, see Feature Stapling and
the FeatureActivated Event in Windows SharePoint Services 3.0
(http://msdn.microsoft.com/enus/library/ff382738(v=office.12).aspx#odcwss2007taFeatureStapleFeatureStapling).

Implementing persistent cookies on a public or shared computer

In a public or shared environment (for example, on a computer deployed as a kiosk), persistent
cookies might pose certain security risks. Some of the measures that can be taken to reduce
possible risks include:

Controlling access to SharePoint sites on computers in a shared environment by logging off

inactive users quickly.

To make persistent cookies perceived as more secure, you can shorten the lifetime of the
token that the identity provider issues and then set the value of the logon token expiration in
the SharePoint site to be less than that. For example, setting a 20 minute lifetime of the
token in the identity provider and then setting a 10 minute logon token expiration will trigger
a re-issuance of the fedauth cookie every 11 minutes, assuming the user is actively
accessing the SharePoint site. If the user is idle for 20 minutes, the maximum value, and
then tries to access a resource, the user will be redirected to the identity provider for
authentication. Depending on the corporate policy, users can configure the idle time they
want to allow and then configure the lifetime of the token issued by the identity provider and
logon token expiration in the SharePoint site.

For more information about how to make the identity provider issue SAML tokens with a
shorter lifetime (assuming ADFS is the identity provider used), see Update #2 in the
following blog post: Setting the Login Token Expiration Correctly for SharePoint 2010
SAML Claims Users (http://blogs.technet.com/b/speschka/archive/2010/08/09/settingthe-login-token-expiration-correctly-for-sharepoint-2010-saml-claims-users.aspx).

2012 Microsoft Corporation. All rights reserved.

To comment on this paper or request more documentation on these developer features, contact Office Developer
Documentation at ITSPdocs (ITSPdocs@microsoft.com).

Page 7