AutoNOC 2.5 User Guide
Preface
Acknowledgements
System Requirements
Legal

Part 1 - Introduction
1.1 The Ideal Difference
1.2 Automated Operations
1.3 Services & Scaler
1.4 Acquisition Stacks
1.5 Portal Deployment
1.6 Discovery and Crawler
1.7 Monitoring Agents
1.8 Recoiling Database
1.9 Multiple Languages
1.10 Security

Part 2 - NOC Views
2.1 Investigate
2.2 Observe
2.3 Visualize
2.4 Alarms
2.5 Analyze
2.6 Design
2.7 Configure

Part 3 - Model Design
3.1 Object Model
3.2 Devices
3.3 Sets
3.4 Set Criteria
3.5 Probes
3.6 Logs & Events
3.7 Alarms
3.8 Actions
3.9 Reports
3.10 Users
3.11 Polling
3.12 Service Levels
3.13 Dependencies
3.14 Performance

Part 4 - Developer Features
4.1 Adding SNMP MIBs
4.2 Variables
4.3 OSP API
4.4 Probe Template
4.5 Log Template
4.6 Device Template
4.7 Interface Template
4.8 Rebranding

Part 5 - Troubleshooting
5.1 General Issues
5.2 Linux
5.3 Windows

Appendix
A.1 OSP API Functions
A.2 Variables
A.3 Object Reference

3.10 Users
AutoNOC provides powerful user access control in the form of a User object. User objects can be found on the Configure tab under the Users root.

The following are the four primary user classes this object is designed to support:

  • Administrator
    Administrators have access to all features without limitation including portal settings and portal configuration features. Administrator access is typically limited to the people who are responsible for deploying AutoNOC itself.
  • Designer
    Designers have access to the design tab and can add devices and otherwise make changes to the actual running model.
  • Technician
    Technician level users can navigate within the operations model like help desk users. They gain the added capability of turning on and off alarms as well as enabling and disabling objects. They can not however make actual changes to the model.
  • Help Desk (End User)
    Help desk level users can do nothing more than view the model and related analysis.

You do not have to define your model in terms of these user classes of course. The user roles are there primarily to give the ability to control who can see and do what. Help desk users, for instance, should be able to log into the model and only see service level information and should not be allowed to change the model.

3.10.1 Adding a New User
In order to create a new user account, you have to be logged into an account with Administrator privileges. Click the + next to Users to open up the list of users and then click on Users. In the Users dialog box, click on New User as shown in the following picture:

Note that a new entry, User 1 appears in the list of users. Now click on User 1 and then on the Properties tab. Replace User 1 with the name you would like to associate with the user account you are creating. There are five switches which effect this account that are all off by default. Help is available by clicking on the "?" next to each switch if needed. When you are satisfied with your inputs, click on Save. Next set the Password and fill in the User Details. Then click on Session. If this is a user account that you do not want to time out, click on the No Session Timeout switch. Finally, set the security for this user.

If you want to limit the view this user has to a specific set of object, specify the name of the set with defines those objects from the Select Set drop down. Click on the security settings that go with the user's role. Defining an account for help desk capability is specified by leaving all security settings unchecked.

3.10.2 Security, User Names, and Passwords
AutoNOC seeks to provide an ideal mix between ease of use and security functionality. All access to the software is built around a user session model. To gain access, the user must have an account and accounts are built by creating user objects and specifying access settings.

The name to use for logging in to AutoNOC is the name of the user object. The password is also configured by editing the user object.

The following screenshot shows the security and access settings available for the user:

The Allow * check boxes control access to individual tabs in the software. The user role check boxes control the availability of certain toolbar buttons and some override features. The user set is described below and is used for specifying access to only certain objects.

3.10.3 Details
A variety of information for users can be provided including an e-mail address and pager information as shown in the following screenshot:

Each field is described below:

  • User's Full Name
    Specifies a full name for the user.
  • User Description
    Description of the user and the purpose of the user account.
  • E-Mail Address
    Specifies the e-mail address that AutoNOC should use when trying to contact the user.
  • Phone Number
    Specifies a voice phone number for the user.
  • Pager Number
    Specifies the phone number of the user's pager.
  • Fax Number
    Provides AutoNOC with the phone number to a fax machine that can be used to contact the user.
  • Pager Gateway (TAP)
    For user's that have access to a TAP alphanumeric pager gateway, this field tells the software the gateway telephone number.
  • Pager Gateway Pin (TAP)
    When sending a message to a pager over a TAP gateway, the connection requires a pin number. On may systems the pin number is the phone number to the pager or cell phone, but that is not always the case.

3.10.4 PAM and Windows Authentication
AutoNOC supports local user server authentication using PAM (Linux) or Win32 authentication. By default local server authentication is enabled, under the Configure

The way it works is when a user attempts to logon, the software will attempt to authenticate the user on the local server, and if successful, AutoNOC will create a special internal authenticated account for that user. Whenever he/she logs in it will again attempt to locally authenticate. What is nice about this approach is AutoNOC is able to maintain specialized local security settings and capabilities for each user, while still allowing password authentication via a common security model.

For Linux users, please note that on some systems with certain security models, minor modifications to the /etc/pam.d/autonoc file may be required for AutoNOC to properly connect to your authentication system. For more information on setting up PAM authentication, see The Linux-PAM System Administrators' Guide.

(C) 2007 - All Rights Reserved - AutoNOC LLC
      Call me!