Re: [cisco-voip] Route Pattern and Route list detail issue

2017-09-27 Thread Erick Bergquist
Brian.

No transformations configured at all.  I'm not able to recreate the
issue now like I was earlier and in past few days. Seems to have
cleared itself up.  I did find a few older route patterns with the
ISDN specific settings set and set those to default (not selected) -
that's about the only thing I changed. I'm going to keep an eye on it.
We need to set the calling party number to specific numbers for some
patterns and locations and it wasn't passing through correctly.

Erick


On Wed, Sep 27, 2017 at 2:03 PM, Brian Meade  wrote:
> Is it possible matching a calling party transformation?
>
> What does the Digit Analysis look like in the CallManager traces?
>
> On Wed, Sep 27, 2017 at 3:40 PM, Erick Bergquist  wrote:
>>
>> I checked that and it is good.  I did a dbreplication status and it
>> checked and came back with no errors.
>>
>>
>> On Wed, Sep 27, 2017 at 1:29 PM, Brian Meade  wrote:
>> > dbreplication working okay?
>> >
>> > Might want to try "utils dbreplication repair all" so it just goes
>> > through
>> > and checks all the tables assuming you're in a good state now.
>> >
>> > On Wed, Sep 27, 2017 at 3:17 PM, Erick Bergquist 
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have been facing a weird route pattern and route list issue and am
>> >> unable to find cause or reason why the route list is not passing along
>> >> changes made at route pattern level.
>> >>
>> >> Call Manager version 11.0(1) SU3 -- 11.0.1.23900-5
>> >>
>> >>
>> >> On the route pattern level I am hard setting the calling party
>> >> transform mask to a specific number to be sent out for Caller ID.
>> >>
>> >> The route list level is default, and is not passing through the set
>> >> number and calls go out with extension on phone.
>> >>
>> >> I have deleted the route pattern, route list, and route group and made
>> >> them from scratch and same problem.  There are no transformations
>> >> being done on the SIP trunk and no modifications on the trunk. The
>> >> route list and trunks have been reset and saved and updated numerous
>> >> times.
>> >>
>> >> Cisco DNA output shows the changes being done to calling party number
>> >> on route pattern level and on route list detail level in DNA it shows
>> >> the phone extension.
>> >>
>> >> I have tried changing the settings from default to Off and on on the
>> >> route list detail without effect.
>> >>
>> >> I've never had this problem before with route pattern changes not
>> >> being passed through to the destination gateway or trunk.
>> >>
>> >> I'm having to create extra route lists at moment to put the specific
>> >> number on the calling party transform field on route list detail
>> >> level. I don't really want the extra route lists though.
>> >>
>> >> Anyone have any ideas?
>> >>
>> >> Erick
>> >> ___
>> >> 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


Re: [cisco-voip] Adding custom entries to the Unity directory?

2017-09-27 Thread Anthony Holloway
If you already have a mailbox in there for Helpdesk, can't you just change
the Standard Transfer Rule on that mailbox, to whatever number you need the
caller transferred to?

On Wed, Sep 27, 2017 at 8:44 AM Ben Amick  wrote:

> Hey, running 9.1 here, I was recently asked if we could add our helpdesk
> number into the search by name directory in Unity – We do have a box in
> there for helpdesk, but the actual line for our helpdesk extension is tied
> to a call handler for the prompt. Is there any way we can add an entry into
> the unity directory to allow this to be searched for?
>
>
>
> Ben Amick
>
> Unified Communications Analyst
>
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you ___
> 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


Re: [cisco-voip] Route Pattern and Route list detail issue

2017-09-27 Thread Brian Meade
Is it possible matching a calling party transformation?

What does the Digit Analysis look like in the CallManager traces?

On Wed, Sep 27, 2017 at 3:40 PM, Erick Bergquist  wrote:

> I checked that and it is good.  I did a dbreplication status and it
> checked and came back with no errors.
>
>
> On Wed, Sep 27, 2017 at 1:29 PM, Brian Meade  wrote:
> > dbreplication working okay?
> >
> > Might want to try "utils dbreplication repair all" so it just goes
> through
> > and checks all the tables assuming you're in a good state now.
> >
> > On Wed, Sep 27, 2017 at 3:17 PM, Erick Bergquist 
> wrote:
> >>
> >> Hello,
> >>
> >> I have been facing a weird route pattern and route list issue and am
> >> unable to find cause or reason why the route list is not passing along
> >> changes made at route pattern level.
> >>
> >> Call Manager version 11.0(1) SU3 -- 11.0.1.23900-5
> >>
> >>
> >> On the route pattern level I am hard setting the calling party
> >> transform mask to a specific number to be sent out for Caller ID.
> >>
> >> The route list level is default, and is not passing through the set
> >> number and calls go out with extension on phone.
> >>
> >> I have deleted the route pattern, route list, and route group and made
> >> them from scratch and same problem.  There are no transformations
> >> being done on the SIP trunk and no modifications on the trunk. The
> >> route list and trunks have been reset and saved and updated numerous
> >> times.
> >>
> >> Cisco DNA output shows the changes being done to calling party number
> >> on route pattern level and on route list detail level in DNA it shows
> >> the phone extension.
> >>
> >> I have tried changing the settings from default to Off and on on the
> >> route list detail without effect.
> >>
> >> I've never had this problem before with route pattern changes not
> >> being passed through to the destination gateway or trunk.
> >>
> >> I'm having to create extra route lists at moment to put the specific
> >> number on the calling party transform field on route list detail
> >> level. I don't really want the extra route lists though.
> >>
> >> Anyone have any ideas?
> >>
> >> Erick
> >> ___
> >> 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


Re: [cisco-voip] Route Pattern and Route list detail issue

2017-09-27 Thread Erick Bergquist
I checked that and it is good.  I did a dbreplication status and it
checked and came back with no errors.


On Wed, Sep 27, 2017 at 1:29 PM, Brian Meade  wrote:
> dbreplication working okay?
>
> Might want to try "utils dbreplication repair all" so it just goes through
> and checks all the tables assuming you're in a good state now.
>
> On Wed, Sep 27, 2017 at 3:17 PM, Erick Bergquist  wrote:
>>
>> Hello,
>>
>> I have been facing a weird route pattern and route list issue and am
>> unable to find cause or reason why the route list is not passing along
>> changes made at route pattern level.
>>
>> Call Manager version 11.0(1) SU3 -- 11.0.1.23900-5
>>
>>
>> On the route pattern level I am hard setting the calling party
>> transform mask to a specific number to be sent out for Caller ID.
>>
>> The route list level is default, and is not passing through the set
>> number and calls go out with extension on phone.
>>
>> I have deleted the route pattern, route list, and route group and made
>> them from scratch and same problem.  There are no transformations
>> being done on the SIP trunk and no modifications on the trunk. The
>> route list and trunks have been reset and saved and updated numerous
>> times.
>>
>> Cisco DNA output shows the changes being done to calling party number
>> on route pattern level and on route list detail level in DNA it shows
>> the phone extension.
>>
>> I have tried changing the settings from default to Off and on on the
>> route list detail without effect.
>>
>> I've never had this problem before with route pattern changes not
>> being passed through to the destination gateway or trunk.
>>
>> I'm having to create extra route lists at moment to put the specific
>> number on the calling party transform field on route list detail
>> level. I don't really want the extra route lists though.
>>
>> Anyone have any ideas?
>>
>> Erick
>> ___
>> 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


Re: [cisco-voip] Route Pattern and Route list detail issue

2017-09-27 Thread Brian Meade
dbreplication working okay?

Might want to try "utils dbreplication repair all" so it just goes through
and checks all the tables assuming you're in a good state now.

On Wed, Sep 27, 2017 at 3:17 PM, Erick Bergquist  wrote:

