-
Notifications
You must be signed in to change notification settings - Fork 63
User Guide: Administration
See dedicated page.
Netshot supports both local and remote accounts. Local means the authentication process stays local to Netshot (the user is stored in the local database) while remote means that authentication is delegated to a RADIUS or a TACACS+ server or an OIDC Identity Provider.
When an user tries to log into Netshot, Netshot first looks for a local account in the database. If the local account exists, it checks the password and accepts or denies the user based on that, with the assigned permission level.
If the local account doesn't exist, and at least one RADIUS (or a TACACS+) server is configured, Netshot will try a RADIUS/TACACS+ challenge. If RADIUS/TACACS+ fails, then the user is rejected. If it succeeds, the user is allowed as visitor by default. If the RADIUS response contains a Service-Type attribute equals to AdministrativeUser (well known value), then the user is allowed as admin. If the Service-Type attributes equals to OutboundUser then the user gets read-write and device command permissions. If the Service-Type attribute equals to NASPromptUser then the user gets read-write permissions. However if the user exists in the database as remote user, and has been successfully authenticated by RADIUS, then the permission level locally assigned to the account will override the RADIUS-provided level. For TACACS+, the role attribute is checked against known values: admin, execute-read-write, read-write (this can be customized further in the config file).
An other option is OpenID Connect (OIDC - starting with Netshot 0.22). Netshot only supports Authorization Code flow with authenticated client. OIDC is used for initial authentication only: once the user is successfully authenticated, the rest of the session in based on locally-significant cookie between Netshot Web server and the user's browser. When this mode is enabled, the authentication process is:
- At startup and time to time, Netshot downloads the IdP metadata from the well known discovery URL based on configured IdP URL.
- The user sees a SSO login button on the frontpage of the Netshot web application
- Clicking the button redirects to the SSO IdP
- Once the user is successfully authenticated on the SSO IdP, the user is redirected back to the Netshot web application with a temporary authorization code
- The web application verifies the returned state and posts the authorization code to the Netshot backend
- The Netshot server exchanges the code with a token by contacting the IdP and authenticating itself with the configured client ID and secret.
- Netshot validates the received token and uses username and role from mapped claims in the ID token.
- Netshot creates a session for the authenticated user, and pass a cookie to the web application to track this session.
- Next requests from the web application will use the cookie to authenticate.
To enable local authentication, simply create local accounts in the Admin page.
- Users with visitor permissions may only see the content of Netshot, then cannot change anything.
- Users with operator permissions have also read only permissions, but they can start simple standard tasks (run snapshots, diagnostics, compliance checks). Added with Netshot 0.19.
- Users with read-write permissions may see, create, edit, delete everything, schedule tasks, but they cannot create, edit or create device scripts and diagnostics, nor touch to the items from the Admin tab.
- Users with read-write & execute commands permissions may also alter scripts and diagnostics.
- Users with admin permissions may do everything.
To enable RADIUS authentication, you have to declare the server(s) in the Netshot configuration file. You can have up to 3 servers. They will be tried one by one until one responds. For instance:
netshot.aaa.radius1.ip = 1.2.3.4
netshot.aaa.radius1.authport = 1812
netshot.aaa.radius1.secret = MyKey#1
netshot.aaa.radius2.ip = 1.2.3.5
netshot.aaa.radius2.authport = 1812
netshot.aaa.radius2.secret = MyKey#1
To enable TACACS+ authentication, similarly, you declare the server(s) in the Netshot configuration file. For instance:
netshot.aaa.tacacs1.ip = 1.2.3.4
netshot.aaa.tacacs1.authport = 1812
netshot.aaa.tacacs1.secret = MyKey#1
netshot.aaa.tacacs2.ip = 1.2.3.5
netshot.aaa.tacacs2.authport = 1812
netshot.aaa.tacacs2.secret = MyKey#1
To enable OIDC authentication, you need to configure at least the IdP URL and client ID and secret in the Netshot configuration file:
netshot.aaa.oidc.idp.url = https://idp/path/to/realm
netshot.aaa.oidc.clientid = netshot
netshot.aaa.oidc.clientsecret = MySecret
See the configuration section for more details.
API tokens can be used to interact easily with Netshot embedded REST API. Generate a new API token by clicking Add. Copy the key immediately as it won't be available for reading once created. Choose the right permission level (same levels as for normal users). The description is used only to easily identify the tokens in the list.
See the note on using the API for help on how to use the API once the token is created.
When adding a device to Netshot, you must associate it with a management domain. A management domain defines a set of parameters that will apply to the associated devices.
- The IP address defined in the management domain is the IP address of the Netshot server as seen by the devices of the domain. This can be useful in drivers which use FTP/TFTP to upload configuration items to Netshot.
- When creating device credential sets, you can assign them to a specific management domain. In that case, only the devices of the domain will use these credential sets.
The device domains are created in the Admin page. A domain can't be deleted if it contains any device or is associated to a specific credential set.
The credentials used to access devices are globally managed from the Admin page.
You can create SNMP v1, SNMP v2c, SNMP v3, Telnet and SSH (versions 1.5, 1.99 or 2.0) credential sets.
The SSH authentication can either use a simple password, or can be key-based. To add an SSH key credential set, you need the public and the private RSA key couple. Assuming you've generated the keys using ssh-keygen, just copy and paste the content of the files, ~/.ssh/id_rsa (private key) and ~/.ssh/id_rsa.pub (public key).
Although the credentials are offuscated in the Netshot database, it remains critical to ensure that the access to the Netshot database and to its hosting server is properly secured.
If you associate the credential set to a management domain, it will automatically be used only by the devices of the domain. If you don't specify a management domain, any device will be able to use it.
When adding a device to Netshot, the available credential sets will be tried in turn. The working credential set will be saved as the main one for the device.
The Admin page lets the administrator dynamically reload the Javascript driver files.
By clicking on the Reload the drivers button, the driver files will be scanned and reloaded, so any change made to them will be taken into account by Netshot.
With Web Hooks, Netshot will trigger HTTP POST calls upon specific events, such as the end of a snapshot task.
See also dedicated page on Web Hooks.
In clustering mode, the Admin page shows the cluster members and their state. See Clustering and High Availability for more details.
Note: The expired members will disappear at next reload of the current server.