How to select script monitoring authentication types
Learn how to get the most out of your infrastructure by selecting different indeni configuration and authentication settings.
Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.
The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog
Key takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.This article explains how authentication and authorization choices affect indeni monitoring on F5 devices, highlighting that deeper monitoring requires advanced shell access and sometimes local administrator accounts. It describes version-specific constraints—especially that iControl REST on F5 up to 11.5.4 requires local authentication and that RADIUS-based authorization can prevent setting the advanced shell—leading to trade-offs between using local admin accounts and avoiding heavy TMSH monitoring. The operational impact is that administrators must configure authentication per F5 version and desired access (local vs remote auth) to enable indeni’s proactive detection without causing system performance issues.
Why does indeni need advanced shell access on F5 devices rather than just read-only monitoring?
Indeni aims to detect problems before they occur by running advanced checks that go beyond basic read-only monitoring. To perform those proactive diagnostics and gather the necessary internal state, indeni requires access to the F5 advanced shell so it can execute more sophisticated commands and interfaces. The article indicates that without advanced shell access indeni cannot perform its deeper monitoring goals, which is why administrators must ensure accounts have the correct role and shell settings to enable those capabilities.
What are the authentication implications for F5 versions up to 11.5.4 when using iControl REST and RADIUS?
For F5 versions up to 11.5.4, iControl REST requires the user to be locally authenticated, so REST calls must use a locally authenticated account. If the system uses RADIUS for authentication and authorization, the article states there is no way to set the shell to Advanced Shell under any version when RADIUS is configured, so administrators must fall back to the local admin account for REST and to set the proper permissions. This constraint forces use of local admin accounts for indeni to function with older F5 versions.
How should administrators configure authentication on F5 11.6.0 and later to enable indeni monitoring without using the local admin account?
On F5 11.6.0 and later, administrators have more flexibility: if both authentication and authorization are local, any account with the Administrator role and the shell set to Advanced Shell can be used for indeni monitoring (avoiding the local admin account). If authentication is remote and authorization is local, the same requirement applies—an Administrator-role account with Advanced Shell is needed. However, if authentication and authorization are both remote, the table still lists the local admin (with SSH access) as a required user in one row, so administrators should ensure at least one Administrator account with Advanced Shell exists locally when necessary to provide indeni the advanced access it needs.
Considerations when selecting authentication types
Choosing an authentication method for monitoring your infrastructure devices might sound easy at first glance. After all, a monitoring script would only need read-only, right? Wrong.
Monitoring with indeni goes beyond what normal monitoring tools does. The goal of indeni is to detect problems before they occur, saving you hours of troubleshooting and root cause analysis down the road. To get early detection indeni needs access to the advanced shell. Let’s take a look at what this means on F5 devices.
Example: Selecting authentication types for F5 devices
On an F5, having access to the advanced shell means that the user in question must have administrator access. Also, iControl REST requires the user to be locally authenticated up until version 11.5.4. This means that for systems running versions up to 11.5.4 using RADIUS for authentication administrators will have to resort to the local admin account for REST calls.
On top of that if a system has configured authentication and authorization using RADIUS there is no way of setting the shell to advanced shell on any version. So yet again, administrators must resort to the local admin account in order to set the proper permissions.
We have gone above and beyond to avoid using local admin accounts by investing a lot of time running monitor commands via TMSH. However, this has turned out to cause harm to the system due to TMSH using way too much memory. So what does this mean? In order for get the most out of using indeni, administrators will have to configure authentication according to the following table:
[divider width=”full”]
[row style=”collapse”]
[col span=”1/4″ ]
Version
[/col]
[col span=”1/4″ ]
Authentication
[/col]
[col span=”1/4″ ]
Authorization
[/col]
[col span=”1/4″ ]
User
[/col]
[/row]
[row style=”collapse”]
[col span=”1/4″ ]
11.5.4 and earlier
[/col]
[col span=”1/4″ ]
Any
[/col]
[col span=”1/4″ ]
Any[/col]
[col span=”1/4″ ]
Local admin (with SSH access)
[/col]
[/row]
[row style=”collapse”]
[col span=”1/4″ ]
11.6.0 and later
[/col]
[col span=”1/4″ ]
Remote
[/col]
[col span=”1/4″ ]
Remote
[/col]
[col span=”1/4″ ]
Local admin (with SSH access)
[/col]
[/row]
[row style=”collapse”]
[col span=”1/4″ ]
11.6.0 and later
[/col]
[col span=”1/4″ ]
Local
[/col]
[col span=”1/4″ ]
Local
[/col]
[col span=”1/4″ ]
Any account with role Administrator and shell set to Advanced Shell
[/col]
[/row]
[row style=”collapse”]
[col span=”1/4″ ]
11.6.0 and later
[/col]
[col span=”1/4″ ]
Remote
[/col]
[col span=”1/4″ ]
Local
[/col]
[col span=”1/4″ ]
Any account with role Administrator and shell set to Advanced Shell
[/col]
[/row]
[divider width=”full”]
Thank you to Patrik Jonsson for contributing this article.
Related content
BlueCat DDI data boosts Cisco Cloud Control AI-driven operations
BlueCat’s integration with Cisco Cloud Control provides AI agents with access to trusted DDI data for network investigation and remediation.
Automate your DDI modernization path by migrating with Micetro
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
How to map your network with user-defined links in Integrity X
Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.
Your journey to intelligent NetOps begins at Cisco Live
Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.