Dcom security and Configuration
scope, enter the OPC client node’s IP address and click OK
Download 311.88 Kb. View original pdf
|
- Navigate this page:
- Parent topic
- \\computername
| scope, enter the OPC client node’s IP address and click OK. • Specify DCOM ports to use Parent topic: Configuring operating system settings Specify DCOM ports to use DCOM, unlike most Internet applications, dynamically assigns one TCP port to each executable process that serves DCOM objects on a computer. To find out which ports will be used, any OPC client communicating with objects owned by the OPC server initiates a connection to the remote DCOM's Service Control Manager through TCP port 135. After that initial connection, the Service Control Manager informs the client which port should be used for further communication. The default start port is 49152, and the default end port is Page 11 ©2022 AVEVA Group plc and its subsidiaries. All rights reserved. DCOM Security and Configuration DCOM configurations for OPC Note Windows systems earlier than Windows Server 2008 used a start port of 1024, and a default end port of 4999. While port number is arbitrary, some ports are specified as defaults for specific services. PI Server, for instance, communicates over port 5450. Specifying a range within the Microsoft default start and end port range helps to avoid port conflicts with default port settings. Additionally, some OPC operations use asynchronous callbacks. During callbacks, the OPC client becomes a DCOM server, and the OPC server becomes a DCOM client. When a server makes a callback to a client, it creates anew connection to the client and sends method calls over a separate TCP channel. The same dynamic port allocation, described above, takes place on the OPC client side. This dynamic port allocation in this ephemeral port range makes DCOM a "firewall unfriendly" protocol. For additional information, seethe Microsoft Support article The default dynamic port range for TCP/IP has changed since Windows Vista and in Windows Server 2008 Parent topic: Configure Windows Firewall settings Setting encryption level and NTLM negotiation The local accounts used for OPC server or interface may not be authenticated correctly when connecting to Windows Server 2008, Windows 7, and later. Windows Server 2008 and Windows 7 include changes designed to enhance the security of the NTLM authentication protocol, which is used by servers and clients when running in workgroup mode. By default, these versions of Windows are configured so that they will only communicate with other computers that use the enhanced NTLM security. This will prevent authentication from the OPC client to the OPC server when using local accounts. In order to ensure interoperability, OPC server and client nodes should be configured so that the NTLM-specific settings on the two computers match. Older Windows versions (at least back to Windows XP) with up-to-date service packs will support the new settings. Windows 2003 Service Pack 1 supports this setting. To determine if this might be the issue, perform a simple file-sharing request from the interface/client machine to the server and vice-versa: Procedure 1. Choose start->run . 2. In the textbox, type \\computername and hit enter key You can use a RUNAS like this to run Windows Explorer if you cannot login to the machine with the credentials: runas /user:domain\user "explorer/separate" If successful, a window will display. If you have no access to shares/files on the computer, the window will be empty otherwise it will contain accessible shares/folders/files. If it fails, run the Local Security Control Panel and check the following policies on both the OPC server and interface nodes "Network security LAN Manager authentication level. The NTLM authentication level should beset to "Send NTLMv2 response only" Caution: If there are legacy systems on the network using Windows XP, Windows Server 2003 or earlier, then Send NTLM2 responses may break authentication for the older computers. The setting Page 12 ©2022 AVEVA Group plc and its subsidiaries. All rights reserved. DCOM Security and Configuration DCOM configurations for OPC Send LM & NTLM - use NTLMv2 session security if negotiated should be used instead to remain compatible with legacy systems "Network security Minimum session security for NTLM SSP based (including secure RPC) clients. Set to "Require bit encryption "Network security Minimum session security for NTLM SSP based (including secure RPC) servers. Set to "Require bit encryption Accessing Server 2012 systems remotely, "ServerName"\C$ will notwork with local admin credentials. To resolve this one Regedit HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and change the LocalAccountTokenFilterPolicy to value of 1. If the key does not exist you'll have to create it as type DWORD (32-bit). The settings for the policies given above represent options that should allow interoperability inmost cases. However, sometimes it will not be possible to change the configuration of one machine or the other it will be necessary to change the settings on the computer where the policies can be changed to match those of the computer where they cannot be changed. Note: A system reboot is required for changes to the settings to take effect. If the reboot does not work, try the following command or contact tech support >gupdate/force/wait:0/wait:value Download 311.88 Kb. Share with your friends:
|