Workplace contingency plans: the hidden issue

iStock-920982208-AndreyPopov-1200x600-600x300The Covid-19 pandemic caused an worldwide cause for concern. The best way to contain it is to reduce people direct interaction.
Some governments already imposed travel bans, forbid crowded events and closing schools.
Companies also limited travelling and ultimately send people to home office.

This is a great case scenario for companies to have the right UCC solution in place.
People can still collaborate, arrange meetings on the ‘safety’ of their home without the risks of public transport travelling, office doors knobs, next desk colleague or customer meetings.
Now, Skype for Business and others become a critical tool for companies.

But there is a ‘unexpected catch’ for companies to send half or more of their workers home: How do workers access the company internal resources? usually using a VPN.

Suddenly, companies have a large number of people using the internet speed and bandwidth to fighting for access to the systems (and also the Internet) -and it’s probably not the 1Gpbs per user as on the office LAN –

Now this old feature topic raised again.

The issue

Besides the issue of available bandwidth (including the one at home), how this can this get worth?

Sound_featureSome companies have VPN policies (either to security reasons or simplified administration) to enforce all their managed PC to send all the traffic throw the VPN (let’s call it ‘Forced-tunnel VPN’).
This includes applications traffic, emails, files, internet browsing including video content and… Skype for Business (SfB)!

As you already imagine people expect audio, video and the shared contents to be real-time but the SfB client is competing with:

  • Other applications loading files, email, video from the same tunnel
  • Double encryption/decryption: SfB encrypts his traffic and the VPN encrypt the traffic that is sent over the internet

If not well planned or prepared, IT support is going to have a flood of disgruntled users complaining about voice quality issues, failures, and unsuccessful meetings.

‘Force-tunnel VPN’ creates an additional problem for real-time protocols. Instead of delivering the packets to the shortest route possible, it will take a very long path in some cases. Let’s use the following picture to show you that:


There are two evident situations:

  • The calls between two home office worker of the same company will go first to the VPN server. And the call might get encrypted/decrypted twice
  • If another ‘SfB enabled’ company also uses Forced-tunneling the traffic will (1) get encrypted/decrypted until the SfB Edge server (2) to the other company Edge server and encrypted/decrypted again.

Now you have SfB traffic getting encrypted on an (overloaded) VPN tunnel traveling between several other systems and networks.

End user calling: “Skype for Business is a sh***. Totally useless”

Is there a solution?

Ask the CFO that you need to increase the internet bandwidth 🙂

Or… implement a Split-tunnel VPN.
SfB takes advantages of protocols like ICE and STUN/TURN to pass through routers and firewalls and get the shortest path to the other endpoint.

Let’s see the same picture now, where users don’t use a VPN or there is a complete Split-tunnel configuration:



  • Home Office calls are going directly throw the Internet and encrypted only once (native done by SfB)
  • The other SfB call and conferencing will go to the internal LAN throw the SfB Edge server (and encrypted only once)
  • All SfB traffic will not consume VPN bandwidth

Is it important? as the Covid-19 continues to spread, more and more companies will adopt, someway or another, home office policies.
If 5% of home office of the users complaining about calls issues might not be important, but if you suddenly have 50-75% of your staff at home a SfB issue would make you look at a different perspective.

How to implements a split-tunnel for SfB?

There are many resources on the Internet to implement split-tunneling. I will not enumerate them because you need to understand how your VPN is implemented and the Windows configurations in place (local firewall, group policies, QoS)

The main concept is to ensure that all the SfB traffic can bypass the VPN. You need to:

  • Ensure that the home office client can reach and route traffic to the Edge servers
  • Block media ports from reaching the internal front-end servers
  • And let the SfB client do the rest!

Almost there! this will get you a ‘half-split-tunnel’. Unless your VPN client is smart enough to allow the SfB client to reach any public IP address, the above solution allows them to reach the Edge servers. The traffic will bypass the VPN, and it will use the Edge servers:


To get to the complete split-tunnel solution, you actually need to configure the VPN client to route only the internal company addresses and let the remaining apps to reach the internet.
Advantages: your VPN will only have traffic for the internal applications, Skype for Business calls will go throw the fastest path.

This solution also place another challenge for companies with stricter security rules: ‘all companies PC traffic must go throw the VPN’. A good opportunity to rethink on newer security solutions 😉

And before you decide to optimize the SfB calls,  here’s my IT usual recommendations:

  • test first before rolling out to users: worst than some call quality issues is having no calls at all
  • Ensure that you have enough resources on the help-desk to support users troubleshooting their Home LAN and the router

You can now a happy ‘home office quarantine’ 🙂

Final notes:

  • This is not an issue/solution specific for SfB. You will face the same situation either if you are using Cisco on-premises, MS Teams, Webex, ….
  • Keep safe! Careless is as bad as Panic.


One Uppercase letter+one misconfiguration=4 hours quest

Just a normal a day with a SfB on-premises (yes, there are still some installed in the world) after migrating the RGS from another domain to this one and you decide to look around on the Monitoring services if everything is OK…


Just go to the Monitoring Reports and pick ‘Response Group Usage Report’:
And… come on !! really?

Let summarize my last 4 hours:
(1) Go to the the SSRS, <program files>\Microsoft SQL Server\LogFiles and you will find this ‘self explanatory’ error message (whaaaat?):
processing!ReportServer_0-41!f30!10/14/2019-14:54:52:: w WARN: Data source ‘CDRDB’: Report processing has been aborted.
processing!ReportServer_0-41!f30!10/14/2019-14:54:52:: e ERROR: Throwing … —> Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Query execution failed for dataset ‘MainDS’. —> System.Data.SqlClient.SqlException: Invalid column name ‘TCTIme’.

(2) Start a SQL Server profiler session for the LcsCDR database, repeat the ‘query’ and you will get the call to a storage procedure:

(3) Open the LcsCDR database and manually execute that stored procedure dbo.CdrRGSUsageTrend. Gotcha!

(4) edit (Modify) the store procedure and you will find one line where the temporary column ‘TCTime’ with the ‘I’ in uppercase (the only one on the entire SQL statement)


(1) The uppercase ‘I’ is a long-term MS bug.
If you go to the <program files>\Common Files\Skype for Business Server 2015\DBSetup and open the ‘CdrDb.sql’ you will find it defined like that.

(2) Check the LcsCDR properties, and you might find that the collation is not Case Insensitive (CI) which means that ‘i’ <> ‘I’


Modify the ‘I’ to lower case and save the store procedure.
This will solve the problem… until you update SfB databases, because the CdrDB.sql will replace the store procedures with the uppercase ‘I’… unless MS fix this on the next CU


Change the DB SQL collation to Case Insensitive (CI), like the default ‘Latin1_General_CP1_CI_AS’

You might now say that you really need an ‘I’ (or two) to troubleshoot this one 😉

Skype for Business security challenges – part 3

This is the third part of the topic: ‘enhancing Skype for Business environments’. In case you miss, check part 1 and part 2 to get the full picture.

On the previous topic post I focused on the ‘challenges’ on exposing user accounts and service from unauthorized access or DDOS. But now let’s see the scenario with authorized users using the collaboration features.

As mentioned before SfB is a tool that enables collaboration between people: any device, anytime and anywhere. And with federation you just extend all these capabilities with people across the world (specially with open federation).


But the ‘openness’ of the features can sometimes expose more information than people want to unintentionally share, or worse: intentionally!


Let’s use a reverse example: in a traditional meeting room you share information with a specific group of people. If it’s confidential you want to make sure that the information keeps private (closed room), that only the right participants are present, no open doors and all whiteboards, slides erased before leaving the meeting.

It should be the same on a SfB Meeting, right? But from my experience, who checks if the meeting URL is private and no available for guest access? Did you select ‘End Meeting’ when it finished? Did you remove all the shared content that was uploaded?

Another unintentional situation: How many of you sent a username and password using a chat session ? I did 🙂 (and regret it sometimes)

Federation is a great capability of SfB (I loved it, really!), but it can also go against you. Others can see your presence, ‘chat-noying’ and, on extreme cases, it can show more than you think.

Let’s use the picture of a federated test contact that I have on my SfB. This is what you can see from you contact when he changes the privacy level:


(1) external contacts

(2) Colleagues


Friends and family



































Work phone








Time zone



Home Phone (3)


Other Phone (3)


(1) default when adding federated contacts

(2) default for internal company contacts

(3) values set manually by the user on the SfB client

‘So what?’ some people ask
What if the customer finds out that you are an outsourcer, when you mentioned that you work on the main contractor? What if someone based on an email looks on the recipients and locates one the VIP? Why contact you for urgent matters if they can ‘escalate’?

The most extreme example is in fact a risk: Would you allow collaborators on a bank to share their desktop with outside participants and give remote control. The quickest corporate espionage is based on a rogue employee exposing sensitive data to competitors. SfB and other similar tools can be a good tool.

I can hear the readers thinking: this guy is paranoid !!
Answer: I’m not 😉  My out-of-the-box thinking always covers security aspects of the projects that I participate

SfB provides to SysAdmins several features to control and limit on how people collaborate, but in some situations it lacks of granularity. Let’s see some examples:

  • You can limit the modalities (can share desktop, application, remote control, use audio/video) on a per user basis. BUT… not per group of users
  • Remember the extreme case of undesired desktop/application sharing? You can block with policy. BUT… what if the end-user support is outsourced and you want your users to share the desktop with them ? or with any ‘company group’ domain partner?
  • You can in fact block your contact card and presence, by setting that only users on your contact list. BUT… it will do it for all external and internal contacts

Other examples of situations that you can think when administrate SfB:

  • Limit federated contacts to reach VIP’s or specific departments
  • Block showing internal presence status to all external users.
  • Prevent an internal user to share an application but allow external user to share with that user.
  • Scan file transfer for virus/malware

And then you get your Legal department with security concerns and compliance policies:

“We need to prevent disclosure of confidential data (ex: block or alert in case confidential project code names, share customer data that violates GDPR rules)”

This 3rd part was also the last one on enumerating the challenges. The next one(s) would be on how to mitigate them.

Skype for Business security challenges – part 2

This is second part of the topic: ‘enhancing Skype for Business environment’. In case you miss, check part 1 to get the full picture.

This one will be shorter and quick to read. It’s about authentication of your user accounts. I will write in form of questions and not go through descriptions the idea is to make you reflect on the topic.


And now how can I:

  • enable multi-factor authentication (ex: RSA keys, biometrics, passwordless, …) on SfB Clients?
  • limit specific mobile devices to connect to SfB (ex: iPhone 10.2.1 only, block Huawei devices)?
  • login in SfB with different credentials than my Domain?
  • prevent the user to save credentials locally on any device?
  • restrict a user can sign-in on a maximum of two different mobile devices?
  • prevent two or more users to sign-in from the same mobile device?
  • limit users to sign-in from specific locations/networks (ex: employees service tablet to only inside the sales store Wifi) ? and block from specific countries?

A little side topic: If by this time you have the idea that ‘Skype for Business’ and MS are unsecured,… well most of this challenges can be also observed on the main competitors 🙂

Take me to part 3 >>


Skype for Business security challenges – part 1

So…! You have roll-out Skype for Busines (SfB) on you company. Either it’s a simple or more complex (HA, PSTN connectivity,…) it contains 3 components: a Front-end on an Active Directory and an Edge and a Reverse Proxy. These last two are, hopefully, isolated by firewalls.

SfB Topology example
Skype for Business topology example

Then you configure several policies to allow remote user access (PC, mobiles clients, ), federation with other SfB domains and conferences.

SfB is about enabling collaboration between people: any device, anytime and anywhere. Once you enable all these abilities to your users, you also create new security challenges to your company.

I would prefer not to call them ‘security risks’ at this time, BUT… ignoring them after reading and knowing them, it would change subject title!

Since there is quite a significant amount of content to cover, I divided this topic into smaller post. Initially I will expose the challenges and after them, I will describe how to mitigate them.

Keep also in notice that, although:

  • I use an On-premises SfB as the example, you will see very similar challenges using Office 365, in either Skype for Business Online or Microsoft Teams;
  • the challenges might be related to external user connectivity, they can be replicated using just inside your corporate LAN.

Let’s start with the first topic:

Part 1 – Denial of Services and exploits


1.1. Denial of Services by account lockout


  1. knowing a SIP address of an user. How difficult is that? In 90% of the case it matches his email address.
  2. knowing the account login. What are the chances that the UPN is the same as the SIP and Email address? Knowing the domain and the samaccountname might be more tricky, but it’s possible.

As soon as someone knows a valid SIP address I can use a SfB client (windows of for mobile) and can now try to login with credentials 5 or more times.

sfb client login attempt
You can try to login on Skype for Business with different credentials

A successful ‘DDoS’ will lock that user AD account (for some minutes or forever depending on the AD policy).

Not big security issue? Well let’s think:

  1. a locked user is a person that cannot work until support unlock him
    (and gets locked again by an active DDoS).
    This can be harmful from but can a possible attempt to sabotage a competitor to reply on time to a last minute RFC. And what happens
  2. It will a significant issue if the affected user is a VIP or the CISO
  3. by default there is no direct way to prevent these, since even the remote access policies will only take effect after the user successfully logs-in
    remember the traditional message: ‘your account is not allowed to sign-in from external networks’?
  4. It can get worse: imagine that you have several UCC 3rd party applications that uses SIP ‘service’ accounts? What happens if they get locked-out?
    What if there are still some companies that uses the default ‘administrator’ account? It can also get locked out the same way as many other critical domain ‘service’ accounts

Getting more concerned now? Using SfB clients is not the only way to cause account lockouts…. (Whaaaaatt?)

A simple SfB installation exposes some Webservices that actually ask for user credentials. How? Less experient SfB administrators configure topology with ‘easy-to- guess’ short URLs.

Here an example of a If you click on the Sign In you will get the chance to enter a username and password (to change a PIN).


But there are more services: (1) the join a meeting URL allows you to try to authenticate, (2) the webscheduler (if installed) request the same, (3) if NTLM is enabled on the IIS (SfB webservices), any browse access attempt on known URLs will request authentication (ex: for the address book service:

1.2 Denial of Services or attacks on published external Web Services

As stated before, a very basic SfB deployment will expose the web services to the internet throw a basic reverse proxy role that forwards the traffic throw the DMZ.

There are at least some potential challenges:

  1. Simple DDoS against the IIS services until the servers CPU/memory is exhausted
  2. Direct exploit of SfB vulnerabilities that on worst case can run unwanted command on the Front-end servers
  3. ‘Espionage’: someone can try to guess and find some running meeting with ‘guest’ permissions, since the formats are usually<username>/<meetingID>


1.3. Service exposures

The default (at least for mobile clients) discovery service is Just by sniffing this URL you might get some more information. And if you provide a SIP address you will get even more because of the authentication.

In the above example you will get the front-end server FQDN that reply to the request. Might be harmless, but this server internal FQDN is an additional clue to try to use it for user UPN DDoS attacks and as you dig throw other responses you might get to know a little bit more about the internal topology.


A normal lyncdiscover and authentication process of a SfB mobile client

Ready to proceed to part 2?

Skype for Business 2015 Server CU8a or CU9?

UPDATE 13/March 21:48 – Microsoft is updating now the info. It’s March2019 update to address a security vulnerability (CVE-2019-0798).Specific details here:
Microsoft Lync Server/Skype for Business spoofing cross site scripting
Better start planning to rollout March/2019 CU9 then! (and Lync 2013 Server if you still use)

I downloaded all the cumulative updates as soon as they are released. I like to keep an history and peek on the changes. Today I need to get the January/2019 CU8, but my repository was unavailable. So I went to official CU download site, but I noticed that the date published was from yesterday, but pointing the the KB3061064 (?!). When I got back the access to my repository, I noticed that this file also has a different version:

Now I have two January/2019 CU with different versions (6.0.9319.537 and 6.0.9319.544) and different file sizes.
Time to dig and spot the differences: there are two msp files that changed:


Two noticeable changes:
– non-US dll language files: they were compiled in different dates, but still have the same version number
– The Tracing files (used by CLS/OcsLogger tracing tool). These one have some significant changes:


The files on both packages have the same size, but a ‘look inside’ reveals one particular difference: the ‘Lync.Client.Common.Consolidated.js’ is different.

A closer look reveals 5 lines of codes changes (one seems an additional protection)

So… since MS didn’t update any documentation so far:

  • Is this CU8 republished?
    If so, MS will now have customers with different files for the same CU
  • Is this a CU9 (or a Cumulative Security update -SU-)?
    It could be, since the date matches the usually releases cycles.

Running the cumulative update installer on a Front-end server with January2019 CU8, confirms the patches changes on the identified components:


The point the a KB4492303 and KB4492302 that don’t exist.

UPDATE 3/April/2019: Microsoft update the ‘Get updates’ section of KB3061064 section with an additional line:
4494279 Fix for Skype for Business 2015 and Lync Server 2013 spoofing vulnerability

That document mentions a ‘March 20’19 security update’:

The March 2019 security update contains a security fix for the spoofing vulnerability that is described in the following security advisory:

My official guess is now is that this is a SU9 and MS just decided to update this ‘silently’

But some IT engineers might believe that they are downloading and installing CU8 today.


The importance of knowing about certificates

Deploying and managing a Lync/Skype for Business environment demands you to know a lot more about technologies and protocols. Their communications are encryption which means that you need to deploy certificates and specially to maintain them over time. One wrong, forgotten or misplaced certificate can give you lot of headaches.

The following issue I faced recently, on a Lync 2013 environment is a good example of how a simple misplaced CA certificate can cause unexpected behaviours.

ISSUE and symptoms

After restarting the servers, the Lync services start reporting connection errors and denials due to certificate validation.

As a consequence, the users experience several issues:

  • Contacts presence status unknown
  • Address book unavailable
  • Unable to schedule, start or join meetings
  • External users unable to join/dial-in meetings

They are still able to sign-in, send IM’s and perform peer-to-peer calls (including video and desktop sharing) and PSTN inbound/outbound calls.

On the servers you will find from several others, eventID 32042 errors ‘Invalid incoming HTTPS certificate’ and eventID 30998 ‘Sending HTTP request failed’


The clue came from some informational events of services receiving invalid client certificates.EventID-61029

The last description line ‘Certificate error: 21482049809.’  translates to error code 0x800b0109, which is defined as CERT_E_UNTRUSTEDROOT. Lync server could not trust the subordinate CA that was installed on the local machine store ?!

Turns out that a new PKI has been deployed, and I found a subordinate CA incorrectly installed on the ‘Trusted Root Certificate Authorities’ of the servers.
(a subordinate CA can be easily identified because it’s not self-signed (‘Issue To’ name doesn’t match the ‘Issued By’)


Windows Server 2012 (and higher) implements checks for a higher level of trust for certificate authentication. By finding the invalid certificate, doesn’t provide any Trust Root CA list and therefore the services cannot to validate the certificates presented to them.


  1. Delete the subCA from the Trusted Root CA store of the server
  2. Reboot the server so it can load correctly the Trusted Root CA list.

Final notes

The issue will only start after a server reboot, so it can take quite some time to associate the cause/effect…. especially if you have just install a OS update !! (and blame it, uninstall, …)

Only after knowing exactly the issue, I manage to ‘google-fu’ a 4 years-old KB2795828 with a similar situation.
From that one I got a very usefull powershell script that help us to find any non self-signed CA on the Trusted Root CA store of the machine

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List *