Introduced in UCM version 11 is the ability to synchronize groups from Active Directory. The primary driver is to have Active Directory groups available in the Cisco Jabber contact list.

One problem this brings up is that if you’re synchronizing from the base DN you’ll import all security groups. So you’ll need an effective filter to only get the groups you want. Generally speaking distribution groups are an ideal target for what you want represented in UCM and Jabber. The more granular you get will require more administration in Active Directory.

I’ll first outline the LDAP filters that will look for security groups and filter different types of groups. These are the bit values for each group and you’ll end up using the bitwise value.

All Security Groups with a type of Global
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483650))

All Security Groups with a type of Domain Local
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483652))

All Security Groups with a type of Universal
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483656))

Values for the different group types:
Global = 2
Domain Local = 4
Universal = 8
Security Group = 2147483648
Distribution Group = no value

Using the above information we can then build LDAP filters to only import distribution groups. Since a distribution group doesn’t have a value you have to add the NOT operator to the query.

All Global Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

All Domain Local Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

All Universal Distribution Groups
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

Now what if you want distribution groups and security groups and want to select certain groups? Depending on how much additional administration you want in Active Directory you can pick a custom attribute. At this point all you have to do is look for the custom attribute not in use and populate it. Exchange 2010 SP2 and higher introduces 5 new multivalued attributes, but in this example we’re still using a custom attribute.

I recommend running some queries to determine if you have any custom attributes currently in use and then picking the next available value. You can use whatever value you would like just as long as it’s descriptive enough why it’s being used. In the examples below I’ve used “CiscoUCM” as a value to indicate the system thats using it in a query.

All Groups with Custom Attribute 1 – (Note the LDAP property is named extensionAttribute1)
(&(objectCategory=group)(extensionAttribute1=CiscoUCM))

Only Universal Distribution Groups with Custom Attribute 1
(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8)(extensionAttribute1=CiscoUCM)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

I personally prefer the highest granular approach based on universal distribution groups and a custom attribute. This way the control is based on the source information and synchronized Cisco UCM/IMP information is kept to a minimum.

Happy filtering!

Cisco Jabber version 11 is significant in many ways and it’s difficult to outline all of the details in a single post. First and foremost Cisco is continuing to show that cross-platform feature parity, mobile first, and secure first is a leading part of the strategy.

Enterprise groups, persistent chat, and WebEx CMR escalation are three things significant enough to mention. There are some future integrations that will be better shown than blogging about.

There is a lot of work happening back at Cisco and I’m sure the Jabber team backlog is growing. In the meantime I highly recommend taking a look at the videos below to become a little more familiar with Cisco Jabber 11.

Check out these new Jabber 11 Videos

• Cisco Jabber for Android 11: Overview
• Cisco Jabber for Android 11: In call Features
• Cisco Jabber for iPhone and iPad 11: Overview
• Cisco Jabber for iPhone and iPad 11: In call Features
• Cisco Jabber for Mac 11: Introduction
• Cisco Jabber for Mac 11: Contacts
• Cisco Jabber for Windows 11: Introduction
• Cisco Jabber for Windows 11: Personalize Your Jabber

The release notes detailing the new features:

• Cisco Jabber for Windows 11.0 Release Notes
• Cisco Jabber for Mac 11.0 Release Notes
• Cisco Jabber for iPhone and iPad 11.0 Release Notes
• Cisco Jabber for Android 11.0 Release Notes
• Cisco Virtualization Experience Media Engine for Windows 11.0 Release Notes
• Cisco Virtualization Experience Media Engine for SUSE Linux 11.0 Release Notes

With VMware 5.5 showing up everywhere including Cisco collaboration specific hosts I found it was time to look into the use of latency sensitivity. Please don’t run off and turn this on without a proper understanding of what you’re changing on your UC cluster especially if you’re not follow co-residency guidelines. (That was a disclaimer and why wouldn’t you follow co-res guidelines anyway?)

When scoping or designing a UC cluster that involves Unity Connection there was always an extra core reservation for the VMware scheduler. With VMware 5.5 and the ability to specify latency sensitivity we don’t need to have one core sitting idle.

