What you need to know about SharePoint & external access

In today’s environment, users expect to be able to work from anywhere. On a plane, on a train, waiting for a table at a restaurant, at their kids’ soccer games, and in the office as per tradition, users need—and demand—to have the access they need to get work done from wherever they are.

But collaborating using SharePoint when your users are spread around different locations on different networks is not for the faint of heart. SharePoint was designed in an era—the late 90s—where users worked in an office and then went home. Mobile devices were few and far between. VPNs existed but generally were only used by senior management. Users had a desktop at work and that’s where their work got done. Times have changed, of course, but SharePoint, at least until very recently, has not caught up.

SharePoint roadblocks and restrictions

Getting SharePoint working for partners can be a real exercise in frustration. For example, with SharePoint 2007 and SharePoint 2010, you needed to give access to partners and other external users through domain accounts on the Microsoft security domain where your SharePoint servers resided—or for domains those servers trusted through Active Directory forests and trusts. Security people tore their collective hairs out about this; given all of the hype surrounding least privilege access and knowing your accountholders, IT folks were howling about giving external people domain accounts directly into systems that are running within the trusted network. But for these releases, there was no other option (well, except for creating one shared account per vendor, which has its own pitfalls and disadvantages). SharePoint 2013 makes this situation a lot better by allowing outside accounts very granularly to specific documents and objects within specific libraries. Even ordinary end users can invite external users to view documents and then simply delete their invitations once business is done. However, even this has a severe limitation — namely, the external users must have a Microsoft or Office 365 account. This means that for every external user you share who isn’t on Office 365, they are logging in with their consumer e-mail address and credentials — so if your external party leaves their organization, they can still access any information you’ve shared with them!

Other issues IT folks run into when trying to allow users to access their SharePoint resources outside of the network local to theSharePoint deployment:

  • Naming convention and DNS issues 

Generally, external users will need to access your SharePoint site through a different DNS name than your internal users, especially if you use what is commonly known as split brain DNS. Your users can generally be trained for this for occasional access, so this is not really a problem for ad hoc usage once in a while, but when you start trying to get external users permanently accessing SharePoint from the outside, you run into issues where. For example, links you send internally don’t work outside; integration with Outlook like subscribing to tasks and calendars doesn’t work seamlessly if you have a user traveling to the corporate campus network often, but that goes on trips outside the office—after all, which name is Outlook connecting to? And more. To avoid this issue, hijinks with your firewalls and proxy servers are required and those changes might affect other applications.

  • Controlling the identity lifecycle

While this is true of any contractor or temporary employee that works for your company, many organizations set up special accounts only for SharePoint. How do you manage the time when these accounts represent contractors and or vendors that are no longer working for you? How do you manage what access these external user accounts have, how long they have it, and when their needs change? What sort of processes do you need to establish for your internal users to request that a partner, vendor, or contractor have access to resources and applications located on your SharePoint deployment?

  • Securing external access to SharePoint

Now that Forefront Unified Access Gateway, Microsoft’s preferred product to put in front of SharePoint, has gone away, the security picture for SharePoint has gotten a lot murkier. While many organizations may have existing licenses for UAG, or are using the sister product Internet Security and Acceleration Server (ISA) to “publish” their SharePoint resources out to the big, bad, wild Internet, other organizations looking to start with SharePoint or begin using an on premises SharePoint deployment need some way to secure access and protect these vulnerable systems from the torrid unknown. This entails expense, configuration difficulty, more things to go wrong, and in general simply complicates the experience. Otherwise, your users need to use ordinary or SSL based VPNs to access your network. And many phones and tablet devices are not supported by corporate VPN devices—thus rendering your “work from anywhere” strategy much weaker.

In contrast, Huddle excels at enabling seamless workflow for users, partners, vendors, contractors, and other interested parties—wherever they happen to be, without barriers. Huddle integrates with SharePoint to give you and your organization the kind ofexternal collaboration you need. Learn more in Nick Fisher’s blog post on Huddle as a secure collaboration platform, tomorrow.

See how Huddle works with SharePoint to enable external collaboration. 

Download the white paper

James Matthews

Get Started