User Management
The user management page allows managing users which can use the Allegro Network Multimeter. It is possible to:
- Create new local users or configure login via LDAP or TACACS+
- Edit user parameters
- Change the password
- Use two-factor authentication with time-based one-time password (TOTP) algorithm. When this option is enabled, a QR code is displayed that needs to be scanned by a TOTP generator (e.g. FreeOTP or Google Authenticator). The Allegro Network Multimeter and the TOTP generator will generate a one-time password independently which needs to be given at login. Both devices need to be time synchronized (e.g. via NTP).
- Modify user roles (and therefore permissions and restrictions)
- Adjust user session timeout/time out in minutes
- Disable users
- Disabled users are not able to login, but their settings are kept.
- Forget Third Party (LDAP or Tacacs+) users (since firmware version 4.1)
- This removes the user settings and Two Factor Authentication Settings from the Multimeter
- Delete users.
- Notes:
- It is not possible to delete or disable the admin account.
- It is not possible to delete or disable the currently logged in user.
Roles before v4.2
Multiple roles can be defined per user to allow different permissions.
Only users with the admin role can:
- change system settings
- manage users
- configure storage settings
- use webdav
Roles can be created or deleted (except for the admin role). A role may have several permissions. Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.
Following pre defined roles exist:
- admin: with version 4.1 the admin role became editable. Per default this role has all permissions without restrictions.
- users: Users with this role can see all measurement data, but they are not able to change settings.
- capture: Users with this role are able to start traffic captures.
- replay-user: Users can only view measurement data from replay slots (replay of ring buffer or pcap files). The user cannot see live data.
- restart-analysis: Users can restart already running ring buffer analyses, for example with different start and end time parameters. This is useful if the admin user wants to select which and when a ring buffer should be analyzed but still letting replay-users to restart the analysis in case they want use a smaller time interval for faster/more detailed analysis.
- api-pcap-4-eyes-authorization: This role requires an authorization for performing a PCAP from another user with the pcap permission in any of the three categories. In the PCAP dialog a dropdown field is displayed where the user needs to select the other user who should grant the capture. The other user will get a popup dialog for granting or denying the PCAP download.
- api-voip-4-eyes-authorization: This role requires an authorization for accessing SIP or RTP statistics pages from another user with the sip or rtp (before the version 4.1 this was the voip permission) permissions in a category. On the page that requires authorization an indicator is displayed where the user needs to select the other user who should grant access to that page. The other user will get a popup dialog for granting or denying the access.
These roles can be combined. For example, a user with the replay-user and capture role can only see replay data and can capture traffic from this data, but they cannot capture live data.
Permissions before v4.2
Permissions are categorized in live view, replay view and 4-eyes authorization.
For each category there is a list of permissions that are granted by this role.
E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.
Following permissions exist:
- all: All permissions are granted. This contains all other permissions mentioned below.
- pcap: Captures and Webshark access is permitted.
- voip: Access to SIP and RTP statistics is permitted. (With version 4.1 this was split into the permissions rtp and sip)
- other: Access to everything else.
- restart-analysis: Allows restarting ring buffer analysis
- pcap-analysis: Allows starting and stopping a PCAP analysis.
With version 4.1 there is an additional permission setting restricting the capture functionality. To use this feature a restricting profile has to be set in the capture profile settings.
Roles after v4.2
Multiple roles can be defined per user to allow for different permissions and some restrictions.
Per default there are the following 5 roles which are meant to be combined, cannot be deleted but are all changeable:
| Role | Description |
|---|---|
| admin | This role has all permissions and no restrictions per default. The admin user has this role by default. |
| user | This role can see the traffic in any views but is not allowed to capture data or change settings. |
| replay-user | This role is only able to see the traffic in the replay view (e.g. when analyzing a pcap). |
| capture | This role is only allowed to capture traffic in any view. |
| restart-analysis | This role is allowed to restart the processing in any view (e.g. restarting the processing of live traffic and restarting pcap-replays). |
Roles can be created or deleted (except for the default roles). A role may have several permissions.
Permissions after v4.2
Permissions are categorized in live view, replay view and 4-eyes authorization. For each category there is a list of permissions that are granted by this role. E.g. if only the permission 'pcap' is selected in live view, the role only allows performing capturing in the corresponding view.
There are administrative permissions for the settings and other features (like the incidents) and traffic permissions for the measurement data.
Administrative Permissions
The administrative permissions are for different resources like the settings and other features like incidents, reports and more.
Users are able to do actions which are read, update and delete. If the user is only allowed to read, they can only see the active settings but cannot change them.
If they are allowed to update, the user is allowed to update the setting (like changing the permissions of a user or creating a report) but are not allowed to delete.
With the delete action the user is also allowed to delete things.
The all action includes all three other actions.
| Resource | Description |
|---|---|
| administration | Settings to restart the multimeter, processing or other settings which are in the administration menu. |
| analysis-profile-settings | Settings for the analysis profiles. |
| analysis-settings | Settings which control how you analyze traffic, like the global or module settings. |
| capture-profile-settings | Settings for the capture profiles. |
| incidents | Incidents and Incident settings. |
| ingress-filter | Ingress filter settings. |
| multi-device | Multi-Device Settings. |
| name-and-lookup | Name and look-up settings which are under the settings menu, more info can be found here: Names and look-ups. |
| remote-export-settings | Remote access and export settings. |
| reports | Reports and report settings. |
| storage | Access to storage devices and saved files. |
| storage-settings | Storage settings, like sftp server, activating disks etc. |
| system-events | Access to and settings for the system events log |
| user-management | User management settings which includes users, roles, active sessions etc. |
| vlg-settings | Virtual link group settings. (Everyone is able to read names but more access can be limited here) |
| wifi-settings | Settings for the wifi-module. |
Traffic Permissions
The traffic permissions are split into four different views: Live, Replay, Requires 4 eyes and Grants 4 eyes. The any view includes Live and Replay.
The Resources are traffic (which includes all traffic except SIP- and RTP-traffic), SIP-Traffic, RTP-Traffic, capture (for capturing live and replay traffic) and restart (for restarting the live traffic processing or the replay).
For SIP- and RTP-traffic and capturing traffic it is possible to require the approval of another person by checking the Requires 4 Eyes for that resource.
The user which approves the action needs to have the Grants 4 Eyes for the Resource.
There is an additional permission setting restricting the capture functionality.
To use this feature a restricting profile has to be set in the capture profile settings.
Because we changed a lot with the new permissions, there are some limitations:
After upgrading to 4.2 a downgrade to 4.1.2 with a restoration of the 4.1.2 permission configuration is only possible when no roles was edited or saved.
When downgrading to 4.1.2 after editing or saving a role, you have to open the role and add the old permissions again.
Password Policy
With version 4.2 the tab Settings with the settings for Password Policies was added. By enabling this settings an additional check will be carried out, scoring the new password by complexity and requiring a score of at least 3 out of 4.
By declaring special words like the company- or team-name the scoring-algorithm will score passwords with these words worse.
LDAP users
In the LDAP user tab, it is possible to define an LDAP or Active Directory source for user management. LDAP users are only an addition to the locally defined users. Locally defined users take precedence over LDAP users.
The values required depend on the setup of the LDAP server.
The user filter requires a %s as a placeholder for the username.
The group filter requires either %s as a placeholder for the username, or any ${value} attribute of the user. The special value ${DN} references the distinguished name of the user.
In the Allegro MM users group and Allegro MM admins group, a comma-separated list of the common name of the groups is given. If the user is in any of the groups, they are allowed to log in. If the user is in one of the admins group, they are treated as an administrator.
At the moment, only the roles admin and user can be used for LDAP access.
Example for a simple LDAP setup involving only the username:
User filter : (uid=%s) Group filter : (memberUid=%s) User group : allegro-mm-users Admin group : allegro-mm-admins
Active Directory
For Active Directory, the distinguished name ('${DN}') is used in the group filter:
User filter : (&(sAMAccountName=%s)(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Group filter : (&(member=${DN})(objectClass=group))
User group : allegro-mm-users
Admin group : allegro-mm-admins
A more complex group filter, using pre-filtering groups for performance reasons in large directories with lots of groups:
Group filter : (&(member=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))
For recursive group membership resolution, the following group filter can be used (but might be slower):
Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(cn=allegro-mm-users)(cn=allegro-mm-admins)))
Depending on the setup, it is also possible to filter groups by distinguished name:
Group filter : (&(member:1.2.840.113556.1.4.1941:=${DN})(objectClass=group)(|(distinguishedName:=CN=allegro-mm-users,OU=Groups,DC=example,DC=com)(distinguishedName:=CN=allegro-mm-admins,OU=Groups,DC=example,DC=com)))
TACACS+ users
In the TACACS+ user tab, it is possible to define a TACACS+ server for user management. TACACS+ users are only an addition to the locally defined users. Locally defined users take precedence over TACACS+ users. If both TACACS+ and LDAP are configured, LDAP will be queried first.
The Authorization service name defines the TACACS+ service (defined on the TACACS+ server) which is queried in the authorization request.
The Authorization group key defines the attribute of the attribute-value pair (AVP) returned in the authroization request, which lists the groups of the user. Theses groups (as defined in the TACACS+ server) can be mapped to roles as defined by the Allegro Network Multimeter.
Example
Lets assume the TACACS+ server is configured to have a service 'allegro'. For this service, it returns the groups of the user as attribute 'groups'. The user groups defined on the TACACS+ server have the names 'allegro-admins', 'allegro-users' or 'allegro-replay'.
This would require the following settings on the Allegro Network Multimeter:
Authorization service name : allegro Authorization group key : groups Group mapping : admin : allegro-admins user : allegro-users replay-user : allegro-replay