am0651_R300

Uniformance®

PHD Security and Network Planning Guide

R300

ii • Uniformance - PHD Security and Network Planning Guide

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 PAR 11 1-3MRIUN Correct RDC reference in table in section 8.2.

12 1-5RU4PG Clarify that client communication to a default Oracle installation is

through multiple ports. 13 n/a 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. 14 n/a R300 updates 15 1-F9T3FP Edited the Port Assignment diagram on page 24

Honeywell Process Solutions 1860 W. Rose Garden Ln

Phoenix, Arizona 85027-2708 USA

Uniformance - PHD Security and Network Planning Guide • iii

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: Honeywell TAC-EMEA Phone: +32-2-728-2732 Facsimile: +32-2-728-2696 Mail: TAC-BE02 Hermes Plaza Hermeslaan, 1H B-1831 Diegem, Belgium

Pacific Contact: Honeywell Global TAC – Pacific Phone: 1300-300-4822 (toll free within Australia) +61-8-9362-9559 (outside Australia) Facsimile: +61-8-9362-9564 Mail: Honeywell Limited Australia 5 Kitchener Way Burswood 6100, Western Australia Email: [email protected]

India Contact: Honeywell Global TAC – India Phone: +91-20- 66039400 Facsimile: +91-20- 66039800 Mail: Honeywell Automation India Ltd. 56 and 57, Hadapsar Industrial Estate Hadapsar, Pune –411 013, India Email: [email protected]

Support and Other Contacts

iv • Uniformance - PHD Security and Network Planning Guide

Korea Contact: Honeywell Global TAC – Korea Phone: +82-2-799-6317 Facsimile: +82-2-792-9015 Mail: Honeywell Co., Ltd 4F, Sangam IT Tower B4-4 Block 1590, DMC Sangam-dong, Mapo-gu, Seoul, 121-836, Korea Email: [email protected]

People’s 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, People’s Republic of China Email: [email protected]

Singapore Contact: Global TAC – South East Asia Phone: +65-6580-3500 Facsimile: +65-6580-3501 +65-6445-3033 Mail: Honeywell Private Limited Honeywell Building 17, Changi Business Park Central 1 Singapore 486073 Email: [email protected]

Taiwan Contact: Global TAC – Taiwan Phone: +886- 7- 536 2567 Facsimile: +886-7-536 2039 Mail: Honeywell Taiwan Ltd. 17F-1, No. 260, Jhongshan 2nd Road. Cianjhen District Kaohsiung, Taiwan, ROC Email: [email protected]


Uniformance - PHD Security and Network Planning Guide • v

Japan Contact: Global TAC – Japan Phone: +81-3-6730-7160 Facsimile: +81-3-6730-7228 Mail: Honeywell Japan Inc. New Pier Takeshiba, South Tower Building, 20th Floor, 1-16-1 Kaigan, Minato-ku, Tokyo 105-0022, Japan Email: [email protected]

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

http://www.honeywell.com/ps

http://www.automationcollege.com/


vi • Uniformance - PHD Security and Network Planning Guide

Uniformance - PHD Security and Network Planning Guide • vii

Contents

1. Introducing PHD Security ................................................................................. 11 1.1 About This Document ............................................................................. 11 1.2 Executive Summary................................................................................ 11 1.3 PHD Security Overview .......................................................................... 12 1.4 Windows NT Security Overview ............................................................. 13 1.5 SQL Server Security Overview............................................................... 14 1.6 Integrated NT Security Overview............................................................ 15

2. Technical Considerations for Security............................................................ 17 2.1 Local Group Requirements – PHD Server ............................................. 17 2.2 Local Group Requirements – SQL Server.............................................. 17

Local Groups used by the PHD Configuration Database and Tools ... 17 2.3 SQL Server Roles................................................................................... 18 2.4 PHD Security Account Requirements .................................................... 19 2.5 User Logon and Validation ..................................................................... 19 2.6 Port Utilization......................................................................................... 21

Default PHD port assignments............................................................. 22

3. User Security Strategies ................................................................................... 25 3.1 Functional Areas of Uniformance Security ............................................. 25 3.2 Security for PHD System Management.................................................. 25 3.3 Access to PHD Data............................................................................... 26

Uniformance R150 ............................................................................... 26 Uniformance R200/201 ........................................................................ 28 Uniformance R210 and later ................................................................ 28 Uniformance R300 ............................................................................... 28

3.4 Remote API Server (RAPIServer) .......................................................... 28

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

Contents

viii • Uniformance - PHD Security and Network Planning Guide

4.1 Cross Domain PHD Access ....................................................................31 4.2 Logon Behavior of Client Software .........................................................31 4.3 Uniformance Desktop Authentication......................................................31 4.4 PHD Data Access through a Firewall......................................................32

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

