Getting SharePoint Back Under Control with Active Directory Groups

SharePoint is one of the fastest-growing applications in the enterprise.  It has many uses and some of those uses have given rise to its popularity such as a collaborative tool for small groups of people, being used as a document repository, and a centralized communications portal for an organization.

The problem with SharePoint however is that it does not provide elegant management tools and the IT-centric education that many receive do not prepare the IT worker to understand the business-centric needs that would be leveraged in a solution like SharePoint. And on the business side, those educated in that discipline will likely not understand or appreciate the technologies available to them to properly implement such a solution that matches their need.

As was the case with early adoption of directory services, and later, messaging platforms, the adoption of solutions such as SharePoint have been in large part, business unit strategies or project specific purpose in nature.  Often referred to as “shadow IT” approaches to application deployment bring rise to the failure to leverage the larger purpose of the business overall and certainly does not leverage the infrastructure that might already be in place. Each SharePoint instance then becomes an independent technology that fails to leverage those existing resources.  Even when there is finally a corporate directive to leverage SharePoint, it has typically grown out of needs of only a few departments or projects.

Some examples:

• A project team finds a need to share documentation related to their common project. They implement a team room to act as a repository for documentation related to the project.  There is no integration or reference to Active Directory users that are members of the project so the SharePoint administrator creates a SharePoint group and the project manager becomes the owner of the group. This is an administrative nightmare and the professional expertise of the project manager is wasted with administrative tasks related to managing the membership.
• The company decides to replace their document repository with SharePoint. Documents are categorized as Public, Department-Specific, Confidential, and Board. Board-level documents are available only to the Board of Directors with the site membership managed locally. The secretary of a board member then goes on vacation and an assistant is brought in as a replacement and their account is added to the board membership. When the secretary returns, the assistant returns to their normal duties but no one remembers to remove the account from the board membership.
• The company attempts to use SharePoint as the main source of contact information for their staff. Active Directory is used as the source of identity. Additional instances are deployed by project management staff with project teams administered manually by each project leader. There may be an additional instance deployed by the administrative staff for document storage with access controlled by the respective document owners.

As you can imagine, there is no coordination. These sites become fragmented and memberships can quickly become out of date and lack proper controls and attestation.  Even if a team member updates a user attribute in their team portal, that information does not propagate to the central repository nor does it end up in HR who is the department that might need the updates most.

So, what should a company do to reign in SharePoint and get the most out of what the platform has to offer?

First, make sure your Active Directory is clean. Most Active Directory deployments are cluttered with out of date and inaccurate details about your staff. There may be disabled accounts that remain in place that can be deleted. Perhaps there are attributes that have been hijacked for purposes no longer necessary or will collide with other departmental needs. A concise and clear attribute definition strategy is necessary to make sense of your users and ensure a consistent use of attributes within Active Directory.  You certainly do not want that “dirty” data to be reflected in your SharePoint when exposed.  Clean data is also important when leveraging intelligent assignment based on ABAC (Attribute Based Access Control).

Next, be sure to make and document your policy decisions. Not only is it necessary to document the policies for the accounts in-place, it will be a guide for future provisioning as well.

Finally, reign in your multiple deployments of SharePoint into a common platform and enforce an Active Directory based deployment with groups managed from Active Directory.

Upcoming SharePoint blogs –

• Use GroupID to leverage ABAC concepts for intelligent SharePoint memberships
• When Users need to control their own SharePoint portals, delegate AD group membership management