> Hello,
>
> I have been facing a weird route pattern and route list issue and am
> unable to find cause or reason why the route list is not passing along
> changes made at route pattern level.
>
> Call Manager version 11.0(1) SU3 -- 11.0.1.23900-5
>
>
> On the route pattern level I am hard setting the calling party
> transform mask to a specific number to be sent out for Caller ID.
>
> The route list level is default, and is not passing through the set
> number and calls go out with extension on phone.
>
> I have deleted the route pattern, route list, and route group and made
> them from scratch and same problem.  There are no transformations
> being done on the SIP trunk and no modifications on the trunk. The
> route list and trunks have been reset and saved and updated numerous
> times.
>
> Cisco DNA output shows the changes being done to calling party number
> on route pattern level and on route list detail level in DNA it shows
> the phone extension.
>
> I have tried changing the settings from default to Off and on on the
> route list detail without effect.
>
> I've never had this problem before with route pattern changes not
> being passed through to the destination gateway or trunk.
>
> I'm having to create extra route lists at moment to put the specific
> number on the calling party transform field on route list detail
> level. I don't really want the extra route lists though.
>
> Anyone have any ideas?
>
> Erick
> ___
> 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] Route Pattern and Route list detail issue

2017-09-27 Thread Erick Bergquist
Hello,

I have been facing a weird route pattern and route list issue and am
unable to find cause or reason why the route list is not passing along
changes made at route pattern level.

Call Manager version 11.0(1) SU3 -- 11.0.1.23900-5


On the route pattern level I am hard setting the calling party
transform mask to a specific number to be sent out for Caller ID.

The route list level is default, and is not passing through the set
number and calls go out with extension on phone.

I have deleted the route pattern, route list, and route group and made
them from scratch and same problem.  There are no transformations
being done on the SIP trunk and no modifications on the trunk. The
route list and trunks have been reset and saved and updated numerous
times.

Cisco DNA output shows the changes being done to calling party number
on route pattern level and on route list detail level in DNA it shows
the phone extension.

I have tried changing the settings from default to Off and on on the
route list detail without effect.

I've never had this problem before with route pattern changes not
being passed through to the destination gateway or trunk.

I'm having to create extra route lists at moment to put the specific
number on the calling party transform field on route list detail
level. I don't really want the extra route lists though.

Anyone have any ideas?

Erick
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] let's encrypt for local admin gui pages

2017-09-27 Thread Doug McIntyre
On Wed, Sep 27, 2017 at 02:31:12PM +, Lelio Fulgenzi wrote:
> The hardest part was finding some decent instructions on how to do so. 
> Apparently, when a private signed certificate is generated and granted it's 
> available for download from the link presented during the process and there's 
> no easy way to find an inventory of generated certificates!


The Windows CA service implements access via several different methods, a
web portal, a command line option, and an API. Machines in a Windows AD
can request services from the CA server via whatever way.

Since there are several ways of doing things in Windows, it all
depends on what you are doing, as to what the instructions are.

If you are doing things by hand, typically you would be using the web
portal.  I find the easiest workflow for me is to have a secure area
set aside to store all the stuff going in and out. My process
typically has the keypair and certificate signer request being done by
hand with OpenSSL, although you can use certtool if you really want.
Then I pass the CSR into the windows CA and get back the signed response,
saving each part along the way rather than being on the fly. 

It should be noted the CA server never stores private key-pairs itself, and
basicly is really as it says, it signs the request and hands it back to you.
If you lose the private key, you can't recover it form the CA. If you let the
web portal have your web browser generate a key-pair and CSR, then you are
going to have to go dig that information out of wherever your web browser
stashed it (different for every single one). Its best to start with you
generating it specificly and stashing the files securely where you can access 
them.

You can easily see all the Issued Certificates from the Certificate
Authority MMC plugin. (eg. under Issued Cerfificates). There are command
line tools to do this as well. Typically, you'll have many certs, all in
various states, so its not like there is a mastory inventory here which is
what you seem to imply on wanting to find.

The CA server is just a signer.  In the Enteprise, you get all your
workstations to trust your CA, you submit a cert req to the signer CA,
it signs it, so then all your workstations trust your new cert.


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

2017-09-27 Thread Pete Brown
Brian,


We're still okay there.  Cisco hasn't changed the algorithm used to store 
passwords in platformConfig.xml, so the UCOS Password Decrypter still works.


