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 http://www.pcworld.com/article/257045/6_5m_linkedin_passwords_posted_online_after_apparent_hack.html . 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 http://blogs.technet.com/b/matabra/archive/2012/08/23/block-mobile-apps-that-use-exchange-web-services.aspx 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 184.108.40.206 POST /EWS/Exchange.asmx – 443 domain\testusername 192.168.1.1 LinkedInEWS+(ExchangeServicesClient/0.0.0.0) 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?
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: http://exchangeserverpro.com/blocking-linkedin-access-to-your-exchange-server-organization/
This story had now been picked up by The Register, have a read here: http://www.theregister.co.uk/2013/06/06/linkedin_snarfing_contacts_from_exchange/
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?