Microsoft SharePoint Services
2003 has evolved into Microsoft
Office SharePoint Server 2007, offering a much fuller, richer security toolset. Whereas SharePoint 2003 relied on
logon security backed by Active Directory
(AD), portal security, and list-level security,
SharePoint 2007 improves previously
existing security features while adding
auditing features, storage policies, and
secure collaboration products such as
Excel Services. Let's take a look at how
security has evolved in SharePoint, how
each version tackles authentication and
authorization, and how SharePoint 2007
will benefit your organization.
SharePoint 2003 Authentication
Let's start by taking a closer look at the
security features of Microsoft's SharePoint
2003 products and technologies. The
foundation of any secure product is the
ability to control access to secured materials—which essentially boils down to
digital identity and passwords. Because
SharePoint 2003 technologies rely on AD
to provide user-account validation, the
password policies of any SharePoint site
are basically the password policies of the
underlying AD network. As the Microsoft
SharePoint Products and Technologies
Resource Kit points out, password
policies need to take a host of recommendations into account, particularly
when you're considering the addition of
SharePoint technologies to a network.
These recommendations include minimum
password length, password complexity,
limits on consecutive password attempts,
prohibition of sharing passwords, and
smart card or biometric device usage.
What exactly does the reliance on AD mean in terms of user authentication
(verifying that users are who they claim to
be)? SharePoint 2003 offers two modes of operation: preexisting-account mode and
account-creation mode. In the preexisting-account mode (aka domain mode), an
AD account must exist before a user can
access a SharePoint site. In the accountcreation mode (selected during SharePoint
installation) you can have an AD account
automatically created each time you add a new SharePoint user. If you're unsure
which mode you're in, you can use the
included Stsadm.exe command-line tool
to find out.
In either case, the existence of this AD
account provides the authentication necessary to access SharePoint. SharePoint
validates the existence of the user in AD
either through NTLM or Kerberos protocols. To provide authorization, the system
compares the authenticated account with
a list of access-control information for the
SharePoint site itself. These authorization
lists are stored in Microsoft SQL Server
content databases and are modified from
within SharePoint. You can organize these
lists or groups at the user level, in site-level groups, or in multisite level groups.
(I've just stated that SharePoint relies
on AD to provide account validation, but
that's not 100 percent accurate. You can also use local Windows accounts.
However, if you don't use AD, you lose
the ability to pre-populate the SharePoint
profile database. And if any users have
personal sites, they won't be registered
for cross-farm synchronization in a server
farm environment. Because of these
severe restrictions, AD environments are
highly recommended.)
SharePoint 2003 Authorization
What does the reliance on AD mean in
terms of user authorization (validating
that users have permissions to access
a resource)? SharePoint 2003 authorization is based on groups of rights to which specified users or groups of users
are assigned. You can easily customize
security groups, but by default five security
groups ship with Windows SharePoint
Services:
- Administrator—Wields complete control over the Web site
- Web Designer—Controls the look and
feel of the Web site
- Contributor—Can add content to
existing Web Parts
- Reader—Has read-only access to
content in lists and document libraries
- Guest—Holds the lowest levels of permissions. This group is designed to give
read access to sub-portions of a site
without giving access to the entire site.
The rights fall into three general categories: list rights, site rights, and personal rights.
The system checks list rights to determine
whether a user is able to contribute to a
list, edit list items, manage columns in a
list, and so on. The system checks site
rights whenever a user attempts to create
a site, manage a site's users, change the look and feel of a site, and more.
The system checks personal rights
when a user tries to create or change
a personal list view and use private or personal Web Parts. Figure 1 shows the full list of available rights in
SharePoint 2003.
After you grasp how your
SharePoint system organizes its rights
into groups, you'll understand how to organize your users. It's possible
to individually manage each user's
permissions, but creating groups to
hold your users is the recommended
best practice. You have two options
for grouping your users: site groups
and cross-site groups. A site group is
a group of users available for assignment on that particular SharePoint
site. If your users are grouped in a
cross-site group, the system actually
creates that group at the top level for
the site collection, and it's available to
any site in that site collection.
Suppose your organization,
Contoso, has several departments,
such as Marketing, Executive,
Finance, and IT. If each of these
departments has its own site under
the top-level Contoso site, a user in
the Executive department might not
have access to documents stored by
the Finance department unless he or she
is explicitly granted those rights. However,
if the users for each department reside in cross-site groups, the manager of the
Finance department has to grant only the Executive cross-site group read access
to its portal, and all members of the team
can be admitted at once.