I know you're familiar with this next part, but I'll include it for the public. 
 When backups are generated, the encrypted security password is copied directly 
from platformConfig.xml and hashed.  The results of that hash are used as a key 
to encrypt the random backup password which then gets stuffed into the backup 
set XML.  The algorithm used for the hash in this process is what they changed.


One option would be to roll the UCOS Password Decrypter functions into the new 
command line Java app.  That way you could run it directly on a rooted UCOS VM 
to dump the platformConfig.xml passwords.


Thanks,

Pete



From: bmead...@gmail.com  on behalf of Brian Meade 

Sent: Wednesday, September 27, 2017 10:10 AM
To: Pete Brown
Cc: Anthony Holloway; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Pete,

I'm assuming we won't be able to decrypt the password from the 
platformConfig.xml anymore?

Thanks,
Brian

On Wed, Sep 27, 2017 at 11:01 AM, Pete Brown 
mailto:j...@chykn.com>> wrote:

Thanks for the feedback everyone, I really appreciate it.


Anthony - Great idea, will keep that one in mind.


Brian - You mentioned using it to verify the cluster security passwords on 
backups.  Given that the workaround has changed from a webservice to a local 
Java app, the Java app could be used via command line under Windows and Linux.  
Maybe have a switch on it to verify the password for a backup set.  Feed it the 
cluster security password and backup set location and it will kick back a pass 
or fail.  That way you could do one off checks or run nightly scripts to make 
sure the cluster security passwords for your backups haven't changed.



From: bmead...@gmail.com 
mailto:bmead...@gmail.com>> on behalf of Brian Meade 
mailto:bmead...@vt.edu>>
Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Definitely a good tip.

That does assume you can guess the password.  I've had a bunch of customers 
have some random cluster security password they had never heard of.

On Tue, Sep 26, 2017 at 4:24 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:
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 
mailto: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 
mailto: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

[cisco-voip] Changing CUC UM Account with API?

2017-09-27 Thread Nick Barnett
I can handle most things in CUCM with SOAP, but I always get confused when
trying to use VMREST in CUC. I cannot find a way to add and remove a UM
account via automation. We're stuck using a CSV and it's really putting a
cramp in our migration to Exchange Online.

The particular change I'm needing is here: Users->EditMenu->Unified
messaging accounts
1) Need to add an additional one that connects to Exchange Online (this
already exists in CUC)
2) Need to delete the old one that connects to on prem Exchange. (Not
delete the whole UM connector service, but just the account association to
a particular user)

Does anyone have any pointers on this? We have batches of people migrating
every week, sometimes multiple times per week... so I can't just make some
global change.

We're on CUC 10.5

Thanks!
Nick

P.S.  I hate that MSFT and CSCO both have a product called "Unified
Messaging" :)
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

2017-09-27 Thread Brian Meade
Pete,

I'm assuming we won't be able to decrypt the password from the
platformConfig.xml anymore?

Thanks,
Brian

On Wed, Sep 27, 2017 at 11:01 AM, Pete Brown  wrote:

> Thanks for the feedback everyone, I really appreciate it.
>
>
> Anthony - Great idea, will keep that one in mind.
>
>
> Brian - You mentioned using it to verify the cluster security passwords on
> backups.  Given that the workaround has changed from a webservice to a
> local Java app, the Java app could be used via command line under Windows
> and Linux.  Maybe have a switch on it to verify the password for a backup
> set.  Feed it the cluster security password and backup set location and it
> will kick back a pass or fail.  That way you could do one off checks or
> run nightly scripts to make sure the cluster security passwords for your
> backups haven't changed.
>
>
>
> --
> *From:* bmead...@gmail.com  on behalf of Brian Meade <
> bmead...@vt.edu>
> *Sent:* Tuesday, September 26, 2017 3:51 PM
> *To:* Anthony Holloway
> *Cc:* Pete Brown; cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input
>
> Definitely a good tip.
>
> That does assume you can guess the password.  I've had a bunch of
> customers have some random cluster security password they had never heard
> of.
>
> On Tue, Sep 26, 2017 at 4:24 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> 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  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  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


Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

