NetMRI uses internal and external authentication systems to control user authentication for performing all administrative tasks. For a simple rollout, you can use the NetMRI local authentication database, which is called the local authentication service, where all user accounts and login information are contained within the appliance. You can also link NetMRI to an external Active Directory, RADIUS, TACACS+ or LDAP authentication server or server group in the enterprise network to perform user authentication and authorization for NetMRI tasks, using the same user roles a
| Anchor | ||||
|---|---|---|---|---|
|
Use the Authentication Services Settings page (Settings icon –> General Settings –> Authentication Services) to configure authentication server settings.
...
If you define one or more authentication servers under Authentication Services Settings, NetMRI uses the account information from those servers in the order given by priority to accept or reject a given username and password. The only exception is the admin account, which is always validated using the Local Database. NetMRI can be accessed by the system administrator even when authentication servers are down or cannot be accessed by the appliance.
You can disable the local authentication service, in which case only the primary Admin account will be locally authenticated. You can also change the priority level of the Local service, which affects the order in which the local service will be activated for authentication requests. For some applications, retaining the Local service as highest priority is recommended.
You can also enable multiple server groups of different types to authenticate and authorize users. Each server group, whether LDAP, AD, RADIUS or TACACS+, and the mapping between the remote user groups with the local NetMRI roles, is referred to as an authentication service. You configure each authentication service to use a group of on or more authentication servers.
For NetMRI user accounts, you define roles and privileges locally in the NetMRI appliance. All user account roles and privileges remain local to the NetMRI appliance and are not directly defined on the RADIUS, TACACS+, LDAP or AD server (for information about user Roles and Privileges, see Creating Admin and User Accounts.) The external server is used for authentication of the user account. Authorization functions are tied to the assignments between the remote user group names and the NetMRI Roles in the desired NetMRI device groups.
The following figure illustrates the authentication and authorization process for users authenticated by remote servers. In the example, two authentication services are configured: a RADIUS service and an Active Directory service. When an admin logs in with a user name and password, NetMRI uses the service configured with the highest Priority setting to authenticate the admin. If authentication fails, NetMRI tries the next-highest-priority service, and so on. For each service, it tries each authentication server in the order given by their priority, until successful or all services fail, including the local authentication service. If all services fail to authenticate the login attempt, NetMRI denies access and generates an error notification.
If authentication succeeds, NetMRI tries to match the user's group names received from the remote server to those assigned to the local roles and device groups defined in the authentication service properties. If it finds a match, the NetMRI appliance applies the privileges of these roles in the specified device groups to the authenticated user. If the appliance does not find a match, it denies access.
...
Active Directory™ (AD)
| Anchor | ||||
|---|---|---|---|---|
|
The Active Directory schema is predefined for User and Group entries, which means that in NetMRI, you only need to specify the Domain of the AD server, along with its IP address.
...
LDAP (Lightweight Directory Access Protocol)
| Anchor | ||||
|---|---|---|---|---|
|
NetMRI queries the LDAP server for the user account's group membership information. The appliance matches the remote group names from the LDAP server with the group names in its local database. NetMRI then authorizes services and grants the admin privileges, based upon the matching admin group on the appliance.
...
Should you have a provisioned Bind User DN (Distinguished Name) and Bind Password needed for the LDAP service, perhaps for a power user, or in cases where anonymous access is not granted by policy, you can use those values to provide another level of security between NetMRI and the servers comprising the LDAP service.
An anonymous bind takes place as follows:
...
When you configure your RADIUS server files to support the Infoblox attributes, you can use modifiable RADIUS service parameters to support Infoblox features. On a basic level, the Infoblox Vendor ID (7779) and Vendor Attribute ID (10) values reflected in the following example should not be changed. Other RADIUS service parameters and attributes are described in this section. All examples use FreeRADIUS syntax, but many other RADIUS server types follow similar principles.
You must configure the RADIUS server to allow the NetMRI connection. To do so, the administrator adds the appliance IP address to the configuration, and defines a shared secret. in the case of FreeRADIUS, you add an entry in the /etc/raddb/clients.conf file (this example shows IPv4 and IPv6 entries):
...
You can declare the custom attribute using any name, but references must be consistent in the rest of the server configuration files that you create.
To support the custom dictionary, create a new text file named dictionary.infoblox in the /etc/raddb directory, containing the following Vendor ID value and attribute ID number:
...
This declaration in the new dictionary file supports the default values that are reflected in the Add Authentication Service dialog in NetMRI when you configure a new RADIUS service. As previously noted, you can use whichever values you want, but those values must be correctly applied throughout the configuration.
Finally, for a query from the NetMRI appliance about a valid user/password, the Radius administrator must ensure that a response will contain the 'na-group-info' attribute with the list of groups' names of which the user is a member.
...
| Anchor | ||||
|---|---|---|---|---|
|
To support TACACS+ authentication and authorization through NetMRI, you configure a custom service, infoblox, on the T+ server, and then define the user names and group names in the infoblox service's custom attribute na-group. (These services and attributes can be named differently according to preference; we use these values by convention in this document.)
Ensure that you apply each user group to the custom service infoblox (or however you choose to name the custom service). On NetMRI, you add the remote groups with the same names to the authentication service. When the TACACS+ server responds to an authentication and authorization request relayed from NetMRI and the response includes the na-group custom attribute, NetMRI matches the group name with the group in the authentication service and automatically assigns the admin to that group.
If you will use T+ only for authentication, the user accounts must all be defined in NetMRI with the User IDs matching the declared values on the T+ server. These accounts must be locally configured on NetMRI with the roles assigned to their specified device groups.
If you will use T+ for both authentication and authorization, and the configurations are done in the T+ server configuration file, the successfully authenticated and authorized users will be dynamically created in NetMRI with the roles defined through the configurations in the Authentication Service configured in NetMRI.
...
User authentication support in TACACS+ requires each user account to be defined in NetMRI with their defined User ID matching their declared value on the TACACS+ server.
For authorization settings, the T+ configuration file contains the group definitions and the relationships of each user account to those groups.
Configuring the TACACS+ Service requires knowledge of the following key values:
...
On NetMRI, for the TACACS+ authentication service, you define remote groups with the same names (test_admin_group, for example – the group names could be any preferred text string), and the roles these users can have in the specified device groups.
When the TACACS+ server responds to an authentication and authorization request relayed from NetMRI, the response includes the group name. If NetMRI does not find a matching remote group in the authentication service, it will not allow the user to log in and will try the following service in its authentication services list.
To configure a TACACS+ authentication service for NetMRI, do the following:
...