Microsoft Project Server Security Architecture and Planning Guide

  • Article

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

 

Microsoft Corporation

March 2002

Applies to:
   Microsoft Project Professional 2002
   Microsoft Project Server 2002
   Microsoft Project Web Access 2002

Summary: Microsoft Project Server for Microsoft Project was designed to meet the needs of both workgroups and enterprises. This overview discusses security concepts essential to the developer, default security levels, and the recommended security settings for department, multiple department hosting, and enterprise configurations. (15 printed pages)

Contents

Introduction
Security in Microsoft Project Server
Security Concepts
   Microsoft Windows Security Concepts
   Microsoft Project Server Security Concepts
Default Security Configuration
Recommended Security Configurations
   Department Configuration
   Multiple Department Hosting Configuration
   Enterprise Configuration
Conclusion

Introduction

Microsoft® Project Server and Microsoft Project Web Access are companion products for Microsoft Project 2002. Together, they provide Web-based timesheet, reporting, analysis, and collaboration features. These features were first introduced with Microsoft Project Central, the Web-based companion product for Microsoft Project 2000. Microsoft Project Server enhances many of the features of Microsoft Project Central. In addition, Microsoft Project Server introduces a set of enterprise project and resource management features to help users manage and secure projects and resources across an organization.

Microsoft Project Server includes an enhanced set of administration and security tools. These tools are accessed using Microsoft Project Web Access and are designed to decrease the effort required for day-to-day management of the server, leverage security features from the Microsoft Windows® 2000 and Microsoft Windows XP family of servers, and maintain the turnkey security features first introduced in Microsoft Project Central.

This white paper describes:

  • Security concepts
  • Default security configuration
  • Recommended security

Security in Microsoft Project Server

Microsoft Project Server is the result of the evolution of Microsoft Project Central and the integration of enterprise management features from Enterprise Project, a product designed by eLabor.com Inc. To support the new enterprise features, Microsoft Project Server's security features were enhanced to support access to projects, resources, and reports stored in the Microsoft Project Server database. In addition, the security features and architecture were modified to simplify management of the larger number of users and projects expected with enterprise-wide use of the server. Supporting the new enterprise features is a goal of the security features of Microsoft Project Server, it may also be used as a turnkey system, much like Microsoft Project Central.

Microsoft Project Server provides the following security features:

  • Authentication using either Windows integrated security or Microsoft Project Server security. Authentication in Microsoft Project Server allows users with or without Windows user accounts to access the server using the Microsoft Project Web Access client or Microsoft Project.
  • Groups. Users can be grouped together and granted access to features and data, reducing the number of security principals that need to be managed by administrators.
  • Categories. Objects such as projects, resources, views, and models, can be grouped together into categories. Users and groups can be granted permissions on these categories.
  • Global permissions. Global permissions allow access to features to be granted or denied at the user, group, or organization level.
  • Object permissions. Object permissions allow data access to be granted or denied for groups of projects, resources, views, and models at the user or group level.
  • Security rules. Security rules allow data access to be granted based on team member, project manager, or resource breakdown structure (RBS) relationships.

Security Concepts

Microsoft Project Server uses security concepts from Windows NT/2000/XP Server, and from Microsoft Project Central. As with many enterprise servers, time spent in the research and planning phases can significantly reduce maintenance costs of a server.

The following are security terms used in this document:

  • Security object: an object that can be secured with permissions granted by an administrator. Organization, projects, resources, views, and models are security objects in Microsoft Project Server.
  • Security principal: an object that can be authenticated, and thus granted permissions on a security object. Users and groups are security principals in Microsoft Project Server.
  • Permissions: an action performed on a security object by a security principal.
  • Global permission: a permission granted to the Organization security object. Global permissions typically include access to the key feature areas within Microsoft Project Web Access, as well as actions that are general to all security objects of the same type. For example, View Project Center is a global permission.
  • Object permission: a permission granted to members of a category, including permission to projects and resources. These permissions typically map to actions in Microsoft Project or Microsoft Project Web Access that first require the selection of an object and then selection of menu item or button.

Microsoft Windows Security Concepts