2017-09-27 Thread Pete Brown
Thanks for the feedback everyone, I really appreciate it.


Anthony - Great idea, will keep that one in mind.


Brian - You mentioned using it to verify the cluster security passwords on 
backups.  Given that the workaround has changed from a webservice to a local 
Java app, the Java app could be used via command line under Windows and Linux.  
Maybe have a switch on it to verify the password for a backup set.  Feed it the 
cluster security password and backup set location and it will kick back a pass 
or fail.  That way you could do one off checks or run nightly scripts to make 
sure the cluster security passwords for your backups haven't changed.



From: bmead...@gmail.com  on behalf of Brian Meade 

Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Definitely a good tip.

That does assume you can guess the password.  I've had a bunch of customers 
have some random cluster security password they had never heard of.

On Tue, Sep 26, 2017 at 4:24 PM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:
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 
mailto: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 
mailto: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


Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

2017-09-27 Thread Pete Brown
(sorry, replied to Stephen but forgot to Reply All to include the list)


Stephen,

Thanks again for the great advice; I'm going that route.  I was able to get an 
updated version of the DRSD working with newer backups by using a Java app.  
Using IKVM has proved a little trickier since the new algorithm requires a 
security provider in cryptojFIPS.jar.  Unfortunately there are security checks 
in that JAR's classes which check for the container name at runtime.  If 
they're repacked into another JAR, they fail to execute.  I may go back and 
play with that later, but for now the Java app on the local host will suffice.


Thanks,

Pete



From: Stephen Welsh 
Sent: Tuesday, September 26, 2017 9:51 AM
To: Pete Brown
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Hi Pete,

Would it not be better to create a small Java application that takes the 
encrypted content and returns the decrypted content (possibly passing in a file 
and creating a new file with the decrypted content?).

You can also compile Java to a .Net DLL using (https://www.ikvm.net), so you 
can call it directly without passing files backward/forward.
IKVM.NET Home Page
www.ikvm.net
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET 
Framework. It includes the following components: A Java Virtual Machine 
implemented in .NET



Kind Regards

Stephen Welsh
CTO

[cid:CBBF0493-235C-43D2-A874-9FB3D95AF598@b2.unifiedfx.com]

On 26 Sep 2017, at 15:38, Pete Brown mailto: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


Re: [cisco-voip] let's encrypt for local admin gui pages

2017-09-27 Thread Lelio Fulgenzi

Thanks for everyone's feedback! It's likely that I will revisit using privately 
signed certificates for non-public facing admin gui pages via our Microsoft AD 
base. As long as it's a Windows workstation signing into AD accessing the page, 
the certificate will be trusted without any warnings, etc. Again, this is just 
for non-public facing admin gui's so our team doesn't have to import private 
keys.

The hardest part was finding some decent instructions on how to do so. 
Apparently, when a private signed certificate is generated and granted it's 
available for download from the link presented during the process and there's 
no easy way to find an inventory of generated certificates!

Lelio


---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Doug 
McIntyre
Sent: Wednesday, September 27, 2017 8:40 AM
To: voyp list, cisco-voip (cisco-voip@puck.nether.net)
Subject: Re: [cisco-voip] let's encrypt for local admin gui pages

On Wed, Sep 27, 2017 at 04:07:53PM +0800, Ki Wi wrote:
> technically it can be done but it's too troublesome. Without "auto" 
> update, you will have to go manual which is to create special DNS (TXT 
> record) entry for each URL during the renewal.


DNS authorization of Let's Encrypt can be done through automated methods. 
Especially with a client such as dehydrated and the use of dynamic DNS updates 
(through ddns methods of nsupdate, or through the API of your DNS provider).

Not sure how easily the SSL cert can be rotated on the appliance devices though.
___
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] Adding custom entries to the Unity directory?

2017-09-27 Thread Ben Amick
Hey, running 9.1 here, I was recently asked if we could add our helpdesk number 
into the search by name directory in Unity - We do have a box in there for 
helpdesk, but the actual line for our helpdesk extension is tied to a call 
handler for the prompt. Is there any way we can add an entry into the unity 
directory to allow this to be searched for?

