By default, the appliance has
Those three "built-in" accounts can be neither created nor destroyed, but 'admin' can enable or disable the other two as needed.
You can leave that arrangement as-is, or you can create additional users with names of your own choice, and assign them any of the roles (and the powers that go with those roles). The default password of any created user is "PASSWORD" (yes, all uppercase).
Thus, you could choose to have:
Administrative users' names can be a single character or as many as 128 characters, chosen from letters a-z, or A-Z, numbers 0-9, the dash, the dot, or the underscore. No spaces.
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._
As with any secure system, no two users (regardless of role) can have the same name.
Abilities or Privileges of Created Users
Named users empowered with the "admin" role can perform most actions that the original admin can perform.
User accounts granted the "operator" role have access to a reduced set of administrative commands.
User accounts granted the "monitor" role can take no actions on the appliance or HSM, and are restricted to commands that view, list or show.
The commands available to the roles are listed here [User Accounts and Their Privileges].
Why Create Extra Administrative Users?
One reason for creating multiple named users would be for the purpose of distinguishing individual persons' activities in the logs.
For example, a user named 'john' running the lunash 'syslog tail' command would show in the April 13 log as:
Apr 13 14:17:15 172 -lunash: Command: syslog tail : john : 172.20.10.133/3107
Command Result : 0 (Success)
Perhaps you have people performing similar functions at physically separate locations, or you might have staff assigned to teams or shifts for 24-hour coverage. It could be valuable (or required by your security auditors) to know and be able to show which specific person performed which actions on the system.
You might find other uses. Please let us know.
Implications of Backup and Restore
The deprecated user commands "user backup" and "user restore", have been replaced by "sysconf config backup" and "sysconf config restore" allowing you to store a snapshot of the administrative user database (the names and status of all named Luna Shell users) that can later be restored if desired.
If users have been created since a particular backup was made, and you restore from that backup, the newer users cease to exist. Similarly, users that were deleted since the backup are reinstated by the restore operation, because you are restoring a user database that pre-dates the deletions and additions.
For example, last Thursday the system had three named Operator Users, Agnetha, Bjorn, and Anni, as well as named Administrator User Benny, and you made a backup on that day. On Saturday, you created two additional Users Terry and Paula, and you also deleted Administrator "Benny" because he left the company. Today you restore the user backup from last Thursday.
Operator Users Terry and Paula disappear, and Admin User Benny is reinstated by the restored backup. This could be inconvenient, because Terry and Paula find themselves unable to log in to the Luna Shell to perform their duties, and it could be a security problem, because former employee Benny has access again that he should not have.
If the named user accounts are not deleted or added by a restore operation, there can still be an effect on:
- their passwords - if a user has changed her/his password in the interim, the previous password is reasserted by the restore operation;
- their enabled/disabled status - if a user was disabled after the backup, the restore operation undoes the "disable" and that user is given "enabled" status by the restore (similarly, a user who is supposed to be enabled might be disabled if her/his account had been disabled at the time of the backup).
While the "built-in" 'admin', 'operator', and 'monitor' accounts are not deleted or added by a restore operation (those accounts are permanent), both their enabled/disabled status and their passwords are changed to whatever prevailed at the time the backup was originally taken.
In summary, some thought and care must be applied when restoring from backup, depending upon what administrative actions have occurred between the time that backup was taken and the time that it is restored.
Security of Shell User Accounts
In most cases anticipated by the design and target markets for Luna SA, both the Luna SA appliance and any computers that make network connections for administrative purposes, would reside inside your organization's secure premises, behind well-maintained firewalls. Site-to-site connections would be undertaken via VPN. Therefore, attacks on the shell account(s) would normally not be an issue.
However, if your application requires placing the Luna appliance in an exposed position (the DMZ and beyond), then please see the Help page "About Connection Security" for some additional thoughts.