TacacsGUI, Configuration Manager

Good afternoon! Today I would like to bring to your attention Configuration Manager - a plugin included in the TacacsGUI project .

What is Configuration Manager ? This is a configuration manager (such as Oxidized or RANCID ) with various modes for viewing changes (diff) and entries in the AAA log (Authentication Authorization Accounting). Thus, you can not only control the difference (diff) between the configurations, but also determine who made these changes. Tested on Cisco and Juniper. Links to the demo inside.



So, our plan is this: we get acquainted with the main interface; evaluate all the advantages and disadvantages ; next we learn how to configure this function; watching a demo; draw conclusions and leave comments.

Main Interface. Preview

We will start with the most interesting part - by viewing configuration changes. Next, I will shorten Configuration Manager to CM .


Now let's look at the picture above:

1. We have several viewing modes at our disposal:
   
   • Brief (Short) - the most optimal diff view mode. Only changes and adjacent configuration lines are shown here. The number 3 just indicates the number of lines of text around the change. If you wish, you can increase this number so that the "picture" becomes more visible.
   • Full View is the same as Brief, only this time the configuration is shown in its entirety.
   • Preview - just viewing the configuration file. Select a file version and browse.
   • Clear Diff - for those who are in the tank and loves the classics.
2. Each version of the file is determined by the date and hash commit (hash will be seen in the future). Those. the configuration from the devices will be collected every day, but a new version of the file will appear only when any changes have occurred.
3. Actually, the diff configuration itself. Here you can clearly see which lines were added, changed or deleted, compared to the older version of the file.
4. We are approaching the most interesting. It contains important information that tells us what criteria are used to select from AAA magazines, namely the date range and device address.
5. A list of users who accessed the device in the specified period of time, as well as brief information about the entries in the AAA journal associated with them. From left to right, the number of Authentication, Authorization, Accounting.
6. Here we can see when and what commands the user entered. In the future, filtering will be added for easy search.

This is the main interface that you will work with using CM . Let's move on to the description of the setting.

CM setup

Brief cheat sheet in the image below.


And now we will analyze in more detail each step presented in the picture:

Step 1. Adding a Device

Everything is simple here: you specify the address, protocol (ssh, telnet) and port. Optionally, you can specify the user (Credential) and Prompt. If the user is not specified in this step, then the default user (defined in Step 4) will be used. If the Prompt field is not filled, then its value will be determined in Step 3 (Creating a model).

Now let's talk about Prompt. Prompt is a device prompt to enter a command, for example, Switch> or Router> . The same device may have different Prompt, depending on the access level, for example, Switch> , Switch # or Switch (config) # . CMuses Prompt notation to understand when to enter a command. You can list all possible Prompt options by separating them with a comma. In the future, I will not once refer to this description.

Step 2. Create a user

There are three fields to fill in: the account name (Credential Name), username (Username) and password (Password). The Credential Name field will be displayed in the user lists when it is selected and is required, and the Username field is used for authorization on the device, and it is not required, for example, when only the password is used on telnet.

Step 3. Creating a model

The most responsible step. Here we indicate the procedure that the CM should perform . Filling out the Prompt field is similar to that described in Step 1 and its value will be applied to all devices defined in Step 4. If at this stage the Prompt field is left blank, then SM will use the # and > characters by default. Further it is better to explain with an example.


In this example, SM , after a successful connection, executes 5 commands:

1. Waiting for an invitation (Expect): router_15>
   Sends a command (Send): enable
2. Waiting for an invitation (Expect): assword: (the output line may be partially specified)
   Sends the command (Send): ****** (if you send a password, you can hide it / hide)
3. Waiting for an invitation (Expect): (if no output is specified, then a line from the Prompt field will be used instead)
   Sends a command (Send): terminal length 0 (some devices use the more function, which hides some information for convenience, CM does not work with more)
4. Waiting for an invitation (Expect):
   Sends a command (Send): show runn and saves (Write) the output to a file
5. Waiting for an invitation (Expect):
   Sends a command (Send): exit (it is desirable to disconnect)

I hope I shed light on what a model is.

And yes, this is the most common expect. These settings are used in conjunction with the Pexpect library .

Step 4. Create a request

If before that we created objects, then here we put them together. We choose where we will save the file (s), model (model), devices (devices), the default user, and we can also trim the output file and check how it will look (Preview, second image). Each file will have a name composed of a template - device-name __ device -id _ request-id .



You can trim a file both from the beginning and from the end. For example, we trim lines 0 through 2, and -1 (last) and -2 (penultimate).

Using Preview, you can immediately determine whether your model will work and how the file will look.

In conclusion, my advice is if you can’t get the configuration, then try to connect to this device yourself and execute the specified commands at the beginning. It is best to do this directly from the server.

This completes the request setup. Now it remains to make sure that the scheduler (cron) is turned on and wait for the CM to go through the requests and collect all the configurations, or start the CM without waiting for the specified time (Force Start).

Demo

Since this is a plugin, Configuration Manager is not in a prominent place. To exclude the questions, “where exactly should I watch the demo”, I decided to put this in a separate section.

1. We pass to the site demo.tacacsgui.com , we are authorized.
2. Next, look at the bottom of the side menu of Configuration Manager -> Configurations
   
   
   
3. Select a file and double-click to open the preview menu (Preview)
   
   
   
   
   Hurrah! We are in place.

Future plans

1. Download any version of the configuration (it already exists, not configured in gui).
2. Add more information for files in CM Explorer .
3. Add model templates.
4. Update a specific file, i.e. make a quick request.
5. Scheduler. Not just once a day or once a week to fulfill all requests. And fulfill the scheduled requests. Using SM, you can not only collect the configuration, but also collect something like optimization, for example, save the configuration on devices.
6. Add support for SFTP (SCP), FTP. So that you can drop files from devices directly to the CM .
7. SNMP support, so that the device throws a message that the configuration has changed and the CM starts working.

Do you have any ideas what else you can add? Leave your comments.

That's all. If you want to see more articles about TacacsGUI by type of recipes and operating tips, you can write about it in the comments.

All the best!