6. Appendix B – Ports ............................................................................................35 6.1 Ports Used by Windows Services ...........................................................35 6.2 Securing Port 445 ...................................................................................37 6.3 Authentication of Users with Port 445 Blocked.......................................38 6.4 Uniformance R210 and later Client Access with Port 445 Blocked ........39 6.5 Data Collection with Port 445 Blocked....................................................39 6.6 Tag and User Update with Port 445 Blocked..........................................40

7. Appendix C - How to Configure a Firewall for Domains and Trusts.............41 7.1 Windows NT............................................................................................41 7.2 Windows Server 2003 and Windows 2000 Server .................................41

8. Appendix D – Firewall Configuration Examples .............................................45 8.1 Example 1 - High Security Configuration ................................................45 8.2 Example 2 - Typical Less Secure Configuration.....................................47

9. Appendix E – PHD Shadow Configuration ......................................................51 9.1 Example Network Diagram of PHD Shadow...........................................51 9.2 PHD Shadow Configuration Checklist ....................................................52

10. Appendix F – PHD Peer Configuration ............................................................53 10.1 Example Network Diagram of PHD Peer ................................................53 10.2 PHD Peer Configuration Checklist..........................................................53

Content

Uniformance - PHD Security and Network Planning Guide • ix

Index 55

Contents

x • Uniformance - PHD Security and Network Planning Guide

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

Uniformance - PHD Security and Network Planning Guide • 11

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 company’s 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 user’s 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.

1 Introducing PHD Security 1.3 PHD Security Overview

12 • Uniformance - PHD Security and Network Planning Guide

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

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

1 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 user’s 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-To-Rel 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 Permissions

Product Administrator Full Control of the PHD and RDI Servers

PHD_VIEW (Optional group)

Permission to view data. Based on the default NT "Everyone" group.

PHD_INTERFACE_* (Optional group)

Where "*" is replaced with the actual RDI name. Full Control of the named RDI. Replaces PHD_PUTDATA and PHD_SECURITY.

PHD_ARCHIVE_* (Optional group)

Where "*" is replace with the archive name. Full control of the named archive. Replaces PHD_EDITDATA.

2.2 Local Group Requirements – SQL Server Local Groups used by the PHD Configuration Database and Tools

Standard Microsoft local groups • Administrators – This group is used by the Database Administrator to perform SQL

Server tasks such as upgrade and backup. Honeywell installed local groups • 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. − 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 SQL Server Roles

BUILTIN/Administrators sysadmin public

HOSTNAME/Product Administrators public

HOSTNAME/Engineers public

HOSTNAME/Operators public

The following table illustrates the PHDCFG Database users and the corresponding roles.

Database Users (PHDCFG) Database Roles

Dbo db_owner

Product Administrators db_owner

Engineers PHDReadWrite, PHDAuditRead, PHDIPRead

Operators PHDReadOnly,PHDIPRead

PHDCFG db_ddladmin

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) Database Roles

Dbo db_owner

Product Administrators db_owner

Engineers PHDReadWrite,PHDIPReadWrite, AFM_ReadWrite_Role,EA_READWRITE_ROLE

Operators PHDReadOnly,PHDIPRead, EA_READONLY_ROLE

PHDAPP db_ddladmin

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

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 Server’s 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

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 user’s 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 API’s 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 user’s access token. The user’s access token and the Legacy API’s access token are merged to determine the Uniformance R200/201 Desktop user’s 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 user’s 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 Overview

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).

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\Parameters 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\Parameters



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 Listening Port # Function

APIServer TCP 3100 Use to connect applications

APIServer TCP 3100 Listening port for client connections

APIServer TCP 3101 Telnet to API Server

LegacyAPIServer TCP 3000 R150 client connections

LegacyAPIServer TCP 3100 Use to connect to apiserver RemoteAPIServer TCP 3150 Use to connect to apiserver

RemoteAPIServer TCP 3150 Desktop: Process Trend Automation Object via Remote PHD API



Service Listening Port # Function

RemoteAPIServer TCP 3151 Telnet to RemoteAPI Server

PHDServer TCP 2000 Communication from APIServer, RemoteAPIServer, RDIServer

SQL Server TCP 1433 (see NOTE in Figure 1) Desktop: Tag Explorer

RDIServer TCP 4100 Listen port

RDIServer TCP 4101 Telnet to RDI Server

Shadow Server (Robust Data Collection)

TCP 5420n/5420n+1 (example)

Robust Data Collection: one pair of ports per RDI where n=0,2,4… (Port Range 49152 – 65534)

Peer Server (Gateway RDI)

TCP 4950n (example)

Gateway RDI: one port per RDI where n=0,1,2,3…. (Port Range 49152 – 65534)

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 Uniformance R150

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.

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 tag’s 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.

For users who do not configure tags • 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.

For users who configure tags • Use collector-based security. People who configure tags need access to multiple

collectors. Assign a collector to a role.

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 User’s Guide (pim290.pdf).


5. Appendix A – Windows Security Overview 5.1 Windows Security Model2

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

2 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 Static ports

Browsing UDP:137,138

DHCP Lease

DHCP Manager TCP:135

Directory Replication UDP:138 TCP:139

DNS Administration TCP:135

DNS Resolution UDP:53

Event Viewer TCP:139

File Sharing TCP:139

Logon Sequence UDP:137,138 TCP:139

NetLogon UDP:138

Pass Through Validation UDP:137,138 TCP:139

Performance Monitor TCP:139

3 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



PPTP TCP:1723 IP Protocol:47 (GRE)

Printing UDP:137,138 TCP:139

Registry Editor TCP:139

Server Manager TCP:139

Trusts UDP:137,138 TCP:139

User Manager TCP:139

WinNT Diagnostics TCP:139

WinNT Secure Channel UDP:137,138 TCP:139

WINS Replication

WINS Manager TCP:135

WINS Registration TCP:137

Additional Ports Used by Windows 2000 services


Direct Hosting of SMB Over TCP/IP TCP,UDP: 445

IPSec: ISAKMP ESP AH

UDP: 500 IP Protocol 50 IP Protocol 51

Kerberos TCP,UDP: 88

RSVP 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. In the context of PHD, side effects include: • 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.

4 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 Trusts5

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) Server Port Service

1024-65535/TCP 135/TCP RPC *

137/UDP 137/UDP NetBIOS Name

138/UDP 138/UDP NetBIOS Netlogon and Browsing

1024-65535/TCP 139/TCP NetBIOS Session

1024-65535/TCP 42/TCP WINS Replication

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 Server-based 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.

5 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) Server Port Service

1024-65535/TCP 135/TCP RPC *

1024-65535/TCP/UDP 389/TCP/UDP LDAP

1024-65535/TCP 636/TCP LDAP SSL

1024-65535/TCP 3268/TCP LDAP GC

1024-65535/TCP 3269/TCP LDAP GC SSL

53,1024-65535/TCP/UDP 53/TCP/UDP DNS

1024-65535/TCP/UDP 88/TCP/UDP Kerberos

1024-65535/TCP 445/TCP 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 Server Port Protocol

1024-65535/TCP 1723/TCP 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 2003-based 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 Shadow Server DMZ 49500/TCP

1st RDI. Each RDI has a port.

PHD Peer Server

PHD Shadow Server DMZ 49501/TCP 2nd RDI

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.



Interface Ports/ Service

Comments

PHD Desktop PHD Peer Server

Business Domain 3100/TCP


Business Domain 3150/TCP

Process Trend, Automation Object through Standard PHD API


Business Domain 445/TCP See above

comments.


Business Domain

1433/TCP (see NOTE in Figure 1)

Tag Explorer (optional).

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




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.




PHD Configuration Tool

PHD Shadow Server

Business Network 1433/TCP SQL Server


PHD Shadow Server

Business Network 3100/TCP


PHD Shadow Server

Business Network 445/TCP

PHD Shadow Server

PHD Active Collector

DMZ 3100/TCP

PHD Shadow Server


DMZ 445/TCP


PHD Shadow Server PCN 1433/TCP

SQL Server

PHD Shadow Server

PHD Standby Collector

DMZ 3100/TCP

PHD Shadow Server


DMZ 445/TCP

PHD Standby PHD Shadow PCN 1433/TCP SQL Server






Collector Server

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.




PHD Desktop PHD Shadow Server

Business Domain

3100/TCP


Business Domain

3150/TCP

Process Trend, Automation Object through Standard PHD API


Business Domain

445/TCP See above comments.


Business Domain

1433/TCP (see NOTE in Figure 1)

Tag Explorer (optional).

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.












PHD Standby Server PCN 54000/TCP



1st RDI, each RDI has a separate set of ports.




PHD Standby Server PCN 54002/TCP



2nd RDI


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


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


10.2 PHD Peer Configuration Checklist Use the following checklist for task planning purposes. 1. Install SQL Server and configure database on Peer Server or dedicated Database

Server in the Business Network. 2. Install the PHD Configuration Tool on the Peer Database Server or another

workstation in the Business Network. 3. Configure the RDIs for the Peer System. 4. Install PHD on the Peer Server.

10 Appendix F – PHD Peer Configuration 10.2 PHD Peer Configuration Checklist


5. Install SQL Server and configure database on Shadow Server or dedicated Database Server in the Process Control Network.

6. Install the PHD Configuration Tool on the Shadow Database Server or another workstation in the Process Control Network.

7. Configure RDIs/Links/RDC for the PHD Shadow System within the PHD Configuration Tool.

8. Install PHD on the Shadow Server. 9. 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

Date post:	13-Apr-2015
Category:	Documents
Upload:	dina-maulida
View:	112 times
Download:	7 times

am0651_R300

Documents