Roles, Users, Groups, and Permissions for Microsoft Project Server 2002

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: June 1, 2003

Applies to:
Microsoft Project Server 2002
Microsoft Project Professional 2002

Summary Learn to govern what users can see and do in Microsoft Project Web Access by managing user permissions and categories.

On This Page

Introduction
Understanding Permissions in Microsoft Project Server
Authentication Options
Defining Permissions
Using Groups Effectively
Applying Security Templates
Using Categories and Views to Manage Security
Additional Resources

Introduction

This article is part of a series of six articles about Microsoft Project Server 2002 security. You can access the other security articles from the links below:

Understanding Permissions in Microsoft Project Server

Every person who has an interest in your organizations projects is a potential user of Microsoft Project Server, whether the individual is an active participant such as a project team member or project manager, or another stakeholder such as an executive overseeing the project or a client interested in the projects progress. Each of these individuals requires a user account to access specific project information on the server. This user account identifies the individual when they log onto the server and personalizes the interface and data of the server according to the user permissions and categories assigned to the account. The user permissions and categories govern what the user can see and do within Microsoft Project Web Access, the Web-based interface for Microsoft Project Server.

Authentication Options

To gain access to the server, users must log in. This process identifies and authenticates the person logging in against the user accounts within Microsoft Project Server. The user can be identified using their Microsoft Windows account or using their own account in the Microsoft Project Server authentication system. The method of authentication can be set for each user. The server administrator can set up one method of authentication or specify a mixed environment. The choice of authentication method will depend on the IT environment the users have, the organizations security policies, and user preferences. The advantages of Microsoft Windows authentication include automated logon and better-integrated security (the same user name and password as a users network identification). The Microsoft Project Server authentication has the advantage that the username and password can be administered locally on the server.

Defining Permissions

User permissions define what project information a user can or cannot view, and identify the actions the user can perform within Microsoft Project Server. These actions include creating, delegating, and updating tasks, accessing issues and documents, and carrying out administrative functions. The administrator account is protected against their permissions being denied to stop accidental lockout from the software

Users also have categories (collections of projects, assignments, resources, and data views) that they may be assigned to. Categories also have object permissions associated with them which define whether certain actions can be carried out on the different objects within the category.

An organizations permissions can also be set on a server basis rather than on a user-by-user basis. The same permissions that are assigned to individual users can be applied to the server as a whole. Any permission that is set to disable access to features of Microsoft Project Server on an organization-wide basis will override permissions allowed on a user basis.

A combination of the server permissions, a users global permissions, the categories the user has access to, and the permissions associated to those categories define what a user can see and do within Microsoft Project Server.

Using Groups Effectively

In an organization where there are many users, setting up a large number of permissions on an individual basis and administering them can be complex and time-consuming. To simplify this task, Microsoft Project Server uses the principle of groups. Users with the same data requirements and functional needs are assembled as a single entity under a group name. All the users belonging to that group are then assigned the same permissions and access to categories.

Because a group requires the users to have the same data requirements and functional needs, they are usually aligned with their type of role or job within the organization.

A project manager, for example, requires different functionality and access to data than a senior executive. Project managers are involved in the process of requesting status, approving work, and managing day-to-day issues and details associated with a single project. Executives are usually responsible for overseeing a portfolio of projects and assessing high-level progress, not viewing detailed tasks for individual projects. As there may be a number of people with similar information needs playing each of these roles, grouping them simplifies administration of the users. Rather than assigning permissions for every individual, users can be assigned to a relevant group with the appropriate rights for that role.

Users can belong to multiple groups depending on the jobs they perform or the organization they work in.

Microsoft Project Server comes with a number of predefined groups that are created during installation. Each of these groups has predefined categories and permissions assigned to them:

  • Administrators

  • Executives

  • Portfolio managers

  • Project managers

  • Resource managers

  • Team leads

  • Team members

Administrators usually assign user rights by adding a user account to one of the default groups or by creating a new group and assigning specific user rights to that group. Users who are subsequently added to a group are automatically granted all user rights assigned to the group account. Generally, permissions should be set for groups rather than individual user accounts; so the user inherits the permissions of the groups they belong to.

Two types of users are automatically assigned to specific groups:

  • Users publishing Microsoft Project plans to the Microsoft Project Server are assigned to the project managers group.

  • Resources with assignments in the published plan are assigned to the team members group.

Each of these users has predefined categories and permissions implicitly assigned to them when the plan is published. A relationship is also implicitly created between:

  • A resource assignment and resource

  • A resource assignment and project manager

  • A project and project manager

  • A project and resource

  • A project manager and resource

  • A resource and their functional manager

  • A project manager and their functional manager

These relationships are stored in the Microsoft Project Server database. This relationship hierarchy, or Resource Breakdown Structure, handles the resource/project manager relationship, which is then used within the categories to personalize the information.

For other types of users, such as managers, the user accounts must be manually associated with a group by the administrator.

These relationships can be changed when using the publishing options:

  • Publish All. Changes project owner.

  • Republish Assignments. Changes assignment owner.

The project plans should always be republished to avoid confusion about these relationships.

Applying Security Templates

Security templates provide a quick way of applying or resetting predefined permission profiles to new or existing users, groups, and categories. By applying security templates, the rights being applied can easily be standardized according to the role. By automatically mapping permissions by role, this eliminates the tedious task of replicating permission across users or groups.

There are a number of predefined templates created, which align with the predefined groups, when Microsoft Project Server is installed. These security templates can be customized to meet the organization's needs, or new security templates can be created.

Using Categories and Views to Manage Security

Security of data in Microsoft Project Server is governed by providing permissions or rights for specified users or groups over collections of specific data or categories.

If users and groups define the rights individuals have to access and carry out actions, categories define what collections of specific data (projects, assignments, resources, and views of information) these rights have been applied to.

Categories allow the administrator to separate the data by scope of the information accessed—for example, task-specific, project-specific, department-specific, business unit-specific, or partition information across multiple instances of these hierarchies (for example, one project from another, one department from another, one business unit from another).

The category definition can also filter the data displayed to be specific to the user, using the relationships as defined in the Resource Breakdown Structure (see the Users and Groups section in this document).

This can be used in each category for personalizing the data to allow users in this category to view:

  • All projects they manage.

  • All projects to which they are assigned.

  • All projects assigned to resources they manage.

  • All projects managed by resources that they manage.

  • Their own information.

  • Information for all resources in projects that they manage.

  • Information for all resources that they manage.

  • Their own models.

  • Models created by resources that they manage.

There are three predefined categories created when Microsoft Project Server is installed.

  • My Organization. Defines a collection of data that covers all projects with all views of the data available.

  • My Projects. Defines a collection of data that covers all projects a user manages or is assigned to with all views of the data available for those projects.

  • My Tasks. Defines a collection of data that covers all projects a user is assigned to with only a view of the assignments of those projects.

Different groups have been assigned to these collections appropriate to the roles they commonly have in an organization, and therefore the scope of data they require.

Each of these categories has predefined groups and permissions assigned to them when Microsoft Project Server is installed:

  • Portfolio managers, administrators, and executives are assigned to the My Organizations category.

  • Project managers, team leads, and resource managers are assigned to the My Projects category.

  • Team members are assigned to the My Tasks category.

Different views of the data can be customized to define what fields are shown within the view, as well as allowing filtering and sorting of the data on different criteria as well.

Additional Resources

The following links provide more information about security and Microsoft Project Server 2002: