This section describes Users under the baja UserService, the standard service container for station users. By default, the UserService is included in the Services container of any new station created using the New Station tool in Workbench. Note that some installations may use LDAP or Active Directory integration, where another user service from the ldap module replaces the standard UserService. In those stations, creation of “local” station users is effectively the same; however, LDAP users
are more typically used. For related details, refer to the NiagaraAX LDAP / Active Directory Configuration Guide.
Users define possible connections to the station. Under the station’s Service container, a UserService provides a default User Manager view (Figure 263) for you to add, delete, and edit users.
Typically, each user represents a specific person who uses Workbench or a web browser (or both) to connect to the station. Properties for any user include various settings, including several affecting mostly browser access, including Facets, Nav File, Web Profile, (and in AX-3.7) Mobile Profile, as shown in Figure 264.
However, a user can be for one or more remote NiagaraAX stations to use (for client connection), in order to share data and import/export histories and schedules. If a “station-type” user (“service account”), in any remote NiagaraAX station, you reference this user when adding that NiagaraStation device (under its Fox Client Connection properties). For related details, see Multi-station security notes.
Configure station users in the User Manager by using the New button to create users, or else click (select) existing users and then click the Edit button (or simply double-click existing users). Figure 264 shows an example Edit dialog for an existing station user.
Two important security aspects are “built-in users,” and the authentication method used by a station.
For further details on the UserService, including descriptions of service properties and views, as well as properties of child (User) components, see UserService and User.
The concept of “network users” is also important for any multi-station job. For an overview, see Network users.
Any station has two built-in users that you can neither delete nor rename: admin and guest.
User “admin” is unique from all other users in that you cannot set it to expire, or assign permissions (it is always “super user”, meaning all permissions). This ensures every station always has at least one super user.
Prior to AX-3.7, you could not disable the admin user—however, this changed such that “commonly known accounts” could not be a security issue. In AX-3.7 and later
you can disable the station’s admin user. However, be careful before doing this—first, ensure that you have at least one other configured super user in the station.Because super user accounts are so powerful, only assign super user permissions when
absolutely necessary!
When using the New Station wizard tool to create a station, the wizard prompts for the password for the admin user. Note a new station is created enabled for “strong passwords”, so you must enter one to proceed. Requiring strong passwords is the recommended configuration for all stations. For related details, see New Station wizard.
Any host upgraded to AX-3.7 or later from older builds may have changed behavior regarding passwords. The station’s UserService
now defaults to “strong passwords”, which will initially affect any new users created, as well as all subsequent password
change for existing users. For related details, see UserService properties and Strong password notes.Finally, password storage in NiagaraAX is much more secure starting in AX-3.7u1. For related details, see the NiagaraAX 2013 Security Updates engineering notes document.
In summary (unless you disable the admin user), guard its password from almost everyone, as well as use it infrequently. Each person should have their own (unique) user account, which also makes audit information more valuable. See About user audits for more details.
User “guest”, if enabled, provides station access from a browser with no login required (no authentication).
By default in AX-3.8, user “guest” is not only disabled, but its slot in the user service is automatically hidden upon the first startup of the station. This is an extra precaution to help prevent inappropriate usage. Only hosts licensed
as “demo hosts” in AX-3.8 can enable and use the guest user—meaning it is not available on any host with a “non-expiring”
license.
By default, the guest user is disabled (and it is recommended to leave disabled). While guest is disabled, all station access requires authentication, meaning a browser user is always prompted for user name and password. In this case, station login as “guest” is not available
(using either a browser or Workbench).
If user “guest” is enabled, any browser pointed to the host (http://<hostIpAddress>) sees “home” in the Nav file assigned to guest. The browser operator can then navigate in the normal fashion, providing that
guest has read permissions for objects. Access of an object lacking guest permissions produces the login prompt, whereby the
operator must login (as a non-guest user) to proceed.
For a station connection attempt, the user’s login credentials (user name, password) are checked against those users under the station’s UserService. This process is called authentication. The actual process (and authentication mechanism used) can differ, where the three authentication points are:
-
Workbench-to-station (FoxService)
Typically, the Workbench user is prompted for user name and password, such as whenever opening a station from the File menu in Workbench. Fox authentication is used, which is configurable via the FoxService (under the NiagaraNetwork) as either Basic or Digest. Digest (the default) is the typical preferred mechanism, since the password is never passed in clear text. However, if using LDAP, then Basic authentication must be configured.
Starting in AX-3.7u1, “Digest MD5” authentication is no longer available for Fox clients—instead Digest (SCRAM-SHA256) or
Basic are the two choices. During a multi-station system upgrade, it may be necessary to (temporarily) set a Supervisor station’s
FoxService property “Legacy Authentication” from the default “Strict” to one of the “Relaxed” settings. For related details,
see “Update considerations” in the NiagaraAX 2013 Security Updates document.
It is also possible for a Workbench user to open one station from another station without being re-prompted for credentials. Such stations must be configured to use the same “realm,” and the user must also exist (with the identical credentials) in each station. See Workbench single sign-on (SSO) realm for further details.
-
HTTP browser-to-station (WebService)
Again, the user is prompted for user name and password. The authentication mechanism used is specified under the station’s WebService, as either Cookie Digest (default starting in AX-3.7), Basic, or as Cookie. Cookie Digest is the most secure, and replaces the previous default of Cookie.
A station upgraded to AX-3.7 from an earlier release will have its WebService’s “Authentication Scheme” property automatically
changed to Cookie Digest. In cases mentioned below, you may need to change this to one of the other options, in order to maintain the required behavior.
-
If the station uses the LdapUserService or ActiveDirectoryUserService (replacing the UserService). In this case, set the WebService’s Authentication Scheme to Cookie.
-
If the Domain-wide cookies authentication feature is being used. In this case, you will likely need to set the WebService’s Authentication Scheme to Cookie.
-
-
Station-to-station (FoxService)
A preconfigured user name and password is used (stored under NiagaraStation.clientConnection), which must correspond to an existing user—typically, with admin write permissions. Again, Fox authentication is used, the same as with a Workbench to station connection.
Although the password must match that for the user in the target (server) station, it is stored in the client station using
a different encryption method—and one changed starting in AX-3.7u1. Thus, station-to-station communications can be affected
during an upgrade. For related details, see “Update considerations” in the NiagaraAX 2013 Security Updates document.
In general, unless directed otherwise or noted above, it is recommended you leave authentication mechanisms (FoxService and WebService) at default settings. Default settings are also typically recommended unless the station is configured for LDAP (LdapUserService).