It is common for organizations to hire experts or consultants to work along with their employees on certain projects of high importance. For these contract employees, the system admin creates user accounts in AD and grants required privileges to access organization resources. Of course, they are allowed to collaborate with peers using Sharepoint Team Site. As per the golden rule of security model, SharePoint admin grants permissions to these people through SharePoint groups. In other words, no direct permissions are granted to them for any SharePoint objects at any level of hierarchy.

Let us assume the signed project is complete. System admin either deletes or disables these temporary user accounts from Active Directory. Those contract employees are no longer able to access to the organization resource. However, it is important to note that SharePoint still retains the permissions assigned for them, no matter whether their account is disabled or deleted in Active Directory.

Deleting user accounts create Orphaned Users in SharePoint

Orphaned Users in SharePoint occur when a SharePoint user account no longer exists in Active Directory. This occurs when a user account is deleted from Active Directory as the end-user left the organization or similar situation. Deleting user accounts will not affect the actual content in SharePoint site. However, it could lead to some other critical issues in different stages of SharePoint usage.

The user profile in SharePoint is mere copy of what was set in Active Directory. Once the account is deleted in Active Directory, the link between SharePoint User Profile and AD user account is broken. However, SharePoint is managed to show up the deleted user’s contribution in SharePoint with the help of the abandoned user profile. In other words, you can still see the deleted user account name in the version history of a document without any glitches. SharePoint is promisingly helping us securing content from unwanted access while retaining the document history as is.

On other side of the coin, it causes issues when you take backups and perform restores in SharePoint. More specifically, it makes SharePoint content migration a bit complicated as there is no way to carry forward deleted user account information in target SharePoint. At the time of critical operations, SharePoint admin is supposed to deal with the deleted accounts. To mitigate common risks at content migration, it is better to disable user accounts than deleting it from Active Directory. It also helps better auditing both in Windows Network and SharePoint repository.

Disabling User Accounts in Active Directory

By disabling a user account, the security concern is fulfilled, but creates a security hole if an admin does not revoke the assigned permissions from SharePoint for the disabled user. Let me explain a situation that is more common in any organization. What-if the organization hires the same consultant to work for another project as his earlier contribution was very much appreciated in the organization.

Thus, the system admin would like to enable his earlier account in Active Directory (Assuming that it was disabled before) and grant required privileges pertinent to the currently signed up project as before. Now, you will notice that the consultant still has access to the content that s/he previously worked with. In a nutshell, we are taking enough care on assigning permissions to people who are going to work on a particular project, but paying very less attention when s/he got completed the project.

To mitigate any security issues, the admin should verify the following things before he enables an existing user account into live.

• Collect history about the user to whom you are going to enable access to the organization resource. This should include about the projects he was involved before.
• Getting a complete inventory reports that should clearly indicate on what content the user was working with. This includes SharePoint site collections, Windows file shares and OneDrive for Business, whatever it is pertinent.
• Getting a complete inventory reports against SharePoint site collections indicating what SharePoint objects (be it Sub-site, Lists or documents) are still accessible if the account is enabled.
• Consult with SharePoint site owner regarding the situation and take corrective measures as below.
  1. Remove permissions against already granted resources
  2. Replace disabled user with equivalent counterpart (say, Replaced with site owner)
  3. If SharePoint site is no longer active, close the site so that no one can access any content from it.

Conclusion

I am sure that the above listed actions are really, really time consuming if any one started doing it manually or writing PowerShell scripts for it. The admin should have necessary tools in hand before taking any actions. Insights alone is not always enough nowadays. The tools should help admin mitigate security risks against data access. It is expected that the tools should be able to do the actions against the report data, so that the admin won’t need to do the same using native tools of every platform.