The Microsoft Windows family of servers uses a number of security concepts familiar to server administrators.

  • Groups

    Groups enable users to be combined into a single security principal. The group is then granted permissions on an object. Each group typically represents a collection of users with a common set of access needs. By defining a small number of groups, granting those groups permissions on objects, and then assigning users to groups, administrators can manage a small number of groups instead of a large number of users.

    An important difference between Microsoft Windows groups and Microsoft Project Server groups is hierarchical group membership. Microsoft Windows groups support both users and groups as members. Microsoft Project Server groups only support users as members, not groups.

  • Permissions

    Permissions define actions that can be taken on security objects (such as categories and organizations, discussed later in this document). Security principals (such as users and groups, also discussed later) are granted permissions on security objects. Permissions can apply to features, as well as to data. For example, Windows supports a permission to log onto a workstation, as well as read and write permissions on individual files. By providing permissions for each action possible through user and programmatic interfaces, administrators have detailed control over user access to an application.

    Permissions have three states: Allow, Deny, and Not Allowed. Allow enables the user to perform the action defined by the permission. Allow permissions aggregate across the system so that if a user is a member of three groups, but in only one group is this user allowed permission on a particular object, the user is allowed permission on the object in all three groups.

    Deny prevents the user from performing the action defined by the permission. Deny permissions always override Allow permissions. A single Deny permission may prevent the user from performing the action across multiple groups. This behavior is useful when an administrator needs to quickly prevent a feature or data from being accessed by a user or group. However, Deny permissions can also result in a denial of access that is difficult for an administrator or user to troubleshoot, given that a user can be denied access through the membership in one of many groups, and the user may not know which group has a Deny permission set. Deny permissions should rarely be used. Not Allowed is the absence of an Allow or Deny permission. A Not Allowed permission prevents the user from performing the action defined by the permission. However, it allows access to be granted through an Allow permission.

  • Access Control Entry

    Access control entry (ACE) is the combination of a security principal granted permission on a security object.

  • Access Control List

    Access control lists (ACL) are one or more ACEs specific to a security object.

Microsoft Project Server Security Concepts

Microsoft Project Server uses several security concepts introduced in Microsoft Project Central. This release also introduces a new concept, the organization.

  • Users and groups

    Users and groups are the security principals in Microsoft Project Server. Administrators should define groups that represent common needs for Microsoft Project Server features, assign those groups permissions to categories, and add users to the groups. if you define groups, users are granted the equivalent rights of the groups that they are members of. Defining groups also keeps the number of security principals with direct permissions on categories to a minimum, greatly simplifying troubleshooting access problems. Typically, membership of groups changes frequently, and permissions of groups change infrequently.

    Users and groups are managed through the Administration pages of Microsoft Project Web Access. For example, the Users pages show the current list of users created on the server, and some of a group's properties can be previewed by selecting a user. Administrators can add, modify, or delete users from this page. To create a user, an administrator specifies identity information (such as the user's name, password, and so on), and group membership for the user. Users often belong to many groups.

  • Organization

    The organization is an instance of a Microsoft Project Server. Administrators can use the organization to manage server-wide settings. Features can be allowed or denied for all users of a server. In addition, the organization enables an administrator to customize the menu structure of Microsoft Project Web Access when connecting to the server.

    Administrators can use Microsoft Project Web Access to enable or disable features and menu items for all users of an organization. This ability to disable features is useful if your organization decides not to deploy a Microsoft Project Server feature. All menus and commands associated with a disabled feature are hidden in the Microsoft Project Web Access user interface.

    Administrators can also reorganize predefined menus and menu items, and add new menus and menu items. New menus and menu items can be targeted at any Uniform Resource Locator (URL).

  • Category

    A category is a collection of projects, resources, views, and models. Object permissions are defined on categories. You cannot directly grant permissions on projects, resources, views, or models. Instead, you add objects to a category and then grant users or groups permissions on the category. When a user is granted permission on a category, the user is granted permission to all applicable objects in that category. For example, if a category contains two projects, granting a user Open Project and Save Project permissions on the category allows that user to open and save changes to both projects.

  • Views

    Views, like the views in Microsoft Project, are a collection of Microsoft Project fields, groups and filters, or charts. To provide users or groups access to a view, define the view as a category, and then grant permissions on the category to the users or groups. You can define views for the Project Center, Resource Center, and Portfolio Analyzer pages.

  • Security Rules

    Security rules are used to define the members of a category. Three project rules are supported:

    • All projects in which a resource is assigned a task
    • All projects in which a user is the project manager
    • All projects in which a manager has resources assigned to a task.

    These rules can be enabled in each category. When enabled, the rules examine each user's granted permissions on the category, and apply permissions to all projects returned by the rule for that user. Rules enable a category and permissions to be dynamic. For example, the pre-defined category My Tasks has enabled the All projects in which a resource is assigned a task permission along with a number of permissions that allow the user to view projects in the Project Center. This category allows users to automatically see any projects to which they are assigned tasks. Since the security rule searches for all assignments, the administrator does not need to manually change the projects defined in the category when new projects are published to the server.

    The deployment examples in this white paper provide detailed examples of how security rules can be used to minimize day-to-day administration.