The reason this is important was due to core oversubscription and the co-residency guidelines published by Cisco. For example; if your host has 12 cores you can now safely lay out the VM reservations across all 12 cores and not 11 cores. This only applies if you have an active Unity Connection VM on the host machine. All other VMs on the host must have the latency sensitivity set to “normal”. Only the Unity Connection VMs will be set to “high”.

So now you’re wondering how do I cut it on? First it has to be modified while the machine is powered off, and if you have vSphere Web Client it is simple as “VM Options | Advanced settings | Edit | Latency Sensitivity = High”.

OK – I see this yellow exlaimation point and what is about to happen? The warning is to let you know this should be performed on a VM that has CPU reservation. If you used the OVA to deploy Unity Connection and have not changed vCPU amounts or reservations you’re in the clear to proceed.

Since most UC clusters and ESXi hosts specific for collaboration are not joined to vSphere you need a way to turn on latency sensitivity without vSphere Web.

• Using the vSphere client edit the settings of the Unity Connection VM.
• Click Options | Advanced-General | Configuration
• First scan to see if “sched.cpu.latencySensitivity” is in the configuration parameters.
• If the setting does not exist click “Add Row”
  • Name = sched.cpu.latencySensitivity
  • Value = high
• Click OK | OK

Don’t forget to power it back on. 🙂

There has been a flurry of activity lately when it comes to Jabber and certificate warnings. Jabber adoption is growing and being exposed to a lot of different installations of Communications Manager and IM & Presence.

Not only do we have the adoption rate skyrocketing but we’re also seeing the development cycle becoming extremely fast. In the last 2 months I believe I’ve counted 4 minor releases to just 1 train of Jabber. This is presenting several challenges between the development and the deployment of Cisco Jabber. The technical information, deployment recommendations, and caveats are not being consumed fast enough in the field to understand the nuances of getting it to work. All of this is a great effort by Cisco but I do believe there could be a better way getting technical notes out to the field.

Certificate warnings are something that just isn’t acceptable. If your workaround is telling someone to ‘Click Accept’ then you’re not doing something right. We’re dealing with a client application and parts of the CUCM system that in the past have rarely needed to be touched. If communications manager and presence were installed for telephony only there are many things lacking to get these certificate warnings to go away.

Here is the latest information straight from Cisco regarding the certificates you need to adjust depending on the products you have deployed.

Required Certificates for On-Premises Servers On-premises servers present the following certificates to establish a secure connection with Cisco Jabber:

So let’s break this table down into something a little more understandable. On Communications Manager this involves uploaded valid CA certificates to callmanager-trust and tomcat-trust. Once those are uploaded you need to generate a CSR for callmanager.pem and tomcat.pem. Even though you can sign all your CUCM nodes with one SAN certificate there are several caveats with this and my personal recommendation is to continue signing each CUCM node with its own certificate.

On IM & Presence you need to upload valid CA certificates to cup-trust, cup-xmpp-trust, and tomcat trust. Once that is complete you need to generate the CSR and sign cup, cup-xmpp, cup-xmpp-s2s, and tomcat.

On Unity Connection you’ll only need to upload and sign the tomcat certificate.

One Expressway-CORE you’ll need to upload the valid CA certificate and generate a server certificate. On Expressway-EDGE you’ll 100% need a public signed CA certificate for the server certificate. If you’re not going to use Expressway for B2B communications and every device using Jabber MRA has managed certificates you MIGHT get away with a private CA signed certificate, but I still wouldn’t recommend it.

These certificates need to be x509v3 compliant for server authentication, client authentication, and ipsec. If you’re looking for the exact settings needed I have the certificate template EKUs below. All of the certificates can all be signed by a Microsoft CA with an x509v3 compliant template.

Version: V3
SignatureAlgorithm: SHA1withRSA (1.2.840.113549.1.1.5)

Extension: ExtKeyUsageSyntax (OID.2.5.29.37)
Critical: false
Usage oids: 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.5, 1.3.6.1.5.5.7.3.2,

Extension: KeyUsage (OID.2.5.29.15)
Critical: false
Usages: digitalSignature, nonRepudiation,keyEncipherment,dataEncipherment

The callmanager certificate also has keyAgreement usage but this is mutually exclusive of keyEncipherment per RFC 3280. The keyCertSign is also not needed as an EKU because this isn’t a self-signed certificate. Your callmanger certificate is perfectly valid without these two EKUs. My x509v3 template typically includes nonRepudiation to allow the certificate template to be used for VMware servers.

A final reminder is if you truly want to support all client types without doing managed PKI go ahead and save yourself a lot of headache and get public CA signed certificates for all of this.

So you’ve done all of that and you still get a certificate warning?

There is a good possibility you have certificates correct but you’re still getting these prompts. Let’s understand this issue a little deeper before I get to the long term fix. SSL certificate validation is based on the client and server agreeing to the subject name or SAN name. For example, if you have a valid and trusted certificate on a web server and you browse to https://10.1.1.0 you’re going to get a certificate warning from your browser. This is because you told the browser you wanted a secure connection to 10.1.1.0 but the server sends back a certificate the the name webserver.domain.com. The same thing is happening underneath Jabber between CUCM, CUPS and Expressway. When Jabber connects to CUCM via UDS or CTI the server may be responding with an IP address even though you’ve requested the FQDN. SO WAIT – isn’t that a reverse of what you just said? Absolutely it is but the same principle applies. The CUCM and CUPS “System > Server” setting is giving you this problem. So while Jabber tries to connect to CUCM via cucm-node1.domain.com the UDS/CTI is responding with https://10.1.1.20 which will be the IP address of the node.

So now what – I can’t just go and change that “System > Server” value without breaking the whole cluster! This is where some additional pain points may come into play. The “System > Server” value controls quite a few communications between cluster nodes and endpoints. This value is essentially put into the phone configuration files that are downloaded. Over the years Cisco SRND and guides have flip flopped with the recommendation here. There have also been several bugs along the way using hostname or FQDN. Now we’re to a point where FQDN is the standard and any bugs will need to be fixed to support FQDN. My first recommendation is make sure you’re on the latest versions of CUCM and CUPS and this is super important if you’re serious about the Jabber deployment.

Some have opted to put the hostname or IP address of the “System > Server” values into the SAN certificate fields that are uploaded to the servers. While this sounds like an OK workaround that particular SSL certficate it still invalid per the CA/Browser forum. It may “work” but at this point in time it is more of a hack. You can read the full details of this CA/Browser change at https://www.digicert.com/internal-names.htm

I know this post got a little long but it’s really important stuff to get your deployment up to the new standards, using valid certificates, and keeping certificate warning prompts away from your users.

Thanks and feel free to comment or reach me on Twitter!

Expressway 8.5 adds the capability to add Unity Connection directly to the Expressway Unified Communications configuration. This gives Jabber mobile and remote access clients the ability to manage voicemail messages via HTTPS to the VMREST(CUMI) API.

In previous versions of Expressway we had to manually add the Unity Connection servers to the HTTP allow list. With this version once we add Unity Connection it automatically updates the HTTP allow list.

A caveat to be aware of similar to the CUCM and IM&P caveat is if you’re using host names or IP addresses for the “System -> Server” setting. In many cases your Unity Connection server is going to be defined by hostname which is default. The thing to note is if your Unity Connection is hostname only and you add this to Expressway your HTTP allow list is going to be incorrect. Expressway will detect hostname only and add only the hostname to the HTTP allow list.

So what’s the fix? Change your Unity Connection server value to FQDN. If you’re running a cluster this does have a little impact where you’ll need to restart services but if it is a single node you can make this change without impact.

Once Unity Connection server value is FQDN go ahead and add or refresh the server on Expressway and the HTTP allow list will update correctly. Just one of the little nuances if you head down this road on Expressway and Jabber MRA cannot connect to voice mail.

Thanks!

Jabber 10.6 is bringing a wealth of new features and functionality to the desktop. However we’re getting to a point you might not want to enable all of these slick features for your entire enterprise. So I’ve recently fielded a question how to ‘group’ enable features.

Let’s get a little context with configuration files so you’ll understand when and when not to have group configuration files. If you’d like to spend time reading the deployment and installation guide you can get more details.

Global configuration files applies to all users. This file (jabber-config.xml) is downloaded by the client from your TFTP nodes. (cough.. UDS via HTTPS). Group configuration files applies to subset of users and take priority over global configuration files.

The ‘take priority’ piece is what you need to logically plan for. You may even think of the global configuration file as a baseline for the environment and have features added by a group configuration file only. This may get to be a lot of work so don’t go overboard with group configuration files. You’ll end up creating a lot of work maintaining the CSF devices.

