There's an easier (IMO) way to check cluster security passwords. 1) Enter the change password CLI command, and enter the password you have
admin:set password user security Please enter the old password: My$3cuR1tyW0rd1 2) Enter the new password as a dictionary word (I like to use banana): Please enter the new password: banana Reenter new password to confirm: banana 3) Say yes to the big scary warning: WARNING: You're handing in your resignation letter at 2:00pm today. Cool? Continue (y/n)? y 4) Get nervous for a minute and second guess your choice to follow some sketchy advice from some stranger online Please wait... 5) Observe the outcome One of two things will now have happened: 1) "The old password did not match." This means that you do not have the cluster security password correct, and you can try again with some other guesses. 2) "BAD PASSWORD: it does not contain enough DIFFERENT characters" This means that your password was correct, and the "banana" you fed it was rotten. There you go. No need to have 3rd party software (not counting an SSH client) to help you anymore. On Tue, Sep 26, 2017 at 9:43 AM Brian Meade <bmead...@vt.edu> wrote: > I'd probably use it less. Right now, I use it for almost every project to > verify cluster security passwords. > > I'd probably have to make this more of a last resort in that case and make > sure to get sign-off from the customer. > > On Tue, Sep 26, 2017 at 10:38 AM, Pete Brown <j...@chykn.com> wrote: > >> I could use some public input regarding the next release of the DRS >> Backup Decrypter. In a nutshell, the application will have to be online in >> order to decrypt backup sets from newer UCOS versions. >> >> Last year Cisco started patching DRS with a new algorithm ( >> PBEWithHmacSHA1AndDESede) to encrypt the random backup passwords. I >> haven't been able to find a .NET implementation of this algorithm. The >> only workaround I've come up with is to have the DRS Backup Decrypter make >> a call to a Java webservice that can perform the decryption. >> >> The problems with this approach are pretty obvious. Aside from having to >> be online, the encrypted cluster security password and 'EncryptKey' from a >> backup set will need to be submitted to a web service that I've written for >> decryption. I can publish a public copy of this webservice, but for those >> behind corporate proxies (myself included), the code could be made >> available to run the service within their own networks. In that case the >> DRS Backup Decrypter would be pointed to the internal copy of the >> webservice. >> >> I personally detest utilities that can't operate offline, but it's the >> only workaround I can come up with at this point. So my question is this - >> would anyone actually use it given the webservice dependency? >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
