PHD Security and Network Planning Guide R300: Uniformance®

Uniformance
PHD Security and Network Planning Guide R300
Copyright, Notices, and Trademarks

Honeywell International Inc. 2010. All Rights Reserved. While this information is presented in good faith and believed to be accurate, Honeywell disclaims the implied warranties of merchantability and fitness for a particular purpose and makes no express warranties except as may be stated in its written agreement with and for its customers. In no event is Honeywell liable to anyone for any indirect, special or consequential damages. The information and specifications in this document are subject to change without notice. Honeywell, TotalPlant, Uniformance PHD, Experion, Plantscape and Business FLEX are U.S. registered trademarks of Honeywell Inc. Other brand or product names are trademarks of their respective owners.
Release Information
Uniformance 300 Document Revision: 15 Document Revision Date: April, 2010 Document ID: am0651 Document PARs Fixed:
Revision 11 12 13 14 15 PAR 1-3MRIUN 1-5RU4PG n/a n/a 1-F9T3FP Correct RDC reference in table in section 8.2. Clarify that client communication to a default Oracle installation is through multiple ports. Update the number of Experion Servers that can be served by a single PHD collector node from 3 to 7 for PHD R210.1.3 and later. R300 updates Edited the Port Assignment diagram on page 24
Honeywell Process Solutions 1860 W. Rose Garden Ln Phoenix, Arizona 85027-2708 USA
ii Uniformance - PHD Security and Network Planning Guide
Support and Other Contacts

United States and Canada Contact: Honeywell Solution Support Center Phone: 1-800 822-7673. Calls are answered by dispatcher between 6:00 A.M. and 4:00 P.M. Mountain Standard Time. Emergency calls outside normal working hours are received by an answering service and returned within one hour. Mail: Honeywell HPS TAC, MS L17 1860 W Rose Garden Ln Phoenix, Arizona 85027-2708 Europe Contact: Phone: Facsimile: Mail: Honeywell TAC-EMEA +32-2-728-2732 +32-2-728-2696 TAC-BE02 Hermes Plaza Hermeslaan, 1H B-1831 Diegem, Belgium Honeywell Global TAC Pacific 1300-300-4822 (toll free within Australia) +61-8-9362-9559 (outside Australia) +61-8-9362-9564 Honeywell Limited Australia 5 Kitchener Way Burswood 6100, Western Australia GTAC@honeywell.com
Pacific Contact: Phone: Facsimile: Mail:
Email: India Contact: Phone: Facsimile: Mail:
Email:
Honeywell Global TAC India +91-20- 66039400 +91-20- 66039800 Honeywell Automation India Ltd. 56 and 57, Hadapsar Industrial Estate Hadapsar, Pune 411 013, India Global-TAC-India@honeywell.com
Uniformance - PHD Security and Network Planning Guide iii
Korea Contact: Phone: Facsimile: Mail: Honeywell Global TAC Korea +82-2-799-6317 +82-2-792-9015 Honeywell Co., Ltd 4F, Sangam IT Tower B4-4 Block 1590, DMC Sangam-dong, Mapo-gu, Seoul, 121-836, Korea Global-TAC-Korea@honeywell.com
Email:
Peoples Republic of China Contact: Honeywell Global TAC China Phone: +86- 21-52574568 Mail: Honeywell (China) Co., Ltd 33/F, Tower A, City Center, 100 Zunyi Rd. Shanghai 200051, Peoples Republic of China Email: Global-TAC-China@honeywell.com Singapore Contact: Phone: Facsimile: Mail: Global TAC South East Asia +65-6580-3500 +65-6580-3501 +65-6445-3033 Honeywell Private Limited Honeywell Building 17, Changi Business Park Central 1 Singapore 486073 GTAC-SEA@honeywell.com Global TAC Taiwan +886- 7- 536 2567 +886-7-536 2039 Honeywell Taiwan Ltd. 17F-1, No. 260, Jhongshan 2nd Road. Cianjhen District Kaohsiung, Taiwan, ROC Global-TAC-Taiwan@honeywell.com
Email: Taiwan Contact: Phone: Facsimile: Mail:
Email:
iv Uniformance - PHD Security and Network Planning Guide
Japan Contact: Phone: Facsimile: Mail: Global TAC Japan +81-3-6730-7160 +81-3-6730-7228 Honeywell Japan Inc. New Pier Takeshiba, South Tower Building, 20th Floor, 1-16-1 Kaigan, Minato-ku, Tokyo 105-0022, Japan Global-TAC-JapanJA25@honeywell.com
Email:
Elsewhere Call your nearest Honeywell office. World Wide Web Honeywell Solution Support Online: http://www.honeywell.com/ps Training Classes Honeywell Automation College: http://www.automationcollege.com
Uniformance - PHD Security and Network Planning Guide v
vi Uniformance - PHD Security and Network Planning Guide
Contents
1. Introducing PHD Security ................................................................................. 11 1.1 1.2 1.3 1.4 1.5 1.6 2. About This Document ............................................................................. 11 Executive Summary................................................................................ 11 PHD Security Overview .......................................................................... 12 Windows NT Security Overview ............................................................. 13 SQL Server Security Overview............................................................... 14 Integrated NT Security Overview............................................................ 15
Technical Considerations for Security............................................................ 17 2.1 2.2 2.3 2.4 2.5 2.6 Local Group Requirements PHD Server ............................................. 17 Local Group Requirements SQL Server.............................................. 17 Local Groups used by the PHD Configuration Database and Tools ... 17 SQL Server Roles................................................................................... 18 PHD Security Account Requirements .................................................... 19 User Logon and Validation ..................................................................... 19 Port Utilization......................................................................................... 21 Default PHD port assignments............................................................. 22
3.
User Security Strategies ................................................................................... 25 3.1 3.2 3.3 Functional Areas of Uniformance Security ............................................. 25 Security for PHD System Management.................................................. 25 Access to PHD Data............................................................................... 26 Uniformance R150 ............................................................................... 26 Uniformance R200/201 ........................................................................ 28 Uniformance R210 and later ................................................................ 28 Uniformance R300 ............................................................................... 28 Remote API Server (RAPIServer) .......................................................... 28
3.4 4.
Special Considerations for PHD Security ....................................................... 31

Uniformance - PHD Security and Network Planning Guide vii
Contents
4.1 4.2 4.3 4.4 5.
Cross Domain PHD Access .................................................................... 31 Logon Behavior of Client Software ......................................................... 31 Uniformance Desktop Authentication...................................................... 31 PHD Data Access through a Firewall...................................................... 32
Appendix A Windows Security Overview ..................................................... 33 5.1 Windows Security Model......................................................................... 33
6.
Appendix B Ports ............................................................................................35 6.1 6.2 6.3 6.4 6.5 6.6 Ports Used by Windows Services ........................................................... 35 Securing Port 445 ...................................................................................37 Authentication of Users with Port 445 Blocked ....................................... 38 Uniformance R210 and later Client Access with Port 445 Blocked ........ 39 Data Collection with Port 445 Blocked.................................................... 39 Tag and User Update with Port 445 Blocked.......................................... 40
7.
Appendix C - How to Configure a Firewall for Domains and Trusts............. 41 7.1 7.2 Windows NT............................................................................................41 Windows Server 2003 and Windows 2000 Server ................................. 41
8.
Appendix D Firewall Configuration Examples ............................................. 45 8.1 8.2 Example 1 - High Security Configuration ................................................ 45 Example 2 - Typical Less Secure Configuration ..................................... 47
9.
Appendix E PHD Shadow Configuration ...................................................... 51 9.1 9.2 Example Network Diagram of PHD Shadow........................................... 51 PHD Shadow Configuration Checklist .................................................... 52
10.
Appendix F PHD Peer Configuration ............................................................ 53 10.1 10.2 Example Network Diagram of PHD Peer ................................................ 53 PHD Peer Configuration Checklist.......................................................... 53
viii Uniformance - PHD Security and Network Planning Guide
Content
Index 55
Uniformance - PHD Security and Network Planning Guide ix
Contents
Table of Figures
Figure 1 Diagram of PHD Port Assignments ..............................................................24 Figure 2 Diagram of High Secure Configuration .........................................................45 Figure 3 Diagram of Less Secure Configuration.........................................................47 Figure 4 Diagram of PHD Shadow Configuration .......................................................51 Figure 5 Diagram of PHD Peer Configuration.............................................................53
x Uniformance - PHD Security and Network Planning Guide
1. Introducing PHD Security

1.1 About This Document
Uniformance PHD supports numerous network topologies and configurations to meet a wide variety of customer needs. This document describes common PHD configurations and identifies best practices for securing these networks. Honeywell services are available to assist with network planning for customers with specific requirements. REFERENCE
For an in-depth description of the overall PHD system, including configuration and management details, refer to the Uniformance - Process History Database System Manual (pim0301).
1.2
Executive Summary
Uniformance R150 provided very flexible access, for desktop users and other clients, to the PHD Server for the purpose of reading and modifying collected data. Essentially any connection request was honored and that client was granted full access to the collected data. However, increased security awareness resulted in a demand by customers for better control of access to the companys sensitive data. The Uniformance 200 release provided the basis for an improved security infrastructure. User validation was modified to use Windows NT User validation. This means that processes, including PHD, can be run as specific users and thereby be granted that users rights. Administrators are able to tailor user rights to specific user responsibilities and are ensured that applications such as PHD honor these rights. Therefore, users can not perform actions through PHD applications that they are not allowed to perform by other means. However, to help customers transition to the new security model, the Uniformance R200 and R201 Desktops will fall back to the Uniformance R150 behavior of creating a connection with public permissions to tag data if authentication fails. To provide a more secure environment and ensure that users have access to only the data and functions for which the administrator has explicitly granted permission, the Uniformance R202 and later Desktop no longer supports the Uniformance R150 behavior using the Legacy API. Users must be validated in the domain where the PHD Server resides. If the user can not be validated, the connection is terminated. For a user to be successfully validated, one of the following conditions must exist.

The user id must be defined in the domain where the PHD Server resides, or There must be a trust relationship between the domains (Can be a one way trust) with the user id defined in the trusted domain.
Uniformance - PHD Security and Network Planning Guide 11
1 Introducing PHD Security 1.3 PHD Security Overview
To assist customers in the transition to a fully secure environment, the Uniformance R300 PHD Server continues to support Uniformance R201 or earlier desktops connection as invalidated users using the Legacy API. The trade-off is that, by not using the Uniformance R202 and later Desktop, users do not have access to Uniformance R300 features such as sub second timestamps, new data types, or configurable engineering units. However, some of the Uniformance R202 security improvements were deemed as being too strict for some sites. Of specific concern was the need to establish trust relationships between domains and the implications of this on the site network topology. Additionally, customers needed Uniformance to be more firewall friendly, to be less dependent on named pipes and well-known ports, and to provide secure remote access to the PHD Server. Uniformance R210 and later address these customer concerns.
1.3
PHD Security Overview

Uniformance PHD supports numerous network topologies and configurations. In response to customer demands for:

Easier management of user IDs More control of access to PHD data Greater differentiation of users (the ability to more closely match users to specific functions and data subsets) Support for firewalls and segmentation of networks
Uniformance PHD has adopted the Windows NT Security Model (see Appendix A). Windows provides for a comprehensive security structure including the partitioning of systems and users into separate domains. Users on one domain can only be validated on the other domain if a trust has been established between the two domains. A trust relationship is one in which one of the domains trusts the other to perform authentication. The domain that trusts the other accepts logon requests for the users who exist in the other domain. The one exception to the requirement of a trust relationship between domains is when the identical user (including identical password) exists in each domain. In this case, the user can be validated from one domain to the other even though a trust does not exist between the domains. The Uniformance R20x and R30x PHD Server supports two modes of access.

Through the R20x/R30x API Server for validated desktop users Through the Legacy API Server for desktop users who can not be validated or programs that were developed to connect to legacy API.
Uniformance R210 and later provide an additional mode of access through the Remote API Server to facilitate access from untrusted environments and through firewalls. While the Uniformance R200 and R201 desktops support both methods of access, the Uniformance R202 Desktop requires that the user be validated. The Uniformance R201 or earlier
12 Uniformance - PHD Security and Network Planning Guide
1 Introducing PHD Security 1.4 Windows NT Security Overview
desktops can continue to be used for invalidated access to the Uniformance R202 and later PHD Server. However, since these continue to use the Legacy API Server some of the enhanced functions of the Uniformance R202and later PHD Server are unavailable. These include: Configurable engineering units Sub-second timestamps Various new data types
For example, if a query is made on a double precision number, the result is returned to the Uniformance R201 Desktop as a single precision number. Validation of users is also a requirement for using Uniformance PHD when integrated into an Experion system. All software integrated into an Experion system must meet the requirements as described in the (Experion) security reference model. 1
1.4
Windows NT Security Overview

The Windows NT security model assumes centralized control for the administration of user accounts and permissions. Windows NT organizes resources and the users of those resources into a domain. Resources include the services provided by servers within the domain (such as shared facilities being printers or directories, files and databases). Within the domain, users are assigned to one or more global groups depending on the functions the user performs (roles) within the domain. The global groups are, in turn, assigned to local groups. Local groups are maintained on each machine within the domain and specific permissions providing access to the resources available are assigned to each local group. Global groups are maintained on the primary domain controller and replicated to the backup domain controllers. Microsoft recommends that groups be used and defined as follows:

At the computer hosting the resource, create a local group and assign the permissions the local group will need to access the resource. At the domain controller, create a global group and add the users who need access to the resource. Add the global group to the local group.
Since Windows NT, Windows creates unique security identifiers for each user and group. When a user logs on, a domain controller validates the account and password and assigns an access token that remains valid until the user logs off. The access token consists of the username as represented by a Security ID and the groups to which the user belongs as represented by Group Ids. When an administrator grants or denies access to a resource based on a user ID or group, the user's Security ID or the group's Group ID is added to the access control list for the resource When the
Staggs, K. (2005) Experion System Security Reference Model, Honeywell Process Solutions, p.10.
1 Introducing PHD Security 1.5 SQL Server Security Overview
user attempts to use the resources, the access control list for the resource is compared to the Security and Group IDs listed on the access token. If a matching ID is found, the corresponding permissions are granted.
1.5
SQL Server Security Overview

The SQL Server database uses Windows authentication for validating user access to the database. This is aligned with the Integrated NT Security mode implemented in previous PHD releases. In this case, your Windows credentials determine the roles assigned to you. These roles determine the users access to the database. For R300, there are four security roles as follows:

Operator This security level allows read access only to the configuration data in the R300 database. You can access the configuration data using the PHD Server. Engineer This security level allows read/modify/delete access to the database configuration data. This does not allow database administration activities. Product Administrator This security level allows you to control the creation/upgrade/maintenance and operation of the SQL Server database, the PHD Server and applications. System Administrator This security level allows full control over the operation of the Windows system. The System Administrator is the standard Administrator account.
The PHD Configuration Database consists of two databases.

PHDCFG PHDAPP
The PHDCFG database contains three schemas.

PHDCFG This contains the tables that store all configuration records except auditing. PHDAUDIT This contains the tables that store auditing configuration records. DBO This contains synonyms for all IP views.
The PHDAPP database contains four schemas.
PHDCEJ This contains the tables that store the data records updated by the CEJ application.
1 Introducing PHD Security 1.6 Integrated NT Security Overview
PHDAPP This contains the tables that store the data records used by the Phd-ToRel application. AFM This contains the tables that store data the data records used by the AFM application. DBO This contains synonyms for all IP views.
1.6
Integrated NT Security Overview

Maintaining and managing two sets of usernames, passwords, and permissions/privileges is an arduous task. It is necessary to control access to the database and grant privileges within SQL Server dependent upon the Windows username. Integrated NT Security (INTS) enables you to access all required resources without providing multiple user names and/or passwords. All the user's permissions are set on logging on to NT. While accessing the SQL Server database, the NT username (used for logging on to NT) and domain are passed on to SQL Server. This information is required to know the groups the user belongs to. The user's NT group affiliation determines which SQL Server roles are assigned. Thus your Server permissions can be managed by controlling which NT groups you are assigned to. This diminishes the need to manage user accounts in both NT and SQL Server and across multiple systems. The impact of INTS must be fully understood to minimize implementation problems. The following areas are directly affected by INTS.

Local Group Requirements PHD Configuration Tool
1 Introducing PHD Security 1.6 Integrated NT Security Overview
2. Technical Considerations for Security

2.1 Local Group Requirements PHD Server
PHD Server requires that the following local groups be created on the host machine:
NT Local Group Product Administrator PHD_VIEW (Optional group) PHD_INTERFACE_* (Optional group) PHD_ARCHIVE_* (Optional group) Permissions Full Control of the PHD and RDI Servers Permission to view data. Based on the default NT "Everyone" group. Where "*" is replaced with the actual RDI name. Full Control of the named RDI. Replaces PHD_PUTDATA and PHD_SECURITY. Where "*" is replace with the archive name. Full control of the named archive. Replaces PHD_EDITDATA.
2.2
Local Group Requirements SQL Server

Standard Microsoft local groups
Local Groups used by the PHD Configuration Database and Tools Administrators This group is used by the Database Administrator to perform SQL Server tasks such as upgrade and backup. Product Administrators This group is used by the PHD administrator. Members of this group are the owners of the database. They execute permissions on all read and write stored procedures in both the PHDCFG and PHDAPP databases. Engineers This group is allowed to perform read and write tasks. Members of this group are provided the following permissions.

Honeywell installed local groups
Execute permissions on all the read and write stored procedures in the PHDCFG schema. Execute permissions on the read stored procedures in the PHDAUDIT schema. Execute permissions on all the read and write stored procedures in the PHDCEJ, PHDAPP and AFM schemas. Select privilege on all IP views.
Operators This group is allowed to perform read-only tasks. Members of this group are provided the following permissions.
Execute permissions on all read stored procedures in the PHDCFG schema.

2 Technical Considerations for Security 2.3 SQL Server Roles
Execute permissions on all read stored procedures in the PHDCEJ and PHDAPP schemas. Select privilege on all IP views.
Privileges that are assigned to users or roles belong to two categories.

System privileges for tasks that may be executed within the database to add, modify or remove database system objects such as users, tables, views, and so on. Object privileges for actions that may be taken within database objects. These include the ability to select, alter, delete, insert, or update data in a specific table or set of tables.
2.3
SQL Server Roles

The following table illustrates the SQL Server users and the corresponding roles.
SQL Server BUILTIN/Administrators HOSTNAME/Product Administrators HOSTNAME/Engineers HOSTNAME/Operators SQL Server Roles sysadmin public public public public
The following table illustrates the PHDCFG Database users and the corresponding roles.
Database Users (PHDCFG) Dbo Product Administrators Engineers Operators PHDCFG db_owner db_owner PHDReadWrite, PHDAuditRead, PHDIPRead PHDReadOnly,PHDIPRead db_ddladmin Database Roles
2 Technical Considerations for Security 2.4 PHD Security Account Requirements
The following table illustrates the PHDAPP Database users and the corresponding roles.
Database Users (PHDAPP) Dbo Product Administrators Engineers db_owner db_owner PHDReadWrite,PHDIPReadWrite, AFM_ReadWrite_Role,EA_READWRITE _ROLE PHDReadOnly,PHDIPRead, EA_READONLY_ROLE db_ddladmin Database Roles
Operators PHDAPP
2.4
PHD Security Account Requirements

Previous versions of PHD supported two client security models. They are: Standard and Integrated NT security.

With the Standard security, separate login accounts are required for the PHD Configuration Tool, PHD Data Access, and Configuration database. With the Integrated NT security, the Windows login is assigned to a Windows local group that is granted permission to the SQL Server database. A secondary login account is not required.
In versions prior to R300, the service log on account used by the PHD Server and RDI Server services on the PHD Shadow and PHD collectors had to be an account that belonged to the Administrators and PHD_MANAGER local groups of the machine. With R300, these requirements have been removed. These services can now be assigned to the more secure Network Service account which has less privilege than the Administrator user.
2.5
User Logon and Validation

Uniformance R150 and earlier, permitted connection to the PHD Server regardless of whether the user was a validated PHD user or not. Each of the Uniformance R150 services ran as a system service. Each connected user borrowed the PHD Servers access token thereby receiving public permission to tag data. Every user is granted the same access because the PHD Server is unable to distinguish between users. While flexible, this behavior created security vulnerability by allowing virtually any user to
Uniformance R150
2 Technical Considerations for Security 2.5 User Logon and Validation
make a connection to the PHD Server and to retrieve data - limited only by whatever tag security was enabled. Uniformance R150 behavior allows invalidated users to bypass a firewall existing between the users domain and the domain of the PHD Server. This implementation also prevents the use of Integrated NT Security (INTS). Uniformance R200/201 The Uniformance R200 release introduced the Legacy API service, which duplicates the functionality of the R150 API, but which also implements Windows NT User validation. A Uniformance R200/201 Desktop first connects to the Legacy API over port 3000; the Legacy API validates the user through the standard Windows NT User validation techniques, requests the Named Pipe Server, and attempts to connect over the Named Pipe as a validated user. If this fails, the Legacy API drops into the Uniformance R150 behavior where the Uniformance R200/201 Desktop user is permitted to use the Legacy APIs access token thereby receiving public permission to tag data. However, if the Named Pipe connection is successful, the Legacy API is passed the Uniformance R200/201 Desktop users access token. The users access token and the Legacy APIs access token are merged to determine the Uniformance R200/201 Desktop users access rights to PHD tag data. Various Uniformance R200/201 Desktop applications, such as the Excel Companion and Process Trend, permit an explicit login to obtain access to tag data not accessible as an invalidated user. Thus, if a "Specified operation failed" or "Tag Read Access Denied" error message is observed, it may be necessary to force an explicit login to obtain access rights over those granted by default. Uniformance R202 The R202 Desktop applications connect to the PHD Server exclusively through the R202 API. When the user connects through the R202 API, the API validates the user through the standard Windows NT User validation techniques. If the user is not a valid Windows User, the connection is immediately dropped, to prevent unauthorized users from connecting to PHD and possibly accessing PHD data they are not authorized to see. If the user is a valid Windows user, a connection is established, and the users access token establishes their access rights to PHD tag data. Uniformance R210 and later Uniformance R210 and later expand on the security features introduced with Uniformance R202. In response to customer concerns regarding the use of Named Pipes across firewalls and the requirement to leave common ports unblocked, Uniformance R210 and later permit the customer to select Named Pipes or Secure Sockets for communication between servers and between the server and the desktop.
2 Technical Considerations for Security 2.6 Port Utilization
2.6
Port Utilization
PHD uses certain standard Windows services that require specific ports. All the ports used directly by PHD can be configured by the site. (For more information about Windows Security, see Appendix A).
Overview
Uniformance R150 Uniformance 150 and earlier did not perform authentication between PHD servers so there was no dependency on any specific ports. Uniformance R20X Uniformance R200 through R202 use Named Pipes for authentication. Thus, if communication through a firewall is required, choose one of the following options.

The ports referenced in Appendix C must be open, or The customer must implement the work-around documented in the following section.
NOTE: The required ports are mandated by the Windows OS and the port assignments cannot be changed.
Uniformance R210 and later Uniformance R210 and later use Named Pipes for authentication by default. On the client, setting the HKEY_LOCAL_MACHINE\Software\Honeywell\Uniformance DWORD called UseFirewallSecurity to a non-zero value causes the client to try authentication through Secure Sockets. On the Uniformance R210 and later PHD Server, setting the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servcies\PHDServer\Para meters DWORD called DisableNamedPipeSecurity to a non-zero value causes the server to disable the creation of the Named Pipe completely. The client, therefore, cannot connect using the Named Pipe. If the client is not configured to use Secure Sockets, it will not try Secure Sockets for authentication and will fail to connect. All clients must use the Uniformance R210 or later Desktop version, because earlier versions of the Desktop will not be able to connect. By leaving the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servcies\PHDServer\Para meters
DWORD called DisableNamedPipeSecurity as zero, it is possible for clients to connect through Named Pipes or through Secure Sockets. Depending on whether port TCP 445 is blocked at the firewall, the Named Pipe connection may or may not be successful. Uniformance R300 With R300, the default use of Named Pipes, which requires port 445 utilization, is eliminated. PHD 300 authenticates users based on the user account for which the application runs. Explicit authorization requests are ignored. PHD300 only supports INTS connections. The user account is used for running the applications with privileges to gain access to the required tags.. To connect PHD 210 and 215 systems (VisualPHD) to a PHD300 server, disable the Named Pipes on the clients (or enable the Named Pipes on the server). To disable named pipes on the client, create the following registry settings. HKLM\Software\Honeywell\Uniformance\UseFirewallSecurity = 1 (REG_DWORD) HKLM\Software\Honeywell\Uniformance\UseFirewallPackage = NTLM (REG_SZ)
Default PHD port assignments PHD, by default, uses the following ports for various internal functions. However, the specific port assignments are configurable and may be changed as required.
Service APIServer APIServer APIServer LegacyAPIServer LegacyAPIServer RemoteAPIServer RemoteAPIServer Listening Port # TCP 3100 TCP 3100 TCP 3101 TCP 3000 TCP 3100 TCP 3150 TCP 3150 Function Use to connect applications Listening port for client connections Telnet to API Server R150 client connections Use to connect to apiserver Use to connect to apiserver Desktop: Process Trend Automation Object via Remote PHD API
Service RemoteAPIServer
Listening Port # TCP 3151
Function Telnet to RemoteAPI Server Communication from APIServer, RemoteAPIServer, RDIServer
PHDServer
TCP 2000
SQL Server
TCP 1433
(see NOTE in Figure 1)
Desktop: Tag Explorer
RDIServer RDIServer
TCP 4100 TCP 4101
Listen port Telnet to RDI Server Robust Data Collection: one pair of ports per RDI where n=0,2,4 (Port Range 49152 65534) Gateway RDI: one port per RDI where n=0,1,2,3. (Port Range 49152 65534)
Shadow Server (Robust Data Collection) Peer Server (Gateway RDI)
TCP 5420n/5420n+1 (example) TCP 4950n (example)
REFERENCE - INTERNAL
For more information about modifying the port settings, refer to the following Uniformance documents. Uniformance Robust Data Collection User Guide (pim 3501.pdf) Uniformance Gateway Real-Time Data Interface Installation Guide (rdi 3501.pdf) Uniformance Virtual Tag RDI Installation Guide (rdi 3601.pdf)
Figure 1 Diagram of PHD Port Assignments
NOTE: With a default SQL Server installation, client communications to the SQL Server database use multiple ports. You can set a registry key on the client computer to force the SQL Server listener to use the single specified port for all connections. However, for firewall configuration, consult your SQL Server/firewall subject matter expert, the SQL Server documentation, the relevant firewall documentation, and/or Honeywell support services - as this configuration is outside the scope of the Honeywell products.
3. User Security Strategies

3.1 Functional Areas of Uniformance Security
Uniformance security is divided into two functional areas.

Managing the PHD system. Gaining access to PHD data.
The first is the responsibility of the PHD Administrator. The second may be a general requirement with users restricted to specific subsets of the data.
3.2
Security for PHD System Management

The PHD Administrator performs system management functions, which are not available to the application users. Uniformance PHD follows the Windows Integrated Security Model (also known as INTS). In this model, domain users are assigned to global groups. The global groups are assigned to three specific local groups on the SQL Server. The three local groups are assigned to the corresponding SQL Login accounts. The SQL Login accounts are assigned access permissions to the various SQL Server objects. Through this model, the members in a global group can be traced to access privileges to SQL objects. The following list includes the management functions.

Application install or upgrade Create a new user, assign existing roles Create a new role, assign existing users Assign an existing user to an existing role Assign a new user to a new role Change logon password Change roles assigned to a user Change role permissions Change menu access for a role Deactivate a user
For R300 and later, selected administration rights may be granted to specific users. PHD uses Windows NT local groups to determine the permissions of a user to perform system management functions.
3 User Security Strategies 3.3 Access to PHD Data
3.3
Access to PHD Data

Access to PHD data is based on the ability to read or write tag data. In PHD, access to specific subsets of the data is based on roles. Roles are assigned functional levels of permission. Users may belong to more than one role definition and inherit the highest level of permission from each role. The default behavior of Uniformance R150 allows connections regardless of whether the user was a valid Windows user or not. Each connected user was allowed public permissions to tag data. Thus, the only security method available was based on tag security. When Uniformance R150 is first installed, it allows all users full access to all tags. This is known as Public access. A tag that has no restrictions assigned for read access is referred to as a public read tag. Similarly, a tag that has no restrictions assigned for write access is referred to as a public write tag. By default, all PHD tags are public read and write tags. Read and write access to tags may be managed independently. For example, read access could default to public, while write access could be managed as private, with access to write tags granted to specific users and roles. Conversely, if there are restrictions on who can read or write a tag, it is no longer a public read or write tag and is now known as a private tag. If a site wants tag security, it is necessary to establish some general tag restrictions and to disable public security. To enable private security, public security must be disabled by setting the following system parameters to zero (0) through a PHDMAN SET command on the PHD Server. These commands should also be placed in the phdparams.cmd file for future startups. PHDMAN SET TAG_PUBLICREAD 0 PHDMAN SET TAG_PUBLICWRITE 0 0 = public disabled, private enabled 1 = public enabled, private disabled Default values = 1 (public enabled) When public security is enabled, all users have access to the tag by default. When an entry for a tag is made in the PHD Security Configuration form, access to this tag is no longer public, and each User/Role requiring access to this tag must be explicitly configured to have the required access. With private security enabled, access to tags must be provided by entries in the PHD Security Configuration form for each User/Role that is to have tag access. If a site wants private security, the next step is to determine how the site wants to manage tags.
Uniformance R150
3 User Security Strategies 3.3 Access to PHD Data
Assignment of tag security roles can be done by object. An object can be an RDI name, a Function Group name, or a tag name. Function Groups are groupings of PHD Function Definitions and 1, 2, 3D Correlation Table Functions. Individual PHD Tag Security A user or a role has access to specified tag(s). If a user is not a member of at least one role matching the list of required roles assigned to read, write, or configure a particular tags data, PHD will deny the attempted access to that tag. Tag Names can be wild carded:

Underscore (_) for single character wildcard Asterisk (*) for multiple character wildcard
PHD Function Security A user or role has access to a specific function group. The functions are grouped together through the Function Group entry on their configuration forms. The user must first define the Function Group names in the Fixed Plant Databook. PHD Collector (RDI) Security A user or role has access to tags on a specific collector. Access Privileges

Read - Read data for all tags matching the object name. Write - Write (Put) data to all tags matching the object name. (Tags must have Put Download enabled and RDI must be configured to do control.) Configure - Allows the role to configure the object name.

T - modify or delete tags C - modify, delete, or create tags on the collector F - modify, delete, or create functions in the function groups
Send Changes to PHD - Triggers PHD to update its internal security for the tags affected. The application does this automatically when the form is closed. Provide access to all tags or provide access to a pattern of tags. For example, provide read/write access to Area A (such as tags with names A*), but read-only access to Area B. Use collector-based security. People who configure tags need access to multiple collectors. Assign a collector to a role.
For users who do not configure tags
For users who configure tags
3 User Security Strategies 3.4 Remote API Server (RAPIServer)
Uniformance R200/201 Uniformance R200 introduced user validation. This permits customers to associate access to specific functions and data to specific users, thereby increasing security. Valid Windows users are users that

Are known in the current domain, or Are users who are defined in a trusted domain, or lastly Are identical to a user in this domain (including password).
In the case that the user is a valid Windows user, a connection is established, and the user is granted access rights to PHD tag data. For companies that are unable to implement proper user cross-domain validation procedures, there are a number of ways to get around this.

Place a shadow server on the same domain as the users and request data from that shadow server. Add the users to the same domain as PHD Uninstall the R202 Desktop and install the latest version of R201 which uses the R150 legacy API
For tags update and users update to work across a firewall with ports UDP 137 & 138 and TCP 135, 139 and 445 disabled, the accounts that start the Uniformance PHD Server and Uniformance RDI Server services on the Shadow Server and on the Buffer nodes across the firewall must be equivalent accounts (same local username and same password). In addition, a command file to execute the PHDMAN UPDATE TAG FULL, PHDMAN UPDATE TAG, PHDMAN UPDATE USERS on the buffer either on demand or on a schedule basis must be created. Uniformance R210 and later In R210 and later, if a user cannot be validated as a valid Windows user, the connection to PHD is not allowed, thereby strengthening the security to tag data by ensuring that only valid users are able to access the PHD system. Uniformance R300 In R300, the user validation is performed as above for R210, however the tag update and user updates have been modified to eliminate the use of the ports specified above and further can be done without the necessity of creating command files on the buffer node to perform the updates. The updates are now able to be performed through the firewall.
3.4
Remote API Server (RAPIServer)

The Remote API Server (installed with R210 and later) provides similar functionality as the API Server, but permits access when no trust relationship exists or through firewalls. Client applications are able to make an initial connection to the Remote API Server by
providing a username and password that the PHD Server is able to validate. This means that the username and password is to be defined in one of the following:

the domain where the PHD Server resides in a trusted domain on the local machine hosting the PHD Server.
The groups to which the username belongs determine the rights that it receives. The RAPI Server is not directly accessible by third-party applications. The intent is that third-party or custom applications use the Visual PHD OLE Server or the .NET wrappers to access data. The Visual PHD OLE Server, .NET wrappers, and the Desktop applications can be configured to use the API Server or the RAPI Server. Those companies not wanting to use the RAPI Server are able to disable the service.
4. Special Considerations for PHD Security

4.1 Cross Domain PHD Access
Cross domain PHD access requires the establishment of a trust relationship between the domains. One exception to this is if the identical user (including identical password) exists on each domain. In this case, the user can be validated from one domain to the other even though a trust does not exist between the domains. For the Remote API Server to function in the absence of a trust relationship, identical users as described above need to be established.
4.2
Logon Behavior of Client Software

Client software behaves differently in the same configuration due to the changed behavior of the Uniformance R202 Server (and later) from that of the Uniformance R201 (and earlier) Server. Process Trend users and Excel users may have to perform an explicit login from the application menu to obtain access to their data. Client connections are established using the default logon. The saved username and password is not used, and no login box appears. If the default logon does not have read privilege, the following behavior may be observed:
Process Trend: Opening a saved trend file shows an error box specified operation failed on the first tag name, and an empty trend. The workaround is to go to FILE > PHD LOGIN and perform an explicit login in case of pre-300 PHD Server. After successful login, the trend can be refreshed and data are seen. Excel: Instead of getting a prompt for username/password, access is denied. The workaround is to go to FILE > PHD LOGIN and perform an explicit login in case of pre-300 PHD Server.
ATTENTION
With R300 PHD, explicit login is not supported.
4.3
Uniformance Desktop Authentication

Uniformance R202 (and later) Desktop fails to authenticate to a Uniformance R20x/210 and later PHD Server. Uniformance R202 (or later) Desktop applications connect to the PHD server through the R20x API Server service rather than through the Legacy API service. When the user connects through the R20x API Server service, the API Server validates the user through the standard Windows user validation techniques. Therefore, the Uniformance R202 (or
4 Special Considerations for PHD Security 4.4 PHD Data Access through a Firewall
later) Desktop user must have valid a Windows account (see the section on User Security Strategies for a definition of a valid Windows account) on the PHD Server or they will be unable to connect to the PHD server. If the Uniformance R202 (or later) Desktop is not in the same domain as the PHD R20x/210 or later PHD Server and a trust cannot be established between the Uniformance R202 Desktop domain and the PHD R20x Server domain, customers are advised to use the Uniformance R201.1 Desktop with the latest PHD R201.1.x patches. The Uniformance R201 Desktop connects through the Legacy API service and bypasses this Windows security requirement. Alternatively, users of the R210 or later Desktop are able to use the Remote API to access data on an R210 or later PHD Server in a different domain without an established trust relationship.
4.4
PHD Data Access through a Firewall

There is no support for PHD Clients accessing the PHD Server through a firewall in R202 and earlier. Uniformance R210 or later provides support for firewalls between the PHD Client and the PHD Server as described earlier in this document.
REFERENCE - INTERNAL
For more information about the ports and trusted connections required for the OPC Server to communicate to the PHD Server, refer to the Uniformance PHD OPC Server Users Guide (pim290.pdf).
5. Appendix A Windows Security Overview

5.1 Windows Security Model 2
A brief overview of the Security Model will provide familiarity with relevant concepts and terminology. A more in-depth examination must be done using the Microsoft Win32 Security API Overviews. Every Microsoft Windows NT object (files, named pipes, registry keys, user objects, kernel objects, private objects, and so on) has its security attributes described by a security descriptor (SD). The security-descriptor contains information about the owner of the object and has an access-control list (ACL), which is a list specifying user and groups and their access permissions on that object. There are two types of ACLs: discretionary and system. The discretionary ACL (DACL) is controlled by the owner of an object and specifies the access particular users or groups can have to that object. The system ACL (SACL) is controlled by the system administrator, and allows system-level security to be associated with the object. The usage of DACL and SACL APIs is very similar. However, the SACL APIs can only be used by a process with System Administrator privileges. Because most security programming does not involve setting the system-level security, the discussion here will focus on the DACL APIs. The DACL contains an entry for each user, global group, or local group that is given access permission (whether allowing or denying access) to the object. Each of these entries is in the form of an access-control entry (ACE). An ACE contains an ACE_HEADER structure, along with the access permission for that ACE type, and the security identifier (SID). The ACE_HEADER defines the type of ACE (ACCESS_ALLOWED_ACE_TYPE or ACCESS_DENIED_ACE_TYPE), the size of the ACE, and control flags for the ACE. The access permission will determine the type of permission (that is, Read, Write, and so on) that the user or group has. The user or group is specified using its SID. When a DACL does not have any ACEs, then no access rights have been explicitly granted. Therefore, access to the object is implicitly denied. However, when an object does not have a DACL, then no protection is assigned to the object and any access request is granted. An SD for an object is initially set to have a DACL with no ACEs, meaning that there is no access for any user. To give access to all users or groups, the DACL for the SD must be explicitly set to NULL. There are two types of SDs used in the system: absolute or self-relative. The distinction between these two types is very important when programming. An absolute SD contains pointers to the DACL and ACE information, while the self-relative format contains
Nefcy, C. (1994) Windows NT Security, in Security (General) Technical Articles, Microsoft MSDN Library.
5 Appendix A Windows Security Overview 5.1 Windows Security Model1F
information in a contiguous block of memory, so the DACLs and ACEs are positioned at offsets. The security APIs use both absolute and self-relative formats at different times. When asking for SD information, it is always returned by the system in self-relative format. The program can then walk through the offsets to obtain the proper information. However, when adding to or changing the SD, it must be in absolute format. When programming a change to the SD, for instance, this means that the program must read in SD in one format, convert it and write it back in the other format. A user of a process is assigned an access token, which contains identifiers that represent the user and any group to which the user belongs. This access token is checked against the SD of an object to determine the permission of the user has with respect to that object. When a Client connects to a Server, the Server process can impersonate the access token of the Client process. This gives the Server the ability to check the access permission of the Client user.
6. Appendix B Ports
6.1 Ports Used by Windows Services
The Microsoft client, server and server program products use a variety of network ports and protocols to communicate with client systems and other server systems over the network. Dedicated firewalls, host-based firewalls, and Internet Protocol security (IPsec) filters are other important components that are required to help secure your network. However, if these technologies are configured to block ports and protocols that are used by a specific server, that server does not respond to client requests. 3 Although Uniformance PHD has no dependence on specific ports, Uniformance PHD does rely extensively on service provided by the Windows operating system and Windows server components. Failure of the operating system or server components to function properly will adversely impact Uniformance PHD. While the need to secure the network is understandable, care must be taken that essential Windows services are not disrupted.
Function Browsing DHCP Lease DHCP Manager Directory Replication DNS Administration DNS Resolution Event Viewer File Sharing Logon Sequence NetLogon Pass Through Validation Performance Monitor
Static ports UDP:137,138
TCP:135 UDP:138 TCP:139 TCP:135 UDP:53 TCP:139 TCP:139 UDP:137,138 TCP:139 UDP:138 UDP:137,138 TCP:139 TCP:139
Microsoft Corporation (2005) Service Overview and Network Port Requirements for the Windows Server System, KB832017.
6 Appendix B Ports 6.1 Ports Used by Windows Services
Function PPTP Printing Registry Editor Server Manager Trusts User Manager WinNT Diagnostics WinNT Secure Channel WINS Replication WINS Manager WINS Registration
Static ports TCP:1723 IP Protocol:47 (GRE) UDP:137,138 TCP:139 TCP:139 TCP:139 UDP:137,138 TCP:139 TCP:139 TCP:139 UDP:137,138 TCP:139
TCP:135 TCP:137
Additional Ports Used by Windows 2000 services
Function Direct Hosting of SMB Over TCP/IP IPSec: ISAKMP ESP AH Kerberos RSVP
Static ports TCP,UDP: 445
UDP: 500 IP Protocol 50 IP Protocol 51 TCP,UDP: 88 IP Protocol 46
6 Appendix B Ports 6.2 Securing Port 445
6.2
Securing Port 445

With Windows 2000, Microsoft introduced port 445 as a replacement for ports 137 through 139. The use of port 445 is fundamental to how Windows 2000 and later perform services. Specifically, it is required for SMB (Server Message Block) over TCP and is the foundation for:

Distributed File System (DFS) service, Group Policy service, License Logging service, Net Logon service, Print Spooler service, Remote Procedure Call (RPC) service, Server service, and Terminal Services Licensing service.
Many other services rely on the services that are provided by RPC, SMB, or the Server service. Therefore, port 445 is deeply embedded in Windows for Windows Server to Windows Server communication. For a cross-domain logon, where a computer is in one domain and the user account is in another, these protocols are required for the client, the resource domain, and the account domain to communicate. 4 As an example, for a person to login to a system which is a member of a domain, Windows uses port 445 (as well as others) for authenticating the userid and privileges granted. Closing port 445 in a server to server environment has far reaching implications. While it is understandable and desirable to block port 445 from the Internet, to do so in an internal environment is not easily done and may have larger implications depending on the network topology. Immediate repercussions include:

Inability to establish trust relationships between domains, Net logons will not work; only logons to local machines, and Inability to access resources across the firewall with port 445 blocked. Inability to share a configuration database across the firewall, Inability to propagate tag updates across the firewall, and Inability to administer servers across the firewall.
In the context of PHD, side effects include:

Microsoft Corporation (2005) Service Overview and Network Port Requirements for the Windows Server System, KB832017.
6 Appendix B Ports 6.3 Authentication of Users with Port 445 Blocked
6.3
Authentication of Users with Port 445 Blocked

Windows 2000 and later use port 445 for the authentication of users and the establishment of trust relationships between domains requires that the domain controllers are able to communicate over port 445. By blocking port 445 at the firewall, a domain controller on one side of the firewall is unable to authenticate users on the other side of the firewall. Therefore, it is necessary to place a domain controller on both sides of the firewall. The following scenarios should be reviewed for guidance on the use of port 445: a) If the client (desktop) is in the same domain as the server, then port 445 on the server will be used by Windows for general login authentication.
In the previous diagram, a user in Domain A will be authenticated by the domain controller in Domain A. With port 445 blocked at the firewall, the user in Domain B can not be authenticated by the domain controller in Domain A. b) If the client (desktop) is in one domain and the server is in another domain with the two domains separated by a firewall, then a trust relationship between the domains requires that port 445 be available for the Windows operating systems to communicate. If the port is blocked in the firewall, then the trust relationship is inoperable. While Uniformance R210 or later does not use port 445, it is still required for the network topology to function.
In the previous diagram, it is not possible for a trust relationship to be established between Domain A and Domain B as the domain controllers are not able to communicate with port 445 blocked at the firewall. A user in Domain A will not be able to access resources in domain B or vice versa. c) In Uniformance R202, all clients and the server have to be members of the same domain or of a trusted domain. This behavior was overly restrictive for some customer sites and changes were implemented in Uniformance R210 and later to
6 Appendix B Ports 6.4 Uniformance R210 and later Client Access with Port 445 Blocked
permit use of two untrusted domains separated by a firewall with port 445 blocked. The client (desktop) is in one domain and the server in the other. When the user logs into the client Windows account, authentication occurs on the local domain using port 445. When logged in, the Uniformance R210 and later Desktop can request remote access to the server in the other domain. A server login name/password is specified and encrypted for transmission to the Uniformance R210 and later PHD Server on the other side of the firewall. The Uniformance R210 and later PHD Server decrypts and validates the received user information locally or on a Domain Controller within the domain where the server resides. This validation uses port 445 on the server side of the firewall.
6.4 Uniformance R210 and later Client Access with Port 445 Blocked
Uniformance R201/R202 used a named pipe approach which relied on port 445 for authentication of clients. In order for clients to access a server without using port 445, Uniformance R210 and later use SSPI (Security Support Provider Interface) for client authentication across firewalls. PHD does not directly use port 445 for its authentication when SSPI is specified. However, port 445 may still be used by services on either side of the firewall. In order to select SSPI for authenticating clients, the site must create two additional registry entries called UseFirewallSecurity (Dword, value of 1) and UseFirewallPackage (String, value of NTLM) under HKEY_LOCAL_MACHINE\SOFTWARE\Honeywell\Uniformance. The UseFirewallSecurity registry setting enables the use of SSPI (Security Support Provider Interface) authentication instead of named pipe authentication. The UseFirewallPackage registry setting ensures SSPI uses the NTLM (NT LAN Manager) package as Kerberos is not supported.
6.5
Data Collection with Port 445 Blocked

If a collector is passing data up to the shadow through a firewall, then a remote peer/gateway type configuration is recommended. In this setup, it is required that each remote peer uses a user-defined port for the proprietary Uniformance communication. This port is user definable and is set up as a dedicated connection port. That is to say that once the connection is established, it will not respond to any new connection requests that may arrive. From a threat perspective, the only potential vulnerability would be when the two systems are initially establishing the communication link
6 Appendix B Ports 6.6 Tag and User Update with Port 445 Blocked
6.6
Tag and User Update with Port 445 Blocked

Blocking port 445 at the firewall prevents sending of tag or user updates from one server, typically a shadow server, to servers on the opposite side of the firewall. If port 445 is blocked, tag and user information on either side of the firewall is administered separately. Executing any of the PHDMAN UPDATE functions on one side of the firewall does not affect the tag and user information on the other side of the firewall. For the same updates to occur on the opposite side of the firewall, the information has to be re-entered and the relevant PHDMAN UPDATE function has to be executed on that side of the firewall. In Uniformance R210 and later, the same constraints exist for the update of routing information.
7. Appendix C - How to Configure a Firewall for Domains and Trusts 5

ATTENTION
To establish a domain trust or a security channel across a firewall, the following ports must be opened. Note that there may be hosts functioning with both client and server roles on both sides of the firewall. Because of this, ports rules may need to be mirrored.
7.1
Windows NT
Client Port(s) 1024-65535/TCP 137/UDP Server Port 135/TCP 137/UDP Service RPC * NetBIOS Name NetBIOS Netlogon and Browsing NetBIOS Session WINS Replication
138/UDP
138/UDP
1024-65535/TCP 1024-65535/TCP
139/TCP 42/TCP
7.2
Windows Server 2003 and Windows 2000 Server

For a mixed-mode domain with either Windows NT domain controllers or legacy clients or trust relationship between two Windows Server 2003-based or Windows 2000 Serverbased domain controllers that are not in the same forest, all of the preceding ports for Windows NT may need to be opened in addition to the following ports.
Microsoft Corporation (2005) How to configure a firewall for domains and trusts, Q179442.
7 Appendix C - How to Configure a Firewall for Domains and Trusts4F 7.2 Windows Server 2003 and Windows 2000 Server
Client Port(s) 1024-65535/TCP 1024-65535/TCP/UDP 1024-65535/TCP 1024-65535/TCP 1024-65535/TCP 53,1024-65535/TCP/UDP 1024-65535/TCP/UDP 1024-65535/TCP
Server Port 135/TCP 389/TCP/UDP 636/TCP 3268/TCP 3269/TCP 53/TCP/UDP 88/TCP/UDP 445/TCP
Service RPC * LDAP LDAP SSL LDAP GC LDAP GC SSL DNS Kerberos SMB
For Active Directory to function correctly through a firewall, the Internet Control Message Protocol (ICMP) protocol must be allowed through the firewall from the clients to the domain controllers so that the clients can receive Group Policy information. ICMP is used to determine whether the link is a slow link or a fast link. ICMP is a legitimate protocol that Active Directory uses for Group Policy detection and for Maximum Transfer Unit (MTU) detection. If you want to minimize ICMP traffic, you can use the following sample firewall rule: <any> ICMP -> DC IP addr = allow Unlike the TCP protocol layer and the UDP protocol layer, ICMP does not have a port number. This is because ICMP is directly hosted by the IP layer.
Alternatively, you can establish a trust through the Point-to-Point Tunneling Protocol (PPTP) compulsory tunnel, and this will limit the number of ports that the firewall will need to open. For PPTP, the following ports must be enabled:
Client Ports 1024-65535/TCP Server Port 1723/TCP Protocol PPTP
In addition, you would need to enable IP PROTOCOL 47 (GRE). Note: When you add permissions to a resource on a trusting domain for users in a trusted domain, there are some differences between the Windows 2000 and Windows NT 4.0 behavior. If the computer is not able to bring up a list of the remote domain's users:
Windows NT 4.0 tries to resolve manually-typed names by contacting the PDC for the remote user's domain (UDP 138). If that communication fails, a Windows NT 4.0-based computer contacts its own PDC, and then asks for resolution of the name. Windows 2000 and Windows Server 2003 also try to contact the remote user's PDC for resolution over UDP 138, but they do not fall back on using their own PDC. Make sure that all Windows 2000-based member servers and Windows Server 2003based member servers that will be granting access to resources have UDP 138 connectivity to the remote PDC.
SQL Server modes SQL Server has two modes, Windows authentication and mixed mode. The modes apply to all databases on the server, whether from PHD or from another application. The standard PHD recommendation is to set up SQL Server for Windows authentication. The mixed mode is allowed, even though PHD does not take advantage of the additional authentication options provided by the mixed mode.
8. Appendix D Firewall Configuration Examples

8.1 Example 1 - High Security Configuration
This example shows a topology with minimal firewall access requirements. A PHD Peer Server in the DMZ gets data from a PHD Shadow Server in the PCN. The PHD Peer and PHD Shadow servers each have an SQL Server database. A PHD Configuration Tool in the business network is used to configure the PHD Peer Server, while a PHD Configuration Tool in the PCN is used to configure the PHD Shadow Server and Collectors. Figure 2 Diagram of High Secure Configuration
NOTE:
PCN is the Control Domain or Control Network.
8 Appendix D Firewall Configuration Examples 8.1 Example 1 - High Security Configuration
The firewall port number requirements for communicating with the PHD Peer Server are shown in the following table. The indicated default settings can be modified.
Source Host/ Network
Destination Host/ Network
Interface
Ports/Service
Comments
PHD Peer Server PHD Peer Server
PHD Shadow Server PHD Shadow Server
DMZ
49500/TCP
1st RDI. Each RDI has a port. 2nd RDI
DMZ
49501/TCP
The firewall port number requirements for the connection between the PHD Desktop and the PHD Peer Server are shown in the following table. The indicate default settings can be modified. The exception is port 445, which is fixed.
Source Host/ Network Destination Host/ Network PHD Desktop PHD Peer Server PHD Peer Server PHD Peer Server PHD Peer Server Business Domain Business Domain Business Domain Business Domain 3100/TCP Process Trend, Automation Object through Standard PHD API See above comments. Tag Explorer (optional). Interface Ports/ Service Comments
PHD Desktop
3150/TCP
PHD Desktop PHD Desktop
445/TCP 1433/TCP
8 Appendix D Firewall Configuration Examples 8.2 Example 2 - Typical Less Secure Configuration
8.2
Example 2 - Typical Less Secure Configuration

A less complex but less secure topology that has more firewall access is shown in the following example. A Shadow Server in the DMZ gets data from redundant PHD Collectors in the PCN. The PHD Configuration SQL Server database is on the Shadow Server. The PHD Configuration Tool is used for configuring PHD in the PCN. Figure 3 Diagram of Less Secure Configuration
NOTE:
This configuration has reduced SQL Server database license and system administration requirements relative to the topology shown in Example 1. However, additional ports need to be opened in the firewall to support communication with the SQL Server database. Furthermore, tag and user updates from the Shadow to the Collectors require specific NT authentication ports to be open. The PHD Configuration Tool requires the following firewall ports for communication with the SQL Server database and for sending tag and user updates from the PHD Shadow server to both PHD Collectors. The port numbers shown in the following table indicate default settings, which can be modified. The exception is port 445, which is fixed. Note that port 3100 can be modified but must be the same on the PHD Shadow Server and both PHD Collectors.
Source Host/ Network PHD Configuration Tool PHD Configuration Tool PHD Configuration Tool PHD Shadow Server PHD Shadow Server PHD Active Collector PHD Shadow Server PHD Shadow Server PHD Standby
Destination Host/ Network PHD Shadow Server PHD Shadow Server PHD Shadow Server PHD Active Collector PHD Active Collector PHD Shadow Server PHD Standby Collector PHD Standby Collector PHD Shadow
Interface
Ports/Service
Comments
Business Network Business Network Business Network
1433/TCP
SQL Server
3100/TCP
445/TCP
DMZ
3100/TCP
DMZ
445/TCP 1433/TCP
PCN
SQL Server
DMZ
3100/TCP
DMZ PCN
445/TCP 1433/TCP SQL Server
Source Host/ Network Collector
Destination Host/ Network Server
Interface
Ports/Service
Comments
The firewall port requirements for the connection between the PHD Desktop and the PHD Shadow Server are shown in the following table. The default settings can be modified. The exception is port 445, which is fixed.
Source Host/ Network Destination Host/ Network PHD Shadow Server PHD Shadow Server PHD Shadow Server PHD Shadow Server Business Domain Business Domain Business Domain Business Domain Process Trend, Automation Object through Standard PHD API See above comments. Tag Explorer (optional). Interface Ports/Service Comments
PHD Desktop
3100/TCP
PHD Desktop
3150/TCP
PHD Desktop
445/TCP 1433/TCP
PHD Desktop
Two approaches can be used for communication between a PHD Collector and a PHD Shadow Server: the Gateway RDI, which supports peer-to-peer communication, or the Shadow RDI.

The Gateway RDI firewall access requirements are shown in Example 1- High Security Configuration. The Shadow RDI as used in conjunction with Robust Data Collection (RDC) is shown in Example 2- Less Secure Configuration. The firewall port requirements for the Shadow RDI are shown in the following table. The default settings can be modified.
Destination Host/ Network Uniformance - PHD Security and Network Planning Guide 49 Interface Ports/Service Comments
Source Host/ Network
Source Host/ Network PHD Active Collector PHD Active Collector PHD Standby Collector PHD Active Collector PHD Active Collector PHD Standby Collector
Destination Host/ Network PHD Shadow Server PHD Standby Server PHD Shadow Server PHD Shadow Server PHD Standby Server PHD Shadow Server
Interface
Ports/Service
Comments
PCN
54000/TCP 1st RDI, each RDI has a separate set of ports.
PCN
54000/TCP
PCN
54001/TCP
PCN
54002/TCP
PCN
54002/TCP
2nd RDI
PCN
54003/TCP
9. Appendix E PHD Shadow Configuration

9.1 Example Network Diagram of PHD Shadow
A PHD Shadow Server supports the collection of data from any number of RDC or standalone PHD collectors. In the above diagram, a PHD Experion Collector is a standalone PHD collector configured to collect data from an Experion Server or a redundant pair of Experion Servers. A maximum of seven (7) Experion Servers or redundant pairs can be served by a single PHD Collector node. Note: Releases prior to Uniformance R210.1.3 support three max. In an Experion configuration, the data collection and tag synchronization components for each Experion Server must be configured on the same PHD Collector node. Figure 4 Diagram of PHD Shadow Configuration
NOTE:
9 Appendix E PHD Shadow Configuration 9.2 PHD Shadow Configuration Checklist
9.2
PHD Shadow Configuration Checklist

Use the following checklist for task planning purposes. Install SQL Server and configure database on Shadow Server or dedicated Database Server in the Business Network. Install the PHD Configuration Tool on the Database Server or another workstation in the Business Network. Configure RDIs/Links/RDC for the PHD System within the PHD Configuration Tool. Install PHD on the Shadow Server. If the Namespace Server is to be used, install the Namespace Server on the Database Server. The PHD Host for the Namespace Server must be set to the Shadow Server. The Namespace Server should only be installed if the tagnames in PHD differ from the point.parameter names in the control system and there is a need to access data in PHD by the point.parameter name. Configure the Firewall to allow for:

SQL Server traffic to pass from the PHD Collectors (Process Control Network) to the Database Server (Business Network). Shadow RDI traffic to pass from the Shadow Server (Business Network) to the PHD Collectors (Process Control Network). If Tag Synchronization is to be used, PHD traffic to pass from the PHD Experion Collectors (Process Control Network) to the Shadow Server (Business Network).
Install PHD on the collectors in the Process Control Network. On all of the collectors:
Modify the PHDServer registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Honeywell\Uniformance to be the Shadow Server. Modify the database parameters in PHDPARAMS.DAT to be the Database Server.
Perform PHD/Experion Link DCOM Configuration on all Experion Servers and PHD Servers. Install Tag Synchronization on all of the PHD Experion Collectors. Tag Synchronization must be installed prior to executing RDISetup. Execute RDISetup on each of the collector nodes.
10. Appendix F PHD Peer Configuration

10.1 Example Network Diagram of PHD Peer
A PHD Peer Server supports the collection of data from any number of Shadow, RDC or standalone PHD collectors. Regardless of the type of server the Peer is collecting data from, the tag definitions are provided in a separate SQL Server database. Figure 5 Diagram of PHD Peer Configuration
NOTE:
10.2 PHD Peer Configuration Checklist

Use the following checklist for task planning purposes. 1. 2. 3. 4. Install SQL Server and configure database on Peer Server or dedicated Database Server in the Business Network. Install the PHD Configuration Tool on the Peer Database Server or another workstation in the Business Network. Configure the RDIs for the Peer System. Install PHD on the Peer Server.
10 Appendix F PHD Peer Configuration 10.2 PHD Peer Configuration Checklist
5. 6. 7. 8. 9.
Install SQL Server and configure database on Shadow Server or dedicated Database Server in the Process Control Network. Install the PHD Configuration Tool on the Shadow Database Server or another workstation in the Process Control Network. Configure RDIs/Links/RDC for the PHD Shadow System within the PHD Configuration Tool. Install PHD on the Shadow Server. If the Namespace Server is to be used, install the Namespace Server on the Database Server. The PHD Host for the Namespace Server must be set to the Shadow Server. The Namespace Server should only be installed if the tagnames in PHD differ from the point.parameter names in the control system and there is a need to access data in PHD by the point.parameter name.
10. Configure the Firewall to allow for: 11. Peer RDI traffic to pass from the Shadow Server (Business Network) to the PHD Collectors (Process Control Network). 12. Install PHD on the collectors in the Process Control Network. On all of the collectors:
Modify the PHDServer registry value in HKEY_LOCAL_MACHINE\SOFTWARE\Honeywell\Uniformance to be the Shadow Server. Modify the database parameters in PHDPARAMS.DAT to be the Shadow Database Server.
13. Perform PHD/Experion Link DCOM Configuration on all Experion Server and PHD Experion Servers. 14. Install Tag Synchronization on all of the PHD Experion Collectors. Tag Synchronization must be installed prior to executing RDISetup. 15. Execute RDISetup on each of the collector nodes.
Index
access privileges configure, 27 read, 27 send changes to PHD, 28 write, 27 access privileges to SQL objects, 25 affected by INTS local group requirements, 15 assigning objects, 27 checklist for task planning purposes, 52 collector (RDI) security, 27 Configurable engineering units, 13 configure access, 27 enable private security, 26 four security roles, 14 fully secure environment, 12 function security, 27 Honeywell installed local groups, 17 individual tag security, 27 Integrated NT Security, 15 local group requirements PHD_ARCHIVE_*, 17 PHD_INTERFACE_*, 17 PHD_VIEW, 17 understanding, 17 mixed-mode domain, 41 modes of access, 12 multiple character wildcard, 27 new data types, 13 partitioning of systems, 12 PHD Collector, 49 PHD Collector node, 51 PHD Configuration Database, 14 PHD data access, 26 PHD Shadow Server, 45 PHD system management, 25 PHDAPP database, 15 Point-to-Point Tunneling Protocol, 43 port assignments, 22 private security, 26, 27 private tag, 26 Product Administrator, 17 public access, 26 public read tag, 26 public security, 26 public write tag, 26 read access, 27 security collector (RDI), 27 function, 27 individual tag, 27 Security Support Provider Interface, 39 send changes to PHD, 28 single character wildcard, 27 software integrated into an Experion system, 13
Index
SQL Login accounts, 25 Standard and Integrated NT security, 19 Standard Microsoft local groups, 17 Sub-second timestamps, 13 System Administrator, 14 system management functions, 25 tag security, 26 trust relationship, 12 understanding assigning objects, 27 local group requirements, 17 PHD data access, 26 PHD system management, 25 private tag, 26 public access, 26 public read tag, 26 public write tag, 26 Windows NT security, 13 Uniformance R300 PHD Server, 12 wildcard
multiple character, 27 single character, 27 Windows authentication, 14 Windows NT security, 13 access control list, 13 access token, 13 domains, 13 global groups, 13 group ID, 13 local groups, 13 permissions, 13 resources, 13 security ID, 13 security identifiers, 13 user accounts, 13 Windows NT Security, 33 Windows NT Security Model, 12 Windows Security, 21 write access, 27
Index
Honeywell Process Solutions 1860 W Rose Garden Ln Phoenix, AZ 85027-2708 USA

PHD Security and Network Planning Guide R300: Uniformance®

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PHD Security and Network Planning Guide R300: Uniformance®

Uploaded by

Copyright:

Available Formats

Uniformance

PHD Security and Network Planning Guide R300

Copyright, Notices, and Trademarks

ii Uniformance - PHD Security and Network Planning Guide

Support and Other Contacts

Pacific Contact: Phone: Facsimile: Mail:

Email: India Contact: Phone: Facsimile: Mail:

Uniformance - PHD Security and Network Planning Guide iii

Support and Other Contacts

Email: Taiwan Contact: Phone: Facsimile: Mail:

iv Uniformance - PHD Security and Network Planning Guide

Support and Other Contacts

Uniformance - PHD Security and Network Planning Guide v

Support and Other Contacts

vi Uniformance - PHD Security and Network Planning Guide

Special Considerations for PHD Security ....................................................... 31

4.1 4.2 4.3 4.4 5.

Appendix A Windows Security Overview ..................................................... 33 5.1 Windows Security Model......................................................................... 33

viii Uniformance - PHD Security and Network Planning Guide

Uniformance - PHD Security and Network Planning Guide ix

x Uniformance - PHD Security and Network Planning Guide

1. Introducing PHD Security

Uniformance - PHD Security and Network Planning Guide 11

1 Introducing PHD Security 1.3 PHD Security Overview

PHD Security Overview

1 Introducing PHD Security 1.4 Windows NT Security Overview

Windows NT Security Overview

1 Introducing PHD Security 1.5 SQL Server Security Overview

SQL Server Security Overview

The PHD Configuration Database consists of two databases.

The PHDCFG database contains three schemas.

The PHDAPP database contains four schemas.

14 Uniformance - PHD Security and Network Planning Guide

1 Introducing PHD Security 1.6 Integrated NT Security Overview

Integrated NT Security Overview

Local Group Requirements PHD Configuration Tool

Uniformance - PHD Security and Network Planning Guide 15

1 Introducing PHD Security 1.6 Integrated NT Security Overview

16 Uniformance - PHD Security and Network Planning Guide

2. Technical Considerations for Security

Local Group Requirements SQL Server

Honeywell installed local groups

Execute permissions on all read stored procedures in the PHDCFG schema.

2 Technical Considerations for Security 2.3 SQL Server Roles

Privileges that are assigned to users or roles belong to two categories.

SQL Server Roles

18 Uniformance - PHD Security and Network Planning Guide

2 Technical Considerations for Security 2.4 PHD Security Account Requirements

PHD Security Account Requirements

User Logon and Validation

2 Technical Considerations for Security 2.5 User Logon and Validation

20 Uniformance - PHD Security and Network Planning Guide

2 Technical Considerations for Security 2.6 Port Utilization

2 Technical Considerations for Security 2.6 Port Utilization

22 Uniformance - PHD Security and Network Planning Guide

2 Technical Considerations for Security 2.6 Port Utilization

Listening Port # TCP 3151

Function Telnet to RemoteAPI Server Communication from APIServer, RemoteAPIServer, RDIServer

(see NOTE in Figure 1)

Desktop: Tag Explorer

TCP 4100 TCP 4101

Shadow Server (Robust Data Collection) Peer Server (Gateway RDI)

TCP 5420n/5420n+1 (example) TCP 4950n (example)