About security

AVEVA Historian provides two ways to authorize access:

• Integrated security. IDAS computers in the same domain as the historian can be configured with integrated security. Using this model, all users and computers that access historian data are assigned membership to one of the following user groups:

  • Administrators (aaAdministrators)

  • Power Users (aaPowerUsers)

  • Replication Users (aaReplicationUsers)

  • Users (aaUsers)

• Workgroup security. IDAS computers outside of the historian's domain can use username and password as security. This username and password must match a local user on the server node, and must be provided in the format <server node hostname>/<user name>.

  When the IDAS is configured with this type of security, an authentication token and is defined and forwarded to the remote IDAS computer. Each time the remote computer accesses the historian, it will use the token and the historian will use it to authenticate the remote computer before allowing access.

Data can be passed from any computer that's a member of the historian's Power User or Administrator group. (Computers must be on the same domain as the historian.)

When data is ready to be sent from a remote computer, the AVEVA Historian pushes configuration information, including ACLs (access control lists) that define access permissions, to HCAP on the client computer. HCAP launches IDAS on the remote computer and data is sent through HCAL to the historian.

For clients to access the Historian, they must pass through both of these security levels.

The Historian Management Console (within the Operations Control Management Console) adds an additional layer of authorization to restrict access to functions affecting the state of the Historian to only authorized users. For example, you can grant a Windows user account access to start and stop Historian services by assigning it the Historian Power Users role, or by adding it to the aaPowerUsers Windows user group. For more information, see Add users and assign roles.

Note: Some Historian components require Windows and SQL Server logins.

For more information on configuring user rights assignments for local security policies, see the Microsoft documentation.

Security for AVEVA Historian is managed using the following tools:

• Microsoft SQL Server Management Studio.
  Use this application to manage access to the SQL Server and databases.

• Windows Local Users & Groups MMC snap-in.
  Use this to manage permissions on the Historian and for the OData/REST web service interface. You can also use it as an alternative to configuring permissions within the database when using Windows authentication.

  For more information, see Manage logins.

• ArchestrA Change Network Account utility.
  Use this utility to modify the Windows login for the Historian services on remote servers. For example, if you are configuring an AppEngine to send data to a remote Historian, this utility is used to choose the Windows user account with which to connect to the server.