Submitting your feedback...
Knowledge Base Article
KB01457 - Using Windows Credential Manager with PI applications
Product: UNIINT
Version(s): All
 

Issue

Active Directory enables the best integrated security user experience for PI System data. Standalone components, such as nodes that host PI Interfaces and PI Connector relays in an untrusted domain or workgroup environment, can also take advantage of Windows integrated security through use of the Credential Manager.
 

Use case

Credential Manager provides a way for computers in a standalone workgroup environment or an untrusted domain to access servers.1 Windows logon to modern PI Servers activates integrated security features such as communication integrity and privacy as well as Windows logging. Credential manager is also preferred over identical accounts reusing passwords across multiple computers. Identical accounts are frequently flagged in security compliance audits and are difficult to manage.  The approach described in this note can be applied to any applications running as a Windows service, such as PI Interfaces, PI Buffer Subsystem and PI Connectors.
 

Solution

Credential manager works together with PI API 2016 for Windows Integrated Security to upgrade the security and reliability of PI Interface node communication. Credential manager provides credential storage specific to a user for any number of target servers. Remembered and configured credentials become an encrypted part of the user’s local profile.1 When the user attempts a connection to a server with stored credentials, they are used implicitly. Successful authentication mimics a domain based single sign-on user experience.
 

Accessing Credential Manager

The Credential Manager control panel applet is found under Control Panel -> User Accounts -> Credential Manager -> Windows Credentials (or Stored Users and Passwords in previous versions of Windows). CMDKEY is a straight forward command utility interface to add, delete, and list stored credentials.2 It may be desirable to use a command line utility in order to script the setup or rotation of credentials.

Note: Since credential storage is handled per user, you must either log on as the service account to add credentials using the Credential Manager control panel applet, or use the RUNAS utility to run a command prompt under the service account context and add the credentials under the service account user context using CMDKEY.
 

Service Account Considerations

Local Account versus Domain Accounts

Domain controllers must be reachable to verify domain credentials. NTLM pass-thru authentication generates messages from the PI server to the domain controller. Workgroup clients do not directly attempt connection with domain controllers. 
 

Built-in Service Accounts

Built-in service accounts such as Local System, Network Service, and Local Service all have credential vaults. Administrative tools such as Microsoft SysInternals PSEXEC can be used to provide a command shell with access to managing credentials.
 
  1. Use psexec to launch a command prompt with the desired identity
  • Local System:
psexec –i –s cmd.exe
  • Network Service:
psexec –i –u “NT Authority\Network Service” cmd.exe
  • Local Service:
psexec –i –u “NT Authority\Local Service” cmd.exe
  1. Add the credentials for the account with CMDKEY.
cmdkey /add:PIserver /user:PIserver\PI-opc-unit1 /pass

Virtual Accounts

Credential manager is currently unavailable for virtual accounts (eg. “NT Service\PIbufss”) because interactive logons are disallowed. There is a credential vault but it can only be configured using programmatic methods.
 

Example Configurations

These examples will highlight steps to enable Windows integrated security for a PI Interface and PI Buffer Subsystem on an untrusted domain or workgroup environment. The steps below assume the following:
  • The PI Interface is using PI Buffer Subsystem to buffer data
  • The PI Buffer Subsystem was not already using Windows Integrated Security to authenticate to the PI Data Archive at the start of the procedure.  
The following examples configure local accounts on the destination PI Data Archive, but a low-privileged domain account from the destination domain, which follows the least-required-permissions practice could similarly be used and substituted in the examples. For more guidance on PI Buffer Subsystem, see the Buffering and Security section in the PI Server 2016 R2 LIve Library documentation. 
 

Example 1: PI Interface with PI Buffer Subsystem using separate identities.

USE CASE: This example gives a least privilege implementation and should be used as a best practice in environments where the highest level of security is required. 

Phase 1: Prepare the PI Data Archive server

  1. Create a local user account for the PI Buffer Subsystem and PI Interface with access allowed for interface node primary and secondary. Remember the password; you will use it again on the interface computer.
