Securing SharePoint and OneDrive Permissions

Introduction

Microsoft SharePoint and OneDrive serve as critical platforms for collaboration, document management, and information sharing. However, their flexibility in sharing and permissions can introduce significant security risks if not properly configured.

This article addresses common security concerns, including unintended data exposure through public sharing, the risks associated with “Everyone” claims in SharePoint, and practical controls for securing your Microsoft 365 environment. We’ll explore tenant-wide security settings, site-level exceptions, Teams privacy controls, and enforcement mechanisms using Microsoft Purview sensitivity labels.

The stakes are high. A misconfigured SharePoint site can expose sensitive records, research data, or internal communications to the internet without authentication. A public team might inadvertently allow unauthorized access to confidential discussions. By implementing the controls outlined in this article, you can balance collaboration needs with robust security practices.

Understanding SharePoint Sharing Permissions

Anonymous and Public Sharing

When SharePoint or OneDrive is configured to allow “Anyone with the link” sharing, files and folders can be accessed without any authentication. This means that anyone who obtains the link, whether through intentional sharing, email forwarding, or discovery, can access the content. No Microsoft account, no organization credentials, and no verification required.

Risk scenarios include:

• Student records accidentally shared via a public link
• Confidential research data exposed through forwarded links
• Internal policy documents indexed by search engines
• Compliance violations resulting from uncontrolled data dissemination

While there are legitimate use cases for public sharing (such as marketing materials, public event information, or open educational resources), these should be the exception rather than the rule and should be carefully controlled and documented.

The “Everyone” Claims Problem

SharePoint includes several built-in claims that can dramatically expand access to content beyond what administrators intend. These claims appear as options when users share content and can create security vulnerabilities:

ShowEveryoneClaim: When enabled, this displays “Everyone” as a sharing option, which grants access to all authenticated users within your organization. While this might seem reasonable for internal content, it prevents granular access control and can expose sensitive information to users who shouldn’t have access.

ShowEveryoneExceptExternalUsersClaim: This claim shows “Everyone except external users” as an option, granting access to all internal users and any external users who have been explicitly added to your tenant. This can be particularly problematic in environments with guest user access, as it may grant broader permissions than intended.

ShowAllUsersClaim: This claim displays “All Users” as an option and can include both internal and external users depending on your configuration. Like the other claims, it removes the ability to carefully control who has access to sensitive information.

These claims are problematic because they encourage oversharing. Users may select these options without understanding the full scope of access they’re granting. In a security-conscious environment, permissions should be granted explicitly to specific users or groups, not through broad, all-encompassing claims.

Tenant-Level Security Controls

Auditing Current Settings

Before making changes, you should audit your current SharePoint Online tenant configuration. This allows you to understand your current security posture and document your baseline before implementing controls.

Connect to SharePoint Online using PowerShell and run the following command:

Get-SPOTenant | Select Show*

This command retrieves all properties beginning with “Show” from your tenant configuration. You’ll see output similar to:

ShowEveryoneClaim                      : True
ShowEveryoneExceptExternalUsersClaim   : True
ShowAllUsersClaim                      : True
ShowPeoplePickerSuggestionsForGuestUsers : True

Interpreting the output:

• True values indicate that these claims are currently available to users when sharing content
• False values indicate the claims are hidden and unavailable
• These settings control visibility in the sharing dialog, not existing permissions

Disabling Problematic Claims

To improve your security posture, disable these claims at the tenant level. This prevents users from selecting these overly broad sharing options going forward:

Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false

Important considerations:

Impact on existing shares: These settings only affect the visibility of options in the sharing dialog. They do not automatically revoke existing permissions that were granted using these claims. You’ll need to audit and remediate existing shares separately.

User experience changes: After disabling these claims, users will need to share content by searching for specific individuals, groups, or distribution lists. While this requires slightly more effort, it encourages intentional, explicit permission grants rather than broad oversharing.

Communication strategy: Before deploying these changes, communicate with your user community about:

• Why the changes are being made (security and compliance)
• How to share content properly using specific users or groups
• Where to find help if they need to set up broader sharing for legitimate purposes
• The timeline for implementation

Controlling Anonymous Sharing at Tenant Level

SharePoint Online implements a hierarchy for sharing settings: tenant settings override site settings, and site settings override individual file settings. By configuring restrictive tenant-level defaults, you establish a strong security baseline.

Recommended baseline configurations:

1. Set sharing level to “Only people in your organization” for OneDrive by default
2. Require authentication for external sharing when external collaboration is needed
3. Disable anonymous access links unless specific business cases require them
4. Set link expiration policies for any external or anonymous links that are permitted
5. Disable “Anyone” links for sensitive site collections

You can configure these through the SharePoint Admin Center under Policies > Sharing, or via PowerShell for automation and consistency.

Site-Level Controls and Exceptions

Creating Exceptions for Public Sharing

Despite the security benefits of restrictive tenant settings, there are legitimate scenarios where specific SharePoint sites need to allow public sharing:

• Marketing and communications sites hosting public-facing content
• Open educational resources intended for public access
• Public event registration forms and information
• Research data repositories with publicly available datasets

To enable a specific site for anonymous sharing:

1. Navigate to SharePoint Admin Center
2. Go to Active Sites
3. Select the site that requires public sharing
4. Click Policies > External Sharing
5. Configure the appropriate sharing level for that site
6. Document the justification and approval

Best practices for exceptions:

• Require written approval from appropriate stakeholders
• Document the business justification
• Set calendar reminders to review exceptions periodically
• Apply sensitivity labels to clearly mark public-facing sites
• Audit public sites more frequently than internal sites

Auditing Site Settings via SharePoint Admin Center

Regular audits help ensure that site configurations remain aligned with security policies and that unauthorized changes haven’t been made.

To review site settings manually:

1. Access the SharePoint Admin Center
2. Navigate to Active Sites
3. Sort or filter to focus on sites of concern (e.g., sites with external sharing enabled)
4. Click on each site to view its policies
5. Review the External Sharing setting under Policies
6. Check for any unexpected configurations

What to look for:

• Sites with more permissive sharing than required
• Recently changed sharing settings that weren’t approved
• Sites that should have restricted sharing but don’t
• Inactive sites that still have permissive settings

PowerShell Script for Site Enumeration

For organizations with many SharePoint sites, manual auditing becomes impractical. PowerShell scripts allow you to enumerate all sites and their sharing configurations quickly, enabling regular automated audits.

Sample script to enumerate SharePoint sites and their sharing settings:

# Connect to SharePoint Online
Connect-SPOService -Url https://yourtenant-admin.sharepoint.com

# Get all site collections
$sites = Get-SPOSite -Limit All

# Create array to store results
$results = @()

# Loop through each site
foreach ($site in $sites) {
    Write-Host "Processing: $($site.Url)" -ForegroundColor Cyan
    
    # Get detailed site information
    $siteDetails = Get-SPOSite -Identity $site.Url -Detailed
    
    # Create custom object with relevant properties
    $siteInfo = [PSCustomObject]@{
        SiteUrl = $site.Url
        Title = $site.Title
        Owner = $site.Owner
        SharingCapability = $site.SharingCapability
        AllowAnonymousAccess = $siteDetails.AllowAnonymousMeetingParticipantsToAccessWhiteboards
        DisableCompanyWideSharingLinks = $site.DisableCompanyWideSharingLinks
        LastContentModifiedDate = $site.LastContentModifiedDate
        StorageUsageCurrent = $site.StorageUsageCurrent
        Template = $site.Template
    }
    
    $results += $siteInfo
}

# Export results to CSV
$results | Export-Csv -Path "SharePoint-Sites-Audit-$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation

Write-Host "`nAudit complete. Results exported to CSV." -ForegroundColor Green

# Display summary statistics
Write-Host "`n=== Sharing Configuration Summary ===" -ForegroundColor Yellow
$results | Group-Object SharingCapability | Select-Object Name, Count | Format-Table -AutoSize

Understanding SharingCapability values:

• Disabled: External sharing is completely disabled
• ExistingExternalUserSharingOnly: Only external users already in the directory
• ExternalUserSharingOnly: External users with authentication required
• ExternalUserAndGuestSharing: External users including anonymous guest links

Customizing the script:

