The user names, roles and privileges described in this section depict those that might by used by a typical customer. Since these attributes are configurable by CLI user management, different user names, roles and privileges may be assigned, as appropriate, for enterprise customers.
The MgmtSession class reads in the list of privileges assigned to the user. By its member function CheckAccess the management classes can verify whether or not the user has access to a particular functionality. Each user is assigned exactly one role containing a list of privileges. Roles can be shared by several users thus making it very efficient to modify the list of privileges for a group of users at once. The RTP has several roles and users pre-installed.
The users, roles and privileges are stored in the following database tables:
Examples for the principle design of these database tables are shown in the tables below.
At installation time, it is recommended that passwords for predefined user accounts be changed from the default value to a new password that is known only by the appropriate authorized personnel.
Table 1. RTP_ADM_USERS
Table 2. RTP_ADM_ROLES
|User||Role||Pass-word||Lock State||Expire Time||Max. Attempts||Max. Inactivity|
|stdop||UserMgmt_Read, EventMgmt_ReadWrite, AppMgmt_Read, Config_Read|
|maxcust||UserMgmt_ReadWrite, EventMgmt_ReadWrite, AppMgmt_ReadWrite, Config_ReadWrite|
|maxint||UserMgmt_ReadWrite, EventMgmt_ReadWrite, AppMgmt_ReadWrite, Config_ReadWrite, IntegratorConfig_ReadWrite|
|super||UserMgmt_ReadWrite, EventMgmt_ReadWrite, AppMgmt_ReadWrite, Config_ReadWrite, IntegratorConfig_ReadWrite, DeveloperConfig_ReadWrite|
Security-related data, such as passwords and the list of privilege IDs is stored in an encrypted way to avoid direct manipulation using low-level database interfaces such as SQL. The RTP_ADM_USERS table not only contains a reference to a role (which is defined in the RTP_ADM_ROLES table) but also the following:
Information about the LockState (if a user is locked out due to unsuccessful login attempts or explicitly by the system administrator)
Expiration time of the password (ExpireTime)
Maximum number of unsuccessful login attempts before the user is locked out implicitly (MaxAttempts)
Maximum time in minutes without any user activity before the session ends implicitly.
The admin logins and their respective authorization profiles shown in the table below are created in the configuration step of the RTP.
Table 3. Admin Logins and Authorization Profiles
|Authorization level for a standard administrator of the end customer|
|maxcust||sysad||Maximum authorization level for end customers|
|maxint||intad||Maximum authorization level for RTP integrators|
|super||superad||Lotus Sametime Unified Telephony development use only|
The roles and users listed in the table above are defined by default, when the RTP is shipped to the integrator. It is based upon the assumption that the RTP development needs the maximum access to the system (user superad). On the other hand, the system integrator should not be confused by too many details (such configuration parameters that make no sense to be modified by him).
Finally, the end customer (users sysad, sysop1,... sysop5) has even more limited access to configuration parameters. (Although user sysad users sysop1 through sysop5 are not allowed to modify the configuration of the RTP; they have readonly access to most management functions.) It is the responsibility of the person or institution installing a RTP system to assure that only the passwords for the appropriate management logins are given to the system user.
Remote Login Restrictions
Remote root access is disabled except between nodes of a cluster. To perform procedures remotely that require root access, log in as user sysad and then switch to root using the switch user (su-) command.
Root User Restrictions
Some Lotus Sametime Unified Telephony scripts requires that root access is enabled. The PermitRootLogin
parameter in the /etc/ssh/sshd_config file
is set by default to Yes
. If access has been denied because the parameter has been changed to No
, as user root change the parameter to “PermitRootLogin yes”
in the sshd_config
file. Restart the sshd daemon with the following command:
Parent topic: CLI User Management