net user PI-opc-unit1 YourStrongPasswordHere! /add /expires:never /passwordchg:no /times:all /workstations:Node1P,Node1S
net user PI-Buffer-unit1 YourOtherStrongPasswordHere! /add /expires:never /passwordchg:no /times:all /workstations:Node1P,Node1S
  1. (Optional) Set the PI Interface service account and the PI Buffer Subsystem service account to never expire.
wmic useraccount where name=’PI-opc-unit1’ set PasswordExpires=FALSE
wmic useraccount where name=’PI-buffer-unit1’ set PasswordExpires=FALSE
  1. Add the user to a local group.
net localgroup PI-interfaces-unit1 PI-opc-unit1 /add
  1. Create a PI Identity for “Unit1” and another identity "Unit1-Buffer" for PI Buffer Subsystem.
  2. Create a Mapping for local group “PI-interfaces-unit1” to identity “Unit1” and local user "PI-buffer-unit1" to identity "Unit1-Buffer"
  3. Create or edit interface point permissions to allow the new identities "Unit1" and "Unit1-Buffer" the appropriate access.  See Security Best Practice #5 of KB00833 for detailed information on least privilege for PI Interfaces in different configurations.  In this scenario, Buffering, No Output Points (Table 5.1 in KB00833), we grant the interfaces identity "Unit1" read access to the point security of the points (PtSecurity: Unit1 A(r)) and grant the PI Buffer Subsystem identity "Unit1-Buffer" read access to the point security of the points (PtSecurity: Unit1-Buffer A(r)) as well as read/write access to the data security of the points (DataSecurity: Unit1-Buffer A(r,w)).  

Phase 2: PI Interface computer preparation

Credential manager stores credentials per user. Identify and/or create the service logon account for running the PI Interface. For example, the PI Interface for OPC typically uses Windows security to connect to the OPC Server and the service logon account may follow a convention such as OPCuser.  You will also need to repeat this process for the service logon account for PI Buffer Subsystem, for example runas BufferUser and store the credentials for PI-buffer-unit1 instead of running as OPCuser and storing the credentials for PI-opc-unit1.

Note: The steps below do not interfere with services that are already started and connected. However be sure to delete the credential manager entry if the test fails and you don’t have time to troubleshoot. A service may not be able to reconnect if a transient issue occurs before preparation is complete.
  1. Open a command prompt as OPCuser with RUNAS. The command below will prompt you for the credentials for OPCuser.
runas /user:OPCuser cmd
  1. Once the command prompt is open under the context of OPCuser, use the command below to add credentials for PI-opc-unit1. You will be prompted for the credentials of PI-opc-unit1. Note that the /add switch specifies the server that the credentials will be used with. Do not specify the target server by IP address.
CMDKEY /add:PIServer /user:PIServer\PI-opc-unit1 /pass:YourStrongPasswordHere!
  1. Enable Group Policies to audit NTLM traffic.3
    1. Open the Local Group Policy Editor (gpedit.msc)
    2. Navigate to the Security Options node under Local Computer Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies.
    3. Open “Restrict NTLM: Outgoing NTLM traffic to remote computers”
    4. Configure “Audit all outgoing NTLM traffic to remote servers”

Phase 3: Verify PI Interface node configuration

  1. Test the credentials.
    1. Open a command prompt as OPCuser using the RUNAS utility as performed in step 1 above.
    2. Navigate to %pihome%\adm
    3. Connect to the PI Data Archive with piartool to verify that the appropriate credentials are used, by verifying that the PIStatus returned is "Success" and the ProtoCredentialsresult matches the user for the stored credentials (PI-opc-unit1).
piartool -node PIServer -Windows -block pibasess -authdebug
  1. (Optional) Verify correct user was used for the connection by examining various logs
    1. Verify the authentication credentials used by examining “Supplied user” for Event ID 8001 in the interface node event log under Applications and Service Logs: Microsoft/Windows/NTLM/Operational log.
    2. Observe the logon account and source workstation from the server Windows security log Event ID 4776 details.
    3. PI Server message log Event ID 7082 confirms logon and cipher details.
Verify the authentication credentials used by examining “Supplied user” for Event ID 8001 in the interface node event log under Applications and Service Logs: Microsoft/Windows/NTLM/Operational log.
Observe the logon account and source workstation from the server Windows security log Event ID 4776 details.
PI Server message log Event ID 7082 confirms logon and cipher details.