The group configuration file is uploaded and maintained just like the global one. You can create a group naming convention that suits your needs. Some have used something similar such as ‘jabber-config-group1.xml’ or feature specific as ‘jabber-config-hunt.xml’ that takes the global config and adds in the hunt group tab.

So where do you specify this group configuration file? On the CSF, BOT, TCT, or TAB “Cisco Support Field”. Yes I know this isn’t the greatest place to maintain this and it’s already been suggested to break this out into another field but that isn’t the direction we’re going. This is really only a stop gap or you have a specific group of people you need to add a feature or turn off a feature. Executives and Contact Centers come to mind.

So scroll down to “Cisco Support Field” and put in something like this.
configurationfile=jabber-config-group1.xml

You can even get creative with TFTP directories if you already have this going on CUCM. So configurationfile=/folder/jabber-config-group1.xml

If you’re uploading the file for the first time you’ll need to restart your TFTP service. If the file already exists and you’re simply making changes you do not need to restart the TFTP service. Send me a note on Twitter if you’d like me to post an explanation of this.

Another thing to note is that the Jabber client will be notified of this change and if it determines it needs a restart it will prompt the user to log out and sign back in.

I’d recommend creating a test XML file for your deployment so you can test the enabling and disabling of features without affecting the enterprise population. Once you get the hang of policies and working with different files you’ll be able to test and roll out new features very quickly.

Thanks and happy Jabbering!

Having a functional SAML SSO product in place is important before attempting to connect any Cisco collaboration applications to it. I’m focusing on Microsoft ADFS because it seems to be the current go-to product for Microsoft centric organizations.

You need to collect and check your federation metadata file before starting any Unity Connection configuration. This file gives you the value you need to configure the custom claim rule on ADFS. You can download the file from https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml

Open this file and get your entityID and in my configuration this looks like https://adfs.domain.com/adfs/services/trust

Go ahead and collect the file from Unity Connection on the SAML SSO configuration page by clicking “Export All Metadata”. You’ll need this file available to your ADFS management application so copy it to your server.

Now we have everything we need and it’s time to configure ADFS and Unity Connection.

1. Open the ADFS Management application
2. Select Add Relying Party Trust.
3. From Add Relying Party Trust Wizard Welcome page, click Start.
4. From the Select Data Source screen, click the Import data about the relying party from a file radio button and browse to the Fedlet metadata XML file which you downloaded from the SAML Single Sign-on configuration pages. Click Next.
5. From the Specify Display Name screen, enter a name in the Display name field. Click Next.
6. From the Choose Issuance Authorization Rules screen, choose Permit All Users to access this relying party. Click Next.
7. Review the settings on the Ready to Add trust screen. Click Next.
8. To add the Claim Rules, from the Finish screen, check the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes check box. Click Close.
9. From the Edit Claim Rules screen, click Add Rule.
10. Select the default Claim Rule template Send LDAP Attributes as Claims. Click Next.
11. From the Configure Claim Rule screen, enter a claim rule name (Example: “Send uid attribute”) in the Configure rule name field.
12. From the Attribute store drop-down list, choose Active Directory.
13. From the LDAP Attribute drop-down list, choose the attribute in the directory that the Cisco Unified Communications application end users are synchronized with (typically “sAMAccountName” or “userPrincipalName”).
14. From the Outgoing Claim Type drop-down list, enter “uid”. Note: “uid” will not appear in the list of drop-down items, you must manually enter it.
15. Click Finish.
16. To add a second rule, click Add Rule.
17. From the Claim rule template drop-down list, select Send Claims Using a Custom Rule.
18. In Claim rule name field, enter a name (Example: “Send additional attributes”).
19. See the next paragraph and code and after pasting click OK and Apply.

So now you can paste your custom claim rule to this ADFS text input box. There is a bit of an issue copy and pasting this correctly from the Cisco documentation and the fact it’s plain wrong in Cisco documentation. Note the two modifications below for entityID and FQDN for Unity Connection on the last line. You should be able to copy below, modify two lines and be able to paste into ADFS management.

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer =

c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =

"urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =

"https://adfs.domain.com/adfs/services/trust",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =

"unityconnection.domain.com");