Ben Amick
Unified Communications Analyst



Confidentiality Note: This message is intended for use only by the individual 
or entity to which it is addressed and may contain information that is 
privileged, confidential, and exempt from disclosure under applicable law. If 
the reader of this message is not the intended recipient or the employee or 
agent responsible for delivering the message to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please contact the sender immediately and destroy the material in its 
entirety, whether electronic or hard copy. Thank you___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] let's encrypt for local admin gui pages

2017-09-27 Thread Doug McIntyre
On Wed, Sep 27, 2017 at 04:07:53PM +0800, Ki Wi wrote:
> technically it can be done but it's too troublesome. Without "auto" update,
> you will have to go manual which is to create special DNS (TXT record)
> entry for each URL during the renewal.


DNS authorization of Let's Encrypt can be done through automated
methods. Especially with a client such as dehydrated and the use of
dynamic DNS updates (through ddns methods of nsupdate, or through the
API of your DNS provider).

Not sure how easily the SSL cert can be rotated on the appliance
devices though.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


Re: [cisco-voip] let's encrypt for local admin gui pages

2017-09-27 Thread Ki Wi
Hi Group,
technically it can be done but it's too troublesome. Without "auto" update,
you will have to go manual which is to create special DNS (TXT record)
entry for each URL during the renewal.

On personal basis, I was doing that for my vpn boxes on google cloud. End
up, I just spend $42 usd recently to get a wildcard SSL (1 year) to solve
all the trouble. I'm lazy.

https://www.ssl2buy.com/alphassl-wildcard.php

Regards,
Ki Wi


On Wed, Sep 27, 2017 at 8:58 AM, Nathan Reeves 
wrote:

> I've been using it on Lab boxes without issue.  The 90 day expiry is a
> pain but for lab acceptable atm.
>
> In terms of generating / renewing the certs, you can use the web server
> validation process outlined by Ryan, but you can also use DNS record
> validation (which is what I've been doing).  Whether you're able to do that
> for your environment is the question.
>
> For reference, the certs load up fine and all services appear to work as
> far as my testing goes (it is a standard cert of course).  Expressways and
> Phone Reg via MRA also works fine when using the LE Certs.  Wasn't sure it
> was going to due to the specific list of certs the devices registering via
> MRA can support, but all worked well.
>
> I did come across https://www.yarnlab.io/certmate/ (though not actually
> tested it) which appeared (at least on the Expressways) to do the renewal
> process automatically using the available api's.
>
> Nathan
>
> On Tue, Sep 26, 2017 at 10:28 PM, Lelio Fulgenzi 
> wrote:
>
>>
>>
>> Thanks – you outlined the issues as I suspected them.
>>
>>
>>
>> I was thinking more about the admin gui for things like CIMC, and other
>> non-client facing services. But again, the same issues apply.
>>
>>
>>
>> Hopefully they modify their model slightly for appliance based systems
>> –or- the partners that are participating build a Let’s Encrypt option for
>> the certificates in their products.
>>
>>
>>
>>
>>
>> ---
>>
>> Lelio Fulgenzi, B.A.
>>
>> Senior Analyst, Network Infrastructure
>>
>> Computing and Communications Services (CCS)
>>
>> University of Guelph
>>
>>
>>
>> 519-824-4120 Ext 56354 <(519)%20824-4120>
>>
>> le...@uoguelph.ca
>>
>> www.uoguelph.ca/ccs
>>
>> Room 037, Animal Science and Nutrition Building
>>
>> Guelph, Ontario, N1G 2W1
>>
>>
>>
>> *From:* Ryan Huff [mailto:ryanh...@outlook.com]
>> *Sent:* Tuesday, September 26, 2017 10:24 AM
>> *To:* Lelio Fulgenzi; voyp list, cisco-voip (cisco-voip@puck.nether.net)
>> *Subject:* Re: let's encrypt for local admin gui pages
>>
>>
>>
>> Its theoretically possible to take the CUCM tomcat CSR and use it to get
>> LE to sign a cert, then take the resulting cert and attempt to upload it to
>> CUCM however; if it worked, LE only signs certificates for 90 days. So if
>> you did get it to work, you'd have to do it every 90 days (the built in LE
>> package on other Linux distros have built in tools to auto manage the
>> renewal process, but no way to do it with CUCM).
>>
>>
>>
>> ... but thats if the moon is blue and you have a winning lotto ticket. To
>> even get to that point, would be a feat; let me explain.
>>
>>
>>
>> The way LE for Linux signs certs is to install local software on the web
>> server that will do an automatic Internet based FQDN check (meaning it
>> automatically looks up the FQDN from the perspective of the Internet)
>> during the signing request. Once it finds the domain, it queries for a
>> specific item within the web path to verify that domain belongs to the same
>> person that started the certification signing request (this isn't a lot
>> different than the way Google or GoDaddy does it). However, the CSR must
>> exist in a specific location on the server you are trying to sign the cert
>> for. Once all criteria is met, LE automatically creates a vaild SSL
>> certificate for the web server that is signed for 90 days and installs it
>> on the web server.
>>
>>
>>
>> So in order to even try and get this to sign a cert for a CUCM CSR you'd
>> have to;
>>
>>- Create an Internet facing Linux web server that mimics all the
>>network details of the CUCM server and try to get LE to sign the CUCM CSR
>>on that web server (you'd take CUCM's CSR and upload it to the Linux Web
>>Server).
>>- Extract the signed .pem from the web server and attempt to upload
>>to CUCM as a tomcat (you'll also need to grab LE's root CA and upload it 
>> to
>>the tomcat-trust)
>>
>>
>>
>> In theory it might work, but is a helluva effort for 90 days just to get
>> free certs, then do it all over again. Now if you got it to work and had a
>> good workflow every 90 days ... maybe not that bad? The other thing to
>> consider that I'm not sure about in CMR cases (thinking if you tried this
>> on an Expressway Edge) is if Cisco Collab Cloud (i.e WebEx) would trust the
>> CA.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Ryan
>>
>>
>> --
>>
>> *From:* cisco-voip  on behalf of
>> Lelio Fulgenzi 
>> *Sent:* Tuesday, September 26, 2017 10:00 AM
>> *To:

Re: [cisco-voip] CUCM 10.5 and Office 365

2017-09-27 Thread Nathan Reeves
In situations where a customer has gone O365 (and they've got licenses for
Unity Connection Via CUWL Standard or Basic Messaging Licenses), I'd be
using Unity for Voicemail and AA's, and using the Single Inbox
functionality of Unity to get Voicemail's synced into the Users Exchange
Mailbox.  Note that Single inbox is still available post 1 July 2018, it's
only the SBC Functionality which is being deprecated.

The only thing from memory you lose with Unity Connection Vs Exchange UM is
missed call notifications.  Only issue I suppose is the additional tasks
required to manage the unity mailboxes vs Checking the box in AD for
Exchange.

Nathan

On Wed, Sep 27, 2017 at 2:47 PM, James Andrewartha <
jandrewar...@ccgs.wa.edu.au> wrote:

> On 27/09/17 13:12, Nathan Reeves wrote:
> > To be honest it was the best thing to happen.  After inheriting a
> > customer setup where they were using AA's on O365, with Cube acting as
> > the SBC, we saw endless issues with calls being answered but no audio
> > heard.  Wouldn't work for a varied length of time only to just start
> > working again.  Managed to move them over to Unity Call Handlers and
> > we've not skipped a beat since.  Like you, being in AU, we also saw
> > latency through to the O365 tenancy, though I'm suspecting the issues we
> > saw were not latency related.
>
> Hmm. AAs are less of an issue, we can leave them on the on-premises
> Exchange server that a hybrid configuration leaves behind for
> management. Voicemail is the main thing, at the moment it seems our
> choices are go to Exchange 2016 on-premises or switch to Unity
> Connection (we already have CUWL Standard for some reason) then go to
> Exchange Online. Is there a third option?
>
> --
> James Andrewartha
> Network & Projects Engineer
> Christ Church Grammar School
> Claremont, Western Australia
> Ph. (08) 9442 1757
> Mob. 0424 160 877
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip