LinkedIn for Outlook Social Connector Discontinued

Today I received the following notice from LinkedIn:

Hi Adam,

As an active user of LinkedIn for Microsoft Outlook Social Connector, we wanted to make sure we let you know that on March 9, we will no longer support LinkedIn for Microsoft Outlook Social Connector in Outlook 2003, 2007, and 2010. This means that LinkedIn information about your email contacts will not be visible in those Outlook versions.
Our team is working with Microsoft to build even more powerful tools to help you stay connected with your professional world. Until then you can get similar capabilities with the “LinkedIn for Outlook” app for Outlook 2013 from the Office Store.
Have questions? Visit our Help Center for more information..
The LinkedIn Team

That’s 6 days notice (although probably seven since I’m going to assume it’s US March 9) for discontinuing a product. I’ve had a brief look around and can’t find any other information around this, apart from a similar message on LinkedIn’s website.

LinkedIn appear to be pushing their new app called LinkedIn for Outlook, which is only supported by Outlook 2013 or Outlook Online. That doesn’t help those of us that can’t run Outlook 2013 for legacy reasons (plugins being the main culprit here!).

One note is worth pointing out on the decomissing of the product taken from LinkedIn’s website:

  • Any contact information that you have locally synced in Outlook will remain in Outlook, but it will no longer be updated.

Does this mean the plugin will continue without erroring, showing cached information? This can be a gotcha for people running it either at home, or in a corporate environment. I’ve reached out to LinkedIn on Twitter, so we’ll see if they respond:


Quick Update: Wes Miller has pointed out that this could be due to LinkedIn API changes, locking down most things.

Update 11th March 2015 – I’ve had LinkedIn help respond. Looks like it’s time to uninstall that addon before users are affected!

More LinkedIn Security Risks with LinkedIn Intro

LinkedIn have just announced a new way they’ve engineered LinkedIn user information into the native iOS mail reader. Have a look at the article here:!

In principal, this is an interesting idea – it’s what CMS (Customer Management Systems) have been doing for a long time, which is integrating a database of users/companies into your emails so at a glance you go from email address to user profile to company all in the one spot.

From a user perspective, this is quite neat. Seeing where someone works as part of the email, their job title, other connections saves a lot of time and brain energy when they’re thinking ‘who is this guy?’ – but from a security standpoint this is bad.

LinkedIn’s whole quote on the privacy aspect of this is:

Security and Privacy

We understand that operating an email proxy server carries great responsibility. We respect the fact that your email may contain very personal or sensitive information, and we will do everything we can to make sure that it is safe. Our principles and key security measures are detailed in our pledge of privacy.

That doesn’t say much, apart from ‘Come on.. trust me!’. Firstly, you’ve got to give LinkedIn your email password. Check my previous article as to why this is bad: – a pledge of privacy isn’t going to help you after a catastrophic event.

So, this method is actually worse again. All your emails traverse via LinkedIn’s proxy service, the email gets modified then delivered to your iOS device. Emails are insecure by nature as they traverse the internet in plain text format (excluding things like PGP and other encryption methods that most people/companies don’t use), but having them centrally filtered via a 3rd party means you’re giving them a truckload of information about yourself, who you deal with, your email habits and so on.

Would your company be happy with a 3rd party that you have no agreement with, receiving and forwarding on all your emails? Even if the emails aren’t stored, if LinkedIn was breached again (which they have been before, multiple times), other people could obtain anything from your contacts, to your password and email contents.

oAuth is supported too, which is a safer approach as it can be revoked – but you’re still giving the same level of access while the connection is approved.

Luckily for Exchange administrators, that doesn’t seem to be supported yet according to but for Google Apps people, you’ll need to look into how this can be blocked if you want to. If you’ve found out how, I’d be happy to add it to this post.

Update: There is a great writeup from Bishop Fox on several great reasons as to why this is a ‘bad idea’

LinkedIn Security/Information Risks with Exchange


Today after logging on to LinkedIn, I was greeted with a new screen I found rather worrying. It is commonplace for services like LinkedIn and Facebook to scan through your address book, and ask for credentials to do so (which is rather concerning already), but a new option has popped up:




This is asking for your work username and password. No 3rd party should be asking for corporate credentials like this, even more so a company that’s been hacked before . I tried this with a test account, entering the username and temporary password. It then asked for further information, which was the address for the Outlook webmail link and then connected and started showing contacts.

LinkedIn on this page says “We’ll import your address book to suggest connections and help you manage your contacts. And we won’t store your password or email anyone without your permission.” which is a start, but it’s just such a bad practise to get into, and encouraging people to do this is irresponsible of LinkedIn in my opinion. On top of this, it’s providing an easy mechanism for staff to mass extract their contacts outside the company, which many companies frown upon or even have strict policies in place.

You can’t stop people from entering in these details of course, but you can block the connection from working at the Exchange end, as long as you have at least Exchange 2010 SP1.

There are a few settings to check. First, under the Set-OrganizationConfig area, you’ll need to check that EwsApplicationAccessPolicy is set to ‘EnforceBlockList’. If it’s not, it’s going to be “EnforceAllowList” and you’re probably OK, as it’s using a whitelist for access to only what’s listed rather than a blacklist, to only block what’s listed.

Next, you need to add LinkedIn into the BlockList. This is done with the command “Set-OrganizationConfig -EwsBlockList LinkedInEWS

How do we know it’s the string “LinkedInEWS” to block? The IIS log files from Exchange will reveal this. After doing your test of trying LinkedIn (or any other Exchange Web Services connection) there will be a log entry. You can read this blog post from Microsoft for some great details but the abbreviated version is to look at what’s connecting fir POST /EWS/Exchange.asmx, and you’ll see the username you used to test, then the named connection. Here’s an example (with domain, username and IP changed):

2013-06-02 10:37:48 POST /EWS/Exchange.asmx – 443 domain\testusername LinkedInEWS+(ExchangeServicesClient/ 200 0 0 296

After applying, I retested and it seemed to still connect, but couldn’t find any contacts. My guess is that it’s authenticating OK, but then refusing to do much else. If anyone else would like to test this and post the results, I’d be very happy to find out update this.


Funnily enough, after writing this I found that LinkedIn had posted a very short version of the above:


Disabling Contact Import Process – Corporate IT Managers Instructions

How do I disable the ability for employees at my company to import contacts from their work email account?

Last Reviewed: 10/10/2012

Report Answer Inaccuracies

If you’re a Corporate IT manager, you can disable an employee’s ability to import contacts from their work email accounts.

Use Set-OrganizationConfig cmdlet to:

  • Set the value of config parameter EwsApplicationAccessPolicy to EnforceBlockList.
  • Add value LinkedInEWS to config parameter EwsBlockList.

For more information on using Set-OrganizationConfig cmdlet, please refer to Microsoft’s Managing Access for EWS Managed API Applications.


Further reading is available here:



Paul Cunningham has done a great writeup about this with some extra investigation and details, have a read:


Update 2:

This story had now been picked up by The Register, have a read here:


Update 3:

Seems to be getting picked up all over the place, so I’ll just keep updating this point as I find other articles. There’s some good discussion and opinions on this out there, such as why is Exchange configured to allow everything by default?