How to clean up user permissions in SharePoint

Transcript

Runtime 5:58. Created by the Cognillo product team. Narrated with an AI-generated voice.

0:00 Thanks for joining. Before we begin, just a disclaimer: this video was written by the Cognillo team, and this voice-over was AI-generated. In this video, we'll clean up user permissions in SharePoint. We'll remove orphaned accounts, take away direct access people shouldn't have, close off content that's open to everyone, and review sharing links.

0:21 Over time, SharePoint permissions drift. People leave, files get shared directly, and whole sites end up open to everyone. On Tasks, pick the sites to clean up, here the Architecture knowledge base and Boston Team, then open Permissions. Every task we need is in this one area.

0:39 Start with Clean up orphaned users. These are accounts that were deleted or disabled in Entra ID, but are still sitting in SharePoint permissions and groups. Click Next. The summary shows the job finds them, and only removes an account after you review and confirm.

0:55 Run now. Every account on both sites is checked against your directory.

1:00 Two accounts no longer exist. Bindu Patel, a user who left the company, and a domain group that was deleted. Neither one is valid. Tick Bindu Patel. The panel shows her status is Not Active. Click Remove selected users.

1:16 The confirmation says exactly what happens: the account is removed from the site's user list, along with any permissions it still holds. Remove one user, and it's done. The deleted group can go the same way, once its owner has confirmed.

1:30 Next, review who has access. Clear Boston Team, so only the Architecture site is selected, click Change, and choose Permissions report. It lists every user and group, their permission level, and how it was granted, on the site and on every list, folder and file. Nothing changes until you act on it.

1:49 Run now. All ten thousand items on the site are checked in under two minutes, and nothing is changed while it runs.

1:57 Switch the view to Direct Grants By User. These are people given access directly, instead of through a SharePoint group, and that's where access tends to creep in. Four users.

2:09 Sandra Brooks has Edit on Handover Documents. Isai has Edit on the capital budget tracker. David Cooper has Contribute on the whole site, and Barbara Connell has Contribute on Handover Documents. David still needs his access, so tick the other three.

2:24 The panel shows three accounts. Click Remove three direct permissions. The review lists every change before anything happens. Each one is local to that list or file, and nothing else changes. Every change is logged, so it can be undone from History. Remove three accounts.

2:42 Applied. Three permissions removed in four seconds. The report updates, and only David's direct grant is left.

2:51 Now remove broad access. In I want to, search for open to everyone, and pick Sites and content open to everyone. Click Next. This job finds every site, list, folder and file that Everyone, Everyone except external users, or an Anyone link can reach.

3:11 Run it on the same site. Every list, folder and file is checked, including ones with their own unique permissions.

3:19 Thirty-seven locations are open. At the site level, Everyone except external users has Read through the site's Visitors group, so every list that inherits from the site is open too. Those grey rows simply follow their parent. And Salvos Project Research gives the same audience Edit, directly. Tick the site row, and Salvos.

3:39 The panel shows where the access comes from. Tick the Visitors group membership as well as the direct grant on Salvos, and the button updates to Remove two permissions.

3:49 The review warns that removing the group membership takes this access away everywhere the Visitors group is used, not only here. That's exactly what we want. Confirm, and both changes are applied.

4:02 Refresh the report to check. It scans the whole site again, and this time, no records found. Two changes closed thirty-seven open locations, and nothing on this site is open to everyone anymore.

4:16 Last, sharing links. A link can give people access without adding them to any group or permission, so links are easy to miss. In I want to, search for sharing links, pick Sharing links report, click Next, and run it. It finds every link on the site, who created it, who it works for, and when it expires.

4:35 Expand the site. Files in Abasca and Project Delivery have links. Most of them work for anyone in your organization, one is for specific people, and the link on the capital budget tracker lets the whole organization edit it. Link Scope shows who each link works for, and Granted By shows who created it, so you know who to ask before you change anything.

4:56 The Matrix view groups the eleven links by file. Tick a link, and the panel offers four ways to fix it: remove the link, change when it expires, narrow who it works for, or reset the item to inherited permissions. Clear the selection, and quick sets pick organization links, links that expire soon, or links with no expiry. We won't change any links here. Our sharing links video covers removing, narrowing and expiring them step by step. You'll find it in the description.

5:25 Finally, open History. Every task you ran is kept here. Filter to Changes, and each permission change is listed. Select one to see exactly what was removed, who ran it, and when. If something was removed by mistake, undo a single change, or all of them at once.

5:43 Thanks for watching. To keep permissions clean, run these tasks regularly, or schedule them. And if you have any questions, email hello at cognillo dot com.