How to get User Permissions audit Logs at web application level in SharePoint Server 2019/SharePoint On Premise 2019?

Question

Hi Team,

We have received a requirement from the SOC/GSO (Security) team to provide SharePoint User Permissions Audit Logs.

Initially, we fulfilled the request by enabling the SharePoint Reporting Feature at the Site Collection level and generated the required audit reports in CSV format by extracting audit logs from an individual Site Collection. However, the requirement has now changed significantly.

The SOC/GSO team is requesting us to:

• Generate audit logs for the entire SharePoint Web Application (approximately 490 Site Collections).
• Produce the output in Log (.log/.txt) format instead of CSV.
• Capture and record permission-related activities in real time, specifically identifying: Who granted access (User X) To whom the access was granted (User Y) What permission was granted On which document/site/folder Date and time of the action

For example:

User X granted access to User Y for https://sharepoint/sites/meetings/Documents/File.aspx on DD/MM/YYYY HH:MM:SS.

Their expectation is to monitor these permission activities in real time (every second), similar to how Windows Event Logs capture security events.

Our initial approach was to develop a SharePoint Farm Solution with a Timer Job that periodically retrieves audit logs from all Site Collections and converts them into the required log format. However, after further analysis, we identified the following challenges:

• A Timer Job is not designed to execute every second.
• The Web Application contains approximately 490 Site Collections, making continuous polling highly resource-intensive.
• Executing audit retrieval every second across all Site Collections would introduce significant performance overhead and is not a scalable or recommended approach in SharePoint.
• SharePoint's built-in auditing infrastructure is designed for periodic reporting rather than true real-time event streaming.

Because of these limitations, the SOC/GSO team has proposed an alternative requirement.

If real-time permission activity logging cannot be implemented efficiently or the implementation is too complex, they would like to disable permission sharing capabilities across the SharePoint environment.

The revised requirement is as follows:

• Only Farm Administrators and Site Collection Administrators should be able to:

1. Share documents, folders, or sites.
2. Grant permissions to other users.
3. Access Manage Permissions.
4. Use the Share or Share With functionality.

• Even if a user has the Full Control permission level, they should not be able to:

1. Share content.
2. Manage permissions.
3. Invite users.
4. View or access the User Permissions section.

• This restriction should apply across both Classic and Modern SharePoint pages.

Initially, we considered injecting JavaScript through the Script Editor Web Part or customizing the Master Page to hide the Share and Manage Permissions options. However, this approach is only applicable to Classic SharePoint pages and is not compatible with Modern pages. Furthermore, since we are currently in the process of migrating from SharePoint Server 2019 to SharePoint Subscription Edition (SE), any solution we implement should be fully compatible with both environments and should remain maintainable after migration.

At this stage, we are evaluating the most appropriate enterprise-grade solution that satisfies both the current SharePoint 2019 environment and the future SharePoint Subscription Edition deployment.

We would greatly appreciate your guidance on the following points:

1. Is there any recommended or supported approach to capture real-time permission grant events across an entire SharePoint Web Application, including identifying both the grantor and the recipient?
2. If true real-time monitoring is not technically feasible, what would be the most suitable enterprise approach to satisfy the audit requirement?
3. For disabling sharing functionality, what is the recommended server-side implementation that works consistently across both Classic and Modern pages, while remaining compatible with SharePoint Subscription Edition?
4. Are there any SharePoint extensibility options, event receivers, permission providers, custom authorization logic, or supported APIs that would be more appropriate than UI customization or Timer Jobs for this scenario?

Any recommendations or architectural guidance would be highly appreciated, as this requirement is critical from a security and compliance perspective.

Thank You.

Answer 1

Hi @Sai Charan GS

Based on the requirement, there are two separate areas to consider: permission activity auditing and restriction of permission/sharing capabilities.

1. Real-time permission grant event logging across the whole Web Application

SharePoint Server auditing can capture security-related activities such as changes to user accounts and permissions through audit log reports at the site collection level. Microsoft documentation describes audit log reports as a way to view audit data for a site collection, including who performed actions on sites, lists, libraries, list items, and files. The available audit events include changes to user accounts and permissions and security settings reports.

However, the documented native SharePoint Server audit mechanism is report-based, not a real-time event streaming mechanism. The audit reports are generated from audit data and saved as workbooks/reports, and the Microsoft documentation also indicates that only site collection owners can run audit log reports, with the Reporting feature required at the site collection level.

Because of that, I would not recommend designing a farm timer job to poll approximately 490 site collections every second. A timer job can be used for scheduled administrative processing, but using it as a near-real-time security event collector across hundreds of site collections would likely introduce unnecessary load and would not align well with the way SharePoint Server auditing is documented.

For comparison, Microsoft 365/Purview audit logging for SharePoint Online has a dedicated sharing audit schema that can identify the acting user, operation, date, and the target user or group through fields such as TargetUserOrGroupName and TargetUserOrGroupType. That documentation is for SharePoint Online and OneDrive audit logging, so it should not be treated as a direct SharePoint Server 2019 on-premises feature.

Recommendation: If SOC/GSO requires centralized near-real-time monitoring, the more suitable enterprise architecture is to integrate SharePoint audit outputs with a SIEM or centralized log management process on a scheduled basis, rather than attempting per-second polling from SharePoint itself. The log output can be transformed into .log or .txt format after extraction, but the source audit mechanism should remain a scheduled/periodic audit process rather than a real-time event stream.

2. Suitable enterprise approach if true real-time monitoring is not feasible

A practical approach would be:

1. Enable and standardize auditing for permission/security-related events across all site collections.
2. Periodically extract the relevant audit data from each site collection.
3. Normalize the data into the required SOC/GSO format, for example:

[DD/MM/YYYY HH:MM:SS] User X granted access to User Y on https://sharepoint/sites/meetings/Documents/File.aspx with permission level: Read
`

1. Store or forward the normalized output to the organization’s central log/SIEM platform.
2. Document the monitoring interval and the limitations clearly, especially that SharePoint Server native auditing is not a per-second Windows Event Log-style stream.

This is more supportable and maintainable than continuous polling every second.

3. Disabling sharing and permission management capabilities

For the revised requirement, I would avoid JavaScript injection, Script Editor Web Part customization, or master page customization. Those approaches only hide UI elements, mainly affect classic pages, and do not provide a reliable security boundary. They also may not behave consistently across modern pages or after migration to SharePoint Subscription Edition.

The recommended direction is server-side permission enforcement.

SharePoint Server provides permission policy levels at the Web Application level, which give administrators a centralized way to configure permissions that apply to users or groups across all site collections in a web application. Microsoft documentation states that permission policy levels can grant or deny list, site, or personal permissions, and that this avoids managing the same permissions separately across multiple site collections.

For your scenario, the most appropriate server-side options are:

• Create or use controlled AD/security groups for users who should not manage permissions.
• Create a custom Web Application permission policy level that denies permission-management-related capabilities where applicable.
• Apply that policy at the Web Application level to the relevant user population.
• Keep Farm Administrators and Site Collection Administrators as the only approved roles for permission administration.
• Review existing site permission levels and avoid assigning standard Full** **Control to users who should not manage permissions.

This is preferable because it relies on SharePoint’s authorization layer, not on hiding buttons in the UI.

-Important caveat about “Full Control”

If a user has the standard Full Control permission level at the site level, that role normally includes administrative capabilities such as managing permissions. Therefore, if the business requirement says that even users with Full Control should not be able to share content or manage permissions, the better design is not to give those users the built-in Full Control permission level. Instead, create a custom permission level that grants the operational permissions they need, but excludes permission-management capabilities.

If Web Application permission policies are used, test carefully with representative users, site owners, and site collection administrators before broad deployment, because deny policies can have wide impact across the web application.

4. Extensibility options: event receivers, claims providers, custom authorization logic

For this specific requirement, I would not recommend event receivers or UI customization as the main solution.

Event receivers are not a good fit for a complete permission governance solution because the requirement is not just to react to item changes, but to consistently control who can grant access across documents, folders, sites, classic pages, modern pages, and administrative pages.

Claims providers are also not the right primary mechanism for this requirement. Microsoft documentation describes SharePoint claims providers as components used for claims augmentation and claims picking, such as augmenting a user token with claims or resolving/searching claims in the people picker. They are not documented as a general-purpose way to block SharePoint permission management actions such as Share, Share With, or Manage Permissions.

Custom authorization logic or farm solutions may introduce maintainability and migration risk, especially because the environment is moving from SharePoint Server 2019 to SharePoint Subscription Edition. For a security-critical requirement, supported SharePoint permission models and Web Application permission policies are safer than custom UI or custom request interception.

---

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click ""Comment"".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.