Ciscoworks - Checking password compliance

[LucaSalvatore_2]

Hi,

We use ciscoworks to do a mass change of our passwords periodically.

I want to run a compliance check to unsure then enable password has been changed.

So i create a template to check for the existance of something like

+ enable secret p4ss0wrd

However when i run the job it tells me that there are no compliant devices, even when i know that most of them are, and i can logon using the enable password.

Is it because the password on the device is encrypted and ciscoworks is not able to see what the real password is?

How can i run a complicance check for passwords then ?

thanks

[Martin Ermel]

have you tried to use the encrypted string of the ena secret as it is shown in the running config?
Compliance check is done as a string comparison between the template and the archived configs. And these stored configs are the same as how they show up when you issue a "show running " or "show startup". So to have a valid compliance check it is also necessary to have an actual config archive on the LMS server.

[LucaSalvatore_2]

Thats not possible as the encrypted string is different on every device....

[Martin Ermel]

I am a bit suprised about the fact it is different on eache device - can you verify this for some devices? I checked this on a few devices here and there was no difference. As well, it is a common practice to take a config (retrieved with "show run" or "show start") and copy and paste it on a new device. In this scenario the string is copied as is and this works - so there cannot be a variable to generate this hash.

As an alternative I could imagine to set up a NetConfig job in RME enter the appropriate credentials but issue just a "show version".

The result of the job should show you the devices where it was not possible to enter ena mode.

[LucaSalvatore_2]

I checked on about 6 different switches and the string is different on all of them.  The password is the same however.

Interestingly the first 3 characters of the string are the same, here are some examples:

$1$Olc.$1t3gBmpVb4VA7qi8qFzGA0

$1$QMDT$2hjV2CYt4FdzajHVEZsXP1

$1$n8G3$z9d739KF1mpimoNCpt7pK/

$1$yVg/$1F/K3f/jSKvatJI6Xkb9E1

[Joel Monge]

Actually, the string will always change as long as you generate it with the "enable secret" command.  You can even generate it multiple times on the device and it will be unique, ie:

CR-NMS-6506E(config)#enable secret 0 test
CR-NMS-6506E(config)#do sh run | inc enable
enable secret 5 $1$FDbm$el.5qOps49M/oP9F/X3y8/
CR-NMS-6506E(config)#no enable secret 0 test

CR-NMS-6506E(config)#enable secret 0 test
CR-NMS-6506E(config)#do sh run | inc enable
enable secret 5 $1$F/mV$3vhEBYTl7dJ9CqiLhUaOq/
CR-NMS-6506E(config)#no enable secret 0 test

CR-NMS-6506E(config)#enable secret 0 test
CR-NMS-6506E(config)#do sh run | inc enable
enable secret 5 $1$8hd6$sBPU9kkIJgu5RHYUtLJml1
CR-NMS-6506E(config)#

However, if you copy paste any of these to the config directly (probably why they are the same on yours Martin), they will all be the same enable secret "test".  The first three characters indicate that this is an MD5 hash.

As Martin says, the best way to test this would be running a dummy NetConfig job which requires enable login.  Veryifing the correct password has been applied is not possible using baseline template (unless you have the custom to copy paste the hash directly), as that would require RME to be able to reverse the MD5 hash.  This is impossible, you can only "break" an MD5 using a dictionary attack.

In Baseline, you could do something like this "+ enable secret 5 [xxx]" where xxx can be substituted by anything.  But this would only show you have a secret MD5 configured.