Cisco JUMP Upgrade – You need things (Part #1)

You need a lot of things to handle a JUMP upgrade. If you’re not familiar with what I’m talking about I’ll run through the basics.

You have a Cisco Communications Manager on an older release and you cannot DIRECTLY upgrade to version 9.1(2). You can JUMP from the following versions – 6.1(4), 6.1(5), 7.1(3), and 7.1(5). Another case is that you’re on Cisco MCS servers and you’re going virtualized. The upgrade to Release 9.1(2) and data migration will be performed in an isolated environment and moved to production during a service window.

The following network services must be available:

  • default gateways—recreate all relevant networks and ensure connectivity between them
  • NTP server—this can be different IP address or a local router
  • DNS server—if a DNS server is used in the existing production environment, ensure the domain name matches for forward and reverse lookup of cluster nodes.
  • FTP and SFTP server—ensure sufficient storage for firmware, images, and backups

WAIT a minute! I’m in an isolated network in VMware, how do I have all of these things available to me? You really expect me to duplicate all of this in an isolated environment? My Cisco cluster will have the same names, IP addresses and configuration. My gateway will be the same. My DNS servers will be the same. Fortunately you can change all of this later on so all we need right now is to get through the installs and make our isolated network functional.

FreeBSD to the rescue. If you don’t know me already, I like FreeBSD. If FreeBSD is good enough for Netflix and Amazon it is good enough for me. Installing and duplicating all of this on a Windows machine would take hours. I’ll get it all done in a matter of minutes with FreeBSD.

5 MINUTES – Install FreeBSD in a guest machine alongside where you plan to upgrade your isolated 9.1(2) server. The current VSwitch should be the live network because we need to pull some actual information from the live network before isolating this FreeBSD VMguest. If this VLAN doesn’t support DHCP be sure to configure the static during installation. This guest doesn’t need much processing with what you’re about to do. Give the guest enough hard drive space you’ll need to host your FTP/SFTP upgrades and backups. I typically allocate 64GB which is thin provisioned anyway.

During installation select NTPD as a system service.

During installation create a user account called “jumpupgrader” or whatever you want. Since this is a controlled environment I add this user to “wheel” so I can get into root as necessary.

Guess what? Now you have a router, NTPd server, DNS server, FTP and SFTP server. However you’ll need slightly more configuration.

NTPd – You’ll need to fudge NTP. You’re going to move this VMguest into an isolated network so NTPd is going to lose contact to upstream stratum servers. (I’m not going into routing though this machine in this blog post)

vi /etc/ntp.conf

Change the last two lines

#server 127.127.1.0 to server 127.127.1.0

#fudge 127.127.1.0 stratum 10 to fudge 127.127.1.0 stratum 1

Service ntpd restart

If I’m going to fudge something I might as well pretend I’m a GPS hardware device. Now you can move this machine into the isolated network and NTPd will continue to respond.

Ntpq –p now responds with “LOCAL(0) .LOCL. 1 l 2 64 1 0.000 0.000 0.000

 

SFTP – SFTP is an SSHD subsystem and is operated by a helper. You can SFTP to your FreeBSD VMguest with your previously created user account. You will be connected to /usr/home/jumpupgrader with Filezilla.

DNS and BIND (I will update and republish within the next week when FreeBSD 10 comes out. There are some changes in the local resolver from BIND to Unbind and LDNS)

Cisco Communications Manager and other Cisco Collaboration products perform reverse and forward lookups during installation. You need to create the DNS zones and host entries. Fortunately this is very easy in BIND. If you need to get more complex than the following configuration just head over to Google and research BIND. As FreeBSD reminds you – I’m not going into the hairy details of DNS.

Vi /etc/rc.conf

 

Add a line

named_enable=”YES”

 

service named start

 

Viola we have a DNS server.

Make a backup of your configuration

/etc/namedb # cp named.conf named.conf.original

You need DNS to listen on the IP addresses you’re going to set up on FreeBSD. You’ll also need to create some zone files for the DNS infrastructure you’re going to fudge. Just follow me on all this and you’ll get it going in no time at all. Copy and paste if you have to.

vi named.conf

 

listen-on { 127.0.0.1; any; };

 

//this enables BIND to listen on any IP address configured. A “sockstat -4 –l” after service restart should show the local LAN ip address:53 in the list.

Go to the bottom of the configuration and put these lines into the configuration. Obviously substituting your “mycompany.local” for your master DNS zone you’re Cisco Collaboration systems exist in. And obviously getting the reverse lookup zone correct for the subnet your isolation servers are going to exist in.

zone “mycompany.local” {

type master;

file “/etc/namedb/master/mycompany.db”;

};

zone “255.31.172.in-addr.arpa”{

type master;

file “/etc/namedb/master/255.31.172.in-addr.arpa”;

};

 

Now write and save.

Time to create the zone files and all that good information needed for a DNS zone. Change the names below and just paste it in.

[email protected]:/etc/namedb/master # ee /etc/namedb/master/mycompany.db

 

PASTE THIS

 

$TTL 3600        ; 1 hour default TTL

mycompany.local.    IN      SOA      jumpupgrader.mycompany.local. admin.mycompany.local. (

                                2006051501      ; Serial

                                10800           ; Refresh

                                3600            ; Retry

                                604800          ; Expire

                                300             ; Negative Response TTL

                        )

; DNS Servers

                IN      NS      jumpupgrader.mycompany.local.

; Machine Names

localhost    IN    A    127.0.0.1

jumpupgrader    IN    A    172.31.255.120

cucm-publisher    IN    A    172.31.255.5

cucm-subscriber    IN    A    172.31.255.6

 

Escape and save the file.

 

Command to create next zone file-

 # ee /etc/namedb/master/255.31.172.in-addr.arpa

 

PASTE THIS

  
 

$TTL 3600        ; 1 hour default TTL

255.31.172.in-addr.arpa.    IN      SOA      jumpupgrader.mycompany.local. admin.mycompany.local. (

                                2006051501      ; Serial

                                10800           ; Refresh

                                3600            ; Retry

                                604800          ; Expire

                                300             ; Negative Response TTL

                        )

                IN      NS      jumpupgrader.mycompany.local.

120             IN      PTR     mycompany.local.

5    IN    PTR    cucm-publisher.mycompany.local.

6    IN    PTR    cucm-subscriber.mycompany.local.

 

Escape and save the file.

Now do a final restart and let’s check the configuration –

service named restart

[email protected]:/etc/namedb/master # nslookup

> server 127.0.0.1

Default server: 127.0.0.1

Address: 127.0.0.1#53

> cucm-publisher.mycompany.local

Server: 127.0.0.1

Address: 127.0.0.1#53

 

Name: cucm-publisher.mycompany.local

Address: 172.31.255.5

> 172.31.255.5

Server: 127.0.0.1

Address: 127.0.0.1#53

 

5.255.31.172.in-addr.arpa name = cucm-publisher.mycompany.local.

>

 

Success!

 

Now we have the basic network services needed to handle the CUCM installations in our isolated network. If you copied and pasted most of this you should’ve been done very quickly. Must less time as compared to installing Windows Server 2012, installing DNS services, installing an NTP service, and installing an SFTP service.

 

The next pieces will come in PART 2!

 

 

 

 

 

Advertisements

Cisco Jabber and your XML file

Greetings! I know not many people read this blog. Primarily because I’ve rarely posted anything. I am starting to get some traction putting a few things up here and essentially it’s for my own use. For years I’ve benefited from other notes and blogs from other engineers. I think it’s time I started contributing. Smile

 

Cisco Jabber for Windows, Mac, iPhone, iPad and Android. You want to support all of these devices on your Cisco Collaboration system? You’re in for a special treat. Each different client has it’s own configuration parameters. Some of the clients need device level configuration. Some of the other devices need the jabber-config.xml file.

Specifically Jabber for Mac 8.6.6 seems to have some issues using the jabber-config.xml. Users are getting SSL prompts and directory lookup issues with Jabber for Mac 8.6.6. It is good to note here that Jabber for Mac 9.2 is in beta and should be released this month. Jabber for Mac 9.2 really fixes a lot of issues and hopefully will be available very soon.

I’ve been pushing for years that corporations move to a UPN login method. Meaning [email protected]” when logging into their PC, their Microsoft domain, and applications. As a general rule of thumb a users Microsoft UPN equals their primary SMTP.. and this should equal primary SIP URI.

“UPN=SMTP=SIPURI” – essentially these three values define the domain the user is in. These values are also unique across all your domains to contact your user.

Below you’ll see my sample XML that is using an integration with Cisco IM and Presence and Cisco Communications Manager 9.1.1b. This integration uses “mail” mapping to the user logon name.

The XML file needed is for obvious reasons. The Jabber client downloads this file from the Communications Manager TFTP service. I have an open TAC case to work with the LDAP connection issues and I’ll post back here with results.

If you’re looking for a decent tool to help generate your jabber-config.xml file; check out this link –

https://supportforums.cisco.com/docs/DOC-25778


Sample jabber-config.xml:

<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Presence>
   <PresenceServerAddress>10.1.1.11</PresenceServerAddress>
   <PresenceServerDomain>externaldomain.net</PresenceServerDomain>
</Presence>
<Directory>
   <DirectoryServerType>EDI</DirectoryServerType>
   <PrimaryServerName>dc1.internaldomain.local</PrimaryServerName>
   <ServerPort1>3268</ServerPort1>
   <SecondaryServerName>dc2.internaldomain.local</SecondaryServerName>
   <ServerPort2>3268</ServerPort2>
   <UseSSL>0</UseSSL>
   <UseSecureConnection>0</UseSecureConnection>
   <UseWindowsCredentials>0</UseWindowsCredentials>
   <ConnectionUsername>cisco_jabber_ldap_user</ConnectionUsername>
   <ConnectionPassword>myspecialpassword</ConnectionPassword>
   <SipUri>mail</SipUri>
   <BusinessPhone>ipPhone</BusinessPhone>
   <MobilePhone>mobile</MobilePhone>
   <OtherPhone>otherTelephone</OtherPhone>
   <DomainName>userPrincipalName</DomainName>
   <BaseFilter>(&amp;(objectCategory=person))</BaseFilter>
   <UserAccountName>mail</UserAccountName>
   <SearchBase1>DC=internaldomain,DC=local</SearchBase1>
</Directory>
<Policies>
   <InitialPhoneSelection>deskphone</InitialPhoneSelection>
</Policies>
<Options>
   <Start_Client_On_Start_OS>true</Start_Client_On_Start_OS>
</Options>
</config>


Cisco ASA–Send the right enrollment request to the CA

A few things I forgot to mention in my previous posts. You need to send a properly formatted request the Microsoft NDES service from the Cisco ASA. This needs to include the domain and correct key size. If you do not specify these enrollment properties correctly the CA will deny the request. Usually the deny will show up in the application log indicating that the key size is wrong.

No real need to go up to a 2048 key size unless your security requirements demand it. Remember – the higher the key size and the number of connections will impact your CPU performance on the ASA.

Here is an example configuration for the ASA enrollment:

image

 

Also – be sure the NDES service has the correct security properties on the template. Go ahead and give it “Full Control” and this will check the Auto-enroll security also.

NDES Server Configuration for SCEP (Cisco ASA SCEP Proxy)

A quick little reminder – the Microsoft NDES implementation requires a one-time password to enroll network devices. However this gets rather complicated because the whole BYOD concept means you do not have access to that one-time password. The administrator is not involved to get you on the network right? You get credentials and that’s all..

An adjustment needs to be made to Microsoft NDES implementation to let the Cisco ASA proxy the SCEP enrollment request.

Disabling the "one-time password" on the NDES server is configured in the following registry key: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\EnforcePassword

EnforcePassword value data is set to "0". "0" ensures no password is requested by NDES.

 

Another thing to keep in mind – default NDES implementation will use the “IPSEC (Offline Request)” certificate template. You need to make a decision if this is the template you want to have enrolled for those getting a BYOD certificate.

 

Let’s say you want some better control of the certificate getting issued. I would recommend creating a custom template. And this is a user device so lets give is the right key usage.

  • Duplicate the “IPsec (Offline Request)” template – I use “User NDES”
  • Modify the extensions so the extension list looks like – You don’t have to assign all of these uses, but this mirrors the most likely use cases.
    • Server Authentication
    • Secure Email
    • Encrypting File System
    • Client Authentication
    • IPSec IKE Intermediate
  • Adjust the certificate validity period and renewal period according to your policy for user certificates.
  • Check the box for publish in Active Directory if you are using EFS
  • Add the NDES service account to the security permissions on the template with “Read and Enroll” checked.
  • Modify the registry key to assign what certificate is assigned during enrollment
    • HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MSCEP
    • image

Cisco CUBE and MOH issues

Recent issue and a quick reminder about Cisco CUBE and MOH issues. If you’re having issues dealing with inbound callers not hearing MOH when being placed on hold – then the issue might not be CUBE.

Check this service parameter on CUCM – Duplex Streaming Enabled

“”This parameter determines whether music on hold (MOH) and Annunciator use duplex streaming. Valid values specify True (use duplex [two-way] streaming for MOH and Annunciator) or False (use simplex [one-way] streaming for MOH and Annunciator). Specifying True facilitates interoperability with certain firewalls and NATs. The default value is "false".””

 

Simple answer – Cisco 15.x IOS likes duplex audio streams.

Cisco ASA enrollment for SSL using SCEP

Alright – so if you’ve set up Microsoft NDES on server 2012 and followed the basic instructions your CA is now ready to auto enroll based on the “IPSECIntermediateOffline” template.

However, let’s say you want to actually enroll the Cisco ASA using SCEP to provide a server authentication certificate? You’re wanting to do this so your AnyConnect SSL/WebVPN will use an SSL certificate from your internal Active Directory Enterprise CA.

Simple – change the registry value for the MSCEP.dll and restart IIS. Then go back to your Cisco ASA and perform an new identity certificate enrollment. Be sure to populate all of the certificate name fields getting your CN correct.

CN=vpn.mydomain.net

 

The key is : HKLM\SOFTWARE\MICROSOFT\CRYPTOGRAPHY\MSCEP\

Set this to GeneralPurposeTemplate = Webserver

You can now enroll your Cisco ASA using SCEP to obtain a Server Authentication certificate. You can check the CA certificate and now you you should see an assigned certificate using the WebServer template.

Be sure to set the GeneralPurposeTemplate back to “IPSECIntermediateOffline” once you’re done unless you need to SCEP enroll more Web Servers.