If you have got a passwordless admin account and then tried to connect to the SharePoint Online Management Shell (Connect-SPOService -Url https://yourtenant-admin.sharepoint.com) you’ve probably met an issue. The login prompt pops up, but it’s the old one, and you cannot use passkeys. It supports just the classic “password + MFA”.
Instead of the embedded browser, this tells the module to open your system’s default browser (Edge, Chrome, whatever you’ve got) where your FIDO2 key, Windows Hello, or Authenticator passkey works exactly as it does everywhere else.
Note: Make sure you are running the latest version of the SharePoint Online Management Shell. You can update it with:
SharePoint can automatically apply sensitivity labels to a document library. New documents, both created online or uploaded and existing ones (when they are edited), will get the sensitivity label you chose.
If a document label gets manually modified, SharePoint won’t overwrite the label. This isn’t usually an issue because only a few selected number of employees should have the permissions to declassify a document.
This automation supports the following file formats:
Word: .docx, .docm
Excel: .xlsx, .xlsm, .xlsb
PowerPoint: .pptx, .ppsx
PDF (Preview)
Whilst the support for PDFs is still in preview, I still have yet to have issues with it.
This script was written because I found the steps to enable this feature a bit confusing, and so I wanted to simplify the process with a simple automation.
Before running the script, create and publish your sensitivity labels. You have to publish the label to the user setting the default sensitivity label.
After running the script, go into the labels and modify the scope to include groups and sites. You’ll have to wait a bit between running the PowerShell script and enabling groups and sites, as it’s greyed out by default.
After you have enabled groups & sites, you’ll have to wait for the setting to label a SharePoint library to show up.
To set the default label, go under SharePoint Admin Center, then Sites, Active Sites, and click on the site you wish to apply the sensitivity label to. Under Settings, you’ll find a Sensitivity label dropdown.
Modify the two variables before running the script.
# Define the variables for your enviroment. The first one is the link to your SharePoint Admin Portal. The second one is your administrator account User Principal Name
$SPAdminLink = "https://yourtenant-admin.sharepoint.com"
$AdminUPN = "youradminUPN@contoso.com"
# Connect to SPO. Replace the link with your SharePoint Admin portal
Connect-SPOService -Url $SPAdminLink
# Enable AIP Integration
Set-SPOTenant -EnableAIPIntegration $true
(Get-SPOTenant).EnableAIPIntegration
# Enable support for PDFs. Update SP Online Module if this fails. The link is https://www.microsoft.com/en-us/download/details.aspx?id=35588
Set-SPOTenant -EnableSensitivityLabelforPDF $true
(Get-SPOTenant).EnableSensitivityLabelforPDF
# Connect to AAD and enable support for labels in groups. Source: https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-teams-groups-sites?view=o365-worldwide
Install-Module AzureADPreview
AzureADPreview\Connect-AzureAD
$grpUnifiedSetting = (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ)
$Setting = $grpUnifiedSetting
# Check if EnableMIPLabels is enabled. If nothing is displayed then you have no group settings. We'll enable it.
$grpUnifiedSetting.Values
# Enable the feature. If it fails check out this guide: https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-settings-cmdlets#create-settings-at-the-directory-level
$Setting["EnableMIPLabels"] = "True"
# Check that now it's enabled. If it's enabled you'll get
#
#Name Value
#---- -----
#EnableMIPLabels True
$Setting.Values
# Save
Set-AzureADDirectorySetting -Id $grpUnifiedSetting.Id -DirectorySetting $Setting
# Now we'll import ExchangeOnlineManagement and then connect the Compliance Powershell to sync the labels
Import-Module ExchangeOnlineManagement
Connect-IPPSSession -UserPrincipalName $AdminUPN
Execute-AzureAdLabelSync
As I speak to more and more customers about the matter, I notice that a lot of companies have a questionable security posture regarding their administrative accounts. For example, many admins are using their “daily-runner” account as privileged administrators for their tenants, or synchronizing their domain admins to privileged roles in Azure AD. In general, a lot of admin accounts aren’t getting the care they deserve.
Losing privileged access is a big deal and it’s happening more and more often. Clearly, attackers love targeting privileged accounts because they give them quick and broad access to a company’s important assets, leaving a lot of defences behind.
I decided to write this article to highlight some of the controls that should be implemented in our tenants to improve our admin accounts posture, as privileged access management should be one of our top security priorities. These points have been aggregated after a lot of discussions with colleagues and experts on the topic and with the help of best practices from Microsoft Docs.
The 10 tips list
As a best practice, administrator accounts should be:
Separate from your daily-runner account. Collaboration tasks should not be done from the administrative accounts. While it’s of course not convenient, admins should get used to handling multiple accounts for different permission levels.
Cloud-only. Your Azure AD administrator accounts should be different to your on-premises admins, and should not be synchronized from the on-premises Active Directory. This is because if one’s identity gets breached, the attackers would have easy access to both Azure AD and AD.
Mailbox-less. The easy way to implement this is by not assigning admins licenses. You should enable a forward from your admin account to your daily driver account, or a dedicated mailbox/distribution list assigned to an unprivileged user.
Using phishing-resistant authentication methods. FIDO2 keys should be your primary way of accessing your admin accounts. If FIDO2 keys or similar methods are unavailable to you, you should have at least MFA active on your account with number matching and additional details active. Ideally, you should also restrict access to your resources to only allow access from known devices.
Reviewed periodically. Periodically analyse the list of admins, and remove excessive permissions. There are a lot of cool tools that can help you out with this, or you can script your own. Microsoft suggests analysing these roles first, then moving to the other administrative accounts: Global Administrator, Privileged Role Administrator (they are a click away from being Global Admins), Exchange Administrator, and SharePoint Administrator. Remove guest admins where applicable.
Protected by IdentityProtection. Identity Protection automatically scans your sign-ins and blocks the user if anything strange is going on. You can also configure it to force the user to do a self-service password reset.
PIM-enabled. You should have administrative privileges only when you require them. Having admin privileges active on an account 24/7 without a specific reason is not the best idea. Moreover, whenever you enable your PIM roles, you get an email, to keep everything under control.
Backed up by one or two emergency accounts. If bad things happen, you should still be able to access your tenant. Emergency access administrators help you with that. You should also consider activating a rule to alert you when this admin gets used. Here is a cool guide to create passwordless emergency admins with FIDO2 Keys: https://janbakker.tech/break-glass-accounts-and-azure-ad-security-defaults/
Protected with Conditional Access Policies. This is a very broad topic, but make sure that at least the following apply. Those policies can be created quickly using Conditional Access policies templates: Require phishing-resistant multifactor authentication for admins, Securing security info registration, block legacy authentication, require multifactor authentication for Azure management, Require compliant or hybrid Azure AD joined device for admins, Block access for unknown or unsupported device platform, No persistent browser session. Of course, before activating this policies, be really careful to test things out and exclude the emergency account(s).
Additional points:
Use precise Administrative roles. Of course, using highly privileged accounts it’s convenient, as you have only to activate one role to manage everything. But if you assign people the correct permissions they need for their daily job, a lot of headaches can be prevented. Check out this documentation page to ease the pain of finding the right role to assign: https://learn.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task
Consider Privileged Access Workstations. Having PAWs for Admin roles can help a lot with your security posture. PAWs can be configured on Azure AD with device filtering rules in Conditional Access Policies. For example the CAP may require: When all admins, except for the emergency access administrator, access all apps, block access unless they are using specified devices, filtered by device ID. These PAWs should be AAD joined, and are usually for Global Admins and Privileged Role Administrators. Also, having Bitlocker on at least this machines is a must. Spoofing device IDs with Powershell is sadly possible at the moment, but it’s kinda hard and not one of the first things that attackers will do. As always, a lot of this depends on your security risk acceptance level. If you want to drill down on PAWs, this article might be useful: https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices
If you have an on-premises AD, you should really look into improving your AD security, as your AAD security and your AD security are tightly correlated. A tiering model for Active Directory is really useful to better manage your forests, and implementing Defender for Identity gives you a whole new level of analysis and reaction on what’s going on. This won’t be discussed here, but there are plenty of resources to get started with this. Also, again, don’t sync your on-prem administrators to Azure AD. You should have some level of filtering from on-prem to Azure AD, such as filtering by OU or by AD attributes.
Also not discussed here, as Azure permissions are a whole topic by themselves, but you should really be analyzing Azure privileged permissions and keeping everything under control.
In Azure Kubernetes Service (AKS) on Azure Stack HCI, you can increase the resources available to your node pool by changing the size of virtual machines in a node pool or expanding the node count. The node count can also be increased with autoscaling methods.
The worker nodes can be scaled using the command Set-AksHciNodePool, while the Set-AksHciCluster scales the control plane.
I’ll be going over scaling both using PowerShell in the following guide. You’ll need to open a PowerShell session on one of the Azure Stack HCI nodes to follow along. Replace the parameter values as needed.
Notes
As of January 2023, the scaling of the management cluster (the one created by AKS HCI automatically) is currently not supported.
Now that we have scaled up the control plane, we can scale the control plane node count. The default is 1. If you scale up the control plane, it will become highly available and will not accept any scale down back to 1 node⚠️
SMS-based authentication allows users to log in without needing to remember their username and password. After enabling the feature for an account, users can enter their phone number at the login prompt instead of their username. They will then receive an authentication code via text message that they can use to complete the login.
This service is often mistaken for SMS-based Multi-factor Authentication, but they are not the same.
This authentication method makes it easier for frontline workers to access applications and services. It’s not recommended to enable this feature for users who could use other passwordless methods or a combination of credentials + MFA. It’s also important to note that the desktop Office apps do not support SMS-based auth. Therefore, you can only use the web app version of the apps and only by logging in via office.com. You also cannot use the mobile version of the apps, except for Teams, Company Portal and Microsoft Azure.
If you decide to enable the feature, you should consider limiting and standardizing the frontline worker’s permissions to what’s necessary.
If you are curious why you should prioritize other methods over phone-based auth, consider reading this always relevant article by Alex Weinert:
Click on SMS (Preview). The feature is not in preview anymore, even if the portal states so at the moment of writing this guide.
Click on “Yes” under “Enable”, then “Select groups”, and select the group you created in the first step. Complete the step by clicking “Select” and “Save”.
To set a phone number, go into All Users | Azure AD, then select a member of the group you created in the first step.
Go into “Authentication methods”, then click “Add authentication method”. From there, select “Phone number” and insert the phone number the user will use to sign in, then click “Add”.
You can also add an authentication method via PowerShell:
# Replace the variables with the user you wish to add the auth method to and phone number you wish to assign
$User = "user@example.com"
$PhoneNumber = "+1 111111111"
Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta
New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber
# Get the phone number of the user
Get-MgUserAuthenticationPhoneMethod -UserId $User
If you need to script this for multiple users, you can refer to the code below.
This script assumes you created a CSV file in “C:\” named contacts.csv, and that the CSV file has a column named UserName and a column named PhoneNumber. If your CSV file has different column names, you will need to update the script accordingly.
# Install the modules and login to Graph
Install-module Microsoft.Graph.Identity.Signins
Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
Select-MgProfile -Name beta
# Import the CSV file containing names and phone numbers
$contacts = Import-Csv -Path "C:\contacts.csv"
# Loop through each user and add their phone number for authentication
# If you changed the column names, replace these placeholders with the actual column names from the CSV file
foreach ($contact in $contacts)
{
$User = $contact.UserName
$PhoneNumber = $contact.PhoneNumber
New-MgUserAuthenticationPhoneMethod -UserId $User -phoneType "mobile" -phoneNumber $PhoneNumber
}
The following script will get all the members of an Azure AD group and add them to another group. You’ll just need to know the name of the two groups to make it work.
In the code shown below, the source group will be called Group1Name and the destination one Group2Name.
# Replace Group1Name with the name of your source group and Group2Name with the name of the destination one. Everything else will be done automatically
$Group1 = "Group1Name"
$Group2 = "Group2Name"
$group1ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group1'" | Select objectid -ExpandProperty ObjectID
$group2ObjectID = Get-AzureADGroup -Filter "Displayname eq '$group2'" | Select objectid -ExpandProperty ObjectID
$membersGroup1 = Get-AzureADGroupMember -ObjectId $group1ObjectID -All $true
foreach($member in $membersGroup1)
{
$currentuser = Get-AzureADUser -ObjectId $member.ObjectId | select objectid
Add-AzureADGroupMember -ObjectId $group2ObjectID -RefObjectId $currentuser.objectid
}
Get-AzureADGroupMember -ObjectId $group2ObjectID -All $true
Azvise 