One of the biggest advantage of using SharePoint as a Document Management and collaboration environment is that a robust security and permissions structure is built-in to the application itself. Authenticating and authorizing users is a fairly straightforward task, and administration of security permissions is simplified. Too often, however, security for SharePoint stops there, and organizations don’t pay enough attention to all of the other considerations that are part of a SharePoint Security stack, and more often than not don’t properly build them into a deployment. This includes such diverse categories including Edge, Transport, Infrastructure, Data, and Rights Management Security, all areas that are often neglected but are nonetheless extremely important. This session discusses the entire stack of Security within SharePoint, from best practices around managing permissions and ACLs to comply with Role Based Access Control, to techniques to secure inbound access to externally-facing SharePoint sites. The session is designed to be comprehensive, and includes all major security topics in SharePoint and a discussion of various real-world designs that are built to be secure.

1. Platinum Sponsor
Gold Sponsors

2. Michael Noel
SHAREPOINT SECURITY IN AN
INSECURE WORLD
UNDERSTANDING THE FIVE LAYERS OF SHAREPOINT
SECURITY

3. MICHAEL NOEL
• Author of SAMS Publishing titles “SharePoint 2007 Unleashed,” the upcoming
“SharePoint 2010 Unleashed,” “SharePoint 2003 Unleashed”, “Teach Yourself
SharePoint 2003 in 10 Minutes,” “Windows Server 2008 R2 Unleashed,” “Exchange
Server 2010 Unleashed”, “ISA Server 2006 Unleashed”, and many other titles .
• Partner at Convergent Computing (www.cco.com / +1(510)444-5700) – San
Francisco, U.S.A. based Infrastructure/Security specialists for
SharePoint, AD, Exchange, Security

4. SHAREPOINT SECURITY
LAYERS OF SECURITY IN A SHAREPOINT ENVIRONMENT
• 1: Infrastructure Security
• Physical Security
• Best Practice Service Account Setup
• Kerberos Authentication
• 2: Data Security
• Role Based Access Control (RBAC)
• Transparent Data Encryption (TDE) of SQL Databases
• Antivirus
• 3: Transport Security
• Secure Sockets Layer (SSL) from Client to Server
• IPSec from Server to Server
• 4: Edge Security
• Inbound Internet Security (Forefront UAG/TMG)
• 5: Rights Management

5. INFRASTRUCTURE
SECURITY
Layer

6. LAYER 1: INFRASTRUCTURE SECURITY
SAMPLE LIST OF SERVICE ACCOUNTS
Service Account Name Role of Service Account Special Permissions
COMPANYABCSRV-SP-Setup SharePoint Installation Account Local Admin on all SP Servers (for installs)
COMPANYABCSRV-SP-SQL SQL Service Account(s) – Should be separate Local Admin on Database Server(s)
admin accounts from SP accounts. (Generally, some exceptions apply)
COMPANYABCSRV-SP-Farm SharePoint Farm Account(s) – Can also be N/A
standard admin accounts. RBAC principles apply
ideally.
COMPANYABCSRV-SP-Search Search Account N/A
COMPANYABCSRV-SP-Content Default Content Access Account Read rights to any external data sources to be
crawled
COMPANYABCSRV-SP-Prof Default Profiles Access Account Member of Domain Users (to be able to read
attributes from users in domain) and „Replicate
Directory Changes‟ rights in AD.
COMPANYABCSRV-SP-AP-SPCA Application Pool Identity account for DBCreator and Security Admin on SQL.
SharePoint Central Admin. Create and Modify contacts rights in OU
used for mail.
COMPANYABCSRV-SP-AP-Data Application Pool Identity account for the Content N/A
related App Pool (Portal, MySites, etc.) Additional
as needed for security.

