Do Disabled and Deleted Accounts in SharePoint Create a Security Risk?

Danny Murphy by   08.27.2018   Auditing

Many organizations, at some point in time, require contractors or third-parties to work alongside their employees on particular tasks. To ensure that they have access to everything within the system that they require to do their job, they are awarded the required privileges through a user account in Active Directory. They can then collaborate with employees in the organization through SharePoint Team Site. Permissions are granted to these users through SharePoint groups, not directly.

Once the job is complete, the normal thing to do would be to delete or disable the temporary AD accounts, thus preventing the user from being able to access the network. What many organizations fail to realize, or simply forget about, is that they will still have the permissions applied to them via SharePoint, regardless of what happens to the Active Directory account. When a SharePoint User Account no longer exists in Active Directory, it is known as an Orphaned User.

Orphaned Users

As previously mentioned, when a user leaves the organization and their Active Directory account is deleted, the SharePoint User Account it is linked to becomes ‘orphaned’. In this situation, deleting the Active Directory account doesn’t actually affect the content in the SharePoint site, but it could lead to other SharePoint usage related issues.

In some ways, SharePoint is actually quite clever in the way that it deals with orphaned users. Despite the link between Active Directory and SharePoint no longer existing, the platform will still show the deleted user’s account name in the version history of a particular document they were associated with.

Alternatively, having lots of orphaned accounts in SharePoint can lead to a number of IT operations-related issues, such as when taking backups for a system restore, or migrating over content (as you cannot actually carry over orphaned users to the target SharePoint environment). The recommended way to deal with a situation where a user with privileged Active Directory access leaves is to simply disable their account instead of deleting it. This will make it much easier to migrate SharePoint content.

Disable Active Directory User Accounts

Even though the recommended way to handle these accounts is to disable rather than delete them, you still need to pay close attention to the permissions associated with these accounts in order to maintain the security of your SharePoint and Active Directory environment. It’s very common for temporary workers or contractors to be carefully assigned the levels of permissions they require during their tenure, and for these permissions to remain dormant and unrevoked in a disabled Active Directory account. If that worker was ever contracted for another position with the company, and their Active Directory account re-enabled, they would have access to all the content that they previously had access to (much of which they will presumably not require access to).

If you find yourself in this situation, there are a number of things you can do to ensure that your systems remain secure once a disabled Active Directory account is re-enabled:

  • Determine which tasks the user worked on in their previous role within the organization and what they had access to
  • Generate a report of the particular content that the user was working on
  • Determine what the user will likely need access to in the new role
  • Revoke permissions from the resources that you have found the user will not need any more access to

Despite this process being a tedious and time-consuming task, it is the only way you can be sure that you maintain a policy of least privilege.

Audit SharePoint Server Changes

As I just mentioned, reporting on the permissions of disabled accounts in SharePoint is a time-consuming and (quite frankly) boring task. The sheer nature of trawling through logs or creating PowerShell scripts puts many IT professionals off and often leads to it not being done at all.

We recommend deploying a third-party SharePoint auditing solution (such as LepideAuditor) that allows you to automate the auditing and reporting on changes to SharePoint configurations and permissions. Lepide’s SharePoint audit solution shows you who has which permissions granted to a SharePoint site, library and list, as well as whenever permissions change, to ensure that you are able to maintain that policy of least privilege.

Start your free trial of Lepide’s SharePoint audit solution today to help you maintain a secure SharePoint environment.

Do you like this blog post?