Implemented

Multiple global login options / NCM Device Connection Method - priority order

Jiri's generalization:

We would like to have a list of login credentials (together with protocol, port etc.); NCM should try using them one by one till a working item is found.

Original text:

Instead of hard-coding all our devices for SSH or Telnet, I would like to suggest that NCM allows us to set a priority order.

For example, we could set the default connection method to SSH, and if that fails then allow NCM to try Telnet.

This would mean that as we migrate our devices to SSH from Telnet, we wouldn't have to keep updating the NCM definition.

The same principle could also apply to SNMPv3 vs SNMPv2 connections.

  • Different credentials and connection protocols based on a custom property would work well in my organization.

    Here is how it would work:

    Create several different NCM templates for login and connection type.

    Then assign template 1 if custom property a = x

  • I would also like to see Global Options by Device Type:  We use entirely different username/password/security etc options for Cisco Switches than we do for HP Switches, which are again completely different from Fortigate Firewalls or NetApp Filers.

  • The design we're considering is as you suggest: The last successfully used credentials will be kept. And you will be able to define the set of credentials to try -- if you don't want telnet, you won't use it.

    Disclaimer: Comments given in this forum should not be interpreted as a commitment that SolarWinds will deliver any specific feature in any particular time frame. All discussions of future plans or product roadmaps are based on the product teams intentions, but those plans can change at any time.

  • a good idea, but managers might have to watch out for some devices that reboot or lose management access if you hit them with the wrong credentials too often, or too fast.

    I'd like this to be part of a discovery process where the last-working credentials are remembered and used the next time. if that fails then try the discovery process. With several thousand devices we can't always change the password fast enough, so we would add the new password to the top of the list and then as we change the password across devices they would switch over to the new password.

    I'm not too keen on falling-back to telnet and sending any credentials across the clear to a device (a hacker might intersperse a device on an uplink port to a switch that blocked ssh packets and then captured a username/password that went across the wire in the clear). In a geographically diverse environment you don't always know what someone has done with your equipment.

  • This feature would have saved me a lot of time when first setting up NCM node configs.