Putting the pieces together

The following illustration shows the relationships between the security concepts. Keep in mind that security principals include users and groups, and security objects include categories and organizations.

Aa164332.projsvrsec01(en-us,office.10).gif

Figure 1. Security concept relationships

A key element of the planning and deployment process should be to define collections of needs for accessing Microsoft Project Server features (security principals). You should create a group for each collection. Each group should contain a unique set of permissions and be granted access to one or more categories. You should then assign users to groups.

Another key element of the planning and deployment process should be to define collections of project information (security objects). You should create a category for each collection, and then grant groups and users permissions to access the data in the category. You can define the collection of data in a category manually or by using security rules. Security rules allow the definition of the data in a category to be based on one of three relationships described above and the users/groups assigned permissions to the category.

Permissions define access to Microsoft Project Server features and data. ACEs tie together a security principal (user or group) with a security object (category) and with permission.

Default Security Configuration

Microsoft Project Server can support a broad range of deployments, from workgroups within single departments to multi-department enterprises. Workgroup servers are often deployed and managed by professionals who are not part of an IT department. These servers need to provide turnkey security to simplify server management. Enterprise servers are deployed and managed by IT professionals. Large organizations have more complex security requirements for both features and data and are typically willing to trade off ease-of-use for power.

Microsoft Project Central for Microsoft Project 2000 was designed primarily for workgroups. Any user of Microsoft Project can create project manager accounts on a Microsoft Project Central server. Publishing a project to the server automatically creates team member accounts on the server. Users of Microsoft Project Central are assigned one role across the server, meaning that a user assigned to the team member role for one set of projects cannot be assigned a project manager role for another set of projects. For many organizations, this security model allowed workgroups to quickly and easily setup Microsoft Project Central and minimized the need for a server administrator.

Microsoft Project Server for Microsoft Project was designed to meet the needs of both workgroups and enterprises. Customers can choose from several levels of security when setting up the server. The lowest security level provides turnkey security, supports both Microsoft Project 2000 and Microsoft Project 2002, and requires minimal administrative support. The highest security level supports only Microsoft Project 2002 and requires part-time administrative support. In addition, Microsoft Project Server allows users to be granted different permissions for different sets of projects and resources so that a user can have different roles across an organization. While the new security features in Microsoft Project Server require active planning and management by a server administrator, the features enable enterprises to customize the server to meet their needs.

Setup Options for Security Levels

During setup, the server can be configured to use low security. In this mode, Microsoft Project users can create project manager accounts on the server, and users are not required to be authenticated by the server. User accounts on the server are automatically created for resources within project plans when those plans are published to the server. This mode should be used when a server supports any Microsoft Project 2000 users, and it is identical to the functionality in Microsoft Project Central. Workgroups will typically run their Microsoft Project Server in this security mode.

Larger organizations can choose two additional security levels during server setup. Medium security does not require users to be authenticated by the server, but disables Microsoft Project users from creating project manager accounts. High security requires users to be authenticated by the server, and requires an administrator to create project manager accounts. Those customers interested in using Microsoft Project Server enterprise features are most likely to use high security. In this mode, a part-time administrator is required to create project manager accounts.

