When defining the functional categories for users, consider the security implementation. For each user category, determine the following:

  • List of the specific managers that must be accessed by the users in the category. If necessary, divide a category. For example, in a category of network administrators, some users require access to managers in Asia, other users require access to managers in Europe, and still other users require access to all managers. In this case, the network administrators category could be divided into three categories to match these user needs while maintaining tighter security.
  • The functionality that must be accessed by users in this category. Software is designed in such a way that users can be classified into any one of the following access levels:
    Impersonate
    An access level that allows a login to perform actions on behalf of other users. It is used only by the EDAA. This access level has all the powers of All, plus the ability to execute actions as other users.
    All
    An access level where users can access all Global Console functionality available for one or more Managers, if their user profile permits it.
    This access level provides full access to all server functions. It is required for all adapter-toserver and server-to-server connections and by all command line utilities, with a few exceptions. This level of authorization is also required by administrative consoles. However, this level of access can be further restricted through user profiles. The Service Assurance Manager provides additional information about using user profiles to restrict access to console operations.
    Monitor
    An access level at which users can access only Global Console monitoring functionality, and not administrative functionality, for one or more Service Assurance Managers, if their user profile permits it.
    This access level supports a monitoring console. A monitoring console cannot change server database or configuration parameters except in special circumstances such as acknowledgement of notifications. Only consoles support Monitor access. If you run a secure Broker, the Broker must also support ping ( <BROKER>:BrokerNonsecure:Nonsecure:ping).
    Ping
    An access level normally reserved for processes.
    This access level allows processes ping the hosts where other processes are installed to determine if the hosts are running. The access level allows connections to a server, but only to ping the server and check whether it is functioning. A Broker requires Ping access to check the status of servers and this is sufficient to allow the dmctl command line utility to connect to a server and execute the ping command.
    None
    An access level that specifically excludes access to the Global Console server. This privilege can be used to explicitly prevent a user from accessing the server.

These types of security access are defined in the serverConnect.conf file located in the BASEDIR/smarts/local/conf directory on the servers where software is installed.