Deploy Microsoft Project Server 2002 Across Non-Trusted Domains

Published: August 1, 2003

Microsoft Corporation

Applies to:

Microsoft Project Server 2002

Summary: Deploy Microsoft Project Server 2002 across non-trusted domains.

Microsoft® Project Server 2002 can be deployed in an environment that allows users access to the server from a non-trusted domain (for example, a Windows® Workgroup environment). However, there are some limitations, especially when using SharePoint™ Team Services, Portfolio Analyzer, or publishing projects and assignments to Microsoft Project Server. In general, using Windows user accounts in non-trusted domains will not provide full Microsoft Project Server functionality and, in the cases where full functionality can be restored, may reduce the overall security of your Microsoft Project Server deployment.

Note: Allowing users to access Microsoft Project Server from a non-trusted domain, regardless of the authentication method, is less secure than requiring users to access Microsoft Project Server from trusted domains using Windows user accounts. Access to Microsoft Project Server from a non-trusted domain should only be allowed after identifying the risks to your deployment and determining whether or not the additional security risks are acceptable.

On This Page

Testing Configuration
SharePoint Team Services
Portfolio Analyzer
Publishing Resource Assignments to Microsoft Project Server

Testing Configuration

Microsoft Project tested this scenario using Microsoft Project Server in a Windows Workgroup environment (see Figure 1 below). All testing used both Microsoft Project Server and Windows user accounts. Using Portfolio Analyzer, publishing projects and assignments to Microsoft Project Server (from Microsoft Project Professional 2002), and using SharePoint Services were all determined to have limitations.

• The Microsoft Project Server 2002, SQL Server 2000, Analysis Services, and SharePoint Team Services server computers were all configured in the same Windows Workgroup and Windows domain.

• The project manager’s computers were set up in a separate Windows Workgroup environment, or in a separate non-trusted Windows domain, with Microsoft Project Professional 2002 and Microsoft Project Web Access available.

• Team members (resources) were set up to access Microsoft Project Server using Microsoft Project Web Access from a separate, non-trusted Windows domain and from another Windows Workgroup environment.

Figure 1: Configuration used for testing Microsoft Project Server 2002 in a Windows Workgroup environment

SharePoint Team Services

Users creating and accessing the Documents and Issues features stored on the server running SharePoint Team Services experienced the following:

• Project managers with Microsoft Project Server user accounts were able to create subwebs on the server running SharePoint Team Services when publishing projects from Microsoft Project Professional. This behavior works because the SharePoint Team Services administrator user account (STSAdmin) that enables subweb creation is being passed from the Pscomplus.exe tool in the same way as it would be from a trusted domain.

• Project managers and team members using Microsoft Project Web Access were required to enter their Windows user name and password when attempting to access the Documents and Issues areas of Microsoft Project Web Access. A solution is to create a local Windows user account that can be used to allow the same functionality for users accessing SharePoint Team Services features, except for the Issues assignment notifications feature, which will not work because it relies on a user’s Windows user account to resolve the e-mail address. If you use a single, local Windows user account to provide access to SharePoint Team Services features, all Issues and Documents owners will be the same user. Note that this local user account needs to be added as an admistrator to all SharePoint Team Services subwebs.

Portfolio Analyzer

Microsoft Project Server, SQL Server 2000, and Analysis Services server computers must all be in the same domain in order to provide full Portfolio Analyzer functionality. Users attempting to create Portfolio Analyzer views and access the OLAP cube from a non-trusted domain experienced the following:

• Authentication to the OLAP cube requires Windows authentication. If the user’s local credentials are not recognized, as is the case when users access Portfolio Analyzer from a non-trusted domain, access to the OLAP cube will be denied. If you want to allow users from non-trusted domains access to Portfolio Analyzer, they must be explicitly granted permission to access the SQL Server 2000 and Analysis Services server computers as Windows user account users.

If a user in a non-trusted domain attempts to access Portfolio Analyzer from Microsoft Project Web Access, they will receive the error “Unable to access the Microsoft Portfolio Analyzer OLAP Cube” unless the user is able to specify a Windows user account to the Analysis Services server. There are two ways to pass the OLAP Administrator account:

• Create a local Windows user account that has been granted permission to view OLAP cube data. Use this account to enable access to Portfolio Analyzer for users in a non-trusted domain. Note that this is not an ideal solution, as this also allows access to the SQL Server 2000 and Analysis Services computers and should be treated as a potential security issue.

• Configure Portfolio Analyzer so that it is accessible using HTTP (this will require using SQL Server 2000 Enterprise Edition), and then enable Secure Sockets Layer (SSL). There are two options: allow a user to log on with a set of credentials created at the Analysis Services computer when they are asked to enter a user name and password; or embed the user name and password in the connection string when creating the view (be sure to uncheck the Show Toolbar option, to hide the connection string). Using HTTPS is the most secure option. For more information about configuring Analysis Services to be accessible using HTTP, see the section titled “Set up Analysis Services to be accessible using HTTP” in the Microsoft Project Server 2002 Installation Guide in the Microsoft Download Center.

Publishing Resource Assignments to Microsoft Project Server

Users accessing Microsoft Project Server from a Windows Workgroup environment experienced the following when publishing resource assignments to Microsoft Project Server:

• Publishing resource assignments worked when Microsoft Project Server user accounts were used. A project manager can publish to Microsoft Project Server using Microsoft Project Professional. Both project managers and team members were able to log on to Microsoft Project Web Access and access Microsoft Project Server data without any problems. Project managers were able to update using Microsoft Project Web Access and view these updates in Microsoft Project Professional.

• Publishing did not work when Windows user accounts were used. Project managers experienced more serious problems: during startup, Microsoft Project Professional is not able to recognize Microsoft Project Server. There is no supported workaround to resolve issues related to publishing projects to Microsoft Project Server when using Windows user accounts. For other Windows applications, a solution to allow server-client communication would be to create matching accounts on the server and client. However, creating matching user accounts for the project manager and team members on the Microsoft Project Server computer does not work and synchronizing user accounts is not a reliable way to overcome this issue. In the case of a Novell environment, it should be noted that Novell is not the problem. Customers using Novell for data sharing and storage, print spooling, and other activities, will still be able to perform those activities in an environment that includes Microsoft Project Server. Novell also provides user account synchronization with the Novell Directory Service. However, Microsoft Project Server is currently not able to take advantage of this service.