Now that all of this has been done you can configure Unity Connection by clicking Enable SAML SSO and following the dialogs. Once you enable SAML SSO obviously you’ll need LDAP users synchronized with administrative privileges on the Unity Connection server. The recovery URL will be available on the start web page just in case ADFS is not functioning.

If everything is working click “Run SSO Test…” and select your administrator account that is synchronized via LDAP. If the redirect works and your browser automatically signs into ADFS you’ll get the wonderful pop-up below.

Cisco Jabber has an administrative feature allowing users to submit problem reports directly from the user interface. When troubleshooting issues with Jabber this is usually one of the first steps. I consider this a better method instead of having the user save the PRT zip file, subsequently lose it on their computer, and then clogging your inbox.

The nuts and bolts of how this works is briefly described in the Cisco Jabber installation and configuration guide. You need a method to submit the problem report and a method to retrieve the problem report. This post is purely focusing on how to submit the problem report to a server and it’s up to you on how to retrieve it. If you’re anticipating using this frequently or in an enterprise you’re going to need to do some light file handling on the server side. The Cisco problem reporting upload mechanism doesn’t randomize file names during the upload.

I’m working with my FreeBSD server specialized for Jabber functions so underneath I have Apache and PHP. The disclaimer I’m going to insert is that is up to YOU to secure your installation. Creating a free-for-all upload location on your network poses a big security risk. My goal here is to give you the basics with Jabber and what it is doing.

Cisco Jabber does an HTTP POST directly to the URL you specified in your jabber-config.xml. This HTTP POST contains the following information so this is merely informational if you would like use a different upload method. The “ciscoID” portion of the POST is generated by the Cisco JID.

POST /uploadprt.php HTTP/1.1
Request Method: POST
Host: yuengling.brewery.com
Full request URI: http://yuengling.brewery.com/uploadprt.php
Type: multipart/form-data
Content-Disposition: form-data; name="zipFileName"; filename="PROBLEM_FEEDBACK_Cisco_Jabber_ciscoID.zip"

Now that you know how Cisco Jabber uploads to your server you need a corresponding catch-all script to accept the upload. Cisco gives you an example HTML form that you can put on your server. This form is optional and not necessary to have Cisco Jabber automatically upload PRTs. The goal was to provide you an example of how you need to accept the ‘zipFileName’ form data.

uploadprt.html

<form name="uploadPrt" action="http://yuengling.brewery.com/uploadprt.php" method="post" enctype="multipart/form-data">
<input type="file" name="zipFileName" id="zipFileName" />

<input type="submit" name="submitBtn" id="submitBtn" value="Upload File" />
</form>

The next piece of the puzzle is the uploadprt.php file and how it interacts with the incoming HTTP POST from Jabber. Jabber uploads a file name that is exactly “PROBLEM_FEEDBACK_Cisco_Jabber_ciscoID.zip” and if you do nothing else to the file name the user will continually overwrite the same file. So I decided to go ahead and add a time-stamp which you can see below in the $uploadfile variable.

I do not recommend you use this code without adding in proper file handling controls. I’m working in a sealed environment so this is the bare essential method to accept the upload. Obviously the $uploaddir needs to be set to your server location you want to store the files.

uploadprt.php

<?php
$uploaddir = '/usr/local/www/apache22/data/uploads/';
$uploadfile = $uploaddir . date('Y_m_d_H_i_s') . basename($_FILES['zipFileName']['name']);
move_uploaded_file($_FILES['zipFileName']['tmp_name'], $uploadfile);
?>

So you’ve put all this together and as always I’m ready to tell Jabber via the jabber-config.xml file where to upload problem reports. It’s important to note that the PrtLogServerUrl parameter points to your upload PHP script and not the HTML form provided in the documentation.

jabber-config.xml

<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Client>
<PrtLogServerUrl>http://yuengling.brewery.com/uploadprt.php</PrtLogServerUrl>
</Client>
</config>

The end result is I have a directory on the server that houses the Jabber problem reports as “2014_12_10_20_19_50PROBLEM_FEEDBACK_Cisco_Jabber_ciscoID.zip”. From here you can work this into any further automation methods such as e-mailing or FTP. The first goal has been met to get the file from the client to the server and from there further automate.

If everything is working you’ll end up with a little window that looks like this. Happy Jabber-ing!