Phase 4: Upgrade the PI Interface node

Recent PI API and PI Buffer Subsystem are required to take advantage of Windows integrated security. PI API 2016 for Windows Integrated Security and PI Buffer Sub System 4.5 provide full support for Windows Integrated Security and transport security. PI Buffer Subsystem 4.5 is bundled with PI Interface Configuration Utility 1.4.16.79B (2016-05-03) and PI Asset Framework (PI AF) Client 2016 SP2 (2.8.2.7626).
 

Phase 5: Perform final checks

Verify the Windows service logon account matches the account used to configure Credential Manager. Typically only PI Interface services and PI Buffer Subsystem will need to be verified at this step. Other service dependencies such as PI Network Manager and PI Message Subsystem do not benefit from use of Credential Manager.
 
  1. Open the services applet to verify the logon account (or SC service_start_name)
sc qc pibufss
sc qc piopcint1
  1. Start the PI services and verify connection and data flows are as expected

Example 2: PI Interface with PI Buffer Subsystem using the same identity.

USE CASE: In this example the PI Buffer Subsystem and PI Interface identities are consolidated to one identity per node.  This option may be more appropriate for administrators migrating from PI Trusts to PI Mappings where the PI Trust access was established on a per machine basis as it would allow them to maintain the same PI Identities on the PI Data Archive.  While this configuration improves the manageability of the solution as there are fewer service accounts involved, it does deviate from a least privilege configuration, since the PI Interfaces will have read and write access to the data security of the points, instead of only PI Buffer Subsystem.  

Phase 1: Prepare the PI Data Archive server

  1. Create a local user account for both the PI Buffer Subsystem and PI Interface to use with access allowed for interface node primary and secondary. Remember the password; you will use it again on the interface computer.
net user PI-interface-unit1 YourStrongPasswordHere! /add /expires:never /passwordchg:no /times:all /workstations:Node1P,Node1S
  1. (Optional) Set the PI Interface service account and the PI Buffer Subsystem service account to never expire.
wmic useraccount where name=’PI-interface-unit1’ set PasswordExpires=FALSE
  1. Create a PI Identity for “Interface-Unit1”.
  2. Create a Mapping for local user “PI-interface-unit1” to identity “Interface-Unit1”.
  3. Create or edit interface point permissions to allow the new identities "Interface-Unit1" the appropriate access.  See Security Best Practice #5 of KB00833 for detailed information on least privilege for PI Interfaces in different configurations.  In this scenario,  Table 5.4 in KB00833, we grant the interfaces identity "Interface-Unit1" read access to the point security of the points (PtSecurity: Unit1 A(r)) as well as read/write access to the data security of the points (DataSecurity: Unit1-Buffer A(r,w)).  

Phase 2: PI Interface computer preparation

Credential manager stores credentials per user. Identify and/or create the service logon account for running the PI Interface. For example, the PI Interface for OPC typically uses Windows security to connect to the OPC Server and the service logon account may follow a convention such as OPCuser.

Note: The steps below do not interfere with services that are already started and connected. However be sure to delete the credential manager entry if the test fails and you don’t have time to troubleshoot. A service may not be able to reconnect if a transient issue occurs before preparation is complete.
  1. Open a command prompt as OPCuser with RUNAS. The command below will prompt you for the credentials for OPCuser.
runas /user:OPCuser cmd
  1. Once the command prompt is open under the context of OPCuser, use the command below to add credentials for PI-interface-unit1. You will be prompted for the credentials of PI-interface-unit1. Note that the /add switch specifies the server that the credentials will be used with. Do not specify the target server by IP address.
CMDKEY /add:PIServer /user:PIServer\PI-interface-unit1 /pass:YourStrongPasswordHere!
  1. Enable Group Policies to audit NTLM traffic.3
    1. Open the Local Group Policy Editor (gpedit.msc)
    2. Navigate to the Security Options node under Local Computer Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies.
    3. Open “Restrict NTLM: Outgoing NTLM traffic to remote computers”
    4. Configure “Audit all outgoing NTLM traffic to remote servers”

Phase 3: Verify PI Interface node configuration

Same procedure as Example 1, Phase 3.
 

Phase 4: Upgrade the PI Interface node

Same procedure as Example 1, Phase 4.
 

Phase 5: Perform final checks

Same procedure as Example 1, Phase 5.

Background

Security of Credential Manager

Any time a tool is used to store credentials, it is important to consider how secure the tool is. Encryption used by credential manager relies on proven cryptographic algorithms in the Windows DPAPI.4 Windows 7 for example uses AES256 encryption in CBC mode, SHA512 for hashing, and PBKDF2 as password-based key derivation routine.4 Windows computes password verifiers during the NTLM authentication handshake with a server; passwords are not transmitted over the wire.4

Commercial administrative utilities and forensic tools can recover encrypted credentials.5,6 Consequently, secrecy and/or abuse of stored credentials thus relies on appropriate safeguards in place for accessing the machine itself, as well as backup images. Additionally, managing credentials that providing just enough permission for approved roles minimizes the impact in the event of compromise.
 

Troubleshooting Common Issues

Credential Manager is disabled: Credential Manager is enabled by default. However, it’s is a best practice to disable credential manager if it is not needed. Windows security policy “Network access: Do not allow storage of passwords and credentials for network authentication” can be used to control the credential manager.7

Stored credentials ignored during connection attempt: Credentials are not shared between users even if they belong to the same group. Be sure to configure the credential while running as the account that will be using the credential, by either logging in as the service account or opening the command prompt under the context of the service account.

Logon failure with Event ID 4625 ‘bad username or password’: The credential tuple must also match the attempted server name. It is possible to mismatch in scenarios where applications silently transform IPaddress to host name. You can minimize this kind of issue by avoiding IP address formats when adding Windows credentials.

Logon failure with Event ID 4625 logon failure ‘User not allowed to logon at this computer’: The account was configured to restrict allowed workstations.

The example below creates a local account PI-opc-unit1 on the PI Server allowing logon only from primary and secondary interface nodes:
net user PI-opc-unit1 YourStrongPasswordHere! /add /workstations:Node1P,Node1S
Repeat the command (without the /add) to allow up to 8 nodes or set workstations to * to remove the restriction. This setting can provide an extra defensive layer over firewall capabilities.
net user PI-opc-unit1 YourStrongPasswordHere! /workstations:Node1P,Node1S,PIserver

Workaround

In the event that Windows Credential Manager cannot be used, then matching local accounts with identical credentials can be created on both machines. This approach is discouraged due to the management burden of maintaining the synchronized accounts and lack of compliance with common audit parameters.
 

Notes

1 Credential Locker Overview
https://technet.microsoft.com/en-us/library/jj554668

2 CMDKEY Command-Line Reference
https://technet.microsoft.com/en-us/library/cc754243

3 Using Group Policies to audit NTLM traffic
https://technet.microsoft.com/en-us/library/jj865672(v=ws.10).aspx

4 Windows Data Protection – DPAPI Security and Fig 4 Key Relationships
https://msdn.microsoft.com/en-us/library/ms995355

5 Recovery Tools: Windows Password Recovery - Vault Explorer and Decoder
http://www.passcape.com/windows_password_recovery_vault_explorer

6 Digital Forensics Incident Response SANS 2015 - Francesco Picasso @dfirfpi
http://blog.digital-forensics.it/2016/01/windows-revaulting.html

7 Security Policy Settings Reference: "Network access: Do not allow storage of passwords and credentials for network authentication"
https://technet.microsoft.com/en-us/library/jj852185

8 Cached and Stored Credentials Technical Overview
https://technet.microsoft.com/en-us/library/hh994565

9 MSDN Blog Post: Protecting Your Digital Identity
https://blogs.msdn.microsoft.com/b8/2011/12/14/protecting-your-digital-identity/

10 Cached and Stored Credentials Technical Overview – (Credential Manager store)
https://technet.microsoft.com/en-us/library/hh994565.aspx

11 Credential Management in Windows Authentication – (Windows Vault and Credential Manager)
https://technet.microsoft.com/en-us/library/dn169014
 
Article ID: KB01457 Created: 2016-10-06
Article Type: How-To Last Updated: 2018-04-09