Home » Exchange Server » How (and Why) You Should Block LinkedIn Access to your Exchange Server Organization

How (and Why) You Should Block LinkedIn Access to your Exchange Server Organization

Earlier today I read a blog post by fellow Australian IT pro Adam Fowler. In the post Adam shares his observation that LinkedIn is now asking users for their corporate (ie Outlook) login credentials for adding new connections.


Adam also provides details for how to block LinkedIn’s servers from making the connection to your Exchange org should one of your users actually provide them the login details. The solution is fairly straightforward and worth considering, so please check it out and make up your own mind

I shared my own opinion of the matter earlier today on Twitter as well.

Though most people seemed to agree with me there was some debate about whether this feature of LinkedIn is as bad as I said it was.

On the one hand, it is a convenient way for LinkedIn users to add connections to their account. It is also something that is made technically possible by the way Exchange remote access works, if a company allows access with username/password only (eg without requiring two-factor).

On the other hand, LinkedIn has a history of serious security breaches. Also, it is one thing for a user to make a decision about whether to provide their personal email (eg Gmail) password when adding connections, it is a far more serious matter when the are providing corporate login credentials.

Consider that:

  • If LinkedIn was currently breached (without their knowledge) the credentials could be getting stolen each time they are submitted
  • Giving your corporate login credentials to a third party like this is a breach of many IT usage policies and can result in employee termination (not a good look when LinkedIn is supposed to help you with your career, not damage it)
  • It trains users that giving away their credentials to websites is okay (imagine a spoofed LinkedIn page and a phishing email campaign to trick users into visiting it)

Bottom line, I think this is a terrible thing and LinkedIn should stop it.

If you’re still not convinced, and in particular if you think LinkedIn is trustworthy and this is just harmless access to a user’s personal contacts, here is a screenshot of the “contacts” that LinkedIn found when I entered the login details for one of my test lab users.

LinkedIn suggested I connect with 107 people.


Meanwhile, the mailbox actually only has a small number of contacts in it.


It appears that LinkedIn accesses something other than just the contacts in the mailbox when a person provides them with corporate login credentials.

I ran some tests with two brand new mailboxes, and it seems that LinkedIn accesses both the Contacts and the Sent Items. For a test mailbox with no Contacts or Sent Items at all the LinkedIn page returned an error that it wasn’t able to recognise the webmail URL I had provided. But as soon as I sent just one email, the next attempt returned that email address in the list to invite to connect on LinkedIn.

Is this a bad thing? Absolutely. especially when LinkedIn has trouble telling the difference between a mailbox and a mailing list.

So what does LinkedIn store when you give them your login details?

In the first screenshot of the article you can see I had to provide the email address, username, password, and webmail URL.

On a second test run, I only had to provide username and password.


That email address hasn’t previously been associated with my LinkedIn account, and for a lot of organizations the username for remote access is the same as the email address. So now in a LinkedIn breach the attacker will get my corporate email address, username (if it is the same as the email), and webmail URL. (Update: it was suggested to me that the details might just be stored in a cookie on my computer. So I tried from a different computer, in a different browser, from a different internet connection, and LinkedIn still has the webmail URL and email address already there).

What do you think, should LinkedIn stop offering this feature? Or should it be up to Exchange administrators to block LinkedIn from accessing their servers?

Update 29/6: LinkedIn responded to my questions:


I tested again with a completely new account and found that:

  • The behaviour of scraping sent items has not changed
  • LinkedIn had retained all previous email addresses it collected from test accounts I used weeks ago, and was including them in the suggested contacts list yet again
  • The scraping is indiscriminate, even finding a conference room and an Exchange 2013 health mailbox


Comments on this article are now closed due to excessive spam.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Shane Bryan says:

    Disgusting. Looking at blocking it thanks to Adam’s instructions.

    If I was one of the tin foil hat brigade, I’d even say that calling it ‘work username’ instead of ‘domain username’ is not an attempt at ‘keeping it simple’ but hiding what they’re doing from people that wouldn’t know any better.

  2. Shane Bryan says:

    did some testing here.

    blocked access to my mailbox, LinkedIn wouldn’t import my contacts.

    allowed access to a test account, LinkedIn would import them.

    blocked access to a colleagues mailbox, LinkedIn wouldn’t import his contacts, but it must have remembered our OWA address as it asked me, but not my colleague!!

    just goes to show you that if they can’t disclose what information they’re gathering, they can’t be trusted.

    it’s now been blocked at the org level. thanks Paul and Adam.

    • I did some more testing tonight as well with a brand new mailbox and brand new LinkedIn account.

      LinkedIn fails to connect (but gives a misleading error that the URL was wrong) if there’s no “contacts” found. But then as soon as I send one email from the test mailbox, LinkedIn is then able to connect and suggest the recipient of that sent mail as a connection.

      So clearly it is grabbing the Contacts + Sent Items and merging the two into the suggested connections list.

      Using Sent Items is ridiculous in my opinion. This whole thing is poorly thought out by LinkedIn.

      • Shane Bryan says:

        Ahh I was wondering about if it was scraping sent items or outlooks ‘suggested contacts’. Interesting.

        And I agree, using Sent Items is ridiculous. Glad thanks to you guys that it was easy to block.

        Going through our IIS logs, there was an instance of someone doing it – so glad I read this.

  3. S.E. says:

    I agree big time.
    The same goes for Facebook. I’m not even registered there but when I tried it’s (almost) first thing to ask were my credentials to my mailbox (for the purpose of acquiring contacts). That’s something I would not approve.

  4. Shane Bryan says:

    yah i let Facebook scrape my Gmail contacts but there’s no chance in hell i’d let it go through my Outlook or OWA.

  5. Robert Coggins says:

    My concern is what other services are starting to do this. Correct me if I am wrong but these steps will only block linkedin right? Looks like about the only way to fully restrict this is by using multi-factor authentication. Or, do you have another idea that might block this across the board?

    • I agree, this is a concern. Blocking EWS entirely, using the EWS whitelist, implementing two-factor… there’s options I guess but not all of them will suit everyone.

      User education as well.

      • Shane Bryan says:

        Sites requesting this sort of info should be clearer to the user that ‘No, we’re just not scraping your personal Outlook contacts, if you enter your business network password, we’re going to scrape your GAL as well while we’re in there. Maybe see what your IT Department thinks of that first hmmm?’

        But that will never happen.

  6. Leo says:

    We IT pro are way to smarter to get caught up with this sort of dump favour from Linkedin.

    But, you will be surprised there are people out there will actually fall into this trap easily!

    Sad but true.

  7. Alex says:

    Guys is this possible in Exchange 2007? Set-OrganizationConfig does not allow me to change ews app access policy to “EnforceBlockList”…it’s almost like it’s not even an option. Is this only possible for 2010/2013? Sorry if this is a stupid question.

  8. Cuenca says:

    Can you help to clarify the concept on the default setting on the Organizationconfig (EXC2010 SP3)
    under the get- OrganizationConfig
    (the EwsApplicationAccessPolicy is blank , This mind the ewsallowlist is set?)

    EwsAllowOutlook :
    EwsAllowMacOutlook :
    EwsAllowEntourage :
    EwsApplicationAccessPolicy :
    EwsAllowList :

  9. Mark Nash says:


    Is this a problem with hosted exchange ? I have many users in my company who are both social website junkies and quite challenged in the common sense department. This is the kind of thing I fully expect many of them to do.



  10. Dan says:

    Scary, and I have some users who are LinkedIn junkies that wouldn’t think twice about entering their network credentials.

  11. Mike says:

    As an IT professional in a post-secondary institution, it’s part of our mandate to protect the privacy of students – therefore I’d say that LinkedIn needs to be more transparent about it, or just stop completely.

  12. Steven says:

    We are having trouble blocking linkedin from our exchange2010 environment. Can someone put some nice easy steps together?

    • Jason M says:

      Any chance this doesn’t work on Exchange 2010 SP2? I have two environments that I have set the Org.Config to EnforceBlockList and added LinkedInEWS to the EWSBlocklist.. Rebooted one environment and am still able to pull new contacts into a LinkedIn account..

  13. David says:

    Paul – we run an Exchange 2007 shop. I’m going into IIS/EWS & OWA and blocking the 2 LinkedIn sties i’ve identified so far.

    While i plan on testing, do you see any issue or additional concerns?


      • David says:

        Using IIS Manager
        Select web sites – EWS
        Select properties
        Select Directory Security tab
        Select edit – IP Address and domain name resolution
        select add – group of computers
        enter network ID:
        subnet mask

        confirm it lists “denied” for range of computers. This is the entire C-class for LinkedIn. You could also just enter the 2 servers they are currently using, but as Paul stated, it works until they change servers.

        Additionally, i would also update the web site for OWA. They have your users’ credentials – block OWA as a precaution.

        Finally, by scraping the IIS logs, identify the users and have them change their passwords.

  14. Edwin says:

    It seems that there is some discussion about the block, for some it works for others it doesnt.
    Can you confirm this Paul?

  15. Adam Fowler says:

    I’m having similar results and so are others in regards to blocking LinkedIn:

    There’s more discussion here so I’ll direct people to this, but personally I tried even changing from the black list to the white list, and I still didn’t get EWS blocking, even though all details online say this should be it.

    For someone that’s done this successfully, what do you see in the Exchange IIS logs, and what happens when you try to enter your Exchange details on LinkedIn, does it just deny?

  16. Arvin says:

    I’d tried the block and Exchange is still allowing the access!!

    Does anyone have a solution to this?

  17. Aron says:

    Could anyone refer a link to a (plain text) network capture or transcript of the connection details?
    This would be in the interest of determining other parameters of the connection, such as user-agent used etc. The results could benefit additional security measures such as reverse proxy or firewalls to block the connection.

  18. Dominic says:

    You could use Url Rewrite if you have Windows 2008 and later

    Download Url Rewrite from http://www.microsoft.com/en-us/download/details.aspx?id=7435

    Install it on the Client Access Servers.

    Open Up IIS, drill down to the EWS virtual directory

    Open up Url Rewrite

    Click on Add Rules and select Request Blocking under Inbound Rules.

    Under Block Access Based On Select “User -agent Header”

    Under Block request that Select “Matches the Pattern”

    Under Pattern (User-agent Header) enter the following “LinkedInEWS*”

    Under Using Select “Wildcards”

    Under How to Block Select “Send an HTTP 403 (Forbidden) Response”

    Click on Ok

    Restart IIS and test.

    • Adam Fowler says:

      If we were talking about a vulnerability of Windows 7 just discovered, that had been around since a patch last year, would you say the same thing?

      • Queeg says:

        Hi Adam, Thanks for taking the time to reply.

        I think you have have misunderstood my question though, or maybe it came across as aggressive. Apologies for this.

        This is a known feature which is well documented and relatively easy to restrict.
        My question really is, “Has something new come to light on this feature, that I should be concerned about?”.

        I would say that this feature is innocuous compared to the likes of the LinkedIn Social Connector.

  19. Carl says:

    I’ve added the LinkedInEWS to the blocklist and that’s notworked either. As a few others seem to have come across too.

    I’m on Exchange 2010 SP1, so will have to look to adding the IP in IIS.

Comments are closed.