Predefined Categories and Groups

Microsoft Project Server setup creates three categories and seven groups. These groups and categories are designed to enable Microsoft Project Server to provide the same levels of security out of the box as Microsoft Project Central. The categories and groups were designed to be used together as follows:

  • Team Members group and My Tasks category

    As projects are published to the server, accounts are created on the server for any new resources in the project plan. By default, the server adds any new resources to the Team Members group, which is granted permissions on the My Tasks category. My Tasks uses security rules to contain all projects to which a team member is assigned and all of the team member's assignments. The Team Members group is generally able to view and not edit data in the category. The Team Members account is granted a number of global permissions that allow use of the Microsoft Project Web Access timesheet, status reports, and to-do list features.

  • Project Managers group and My Projects category

    Users are automatically added to the Project Managers group when a Microsoft Project Professional user publishes a project to the Microsoft Project Server and when a Microsoft Project Standard or Professional user creates a project manager account from the Collaborate tab of the Options dialog box. The Project Managers group is granted permissions on the My Projects category. The My Projects category uses security rules to contain all projects that a project manager has saved or published to the server and all assignments in the projects that a project manager has saved or published to the server. The Project Managers group is able to view and edit projects in the category. Project Managers are granted a number of global permissions that allow creation of new projects, status reports, and to-do lists. They are also granted limited permissions on the My Organization category.

  • Executives group and My Organization category

    Users who require broad visibility of the projects and resources in an organization can be added to the Executives group. This group can view any project and any resource saved or published to the server. Administrators must manually create user accounts for executives. Only team member and project manager accounts can be created automatically. The Executives group is granted permissions on the My Organization category. This category uses security rules to contain all projects, resources, and assignments published or saved to the server. The Executives group is granted global permissions to view project and resource information in the Project Center, Resource Center, Portfolio Analyzer, and Portfolio Modeler.

  • Team Leads and Resource Managers groups

    These groups can be used for users who do not manage projects but need limited ability to view and edit project information. Both groups are granted permissions on the My Projects category.

  • Portfolio Managers group

    Users who manage the enterprise global template and enterprise resources in an organization can be added to the Portfolio Managers group. These users have broad ability to create and edit data but cannot perform server administrative tasks (for example, they cannot add users or groups). Portfolio Managers are able to view and edit all projects and resources in the organization. This group is granted permissions on the My Organization category.

  • Administrators group

    The Administrators group is granted all available permissions on the Microsoft Project Server. This group is granted permissions on the My Organization category.

Microsoft Project Server can support a wide range of deployments. This section describes recommended security settings for common server deployments. There are three typical configurations an organization can use, with increasing levels of administrative maintenance:

  • Department configuration
  • Multiple department hosting configuration
  • Enterprise configuration

Department Configuration

Customers deploying Microsoft Project Server in a department can begin using the server immediately after running the Microsoft Project Server Setup program. Project manager and team member accounts can be created directly from Microsoft Project 2000 or Microsoft Project 2002. Executive accounts should be created by the administrator and added to the Executives group. Users will have access to all the workgroup features (timesheet, views, status reports, and document library). Typically, the server requires minimal administration and can be managed part-time by a user with no prior Windows NT® server management experience.

Planning Requirements

None.

Post-Setup Configuration

Executive accounts must be created and added to the Executives group. These users can view all information, but do not have the ability to edit any information.

Maintenance

As users join and leave the organization, accounts need to be added and removed. As new executives join a team, executive accounts need to be added. Generally, project manager and team member accounts are added and granted appropriate permissions automatically through the publish process.

Security Map Example for the Department Configuration

The map below illustrates the default categories and groups created by Microsoft Project Server setup. The configuration works well for a single department or business unit where executives should be able to view information for all projects and resources.

Aa164332.projsvrsec02(en-us,office.10).gif

Figure 2. Security map example for the department configuration

Multiple Department Hosting Configuration

