Wss Security

Windows SharePoint Services Security
Microsoft Corporation
Published: June 2007
Author: Windows SharePoint Services IT User Assistance (o12ITdx@microsoft.com)
Abstract
This guide describes how security is implemented in Microsoft Windows SharePoint Services 3.0. The audiences for
this guide include information architects, IT generalists, and program managers who are planning to make Windows
SharePoint Services 3.0 sites accessible from the Internet.
The content in this book is a copy of selected content in the Windows SharePoint Services technical library
(http://go.microsoft.com/fwlink/?LinkId=81199) as of the publication date. For the most current content, see the
technical library on the Web.
This guide includes the following parts:
Part 1 — Plan site and content security
Part 1 of this guide describes the permissions that control access to your sites and the content in your sites. It also
discusses security related to implementing search.
Part 2 — Plan for authentication
Part 2 of this guide describes the authentication methods that are supported by Windows SharePoint Services 3.0,
discusses the authentication configuration settings that need to be planned for individual Web applications, and
includes sample configuration settings for several common forms authentication and Web single sign-on (SSO)
authentication providers.
Part 3 — Deploying Windows SharePoint Services 3.0 in a secure manner
Part 3 of this guide describes practical secure configurations for specific server roles. The guidance for each server role
includes recommended secure settings for the network, the operating system, and the applications that are installed,
including Internet Information Services (IIS), the Microsoft.NET Framework, and Microsoft SQL Server database
software. Part 3 also addresses security requirements and recommendations for planning for security roles and for
configuring administrative and service accounts.
The content in this book is a copy of selected content in the Windows SharePoint Services technical library
(http://go.microsoft.com/fwlink/?LinkId=81199) as of the date above. For the most current content, see the technical
library on the Web.

1

The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft
must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO
WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN
THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without
limiting the rights under copyright, no part of this document may be reproduced, stored
in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,
without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectual property rights covering subject matter in this document. Except as expressly
provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places and events depicted herein are fictitious, and no
association with any real company, organization, product, domain name, email address,
logo, person, place or event is intended or should be inferred.

© 2007 Microsoft Corporation. All rights reserved.

Microsoft, Access, Active Directory, Excel, Groove, InfoPath, Internet Explorer,
OneNote, Outlook, PowerPoint, SharePoint, SQL Server, Visio, Windows, Windows
Server, and Windows Vista are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of
their respective owners.

2

Contents
I. Plan site and content security........................................................................................................................7

Plan site and content security (Windows SharePoint Services).......................................................................8

Determine permission levels and groups to use (Windows SharePoint Services)...........................................9
Review available default groups...................................................................................................................9
Review available permission levels............................................................................................................11
Determine whether you need additional permission levels or groups........................................................11
Do you need custom groups?..................................................................................................................11
Do you need custom permission levels?.................................................................................................12
Worksheet...................................................................................................................................................13

Define custom permission levels (Windows SharePoint Services)................................................................14
Customize an existing permission level......................................................................................................14
Copy an existing permission level..............................................................................................................14
Create a permission level............................................................................................................................15

Choose which security groups to use (Windows SharePoint Services).........................................................16
Determine which Windows security groups and accounts to use for granting access to sites...................16
Decide whether to use all authenticated users............................................................................................17
Decide whether to allow access to anonymous users.................................................................................17
Worksheet...................................................................................................................................................18

Choose administrators and owners for the administration hierarchy (Windows SharePoint Services).........19
Levels of administration.............................................................................................................................19
Worksheet...................................................................................................................................................20

Plan for search (Windows SharePoint Services)............................................................................................21
About search in Windows SharePoint Services version 3..........................................................................21
Plan for search administration....................................................................................................................22
Link to worksheet.......................................................................................................................................22

Security considerations for search (Windows SharePoint Services)..............................................................23
Sharing data across Web parts....................................................................................................................23
Exclude content from a crawl.....................................................................................................................23

II. Plan for authentication...............................................................................................................................25

Plan authentication methods (Windows SharePoint Services).......................................................................26
About authentication...................................................................................................................................26
Supported authentication methods..............................................................................................................26
Authentication of system accounts..................................................................................................28
Configure authentication.............................................................................................................................29
Configure authentication for SharePoint Web applications............................................................29
Connect to identity management systems that are external or not based on Windows...................34
Enabling Anonymous Access..........................................................................................................38
Using different authentication methods to access a site..................................................................38
Plan authentication for crawling content....................................................................................................39
Order in which the crawler accesses zones......................................................................................40
3

Authentication scenario...................................................................................................................42
Crawling host-named site collections..............................................................................................43
Planning zones for your authentication design.......................................................................................43
Choose methods of authentication allowed in your environment...............................................................44
Recommendations for specific security environments....................................................................44
Recommendations and tradeoffs for authentication methods..........................................................45
Management of user identity information.......................................................................................47
Management of user accounts.........................................................................................................49
Browser support...............................................................................................................................50
Worksheet...................................................................................................................................................51

Plan authentication settings for Web applications (Windows SharePoint Services)......................................53
Plan authentication settings.........................................................................................................................53
Authentication type.................................................................................................................................54
Anonymous access..................................................................................................................................55
Client integration.....................................................................................................................................55
Expected behaviors when client integration is disabled..................................................................55
Behaviors of specific authentication methods.................................................................................56
Using the Windows Vista operating system with Internet Explorer 7............................................58
Testing client integrations settings..................................................................................................58
Settings for ASP.NET forms authentication and Web SSO....................................................................58
Plan authentication exclusions....................................................................................................................59
Worksheet...................................................................................................................................................61

Authentication samples (Windows SharePoint Services)...............................................................................62
SQL membership provider..........................................................................................................................62
Active Directory membership provider......................................................................................................65
LDAP membership provider.......................................................................................................................67
Web SSO with AD FS................................................................................................................................69
SingleSignOnMembershipProvider/SingleSignOnRoleProvider....................................................70
SingleSignOnMembershipProvider2/SingleSignOnRoleProvider2................................................71

III. Deploying 2nd_OSS_12 in a secure manner............................................................................................74

Plan for and design security (Windows SharePoint Services)........................................................................75

Choose your security environment (Windows SharePoint Services).............................................................78
Internal team or department........................................................................................................................78
Internal IT-hosted........................................................................................................................................79
External secure collaboration......................................................................................................................79
External anonymous access........................................................................................................................80

Review the secure topology design checklists (Windows SharePoint Services)...........................................81
Server topology design checklist................................................................................................................81
Networking topology design checklist........................................................................................................82
Logical architecture design checklist..........................................................................................................82
Operating system design checklist..............................................................................................................83

Plan for secure communication within a server farm (Windows SharePoint Services).................................84
Plan server-to-server communication.........................................................................................................84
IPsec........................................................................................................................................................86
SSL..........................................................................................................................................................86
Scenarios to consider for SSL.............................................................................................................86
Plan client-server communication...............................................................................................................87
4

Plan for using SSL......................................................................................................................................87

Plan security hardening for server roles within a server farm (Windows SharePoint Services)....................89
About security hardening............................................................................................................................89
Application server recommendations.........................................................................................................91
Secure communication with the Microsoft SQL Server database..............................................................91
Blocking the standard SQL Server ports.................................................................................................92
Configuring SQL Server database instances to listen on a nonstandard port.........................................93
Configuring SQL client aliases...............................................................................................................93
Hardening steps.......................................................................................................................................93
Configure SQL Server.........................................................................................................................93
Configure a SQL Server 2000 instance to listen on a nondefault port............................................93
Configure a SQL Server 2005 instance to listen on a nondefault port............................................94
Configure Windows Firewall..............................................................................................................96
Configure Windows Firewall to block default SQL Server listening ports.....................................96
Configure Windows Firewall to open manually assigned ports......................................................96
Configure a SQL client alias...............................................................................................................96
Configure a SQL client alias............................................................................................................96
Test the SQL client alias..................................................................................................................97
File and Printer Sharing service requirements............................................................................................97
Service requirements for e-mail integration...............................................................................................98
SMTP service...................................................................................................................................98
Microsoft SharePoint Directory Management Service....................................................................98
Windows SharePoint Services services......................................................................................................99
Accounts and groups.................................................................................................................................100
Web.config file.........................................................................................................................................100
Secure snapshot additions.........................................................................................................................100
Securing your network snapshot additions....................................................................................101
Securing your Web server snapshot additions...............................................................................101
Securing your database server snapshot additions.........................................................................104

Plan security hardening for extranet environments (Windows SharePoint Services)..................................106
Network topology.....................................................................................................................................106
Domain trust relationships........................................................................................................................107
Server farm resides in the perimeter network................................................................................107
Server farm is split between the perimeter network and the corporate network...........................107
Communication with server-farm roles....................................................................................................110
Communication between server roles............................................................................................110
Communication between administrator workstations and Central Administration.......................111
Communication with infrastructure server roles.......................................................................................113
Active Directory domain controller...............................................................................................113
DNS server.....................................................................................................................................113
SMTP service.................................................................................................................................113
Active Directory communication between network domains...................................................................114

Plan secure configurations for Windows SharePoint Services features.......................................................115
Recommendations for Windows SharePoint Services features................................................................115

Plan security for an internal team or department environment (Windows SharePoint Services)................118
Secure design checklist.............................................................................................................................118
Plan security hardening for server roles....................................................................................................119
Plan secure configurations for Windows SharePoint Services features...................................................120

5

Plan security for an internal IT-hosted environment (Windows SharePoint Services)................................122

Plan security for an external secure collaboration environment (Windows SharePoint Services)...............124
Protect back-end servers...........................................................................................................................124
Secure client-server communication.........................................................................................................125
Secure the Central Administration site.....................................................................................................125

Plan for security roles (Windows SharePoint Services)...............................................................................127
Farm-level administration.........................................................................................................................127
Farm administrators...............................................................................................................................128
Server-level administrators...................................................................................................................129
Site-level administration...........................................................................................................................130
Site collection administrators........................................................................................................131
Site owners.....................................................................................................................................131
Worksheet.................................................................................................................................................132
See Also.........................................................................................................................................132

Plan for administrative and service accounts (Windows SharePoint Services)...........................................133
About administrative and service accounts...............................................................................................133
Server farm-level accounts....................................................................................................................134
Windows SharePoint Services Search accounts....................................................................................134
Additional application pool identity accounts.......................................................................................135
Single server standard requirements.........................................................................................................135
Server farm requirements..........................................................................................................................136
Least-privilege administration requirements when using domain user accounts.....................................137
Least-privilege administration requirements when using SQL authentication.........................................137
Setup and configuration........................................................................................................................137
Creating service and administration accounts.......................................................................................138
Creating SQL Server logins..................................................................................................................138
Least-privilege administration requirements when connecting to pre-created databases.........................139
Creating service and administration accounts.......................................................................................140
Creating SQL Server logins..................................................................................................................140
Technical reference: Account requirements by scenario..........................................................................140
Single server standard requirements.....................................................................................................141
Server farm standard requirements.......................................................................................................142
Least-privilege administration requirements when using domain user accounts..................................144
Least-privilege administration requirements when using SQL authentication.....................................148
Least-privilege administration requirements when connecting to pre-created databases.....................153
See Also.........................................................................................................................................159

6

I. Plan site and content security

7

Plan site and content security (Windows
SharePoint Services)
There are several elements that make up security for your environment. One of these
elements is the permissions that control access to your sites and the content in your sites.
A new security model and new security features (such as SharePoint® groups to control
membership, and item- and document-level permissions) make it easy to control who has
access to what content in your sites. This chapter explains how security for sites and site
content works, and it guides you through making choices about site security.
Another element integral to the security of your environment is how you structure
security at the Web application level — choosing authentication methods and specifying
the encryption methods to use. For more information, see Plan for and design security
(Windows SharePoint Services).
In this chapter:
• Plan site security [Windows SharePoint Services] helps you understand the
elements of site security and how permissions are assigned, and it helps you
choose which levels of site security to use in your site collection or subsite.
• Determine permission levels and groups to use (Windows SharePoint Services) reviews the
available permission levels and groups, and it helps you determine whether you
need additional permission levels or groups.
• Define custom permission levels (Windows SharePoint Services) helps you create any
custom permission levels you might need.
• Choose which security groups to use (Windows SharePoint Services) helps you determine
which Microsoft® Windows® security groups and user accounts to use to grant
access to sites, decide whether to use the All Authenticated Users group, and
decide whether to allow anonymous access.
• Choose administrators and owners for the administration hierarchy (Windows SharePoint
Services) defines the levels of administration from the server level to the subsite
level, and it helps you choose the administrators you need for each level.

8

Determine permission levels and groups to use
(Windows SharePoint Services)
In this article:
• Review available default groups
• Review available permission levels
• Determine whether you need additional permission levels or groups
• Worksheet
The most important decision about your site and content security in Microsoft Windows
SharePoint Services 3.0 is to decide how to categorize your users and what permission
levels to assign.
There are several default SharePoint groups that are intended to help you categorize your
users based on the types of actions they need to perform, but you might have unique
requirements or other ways of looking at sets of users. Likewise, there are default
permission levels, but they might not always align exactly with the tasks that your groups
need to perform.
In this article, you review the default groups and permission levels and decide whether to
use them as they are, customize them, or create different groups and permission levels.

Review available default groups
With SharePoint groups, you manage sets of users rather than individual users.
SharePoint groups can be composed of many individual users, can hold a single Windows
security group, or can be some combination of the two. SharePoint groups confer no
specific rights to the site; they are merely a means to contain a set of users. Depending on
the size and complexity of your organization or Web site, you can organize your users
into several groups, or just a few.
The default SharePoint groups that are created for sites in Windows SharePoint Services
3.0 are listed in the following table.

Group name Default permission level

<Site name> Visitors Read

<Site name> Members Contribute

9

Group name Default permission level

<Site name> Owners Full Control

In addition, the following special users and groups are available for higher-level
administration tasks:
• Site collection administrators You can designate one or more users as
primary and secondary site collection administrators. These users are recorded in
the database as the contacts for the site collection, have full control of all sites
within the site collection, can audit all site content, and receive any administrative
alerts (such as verifying whether the site is still in use). Generally, you designate
site collection administrators when you create the site, but you can change them
as needed by using the Central Administration site or Site Settings pages.
• Farm administrators Controls which users can manage server and server
farm settings. The Farm Administrators group replaces the need for adding users
to the Administrators group for the server, or to the SharePoint Administrators
group that was used in Windows SharePoint Services version 2.0. Farm
administrators have no access to site content by default; they must take ownership
of the site to view any content. They do this by adding themselves as site
collection administrators, which action is recorded in the audit logs. The Farm
Administrators group is used in Central Administration only, and is not available
for any sites.
• Administrators Members of the Administrators group on the local server
can perform all farm administrator actions and more, including:
• Installing new products or applications.
• Deploying Web Parts and new features to the global assembly cache.
• Creating new Web applications and new IIS Web sites.
• Starting services.
Like the Farm Administrators group, members of the Administrators group on the
local server have no access to site content, by default.
After you identify the groups you need, determine the permission levels to assign to each
group on your site.

Worksheet action

Use the Custom permission levels and groups worksheet
(http://go.microsoft.com/fwlink/?LinkId=73133&clcid=0x409)
to record any groups you need to create.

10

Review available permission levels
The ability to view, change, or manage a particular site is determined by the permission
level that you assign to a user or group. This permission level controls all permissions for
the site and for any subsites, lists, document libraries, folders, and items or documents
that inherit the site's permissions. Without the appropriate permission levels, your users
might not be able to perform their tasks, or they might be able to perform tasks that you
did not intend them to perform.
By default, the following permission levels are available:
• Limited Access Includes permissions that allow users to view specific lists,
document libraries, list items, folders, or documents when given permissions.
• Read Includes permissions that allow users to view items on the site pages.
• Contribute Includes permissions that allow users to add or change items on
the site pages or in lists and document libraries.
• Design Includes permissions that allow users to change the layout of site
pages by using the browser or Microsoft Office SharePoint Designer 2007.
• Full Control Includes all permissions.
For more information about permissions that are included in the default permission
levels, see User permissions and permission levels.

Determine whether you need additional permission
levels or groups
The default groups and permission levels are designed to provide a general framework
for permissions, covering a wide range of organization types and roles within those
organizations. However, they might not map exactly to how your users are organized or
to the variety of tasks that your users perform on your sites. If the default groups and
permission levels do not suit your organization, you can create custom groups, change the
permissions included in specific permission levels, or create custom permission levels.

Do you need custom groups?
The decision to create custom groups is fairly straightforward and has little impact on
your site's security. Essentially, you should create custom groups instead of using the
default groups if any of the following applies:
• You have more (or fewer) user roles within your organization than are
apparent in the default groups. For example, if in addition to Designers, you have
a set of people who are tasked with publishing content to the site, you might want
to create a Publishers group.
11

• There are well-known names for unique roles within your organization that
perform very different tasks in the sites. For example, if you are creating a public
site to sell your organization's products, you might want to create a Customers
group that replaces Visitors or Viewers.
• You want to preserve a one-to-one relationship between Windows security
groups and the SharePoint groups. (For example, your organization has a security
group for Web Site Managers, and you want to use that name as a group name for
easy identification when managing the site).
• You prefer other group names.

Do you need custom permission levels?
The decision to customize permission levels is less straightforward than the decision to
customize SharePoint groups. If you customize the permissions assigned to a particular
permission level, you must keep track of that change, verify that it works for all groups
and sites affected by that change, and ensure that the change does not negatively affect
your security or your server capacity or performance.
For example, regarding security, if you customize the Contribute permission level to
include the Create Subsites permission that is typically part of the Full Control
permission level, Contributors can create and own subsites, potentially inviting malicious
users to their subsites or posting unapproved content. Or, regarding capacity, if you
change the Read permission level to include the Create Alerts permission that is typically
part of the Contribute permission level, all members of the Visitors group can create
alerts, which might overload your servers.
You should customize the default permission levels if either of the following applies:
• A default permission level includes all permissions except one that your users
need to do their jobs, and you want to add that permission.
• A default permission level includes a permission that your users do not need.
Note
You should not customize the default permission levels if your organization
has security or other concerns about a particular permission and wants to
make that permission unavailable for all users assigned to the permission level
or levels that include that permission. In this case, you should turn off this
permission for all Web applications in your server farm, rather than change all
of the permission levels. To manage permissions for a Web application, in
Central Administration, on the Application Management page, in the
Application Security section, click User permissions for Web application.
If you need to make several changes to a particular permission level, it is better to create
a custom permission level that includes all of the permissions you need.
12

You might want to create additional permission levels if any of the following applies:
• You want to exclude several permissions from a particular permission level.
• You want to define a unique set of permissions for a new permission level.
To create a permission level, you can copy an existing permission level and then make
changes, or you can create a permission level and then select the permissions that you
want to include.
Note
Some permissions are dependent on other permissions. If you clear a permission
that another permission depends on, the other permission is also cleared.

Worksheet action

Use the Custom permission levels and groups worksheet
to record any permission levels you want to customize or
create.

Worksheet
Use the following worksheet to determine permission levels and groups to use:
• Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/?
LinkId=73133&clcid=0x409)

13

Define custom permission levels (Windows
In this article:
• Customize an existing permission level
• Copy an existing permission level
• Create a permission level
After you have determined that you need custom permission levels and you have decided
what permissions to include in the new permission level, you can create a custom
permission level. Permission levels can be created for a site or site collection. You can
create a custom permission level by using any of the three procedures in this article.

Customize an existing permission level
If the custom permission level that you want is nearly identical to an existing default
permission level and you don't need to use the default permission level, you can
customize the default permission level to include or exclude permissions that you do or
do not need.
1. On the Site Settings page, under Users and Permissions, click Advanced
permissions.
2. On the toolbar, click Settings, and then click Permission Levels.
3. In the list of permission levels, click the name of the permission level you
want to customize.
4. On the Add a Permission Level page, in the Name box, type a name for the
new permission level.
5. Click Submit.

Copy an existing permission level
If the custom permission level that you want is similar to an existing default permission
level, and you need to use both the default permission level and your custom permission
level, you can copy the default permission level, and then modify the copy and save it as
a new permission level.
permissions.
14

3. In the list of permission levels, click the name of the permission level you
want to copy.
4. At the bottom of the page, click Copy Permission Level.
5. On the Copy Permission Level page, in the Name box, type a name for the
6. In the Description box, type a description for the new permission level.
7. In the list of permissions, select or clear the check boxes to add permissions to
or remove permissions from the permission level.
8. Click Create.

Create a permission level
If there is no permission level similar to the one you need, you can create one and include
just the permissions that you need.
permissions.
3. On the toolbar, click Add a Permission Level.
4. On the Add a Permission Level page, in the Name box, type a name for the
5. In the Description box, type a description for the new permission level.
6. In the list of permissions, select the check boxes to add permissions to the
permission level.
7. Click Create.

15

Choose which security groups to use (Windows
In this article:
• Determine which Windows security groups and accounts to use for granting access to sites
• Decide whether to use all authenticated users
• Decide whether to allow access to anonymous users
• Worksheet
For easier user management, we recommend that you assign site permissions to groups
rather than to individual users. In the Microsoft Active Directory directory service, the
following two types of groups are commonly used to organize users:
• Distribution group A group that is only used for e-mail distribution and that
is not security-enabled. Distribution groups cannot be listed in discretionary
access control lists (DACLs) used to define permissions on resources and objects.
• Security group A group that can be listed in discretionary access control
lists (DACLs) used to define permissions on resources and objects. A security
group can also be used as an e-mail entity.
You can use security groups to control permissions for your site by directly adding the
security group and granting the entire group permissions. You cannot use distribution
groups in this way; however, you can expand a distribution list and add the individual
users to a SharePoint group. If you use this method, you must manage the process of
keeping the SharePoint group synchronized with the distribution group. If you use
security groups, you do not need to manage the individual users in the SharePoint
application. Because you included the security group itself and not the individual
members of the group, Active Directory manages the users for you.

Determine which Windows security groups and
accounts to use for granting access to sites
Each organization sets up its Windows security groups differently. For easiest permission
management, security groups should be:
• Large and stable enough that you aren't constantly adding additional groups to
your SharePoint sites.
• Small enough that you can assign appropriate permissions.

16

For example, a security group called quot;all users in building 2quot; is probably not small
enough to assign permissions, unless it happens that all users in building 2 have the same
job function, such as accounts receivable clerks. This is rarely the case, so you should
look for a smaller set of users, such as quot;accounts receivablequot; or some other smaller,
highly-related group.

Decide whether to use all authenticated users
If you want all users within your domain to be able to view content on your site, consider
granting access to all authenticated users (the Domain Users Windows security group).
This special group allows all members of your domain to access a Web site (at the
permission level you choose), without your having to enable anonymous access.

Decide whether to allow access to anonymous users
You can enable anonymous access to allow users to view pages anonymously. Most
Internet Web sites allow anonymous viewing of the site, but might ask for authentication
when someone wants to edit the site or buy an item on a shopping site. Anonymous
access must be granted at the Web application level at the time that the Web application
is created. If anonymous access is allowed for the Web application, then site
administrators can decide whether to:
• Grant anonymous access to a site.
• Grant anonymous access only to lists and libraries.
• Block anonymous access to a site altogether.
Anonymous access relies on the anonymous user account on the Web server. This
account is created and maintained by Microsoft Internet Information Services (IIS), not
your SharePoint site. By default in IIS, the anonymous user account is IUSR_
ComputerName. When you enable anonymous access, you are in effect granting that
account access to the SharePoint site. Allowing access to a site, or to lists and libraries,
grants the View Items permission to the anonymous user account. Even with the View
Items permission, however, there are restrictions to what anonymous users can do.
Anonymous users cannot:
• Use the Microsoft Office SharePoint Designer remote procedure call (RPC);
in other words, they cannot open sites for editing in Office SharePoint Designer.
They can also not use DAV (the Web Folders protocol in Windows); in other
words, they cannot view the site in My Network Places.
• Upload or edit documents in document libraries, including wiki libraries.

17

Important
To create more secure sites, lists, or libraries, do not enable anonymous
access. Enabling anonymous access allows users to contribute to lists,
discussions, and surveys, possibly using up server disk space and other
resources. Further, it allows anonymous users to discover site information,
including user e-mail addresses and any content posted to lists, and libraries,
and discussions.
You can also set permission policies for the anonymous user for different zones (Internet,
Extranet, Intranet, Other) if you have the same Web application serving content in those
different zones. The policies are described in the following list:
• None No policy. This is the default option. No additional permission
restrictions or additions are applied to site anonymous users.
• Read Anonymous users can read content, unless the site administrator turns
off anonymous access.
• Deny Write Anonymous users cannot write content, even if the site
administrator specifically attempts to grant the anonymous user account that
permission.
• Deny All Anonymous users cannot have any access, even if site
administrators specifically attempt to grant the anonymous user account access to
their sites.

Worksheet
Use the following worksheet to list the security groups that you will use and the
permission levels that the groups will need at each level of your site hierarchy.
• Site and content security worksheet (http://go.microsoft.com/fwlink/?
LinkID=73136&clcid=0x409)

18

Choose administrators and owners for the
administration hierarchy (Windows SharePoint
Services)
In this article:
• Levels of administration
• Worksheet
Administration of Microsoft Windows SharePoint Services 3.0 occurs at many levels,
such as on the server farm as a whole, on shared services, and on individual sites. Many
people can be involved in managing Windows SharePoint Services 3.0.

Levels of administration
Most levels of the server and site hierarchy have a corresponding administration group.
Although the Web application level does not have a unique administrator group, farm
administrators and service administrators have control over the Web applications within
their scope. Members of the Farm Administrators group and members of the
Administrators group on the local server can define a policy to grant individual users
permissions at the Web application level. For more information about policy, see quot;Policy
for Web applicationsquot; in the Logical architecture elements (Windows SharePoint
Services) article.
The groups of users who have administrative permissions at different levels are described
in the following list:
• Server or server farm level
• Farm Administrators group Members of the Farm Administrators
group have permissions to and responsibility for all servers in the server
farm. Members can perform all administrative tasks in Central
Administration for the server or server farm. Members of this group can
also perform command-line operations. This group does not have access to
individual sites or their content. However, members can take ownership of
a specific site collection if need be (for example, if the administrator of a
site leaves the organization and a new administrator must be added).
• Administrators group Members of the Administrators group on the
local server can perform all farm administrator actions and more,
including installing new products or applications, deploying Web Parts
and new features to the global assembly cache, creating new Web
19

applications and new Internet Information Services (IIS) Web sites, and
starting services. Like farm administrators, members of this group on the
local server have no access to site content, by default.
Note
Farm administrators and administrators can also take ownership of
specific site collections, if needed. To take ownership, they can add
themselves as the site collection administrator by using the Site Collection
Administrators page in Central Administration.
• Site level
• Site collection administrators Have the Full Control permission
level on all Web sites within a site collection. This means that they have
access to content in all sites in that site collection, even if they do not have
explicit permissions on that site.
• Site owners By default, members of the Owners group for a site have
the Full Control permission level on that site. They can perform
administration tasks for the site, and for any list or library within that site.

Worksheet action

Use the Administrators and owners worksheet
to record which administrators to assign to each level. Refer to
your site hierarchy diagram to be sure you assign owners for
each site collection, top-level Web site, and subsite that you
are planning.

Worksheet
Use the following worksheet to choose administrators and owners for the administration
hierarchy:
• Administrators and owners worksheet (http://go.microsoft.com/fwlink/?
LinkId=73128&clcid=0x409)

20

Plan for search (Windows SharePoint Services)
In this article:
• About search in Windows SharePoint Services version 3
• Plan for search administration
• Link to worksheet
Microsoft Windows SharePoint Services 3.0 uses the SharePoint search technology used
by Office SharePoint Server 2007, rather than relying on Microsoft SQL Server full-text
searching as previous versions of Microsoft Windows SharePoint Services did.
Most of the search capabilities for Windows SharePoint Services 3.0 are configured
automatically during installation, leaving few options for administrators to plan and
configure. There are a few settings for content access accounts and search servers that
can be configured, however, and it is a good idea to consider the implications of these
settings before deployment.

About search in Windows SharePoint Services version 3
Search for Windows SharePoint Services 3.0 is straightforward:
• Scalability Search covers a single site collection. Only SharePoint content in
the site collection can be crawled. You cannot crawl databases, mail servers,
application servers, or Web sites and file shares outside of the site collection. In a
deployment with more than one site collection, each site collection provides
search only for content on that site collection, and there is no aggregation of
search results across site collections.
• Content sources One content source is automatically created for each Web
application in the site collection, and no administration details are exposed to
administrators.
• Search scopes Search is automatically scoped to current context and limited
to site and subsites, list or library, or folder. These search scopes appear in the
search dropdown menu. If you are looking at a subsite, you cannot search over the
entire site collection, but you can search over all of the subsites of the current site.
Scope management is not exposed to administrators.
• Crawling Full crawls occur automatically without scheduling and without
administrator control.
• Error logging Administrators can view a limited set of error message types,
including:
• Authorization messages.
21

• Propagation messages.
• Hardware failure and data corruption messages.
• IFilters A limited set of IFilters to search content in certain formats are
included with Windows SharePoint Services 3.0. Other IFilters are available
through other distributors.
The search service runs on one or more servers in the farm, depending upon the servers
you select during deployment and configuration. Search consists of search query and
index roles. Search queries are performed using the network service account, or another
account selected during installation. A separate content access account is used when
crawling content sources and indexing content. A small set of administration tasks are
available to site collection and farm administrators.
People using a site collection type search terms into the search box, and select a search
scope from the dropdown menu. Search results appear in order of relevancy.

Plan for search administration
The simple one-click installation of Windows SharePoint Services 3.0 automatically
configures the following settings:
• The search service and content access account use the network service
account.
• The single server is automatically assigned both the search and index roles.
More complex deployments enable you to select different accounts for the search service
and the content access account. Which account you use depends upon the larger security
considerations for your organization. Record your decision in the security planning
worksheet.
More complex deployments also enable you to change how you assign the search and
index roles. Each of these roles can be assigned to any server, though you can only assign
the index role to one server. You can add multiple search servers for large site collections
with many users. For more information about assigning search and indexing roles, see the
capacity and performance planning documentation.

Link to worksheet
Because Windows SharePoint Services 3.0 search administration is relatively
streamlined, you don't need a separate search planning worksheet for Windows
SharePoint Services 3.0. However, any decisions made about the search service account,
the content access account, or the search and index roles should be recorded in the
appropriate worksheets for security, capacity, and performance planning.

22

Security considerations for search (Windows
Microsoft Windows SharePoint Services 3.0 uses a technique, sometimes called security
trimming, to ensure that users do not see content or links to content that they do not have
permissions to view. However, when using the Windows SharePoint Services Search
service to perform search queries, certain conditions can exist in which users might see
links to content that they do not have permission to access. While they will not be able to
use the link on the search results page to view the content, the links that appear on the
search results page might be accompanied by text that discloses information the users
should not see. This article describes the conditions in which this can occur and how to
avoid them.

Sharing data across Web parts
When sharing data between Web parts, to avoid the risk of disclosing information that
users should not see in search results pages, we recommend that you do not use fine-
grained permissions. Instead, set permissions only at the site or site collection level and
do not share data with a Web part that is contained by a page that has different
permissions than any of the data being shared.
Note
Permissions can be set at the site, list and library, or item levels.
If you must use fine grained permissions, do not share data between Web parts. If this
cannot be avoided either, do not crawl this content. See the following section for
information about excluding content from being crawled.
If you have already crawled the content, consider removing it from the index.

Exclude content from a crawl
Site owners and designers can exclude content from being crawled that may pose an
information disclosure risk in any of the following ways:
• Designers can add the <META NAME=quot;ROBOTSquot;
CONTENT=quot;NOHTMLINDEXquot;/> element manually to all pages that they don't
want the index server to crawl.
• At the site level, use the Search Visibility page (accessed through the Site
Settings page) to prevent the index server from crawling a particular site. You can
optionally use this page to specify one of the following:
• Do not index ASPX pages if this site contains fine-grained permissions
23

• Always index all ASPX pages on this site
• Never index any ASPX pages on this site
• At a list or library level, use the following procedure to specify that content in
a list or library does not appear in search results.

Exclude content from a list or library from search results
1. In the list or library that contains content that you do not want to
appear in search results, on the Settings menu, click <Library type>
Library Settings or List Settings.
2. In the General Settings section, click Advanced Settings.
3. In the Search section, select No and then click OK.

24

II. Plan for authentication

25

Plan authentication methods (Windows
In this article:
• About authentication
• Supported authentication methods
• Configure authentication
• Plan authentication for crawling content
• Planning zones for your authentication design
• Choose methods of authentication allowed in your environment
• Worksheet
This article describes the authentication methods that are supported by Microsoft
Windows SharePoint Services 3.0. After reading this article, you will be able to:
• Understand how authentication is implemented in Windows SharePoint
Services 3.0.
• Identify the authentication methods that are appropriate for your environment.

About authentication
Authentication is the process of validating a user's identity. After a user's identity is
validated, the authorization process determines which sites, content, and other features
the user can access.
In Windows SharePoint Services 3.0, the authentication process is managed by Internet
Information Services (IIS). After IIS performs authentication of users, the security
features in Windows SharePoint Services 3.0 perform the authorization process.
For more information about implementing Windows SharePoint Services 3.0
authorization, see Plan site and content security (Windows SharePoint Services).
Planning for authentication is important not only to protect your solution by validating
users' identities, but also to secure user credentials over the network.

Supported authentication methods
Windows SharePoint Services 3.0 provides a flexible and extensible authentication
system, which supports authentication for identity management systems that are based or
are not based on the Microsoft Windows operating system. By integrating with ASP
26

.NET pluggable authentication, Windows SharePoint Services 3.0 supports a variety of
forms-based authentication schemes. Authentication support in Windows SharePoint
Services 3.0 enables a variety of authentication scenarios, including:
• Using standard Windows authentication methods.
• Using a simple database of user names and passwords.
• Connecting directly to an organization's identity management system.
• Using two or more methods of authentication for accessing partner
applications (for example, connecting to your partner company's identity
management system for authenticating partner employees while using Windows
authentication methods to authenticate your internal employees).
• Participating in federated identity management systems.
The following table lists the supported authentication methods:

Authentication method Description Examples

Windows The standard IIS Windows • Anonymous
authentication methods are • Basic
supported. • Digest
• Certificates
• Kerberos
(Integrated
Windows)
• NTLM
(Integrated
Windows)
•

27

Authentication method Description Examples

ASP.NET forms Windows SharePoint Services • Lightweight
3.0 adds support for identity Directory Access
management systems that are Protocol (LDAP)
not based on Windows by • SQL database or
integrating with the ASP.NET other database
forms authentication system. • Other
ASP.NET authentication ASP.NET-based
enables Windows SharePoint forms authentication
Services 3.0 to work with solutions
identity management systems
that implement the
MembershipProvider
interface. You do not need to
rewrite the security
administration pages or
manage shadow Active
Directory directory service
accounts.

Web Single Sign-On Windows SharePoint Services • Active Directory
(SSO) 3.0 supports federated Federation Services
authentication through Web (AD FS)
SSO vendors. Web SSO • Other identity
enables SSO in environments management
that include services running systems
on disparate platforms. You
do not need to manage
separate Active Directory
accounts.

Authentication of system accounts
ASP.NET forms authentication and Web SSO can be used to authenticate only user
accounts. The process accounts used to connect to Microsoft SQL Server database
software and run the Web farm must be Windows accounts, even when using alternative
methods of authentication to authenticate users.
Windows SharePoint Services 3.0 supports SQL Server authentication and local
computer process accounts for farms that are not running Active Directory. For example,

28

you can implement local accounts by using identical user names and passwords across all
servers within a farm.

Configure authentication
Although configuring Windows authentication is a straightforward process, configuring
authentication to use ASP.NET forms or Web SSO requires more planning. This section
provides a summary of how authentication is configured in Windows SharePoint Services
3.0. This information will help you understand how to put together an authentication
strategy for your solution and determine who in your organization needs to be involved in
planning for authentication.

Configure authentication for SharePoint Web applications
Authentication in Windows SharePoint Services 3.0 is configured at the SharePoint Web
application level. The following diagram illustrates a Windows SharePoint Services
server farm that is configured to host sites for multiple companies. Authentication is
configured separately for each company.

29

When you initially create or extend a Web application, you are presented with a limited
number of authentication options (Kerberos, NTLM, and anonymous). If you are using
one of these methods, you can configure authentication when you create or extend the
Web application.
The following illustration shows the limited authentication choices that are available
when you initially create or extend a Web application:

30

However, if you are using different authentication settings, select the default
authentication options, and then configure authentication after the Web application is
created or extended. (To do so, in Central Administration, on the Application
Management page, in the Application Security section, select Authentication
providers, and then click the zone to open the Edit Authentication page.) The settings
that are configured on this page depend on the type of authentication that is selected:
Windows, forms, or Web SSO.
The following illustration shows the Edit Authentication page:

31

Depending on the authentication choices that you select in Central Administration,
additional configuration might be necessary. The following table summarizes the
configuration steps based on the authentication method. This table also indicates if
specialized roles in addition to SharePoint Administrator are needed.

Authentication method Additional configuration Specialized roles

Anonymous, None None

Basic None None

Digest Configure digest None
authentication directly in
IIS.
1. Select Windows
Certificates Windows Server 2003
32


authentication in administrator, to obtain and
Central configure certificates
Administration.
2. Configure IIS for
certificate
authentication.
3. Enable Secure
Sockets Layer
(SSL).
4. Obtain and
configure certificates
from a certification
authority (CA).
NTLM (Integrated None None
Windows)
1. Configure the
Kerberos (Integrated IIS administrator
Web application to
Windows)
use Kerberos
authentication.
2. Configure a
Service Principal
Name (SPN) for the
domain user account
that is used for the
application pool
identity (application
pool process
account).
3. Register the SPN
for the domain user
account in Active
Directory.

33


Forms 1. Register the • ASP.NET
membership developer
provider in the • Administrator of
Web.config file for the identity
the SharePoint Web management system
application. you are connecting to
2. Register the role
manager in the
Web.config file for
the SharePoint Web
application
(optional).
3. Register the
membership
provider in the
Web.config file for
the Central
Administration site.
Web SSO In addition to configuration • ASP.NET
steps required for ASP.NET developer
forms authentication, • Administrator of
register an HTTP module the identity
for the Web SSO provider. management system
you are connecting to

Connect to identity management systems that are external or not based on Windows
To use ASP.NET forms or Web SSO to authenticate users against an identity
management system that is not based on Windows or that is external, you must register
the membership provider in the Web.config file. In addition to registering a membership
provider, you can register a role manager as well. Windows SharePoint Services 3.0 uses
the standard ASP.NET role manager interface to gather group information about the
current user. Each ASP.NET role is treated like a domain group by the authorization
process in Windows SharePoint Services 3.0. You register role managers in the
Web.config file the same way you register membership providers for authentication.
If you want to manage membership user or roles from the Central Administration site,
you can optionally register the membership provider and the role manager in the
Web.config file for the Central Administration site (in addition to registering these in the
Web.config file for the Web application that hosts the content).

34

Ensure that the membership provider name and role manager name that you registered in
the Web.config file is the same as the name that you entered in the Central
Administration Authentication.aspx page. If you do not enter the role manager in the
Web.config file, the default provider specified in the machine.config file might be used
instead.
For example, the following string in a Web.config file specifies a SQL membership
provider:
<membership defaultProvider=quot;AspNetSqlMembershipProviderquot;>

For additional information about using ASP.NET forms authentication to connect to a
SQL Server authentication provider, see Authentication samples (Windows SharePoint Services).
Finally, if you are using Web SSO to connect to an external identity management system,
you must also register an HTTP module for the Web SSO. An HTTP module is an
assembly that is called on every request made to your application. HTTP modules are
called as part of the ASP.NET request pipeline. For more information, see Introduction to
HTTP Modules (http://go.microsoft.com/fwlink/?LinkId=77954&clcid=0x409).
Integrating with ASP.NET forms authentication places additional requirements on the
authentication provider. In addition to registering the various elements in the Web.config
file, the membership provider, role manager, and HTTP module must be programmed to
interact with Windows SharePoint Services 3.0 and ASP.NET methods, as indicated in
the following table:

35

Category Description

Membership provider To work with Windows SharePoint Services
3.0, the membership provider must
implement the following methods:
• GetUser (String) Windows
SharePoint Services 3.0 calls this
method to resolve user names during
invitations and to get the user's
display name.
• GetUserNameByEmail Windo
ws SharePoint Services 3.0 calls this
method to resolve user names in
invitations.
• FindUsersByName,
FindUsersByEmail Windows
SharePoint Services 3.0 calls these
methods to populate the user picker
control on the Add Users page. If
the membership provider does not
return any users, the picker will not
function and administrators will
need to type the user name or e-mail
address in the Add User text box.

36


Role manager The role manager must implement the
following methods:
• RoleExists Windows
method during invitations to verify
that a role name exists.
• GetRolesForUser Windows
method at access check to gather the
roles for the current user.
• GetAllRoles Windows
method to populate the group and
role picker. If the role provider does
not return any groups or roles, the
Windows SharePoint Services 3.0
picker will not function and the
administrator will need to type the
name of the role in the Add User
text box.
HTTP module The HTTP module must handle the
following events:
• AuthenticateRequest This
event is called when ASP.NET is
ready to authenticate the user. The
Web SSO module must unpack the
user's authentication cookie and set
the HttpContext.User object with the
identity of the current user.
• EndRequest This is the last
event in the ASP.NET pipeline. This
event is called just before returning
the code to the client. The Web SSO
module must capture 401 responses
coming from Windows SharePoint
Services 3.0 and turn these into an
appropriate 302 redirect for
authentication to the Web SSO
37


logon server.

Enabling Anonymous Access
You can enable anonymous access for a Web application in addition to configuring a
more secure authentication method. With this configuration, administrators of sites within
the Web application can choose to allow anonymous access. If anonymous users want to
gain access to secured resources and capabilities, they can click a logon button to submit
their credentials.

Using different authentication methods to access a site
You can configure Web applications in Windows SharePoint Services 3.0 to be accessed
by up to five different authentication methods or identity management systems. The
following figure illustrates a partner application that is configured to be accessed by users
from two different identity management systems. Internal employees are authenticated by
using one of the standard Windows authentication methods. Employees of the partner
company are authenticated against their own company's identity management system.

To configure a Web application to be accessed by two or more different authentication
systems, you must configure additional zones for the Web application. Zones represent
different logical paths of gaining access to the same physical application. With a typical
38

partner application, employees of a partner company access the application through the
Internet, while internal employees access the application directly through the intranet.
To create a new zone, extend the Web application. On the Extend Web Application to
Another IIS Web Site page, in the Load Balanced URL section, specify the URL and
zone type. The zone type is simply a category name applied to the zone and does not
affect the configuration of the zone.
After extending the Web application, you can configure a separate authentication method
for the new zone. The following figure shows the Authentication Providers page for a
Web application that is configured by using two different zones. The default zone is the
zone used by internal employees. The Internet zone is configured for partner access and
uses ASP.NET forms to authenticate partner employees against the partner identity
management system.

Plan authentication for crawling content
To perform successful crawls of content in a Web application, you must understand the
authentication requirements of the index component of the search server (also known as
the crawler). This section describes how to configure authentication for Web applications
to ensure that the content in those Web applications can be successfully crawled.
When a farm administrator creates a Web application by using all default settings, the
default zone for that Web application is configured to use NTLM. The farm administrator
can change the authentication method for the default zone to any authentication method
supported by Windows SharePoint Services 3.0.
The farm administrator can also extend a Web application one or more times to enable
additional zones. Up to five zones can be associated with a particular Web application,
and each zone can be configured to use any authentication method supported by
Windows SharePoint Services 3.0.

39

Order in which the crawler accesses zones
When planning the zones for a Web application, consider the polling order in which the
crawler accesses zones when attempting to authenticate. The polling order is important,
because if the crawler encounters a zone configured to use basic, digest, or Kerberos
authentication, authentication fails and the crawler does not attempt to access the next
zone in the polling order. If this occurs, the crawler will not crawl content on that Web
application.
Tip
Ensure that a zone configured for NTLM is earlier in the polling order than a zone
configured for basic, digest, or Kerberos authentication.
The crawler polls the zones in the following order:
• Default zone
• Intranet zone
• Internet zone
• Custom zone
• Extranet zone
The following figure shows the decisions that are made by the authentication system
when the crawler attempts to authenticate:

40

The following table describes the actions associated with each callout in the figure:

41

Callout Action

1 Crawler attempts to authenticate by using the default zone.
Note
The crawler always attempts to use the default zone first
when attempting to authenticate for a particular Web
application.
2 If the zone is configured for NTLM, the crawler is authenticated
and proceeds to the authorization phase.

3 If the zone is configured for basic, digest, or Kerberos
authentication, authentication fails and the crawler does not attempt
to authenticate by using another zone. This means the content is not
crawled.

4 If there are no more zones in the polling order, authentication fails
and the content is not crawled.

5 Crawler attempts to authenticate by using the next zone in the
polling order.

If you configure the default zone to use an authentication method that the crawler does
not support — for example, forms authentication or Web SSO — you must create at least
one additional zone and configure this zone to use NTLM authentication. Consider the
following scenario.
Authentication scenario
The farm administrator creates a Web application and configures it to use forms
authentication. Because the farm administrator wants the content in the Web application
to be crawled and indexed, and because she knows that the crawler requires a zone
configured with NTLM, the farm administrator extends the Web application and
configures the intranet zone to use NTLM.
When the crawler attempts to authenticate by using the default zone, the authentication
system determines that the crawler and the zone are not configured to use the same
authentication method. Because the zone is not configured for basic, digest, or Kerberos
authentication and there is at least one additional zone in the polling order, the crawler
attempts to authenticate by using the intranet zone. Because the intranet zone is
configured to use NTLM and the crawler also uses NTLM, authentication succeeds.

42

In addition to properly configuring the authentication method, you must ensure that the
crawler is authorized to crawl content within the Web application. To do this, you must
ensure that the credentials used for the content access account have the Full Read
permission level or higher on the Web application that you want to crawl. Farm
administrators can use the Policy for Web Application page in Central Administration to
create a policy that gives the content access account the Full Read permission level on a
particular Web application.

Crawling host-named site collections
The process and rules illustrated in the previous figure do not apply to host-named site
collections. This is because host-named site collections are available only through the
default zone. If you do not configure the default zone to use NTLM when deploying host-
named site collections, you must configure an alternate method for the index component
to access content.
For more information about crawling host-named site collections that are not configured
for NTLM authentication, see the following articles:
• Prepare to crawl host-named sites that use forms authentication
• Prepare to crawl host-named sites that use basic authentication

Planning zones for your authentication design
If you plan to implement more than one authentication method for a Web application by
using zones, use the following guidelines:
• Use the default zone to implement your most secure authentication settings. If
a request cannot be associated with a specific zone, the authentication settings and
other security policies of the default zone are applied. The default zone is the zone
that is created when you initially create a Web application. Typically, the most
secure authentication settings are designed for end-user access. Consequently, the
default zone will likely be the zone that is accessed by end users.
• Use the minimum number of zones that is required by the application. Each
zone is associated with a new IIS site and domain for accessing the Web
application. Only add new access points when these are required.
• If you want content within the Web application to be included in search
results, ensure that at least one zone is configured to use NTLM authentication.
NTLM authentication is required by the index component to crawl content. Do
not create a dedicated zone for the index component unless necessary.

43

Choose methods of authentication allowed in your
environment
In addition to understanding how authentication is configured, planning for
authentication includes:
• Considering the security context or environment of your Web application in
Windows SharePoint Services 3.0.
• Evaluating the recommendations and tradeoffs for each method.
• Understanding how user credentials and related identity data are cached and
consumed by Windows SharePoint Services 3.0.
• Understanding how user accounts are managed.
• Ensuring that authentication methods are compatible with browsers that are
used by your users.

Worksheet action

Use the Authentication methods worksheet (http://go.microsoft.com/
fwlink/?LinkId=77970&clcid=0x409) to identify which
authentication methods you are willing to support in your
environment and to record your decisions and
recommendations for each. This worksheet will be used when
planning authentication methods for individual Web
applications in Windows SharePoint Services 3.0.

Recommendations for specific security environments
Your choice of authentication methods will primarily be driven by the security context of
your application. The following table provides recommendations based on the most
common security environments:

44

Environment Considerations

Internal intranet At a minimum, protect user credentials from plain
view. Integrate with the user management system that
is implemented in your environment. If Active
Directory is implemented, use the Windows
authentication methods built into IIS.

External secure collaboration Configure a separate zone for each partner company
that connects to the site. Use Web SSO to authenticate
against each partner’s own identity management
system. This eliminates the need to create accounts in
your own identity management system and also ensures
that contributor identities continue to be maintained and
validated by partner employers. If a contributor is no
longer employed by a partner company, the contributor
cannot continue to gain access to your partner
application.

External anonymous Enable anonymous access (no authentication) and
allow Read-Only permissions for users who connect
from the Internet. If you want to provide targeted or
role-based content, you can use ASP.NET forms
authentication to register users by using a simple
database of user names and roles. Use the registration
process to identify users by role (such as doctor,
patient, or pharmacist). When users log on, your site
can present content that is specific to the user role. In
this scenario, authentication is not used to validate
credentials or to limit who can access the content; the
authentication process simply provides a method of
targeting content.

Recommendations and tradeoffs for authentication methods
Understanding the advantages, recommendations, and tradeoffs for each specific
authentication method can help you to determine which methods to use in your
environment. The following table highlights the recommendations and tradeoffs for each
authentication method. For more information about each of the Windows authentication
methods supported by IIS, see IIS Authentication (http://go.microsoft.com/fwlink/?
LinkId=78066&clcid=0x409).
45

Wss Security

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Wss Security

Semelhante a Wss Security (20)

Mais de LiquidHub

Mais de LiquidHub (20)

Último

Último (20)

Wss Security