• Add filters for specific templates or site patterns
• Include additional properties like conditional access policies
• Schedule the script to run weekly via Azure Automation or Task Scheduler
• Send results to your SIEM (like Splunk) for alerting on configuration changes
• Create alerts for sites that deviate from expected configurations

Microsoft Teams Privacy Controls

Public vs. Private Teams

Microsoft Teams can be created as either public or private, with significant security implications for each choice:

Public Teams:

• Discoverable by anyone in the organization
• Anyone in the organization can join without approval
• Content is more easily searchable across the organization
• Appropriate for: organization-wide announcements, general interest groups, open communities

Private Teams:

• Not discoverable in Teams search
• Joining requires owner approval
• Content is restricted to members only
• Appropriate for: departmental work, project teams, confidential discussions

The default setting in many organizations allows users to create public teams freely, which can lead to unintended data exposure. Sensitive discussions, student information, or confidential projects should always be conducted in private teams.

Identifying Team Privacy Settings

Via Teams Admin Center:

1. Navigate to Microsoft Teams Admin Center
2. Go to Teams > Manage Teams
3. The Privacy column shows whether each team is Public or Private
4. Click on a team name to view detailed settings

Via PowerShell:

# Connect to Microsoft Teams
Connect-MicrosoftTeams

# Get all teams and their privacy settings
Get-Team | Select-Object DisplayName, GroupId, Visibility, Archived | Format-Table -AutoSize

# Export to CSV for analysis
Get-Team | Select-Object DisplayName, GroupId, Visibility, Archived, Description | 
    Export-Csv -Path "Teams-Privacy-Audit-$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation

For bulk auditing:

# Get all public teams
$publicTeams = Get-Team | Where-Object {$_.Visibility -eq "Public"}

Write-Host "Found $($publicTeams.Count) public teams:" -ForegroundColor Yellow
$publicTeams | Select-Object DisplayName, GroupId | Format-Table -AutoSize

# Identify teams that might need to be private
$suspiciousKeywords = @("confidential", "restricted", "internal", "private", "student", "FERPA")
$publicTeams | Where-Object {
    $teamName = $_.DisplayName
    $suspiciousKeywords | Where-Object { $teamName -like "*$_*" }
} | Select-Object DisplayName, GroupId

Converting Public Teams to Private

When you identify public teams that should be private, you can convert them through the Teams interface or PowerShell.

Via Teams Interface:

1. Open Microsoft Teams
2. Navigate to the team that needs to be changed
3. Click the three dots (…) next to the team name
4. Select “Edit team”
5. Under Privacy, select “Private - Only team owners can add members”
6. Click “Done”

Via PowerShell:

# Connect to Microsoft Teams
Connect-MicrosoftTeams

# Change a specific team to private
Set-Team -GroupId "team-group-id-here" -Visibility Private

# Bulk conversion of teams matching criteria
$teamsToConvert = Get-Team | Where-Object {
    $_.Visibility -eq "Public" -and 
    $_.DisplayName -like "*Confidential*"
}

foreach ($team in $teamsToConvert) {
    Write-Host "Converting $($team.DisplayName) to Private..." -ForegroundColor Cyan
    Set-Team -GroupId $team.GroupId -Visibility Private
    Write-Host "  ✓ Converted successfully" -ForegroundColor Green
}

Important considerations:

Impact on existing members: Converting a public team to private does not remove any existing members. All current members retain their access. However, new users will no longer be able to discover or join the team without an invitation.

Communication requirements: Before converting teams, notify team owners and members about:

• The reason for the change (security, compliance, data sensitivity)
• What will happen (team becomes private)
• What won’t change (existing members, content, channels)
• How to add new members going forward (owner approval required)

Timing: Consider implementing changes during low-activity periods and providing advance notice to minimize disruption.

Enforcing Controls with Purview Sensitivity Labels

Microsoft Purview sensitivity labels provide a powerful mechanism for enforcing security policies consistently across SharePoint, Teams, and Microsoft 365 Groups.

Using Sensitivity Labels to Block Public Teams

You can create sensitivity labels that enforce private team creation, preventing users from creating public teams that could expose sensitive information.

Creating a label that requires private teams:

1. Navigate to Microsoft Purview compliance portal
2. Go to Information Protection > Labels
3. Create a new sensitivity label (or edit an existing one)
4. In the label wizard, proceed to “Define protection settings for groups and sites”
5. Enable “Privacy and external user access settings”
6. Under Privacy, select “Private - only members can access the site”
7. Configure additional settings as needed:
   • External user access (allow/disallow)
   • External sharing (control sharing settings)
   • Unmanaged devices (conditional access)
8. Publish the label to appropriate users or groups

Enforcing the label for new teams:

To require that all new teams use a label that enforces privacy:

1. In the label policy, configure “Apply this label by default to groups and sites”
2. Alternatively, require users to select a label when creating teams
3. Configure the label to make Privacy settings mandatory and unchangeable

Example configuration:

# Note: This is conceptual - label configuration is primarily done via UI
# But you can verify label policies via PowerShell

# Connect to Security & Compliance Center
Connect-IPPSSession

# View existing sensitivity labels
Get-Label | Select-Object DisplayName, Guid, Priority

# View label policies
Get-LabelPolicy | Select-Object Name, Labels, Mode

Enforcement and Monitoring

After deploying sensitivity labels, ongoing monitoring ensures compliance and helps identify issues.

Testing label effectiveness:

1. Attempt to create a new team without selecting a label
2. Verify that the label is automatically applied or that selection is required
3. Confirm that public team creation is blocked when using the enforcing label
4. Test external sharing to ensure restrictions are applied

Handling existing public teams:

Sensitivity labels are typically applied to new teams going forward. For existing public teams:

1. Run an audit to identify all public teams (as shown in previous sections)
2. Assess each public team to determine if it should remain public
3. For teams that should be private, apply the appropriate sensitivity label
4. The label will enforce privacy settings and convert the team

User guidance and training:

Successful implementation requires user education:

• Explain why sensitivity labels are being used
• Demonstrate how to select appropriate labels when creating teams
• Provide guidance on which label to use for different scenarios
• Create quick reference guides or decision trees
• Offer training sessions for team owners and frequent creators

Monitoring and Compliance

Security is not a one-time configuration but an ongoing process requiring regular monitoring and adjustment.

Ongoing Auditing

Scheduled PowerShell scripts:

Set up automated scripts to run weekly or monthly:

# Example: Weekly audit script that can run via Azure Automation

# Connect to services
Connect-SPOService -Url https://yourtenant-admin.sharepoint.com
Connect-MicrosoftTeams

# Audit SharePoint sites
$sites = Get-SPOSite -Limit All | Where-Object {
    $_.SharingCapability -ne "Disabled"
}

# Audit Teams
$publicTeams = Get-Team | Where-Object {$_.Visibility -eq "Public"}

# Create report
$report = @{
    AuditDate = Get-Date
    SitesWithExternalSharing = $sites.Count
    PublicTeams = $publicTeams.Count
    Sites = $sites
    Teams = $publicTeams
}

# Send report via email or store in secure location
# Alert if thresholds are exceeded
if ($publicTeams.Count -gt 50) {
    # Send alert to security team
    Write-Warning "High number of public teams detected: $($publicTeams.Count)"
}

Alert configuration for policy violations:

Configure alerts for:

• Creation of sites with external sharing enabled
• Changes to tenant-level sharing settings
• New public teams created
• Existing private teams changed to public
• Anonymous link creation events
• Excessive external sharing by individual users

Integration with SIEM tools:

For organizations using Splunk or similar SIEM platforms:

1. Configure Microsoft 365 audit logging
2. Set up log forwarding to Splunk
3. Create searches for SharePoint/Teams security events:
   • SharingSet events
   • SharingInvitationCreated events
   • TeamCreated events with visibility=Public
4. Build dashboards for security metrics
5. Configure automated alerts for suspicious patterns

Example Splunk search:

index=o365 sourcetype="o365:management:activity" 
Operation="SharingSet" 
| where ItemType="Site" 
| stats count by SiteUrl, User, SharingCapability
| where SharingCapability!="Disabled"

Reporting for Leadership

Executive stakeholders need clear, actionable reporting on security posture and compliance status.

Metrics to track:

• Number of sites with external sharing enabled vs. total sites
• Percentage of teams that are private vs. public
• Number of sensitivity labels applied to new teams
• Trend lines showing improvement in security posture over time
• Number of policy violations detected and remediated
• Mean time to remediate configuration issues
• User compliance with training requirements

Compliance dashboards:

Create dashboards that show:

1. Current State: How many sites/teams comply with policy
2. Trends: Improvement or degradation over time
3. Risk Areas: Sites or teams requiring immediate attention
4. Remediation Progress: Outstanding issues and closure rates

Remediation workflows:

Establish clear processes for handling non-compliant configurations:

1. Detection: Automated scripts identify issues
2. Classification: Determine severity (high/medium/low)
3. Notification: Alert site owners or responsible parties
4. Remediation: Apply fixes manually or automatically
5. Verification: Confirm resolution and document
6. Follow-up: Ensure issues don’t recur

Best Practices and Recommendations

Implementing these controls effectively requires a comprehensive approach that balances security with usability.

Defense-in-depth approach:

Don’t rely on a single control. Layer multiple protections:

• Tenant-level restrictions as the foundation
• Site-level policies for specific needs
• Sensitivity labels for consistent enforcement
• Conditional access for additional context-aware security
• Data loss prevention (DLP) for content-based protection
• Regular auditing to verify controls remain effective

User education requirements:

Technical controls are most effective when users understand and support them:

• Conduct regular security awareness training
• Explain the “why” behind restrictions, not just the “what”
• Provide clear guidance on how to accomplish legitimate tasks securely
• Create easily accessible documentation and FAQs
• Offer office hours or help desk support for sharing questions
• Celebrate security-conscious behavior

Exception request process:

Create a formal process for requesting exceptions to security policies:

1. Require written justification from the requestor
2. Obtain approval from appropriate stakeholders (security, compliance, management)
3. Document the exception in a central registry
4. Set expiration dates for temporary exceptions
5. Review exceptions periodically (quarterly or semi-annually)
6. Revoke exceptions that are no longer needed

Regular access reviews:

Implement periodic reviews of sharing and access:

• Quarterly reviews of sites with external sharing enabled
• Annual reviews of all site permissions
• Monthly reviews of public teams
• Automated removal of stale guest accounts
• Owner attestation that team members still require access

Integration with broader information security program:

SharePoint and Teams security should align with your overall security strategy:

• Include SharePoint/Teams in risk assessments
• Address findings in audit reports and security assessments
• Coordinate with identity and access management initiatives
• Align with data classification and handling policies
• Include in incident response planning and exercises
• Consider in business continuity and disaster recovery plans

Conclusion

Securing SharePoint and OneDrive permissions is critical for protecting sensitive data in higher education and other regulated environments. By disabling problematic “Everyone” claims, controlling anonymous sharing, enforcing team privacy settings, and leveraging sensitivity labels, you can significantly reduce the risk of unintended data exposure.

The key to success is finding the right balance between security and collaboration. Overly restrictive controls that prevent legitimate work will be circumvented. Controls that are too permissive will lead to data exposure and compliance violations. The approach outlined in this article provides multiple layers of defense while still enabling collaboration when properly configured.

Next steps for implementation:

1. Audit current state: Run the PowerShell scripts to understand your current configuration
2. Disable problematic claims: Implement the tenant-level settings to remove broad sharing options
3. Review public teams: Identify and convert teams that should be private
4. Deploy sensitivity labels: Create and publish labels that enforce security policies
5. Establish monitoring: Set up automated audits and alerts for policy violations
6. Train users: Ensure your community understands the changes and how to work within them
7. Document exceptions: Create a formal process for handling legitimate exceptions
8. Review regularly: Schedule periodic reviews of configurations and access

Security is an ongoing journey, not a destination. Regular monitoring, continuous improvement, and adaptation to new threats and business needs will keep your SharePoint and Teams environment secure while supporting your organization’s mission.

For additional resources on SharePoint security, consult Microsoft’s documentation on SharePoint Online security and compliance, and consider engaging with the security community in higher education through forums like EDUCAUSE and regional IT security groups.