Customers deploying Microsoft Project Server to support multiple departments need to plan for security before deploying the server. After the server is deployed, it should require minimal management. Security planning typically will require participation of an experienced Windows NT server manager.

This configuration is typical of a large organization with a number of relatively independent project teams. Team members and project managers may work on multiple project teams. Executives need the ability to easily view reports on projects for their teams but should not be able to view reports on projects for other teams. This configuration assumes that the customer is using Microsoft Project Standard and the workgroup features of Microsoft Project Server.

Planning Requirements

Planning will help you to understand which projects report to which executives.

Post-Setup Configuration

After the project and executive reporting relationships are defined, one category is created for each executive or group of executives able to view the same set of projects. A group is created for each of these categories. Executive accounts must be created and added to the appropriate executive group or groups. These users can view all information but do not have the ability to edit any information.

Maintenance

As new projects begin in a department, the projects must be added to the appropriate executive category or categories.

Security Map Example for the Multiple Department Hosting Configuration

The map below illustrates the categories and groups for an organization with two departments and two layers of executives: departmental managers and executives. Departmental managers can view only the projects and resources within their department. Executives can view all project and resources. The executives, project managers, and team member groups can be used as created during setup.

Aa164332.projsvrsec03(en-us,office.10).gif

Figure 3. Security map example for the multiple department hosting configuration

Enterprise Configuration

Microsoft Project Server is designed to support large organizations in centrally managing a portfolio of projects and resources. In an enterprise configuration, multiple departments use a centrally defined set of project, resource, and task fields, and a centrally defined resource pool. Typically, enterprise configurations must support multiple layers of management.

This configuration is appropriate for customers using Microsoft Project Professional and the enterprise features of Microsoft Project Server. Like the hosted department configuration, multiple layers of management need to access reports. In addition, enterprise configurations frequently need to support resource managers and portfolio managers. Resource managers need to be able to view projects and view and edit resource information. Portfolio managers need to be able to view and edit the enterprise global template and the enterprise resource pool.

Planning Requirements

From a security perspective, planning for an enterprise configuration is quite similar to planning for a multiple department hosting department configuration. One exception is the ability to use the RBS enterprise resource outline code. Microsoft Project Server categories support a security rule based on the RBS code. This security rule allows users and groups granted permissions on a category to view all resources managed by the user. The security rule works by:

  • Querying for the RBS value of a user assigned permissions on the category.
  • Using the returned value to find all resources with a RBS value that is a child node of the security principal's RBS value.

This security rule can significantly simplify setting resource manager permissions. However, it requires the RBS lookup table to be designed, and it requires all users to have RBS values.

Post-Setup Configuration

Typically, post-setup configuration for enterprise servers is similar to configuration of multiple-department hosted servers. Categories and groups should be defined for departmental and middle managers, as in the hosted multiple department configuration. Portfolio manager accounts should be created and added to the predefined portfolio managers group. Resource manager accounts should be created and added to the pre-defined resource managers group. The predefined resource managers group depends on all resources being assigned an RBS value.

If resources are not assigned RBS values, resource manager groups and, possibly, categories should be created. In general, the groups and categories should be designed to correspond to the reporting structure for resource managers.

Maintenance

As new projects are begun in a department, these projects must be added to the appropriate executive category or categories.

Security Map Example for the Enterprise Configuration

The map below illustrates the categories and groups for an organization with two departments and two layers of executives: departmental managers, and executives. Departmental managers can view only the projects and resources within their department. Executives can view all project and resources. The executives, project managers, team members, resource managers, and portfolio managers groups can be used as created during setup.

Aa164332.projsvrsec04(en-us,office.10).gif

Figure 4. Security map example for the Enterprise Configuration

Conclusion

Microsoft Project Server's security features extend the concepts of users, roles, and categories first introduced in Microsoft Project Central. The introduction of groups and permissions reduce the amount of security management required for departmental configurations and make it easier to deploy and manage enterprise configurations.

For More Information

More information on Microsoft Project Standard, Microsoft Project Professional, and Microsoft Project Server is available from Microsoft online.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

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 OR IMPLIED, 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.

© 2002 Microsoft Corporation. All rights reserved.