7. LAYER 1: INFRASTRUCTURE SECURITY
ENABLE KERBEROS
• When creating any Web Applications in Classic-mode, USE KERBEROS.
It is much more secure and also faster with heavy loads as the SP server
doesn‟t have to keep asking for auth requests from AD.
• Kerberos auth does require extra steps, which makes people shy away
from it, but once configured, it improves security considerably and can
improve performance on high-load sites.
• Should also be configured on SPCA Site! (Best Practice = Configure
SPCA for NLB, SSL, and Kerberos (i.e. https://spca.companyabc.com)

8. LAYER 1: INFRASTRUCTURE SECURITY
KERBEROS STEP 1: CREATE THE SERVICE PRINCIPAL NAMES
• Use the setspn utility to create Service Principle Names in AD, the
following syntax for example:
• Setspn.exe -A HTTP/mysite.companyabc.com DOMAINNAMEMYSiteAppAccount
• Setspn.exe -A HTTP/mysite DOMAINNAMEMYSITEAppAccount
• Setspn.exe -A HTTP/home.companyabc.com DOMAINNAMEHOMEAppAccount
• Setspn.exe -A HTTP/sp DOMAINNAMEHOMEAppAccount

9. LAYER 1: INFRASTRUCTURE SECURITY
KERBEROS STEP 2: ENABLE KERBEROS BETWEEN SP AND SQL
• Use setspn to create SPNs for SQL Service Account
• SPNs need to match the name that SharePoint uses to
connect to SQL (Ideally SQL Alias, more on this later)
• Syntax similar to following:
• Setspn.exe -A MSSQLSvc/spsql:1433 COMPANYABCSRV-SQL-DB
• Setspn.exe –A MSSQLSvc/spsql.companyabc.com:1433 COMPANYABCSRV-
SQL-DB
• MSSQLSvc = Default instance, if named instance, specify the name
instead
• In this example, SRV-SQL-DB is the SQL Admin account

10. LAYER 1: INFRASTRUCTURE SECURITY
KERBEROS STEP 3: ALLOW ACCOUNTS TO DELEGATE (OPTIONAL)
• Required only for Excel
Services and other
impersonation applications.
• On all SP Computer accounts
and on the Application Identity
accounts, check the box in
ADUC to allow for delegation.
• In ADUC, navigate to the
computer or user account, right-
click and choose Properties.
• Go to the Delegation tab
• Choose Trust this
user/computer for delegation to
any service (Kerberos)

11. LAYER 1: INFRASTRUCTURE SECURITY
KERBEROS STEP 4: ENABLE KERBEROS ON WEB APPLICATION
• Go to Application Management – Authentication Providers
• Choose the appropriate Web Application
• Click on the link for „Default‟ under Zone
• Change to Integrated Windows Authentication - Kerberos
(Negotiate)
• Run iisreset /noforce from the command prompt
• If creating Web App from scratch, this step may be unnecessary if
you choose Negotiate from the beginning

12. DATA SECURITY
Layer

13. LAYER 2: DATA SECURITY
ROLE BASED ACCESS CONTROL (RBAC)
• Role Groups defined within Active Directory (Universal Groups) –
i.e. „Marketing,‟ „Sales,‟ „IT,‟ etc.
• Role Groups added directly into SharePoint „Access Groups‟
such as „Contributors,‟ „Authors,‟ etc.
• Simply by adding a user account into the associated Role Group,
they gain access to whatever rights their role requires.
User1
Role SharePoint
Group Group
User2

14. LAYER 2: DATA SECURITY
SQL TRANSPARENT DATA ENCRYPTION (TDE)
• SQL Server 2008 and 2008 R2 Enterprise Edition Feature
• Encrypts SQL Databases Transparently, SharePoint is
unaware of the encryption and does not need a key
• Encrypts the backups of the database as well
(c) 2011 Microsoft. All rights

15. LAYER 2: DATA SECURITY
TDE VS. CELL LEVEL ENCRYPTION
• Available with either SQL 2005 or SQL 2008
• Encrypts individual cells in a database
• Requires a password to access the cell
• Requires that columns be changed from their original data
type to varbinary
• Advantage is that only specific info is encrypted
• Disadvantage is that you cannot use this for SharePoint
Databases
(c) 2011 Microsoft. All rights

16. LAYER 2: DATA SECURITY
TDE VS. FILE LEVEL ENCRYPTION
• Two forms, older Encrypting File System (EFS) and
Bitlocker
• EFS encrypts data at the File Level
• Bitlocker encrypts data at the Volume Level
• Bitlocker Encrypts every file on the disk, not just database
files
• Could be used together with TDE
(c) 2011 Microsoft. All rights

17. LAYER 2: DATA SECURITY
SQL TRANSPARENT DATA ENCRYPTION (TDE) LIMITATIONS
• Does not encrypt the Communication Channel (IPSec can be
added)
• Does not protect data in memory (DBAs could access)
• Cannot take advantage of SQL 2008 Backup Compression
• TempDB is encrypted for the entire instance, even if only one
DB is enabled for TDE, which can have a peprformance effect
for other DBs
• Replication or FILESTREAM data is not encrypted when TDE
is enabled (i.e. RBS BLOBs not encrypted)
(c) 2011 Microsoft. All rights

18. Key and OS Level Hierarchy
Windows Cert Data Protection API (DPAPI)
DPAPI Encrypts SMK
SQL Instance Level Service Master Key
SMK encrypts the DMK for master DB
master DB Level Database Master Key
DMK creates Cert in master DB
master DB Level Certificate
Certificate Encrypts DEK in Content DB
Content DB Level Database Encryption Key
DEK used to encrypt Content DB
(c) 2011 Microsoft. All rights reserved.

19. LAYER 2: DATA SECURITY
SQL TDE STEP 1: CREATING THE DATABASE MASTER KEY (DMK)
• Symmetric key used to protect private keys and asymmetric
keys
• Protected itself by Service Master Key (SMK), which is
created by SQL Server setup
• Use syntax as follows:
• USE master;
• GO
• CREATE MASTER KEY ENCRYPTION BY PASSWORD =
'CrypticTDEpw4CompanyABC';
• GO
(c) 2011 Microsoft. All rights

20. LAYER 2: DATA SECURITY
SQL TDE STEP 2: CREATING THE TDE CERTIFICATE
• Protected by the DMK
• Used to protect the database encryption key
• Use syntax as follows:
USE master;
GO
CREATE CERTIFICATE CompanyABCtdeCert WITH SUBJECT = 'CompanyABC TDE
Certificate' ;
GO
(c) 2011 Microsoft. All rights

21. LAYER 2: DATA SECURITY
SQL TDE STEP 3: BACKUP THE MASTER KEY
• Without a backup, data can be lost
• Backup creates two files, the Cert backup and the Private Key File
• Use following syntax:
USE master;
GO
BACKUP CERTIFICATE CompanyABCtdeCert TO FILE =
'c:BackupCompanyABCtdeCERT.cer'
WITH PRIVATE KEY (
FILE = 'c:BackupCompanyABCtdeDECert.pvk',
ENCRYPTION BY PASSWORD = 'CrypticTDEpw4CompanyABC!' );
GO
(c) 2011 Microsoft. All rights

22. LAYER 2: DATA SECURITY
SQL TDE STEP 4: CREATING THE DATABASE ENCRYPTION KEY (DEK)
• DEK is used to encrypt specific database
• One created for each database
• Encryption method can be chosen for each DEK
• Use following syntax:
USE SharePointContentDB;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE CompanyABCtdeCert
GO
(c) 2011 Microsoft. All rights

23. LAYER 2: DATA SECURITY
SQL TDE STEP 5: ENABLE TDE ON THE DATABASE(S)
• Data encryption will begin after running command
• Size of DB will determine time it will take, can be lengthy
and could cause user blocking
• Use following syntax:
USE SharePointContentDB
GO
ALTER DATABASE SharePointContentDB
SET ENCRYPTION ON
GO
(c) 2011 Microsoft. All rights

24. LAYER 2: DATA SECURITY
SQL TDE STEP 6: MONITOR THE TDE ENCRYPTION PROGRESS
• State is Returned
• State of 2 = Encryption Begun
• State of 3 = Encryption Complete
• Use following syntax:
USE SharePointContentDB
GO
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO
(c) 2011 Microsoft. All rights

25. LAYER 2: DATA SECURITY
SQL TDE: RESTORING A TDE DATABASE TO ANOTHER SERVER
• Step 1: Create new Master Key on Target Server (Does not need to match source master key)
• Step 2: Backup Cert and Private Key from Source
• Step 3: Restore Cert and Private Key onto Target (No need to export the DEK as it is part of
the backup)
USE master;
GO
CREATE CERTIFICATE CompanyABCtdeCert
FROM FILE = 'C:RestoreCompanyABCtdeCert.cer'
WITH PRIVATE KEY (
FILE = 'C:RestoreCompanyABCtdeCert.pvk'
, DECRYPTION BY PASSWORD = 'CrypticTDEpw4CompanyABC!'
)
• Step 4: Restore DB
(c) 2011 Microsoft. All rights

26. (c) 2011 Microsoft. All rights

27. LAYER 2: DATA SECURITY
SHAREPOINT ANTIVIRUS

29. LAYER 2: DATA SECURITY
SHAREPOINT ANTIVIRUS VSAPI
• Realtime scanning only uses the VSAPI
• Realtime Scan Settings are Administered through the
SharePoint Central Admin Tool
• Realtime Options are grayed out in the ForeFront Admin Console

30. LAYER 2: DATA SECURITY
SHAREPOINT ANTIVIRUS: FPS KEYWORD AND FILE FILTERING
• Look for specific
keywords (sensitive
company
info, profanity, etc.)
• Block
• Simply detect and notify
• Create Filter List
• Add Keywords, either
manually or bulk as lines
in a text file

31. LAYER 2: DATA SECURITY
SHAREPOINT ANTIVIRUS: FPS PROFANITY FILTERS
• New Profanity lists in 11 languages
available in SP2
• (Run KeywordInstaller.msi to install)
• Import the lists into FF from Program
FilesMicrosoft Forefront
SecuritySharePointDataExample
Keywords

33. TRANSPORT SECURITY
Layer

34. LAYER 3: TRANSPORT SECURITY
CLIENT TO SERVER: USING SECURE SOCKETS LAYER (SSL)
ENCRYPTION
• External or Internal Certs highly recommended
• Protects Transport of content
• 20% overhead on Web Servers
• Can be offloaded via SSL offloaders if needed
• Don‟t forget for SPCA as well!

35. LAYER 3: TRANSPORT SECURITY
SERVER TO SERVER: USING IPSEC TO ENCRYPT TRAFFIC
• By default, traffic between SharePoint Servers (i.e.
Web and SQL) is unencrypted
• IPSec encrypts all packets sent between servers in a
farm
• For very high security scenarios when all possible
data breaches must be addressed

36. EDGE SECURITY
Layer

37. LAYER 4: EDGE SECURITY
FOREFRONT UNIFIED ACCESS GATEWAY (UAG) 2010

39. LAYER 4: EDGE SECURITY
UAG COMPARISON WITH FOREFRONT TMG
Capability TMG 2010 UAG
2010
Publish Web applications using HTTPS X X
Publish internal mobile applications to roaming mobile devices X X
Layer 3 firewall X X*
Outbound scenarios support X X*
Array support X
Globalization and administration console localization X
Wizards and predefined settings to publish SharePoint sites and Exchange X X
Wizards and predefined settings to publish various applications X
Active Directory Federation Services (ADFS) support X
Rich authentication (for example, one-time password, forms-based, smart card) X X
Application protection (Web application firewall) Basic Full
Endpoint health detection X
Information leakage prevention X
Granular access policy X
Unified Portal X

40. RIGHTS MANAGEMENT
Layer

41. LAYER 5: RIGHTS MANAGEMENT
ACTIVE DIRECTORY RIGHTS MANAGEMENT SERVICES (AD RMS)
• AD RMS is a form of Digital Rights Management (DRM)
technology, used in various forms to protect content
• Used to restrict activities on files AFTER they have been
accessed:
• Cut/Paste
• Print
• Save As…
• Directly integrates with SharePoint DocLibs

42. LAYER 5: RIGHTS MANAGEMENT
HOW AD RMS WORKS
1. On first use, authors receive
client licensor certificate from
RMS server
2. Author creates content and
assigns rights
3. File is distributed to
recipient(s)
4. Recipient opens file, and
their RMS client contacts
server for user validation and
to obtain a license
5. Application opens the file
and enforces the restrictions

43. LAYER 5: RIGHTS MANAGEMENT
INSTALLING AD RMS – KEY STORAGE
• Select Cluster Key Storage
• CSP used for advanced scenarios

44. LAYER 5: RIGHTS MANAGEMENT
INSTALLING AD RMS – CREATING THE CLUSTER NAME

45. LAYER 5: RIGHTS MANAGEMENT
INSTALLING AD RMS – USING AN SSL CERT FOR TRANSPORT ENCRYPTION

46. LAYER 5: RIGHTS MANAGEMENT
ALLOWING SHAREPOINT TO USE AD RMS
• By default, RMS server is configured to only
allow the local system account of the RMS
server or the Web Application Identity
accounts to access the certificate pipeline
directly
• SharePoint web servers and/or Web
Application Service Accounts need to be
added to this security list
• Add the RMS Service Group, the machine
account(s) of the SharePoint Server and the
Web App Identity accountswith Read and
Excecute permissions to the
ServerCertification.asmx file in the
%systemroot%inetpubwwwroot_wmcsCerti
fication folder on the RMS server

48. LAYER 5: RIGHTS MANAGEMENT
CLIENT ACCESSING AD RMS DOCUMENTS
• RMS-enabled client, when accessing document in doclib,
will access RMS server to validate credentials

49. LAYER 5: RIGHTS MANAGEMENT
CLIENT ACCESSING AD RMS DOCUMENTS
• Effective permissions
can be viewed from the
document
• The RMS client will
enforce the restrictions

50. Thank you to our Sponsors
Gold Sponsors
Silver Sponsors
Bronze Sponsors

51. Michael Noel
Twitter: @MichaelTNoel
www.cco.com
Slides: slideshare.net/michaeltnoel