05-11-2017 01:22 PM
I need to change the ssh login id and enable password on about 100 switches in NetMRI. The new id is in the global config, but the old id is still configured in the device viewer. Is there a way to force them to use the new id in bulk?
Solved! Go to Solution.
05-11-2017 01:33 PM
Read the section in the Admin Guide with the heading of "Credential Import Formats". You can import a CSV file.
If you do nothing, once the old individual device entries fail, NetMRI will wipe them and go back to password guessing. As soon as the new credentials work, they will be stored.
05-11-2017 02:16 PM
The problem is they are only partially failing. The id can log into the switch, but then NetMRI sends the enable command, which causes an error because the command is incomplete. So the failed id ends up in the device viewer. These are Brocade switches.
We have an id for all of our switches. That id has enable priviledges on all switches. NetMRI is set to try the enable command regardless (Some of our devices do not log in to enable mode by default). However on those 100 switches, when the user is already in enable mode, the enable command returns an error that causes the login to fail. So the solution is to give those switches a lesser priviledged id and use enable command as normal. Now I need to go back and change those 100 switches to the lesser priv'd id and add the enable password.
05-11-2017 02:55 PM
I'm not familiar with the Brocade CLI. When a login session goes immediately to enable mode, can that be inferred from the prompt string? If so, NetMRI password guessing should automatically detect that for each device. It will then store a U/P and no enable in the DV. I've seen this work on Avaya (Nortel) switches. It also works for Cisco devices with RBAC (Nexus, ACE, etc.)
What happens when you force a Discover Now on a Brocade switch that requires a separate enable step vs. one that does not? If it doesn't handle it gracefully, then I'd open a support case.
Back to how to manually load them in -- I realized after my previous post that the method in the Admin Guide only loads global credentials for guessing. But this KB article shows how to make it device-specific. Unfortunately, it says an enable field is required and suggests entering "N/A" for devices that do not use/require one. I can't tell if that causes the enable field to be ignored or if it actually stuffs "N/A" into it.
05-11-2017 03:19 PM
I tried manually updating the creds through the device viewer, but it is reverting back to the original id. In any case, I will try the bulk import and see if that changes anything.
The Brocade CLI is almost the same as Cisco with some variants, such as the enable command not being available when you are already in enable mode.
I think the issue is that NetMRI can't handle the specific error message that arises. Some switches are handled fine in NetMRI, as follows:
Invalid input -> enable
Type ? for a list
However, some switches have a different response, and NetMRI fails.
So, I imagine this will require a patch to fix. We are actually trying to get rid of the Brocade switches, and so I have not pursued that fix with support. I was hoping changing the id would get us through this short period until they are all gone.
05-11-2017 03:48 PM
It sure looks like the CCS script that is used for config collection should detect the "#" prompt and never send an enable command. But perhaps the existence of an enable entry for a device causes it to blindly send it anyway.
I didn't think to ask what version you're running. The release notes for 7.1.1-3 list additions or updates for quite a number of Brocade models.
If you're on 7.1.3 and the bulk load method doesn't work, then it's probably worth opening a TAC case.
05-12-2017 01:04 PM
The bulk load method seems to have done the trick. We are on 7.1.1, but upgrading soon to 7.1.3 or 7.1.4.
05-13-2017 09:17 AM
Glad to hear that works -- others of us might need it sometime.
Did your CSV records have an empty enable pasword or "N/A"?
05-15-2017 11:16 AM
I tried N/A with and without quotes. It puts exactly what you type into the field. I also tried it blank, but the import failed altogether.
Fortunately, in my instance, I needed to put the enable password in there.
07-06-2017 09:50 AM
MAdkins -- When the credentials get imported, all the fields do get populated, including the "N/A" (or any other) value for EnablePwd.
The reason this works anyway is that Cisco devices don't prompt for an enable password if you run the "enable" command from a shell that already has enable privileges.
10-18-2017 01:07 PM
I used this to change over 2000 device CLI creds -- worked great although it took a very long time. (Yes, I tried several sample devices first. )
So my follow up question is: any way to delete Telnet credentials without replacing them with a new value? I.E., is there some way in the text file to blank them out, as one can do in the UI?