Cisco Collaboration Certificates and Security

A lot has changed with CUCM certificate management and requirements. I think it’s only starting to sink in that CUCM is an application and should be treated like any other application that requires certificates. Continuous development has extended to on-prem apps. 

PKI isn’t new and certificates are not new. We’re not talking about bleeding edge technology and the issues that I’m seeing are related to misunderstanding fundamental technologies. Subtract CUCM from the equation and SSL/TLS/PKI principles apply regardless of the product underneath. 

Just because we as voice engineers haven’t “done it this way” before doesn’t mean we should “keep doing it this way”.

I usually start with an assessment of the client and their ability to manage internal PKI. If my assessment is that they haven’t done their PKI correctly or do not understand the concepts I immediately divert to a managed PKI discussion. For example, if I see a single root CA that’s SHA1 and it’s also the issuing CA that’s a thumbs down. If I also see they are lacking MDM or ISE it’s pretty evident adding a single management CA isn’t going to accomplish the end goal.

What is the end goal? Easy.. You don’t want anyone to click through a certificate warning regardless of device. If you as an administrator are clicking through certificate warnings you should seriously consider fixing that. 

Do PKI right or let the professionals do it for you. 

You can save yourself a lot of time, effort, and management headache if you’ll use 3rd party verified certificates internally and externally. The reality is you’re going to spend a fraction of the cost of internal PKI management. 

This also means that your servers should be operating in a domain that is resolvable in the context of the Internet. The service domain and server fields of the collaboration applications should be within an FQDN of a domain that you own. This is a strong recommendation from Cisco and has been a personal recommendation for years. Microsoft has even been advocating this forever but it’s been ignored in a large way. 

Let’s keep it real and stop using IP addresses to define connection points in and out of applications. We’ve all complained to developers before as network engineers if they’ve hard coded IP addresses. However we as voice engineers are doing the same thing. Use fully qualified names and SRV records to connect services together. TLS relies on the naming context of each service connection point and IP addresses in certificates are not acceptable.

Also it’s not reasonable to accept wide use of wild card certificates. What wild cards are intended for and what they’re being used for these days are two drastically different things. If your issuing authority will re-key a wildcard for a single issue SAN that is a step in a better direction but I’m not a fan of that either. You’re putting all your eggs in one basket against that wildcard. 

My final soap box is about secure clusters. A large majority of CUCM clusters are non-secure meaning they use unencrypted communications. Yes the token management hasn’t always been the easiest but this should be a default configuration change moving forward. Version 11 of CUCM has introduced a lot of enhancements in this area. It’s still PKI we are talking but it’s a different key ring. SIP signaling and media encryption inside the network should be just as important as outside the network. More and more we are doing Ethernet handoffs to carriers for the WAN. In reality your voice communications are exposed on those connections unless you’re also running an encrypted WAN. How many of us are running an encrypted WAN? 

Encryption for telecommunications should be a high priority for all enterprises and engineers responsible for telecommunications. It’s been a high exposure area for quite a long time and the conversation needs to shift. We’re not behind the firewall anymore. 

  

Cisco UCM 11 and LDAP Group Filtering

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!