Listen to this Post
Introduction:
SharePoint Online administrators rely on PowerShell for critical security configurations, particularly Conditional Access Policies that enforce stringent authentication controls. A common but poorly documented pitfall in the `PnP.PowerShell` and `Microsoft.Online.SharePoint.PowerShell` modules means the standard `Get-SPOSite` command returns incorrect policy data, potentially creating severe security misconfigurations and compliance gaps.
Learning Objectives:
- Understand the critical difference between the LIST and GET operations within the `Get-SPOSite` PowerShell cmdlet.
- Learn the correct method to accurately enumerate Conditional Access Policies applied to individual SharePoint Online sites.
- Implement a reliable scripting pattern to audit and verify site-level security settings across your tenant.
You Should Know:
1. The Dangers of the Default LIST Operation
The default `Get-SPOSite` cmdlet performs a LIST operation, which is optimized for speed and returning a collection of sites. However, this operation does not fetch all properties for each site; it returns a subset and, crucially, uses the tenant-wide default value for the `ConditionalAccessPolicy` attribute instead of the site-specific setting.
Incorrect Command:
Get-SPOSite | Select-Object Url, ConditionalAccessPolicy
This command is efficient but provides inaccurate data for security auditing, showing the tenant default policy for every site instead of their individually assigned policies.
2. The Accurate GET Operation for Security Auditing
To force a GET operation, which retrieves the full set of properties for a specific site, you must pipe the results of the initial list and call `Get-SPOSite` again with the `-Identity` parameter for each site.
Verified Correct Command:
Get-SPOSite -Limit All | ForEach-Object { Get-SPOSite -Identity $_.Url | Select-Object Url, ConditionalAccessPolicy }
Step-by-Step Guide:
Get-SPOSite -Limit All: Retrieves a list of all sites in the tenant. The `-Limit All` parameter ensures you get every site, not just the first 200.ForEach-Object { ... }: This loop iterates over each site object returned from the list.Get-SPOSite -Identity $_.Url: For each site’s URL, this performs a new GET operation that fetches the complete site object, including the true `ConditionalAccessPolicy` value.Select-Object Url, ConditionalAccessPolicy: Finally, this selects and outputs only the URL and the now-accurate policy setting for reporting.
3. Building a Comprehensive Security Report
Simply getting the data is not enough; you need to format it into an actionable report for compliance and auditing purposes. This enhanced script exports the results to a CSV file.
Verified Script:
$Report = Get-SPOSite -Limit All | ForEach-Object {
$Site = Get-SPOSite -Identity $_.Url
[bash]@{
Url = $Site.Url
ConditionalAccessPolicy = $Site.ConditionalAccessPolicy
SharingCapability = $Site.SharingCapability
StorageQuota = $Site.StorageQuota
}
}
$Report | Export-Csv -Path "C:\Temp\SPOSecurityAudit.csv" -NoTypeInformation
Step-by-Step Guide:
- The script collects all sites and their true properties into the `$Report` variable.
- It creates a custom object for each site, including security-critical properties like `SharingCapability` and `StorageQuota` alongside the policy.
- The `Export-Csv` cmdlet writes the final report to a file, which can be used for audits or to track configuration drift over time.
4. Automating Policy Enforcement and Remediation
Identifying misconfigured sites is only half the battle. This script automates the remediation process by enforcing a strict Conditional Access Policy on any site found with a weaker policy.
Verified Remediation Script:
Define the strict policy to enforce
$StrictPolicy = "StrictAllowLimitedAccess"
Get all sites with their true policy
$AllSites = Get-SPOSite -Limit All | ForEach-Object { Get-SPOSite -Identity $_.Url }
Filter for sites not compliant and apply the strict policy
$NonCompliantSites = $AllSites | Where-Object { $<em>.ConditionalAccessPolicy -ne $StrictPolicy }
$NonCompliantSites | ForEach-Object {
Set-SPOSite -Identity $</em>.Url -ConditionalAccessPolicy $StrictPolicy
Write-Host "Enforced strict policy on: $($_.Url)"
}
Step-by-Step Guide:
- Define the name of the strict policy you want to enforce.
- Use the accurate retrieval method to get all sites and their current policies.
- Filter the list to only those sites that do not match your desired policy state using
Where-Object. - Pipe the non-compliant sites into a `ForEach-Object` loop that uses the `Set-SPOSite` cmdlet to apply the correct policy.
5. Connecting to Your Tenant Securely
Before running any commands, you must establish a secure, authenticated session to your SharePoint Online tenant. This requires the correct modules and permissions.
Verified Connection Commands:
Install the required module (if needed) Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Force Connect to SharePoint Online Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com" You will be prompted for credentials of an account with SharePoint Admin privileges
Step-by-Step Guide:
- Run the `Install-Module` command once on your system to get the necessary cmdlets.
- Use `Connect-SPOService` to start a session, replacing the URL with your admin center URL (e.g., `https://contoso-admin.sharepoint.com`).
- A login prompt will appear; ensure the account you use has the SharePoint Administrator role for your tenant.
What Undercode Say:
- API Design Has Direct Security Consequences: This isn’t just a PowerShell quirk; it’s a fundamental issue in the underlying SharePoint Online API. The choice to have a LIST operation return default values instead of actual values for critical security attributes creates invisible risk that administrators must actively work to overcome.
- Trust, But Verify, All Automated Output: This scenario is a powerful reminder that automation and scripting are not inherently truthful. The output of a command must be validated against reality, especially when dealing with security configurations. Blind faith in a cmdlet’s output can lead to a false sense of security.
The discovery underscores a critical axiom in cloud security: the abstraction of infrastructure does not eliminate complexity—it often hides it. While Microsoft manages the physical servers, the responsibility for secure configuration remains with the customer. This PowerShell behavior creates a dangerous configuration blind spot. Administrators who rely on the basic `Get-SPOSite` command are making decisions based on tenant-level defaults, not reality. This can lead to a scenario where highly sensitive SharePoint sites are mistakenly believed to have strict authentication policies applied, when in fact they are inheriting a less secure tenant default, potentially exposing critical data to unauthorized access. This highlights the need for deep technical scrutiny of even the most basic administrative tools in the cloud shared responsibility model.
Prediction:
This specific issue will likely be resolved in a future update to the SharePoint Online PowerShell modules, with Microsoft potentially adding a `-Detailed` parameter or modifying the default behavior of `Get-SPOSite` to perform a GET for a single site or when specific properties are requested. However, the broader pattern of “hidden” API behaviors will persist. As cloud platforms and their management layers grow more complex, the gap between perceived and actual configuration will widen, giving rise to a new class of vulnerabilities: Cloud Blindspot Vulnerabilities (CBVs). These will not be flaws in the code itself, but misalignments between administrator understanding and the platform’s opaque operational logic, necessitating advanced auditing tools and AI-powered configuration drift detection to manage at scale.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nathanmcnulty In – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
