Skip to main content

Microsoft Entra ID Recommendations

· 9 min read

Microsoft Entra ID is the foundation, which Microsoft 365 is built-on.

In the words of Microsoft:

Microsoft Entra ID (Azure AD) is Microsoft’s cloud-based identity and access management service, which helps your employees sign in and access resources in:

  • External resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications.
  • Internal resources, such as apps on your corporate network and intranet, along with any cloud apps developed by your own organization.

Microsoft Entra ID (AAD) is simply not set and forget, especially given the fact that AAD services are constantly evolving in terms of features and improved security.

Below is a table of some Microsoft Entra ID and best practice recommendations.

Please keep in mind that like any recommendations, do not blindly follow them, make sure to determine the impact on your users on enabling some of this functionality, there may also be recommendations that you will not be able to apply, do to business constraints.

RecommendationWhy Consider ThisProbabilityImpactEffort
Change break glass accounts passwords every 90 daysEmergency access accounts are highly privileged, and they are not assigned to specific individuals. Emergency access accounts are limited to emergency or "break glass"' scenarios where normal administrative accounts can't be used. We recommend that you maintain a goal of restricting emergency account use to only the times when it is absolutely necessary.HighHighLow
Review possible stale Guest (B2B) accountsGuest accounts do not exist by default and pose a potential data exposure vulnerability if left unused. Guest accounts should only be used with a defined business need and closely monitored to ensure accounts are valid/legitimate.HighModerateLow
Remove invited guests who have not accepted inviteRemove invited guests who have not accepted invite as it helps control the scope of identity and access management as it pertains to provisioning users in Azure AD. In addition, removing stale invites and user from Azure AD is part of the recommended routine account maintenance.HighLowLow
Enable Windows Hello for Business PIN Reset ServiceThe Microsoft PIN reset services enables you to help users recover who have forgotten their PIN. Using Group Policy, Microsoft Intune or a compatible MDM, you can configure Windows 10 devices to securely use the Microsoft PIN reset service that enables users to reset their forgotten PIN through settings or above the lock screen without requiring re-enrollment.Low to ModerateModerateLow
Ensure security compliance notification mail is setManaging security and compliance is a partnership. You are responsible for protecting your data, identities, and devices, while Microsoft vigorously protects Office 365 services. You can use Office 365 and Enterprise Mobility + Security (EMS) together to help you achieve the appropriate level of protection for your organization.Low to ModerateModerateLow
Add owner to legacy Service PrincipalLegacy service principals without a defined owner create a challenge for management and accountability.Low to ModerateModerateLow
Add owner to applicationAssigning an application owner provides an opportunity for delegation and establishes accountability for management of the resource.Low to ModerateModerateLow
Add owner to cloud-only groupsAssigning a group owner provides an opportunity for delegation and establishes accountability for management of the resource.Low to ModerateModerateLow
Require that users can create security groups is set to noThe creation and management of security groups should be restricted to administrators only to limit proliferation of this security principal. The default setting is to prevent users from creating security groups in the Azure portal and it is recommended to maintain this configuration unless required by a defined business need.Low to ModerateModerateLow
Delete empty cloud-only groupsCloud-only groups that contain no members and are not associated with Azure applications should be deleted as they serve no purpose.Low to ModerateLowLow
Review Dynamic Groups with membershipRuleProcessingState not turned onSometimes you may want to stop the processing of a dynamic group, like when you’re importing a large number of new users or reorganizing your group architecture. To do that, use the MembershipRuleProcessingState parameter to switch processing on and off.Low to ModerateLowLow
Review and consider federating all domainsWhen a domain is federated with Azure AD, several properties are set on the domain in Azure. One important one is IssuerUri. This property is a URI that is used by Azure AD to identify the domain that the token is associated with.Low to ModerateLowLow
Review applications with credentials about to expire or are expiredApplications with expired credentials will prevent its use and should be updated before expiration to avoid an outage. If the application's service principal already has newer credentials remove the no longer valid credentials.ModerateHighLow
Review applications granted with risky OAUTH2 permissionsDepending on the scope of permissions, it can pose a risk to the confidentiality, integrity, or availability of the organization's data. Periodic review of application permission grants can help identity over-privileged applications and establish access controls that align with the principle of least privilege.ModerateHighLow
Configure user passwords to never expireRequesting users to regularly change passwords will lead to weak password practices like patterns or sequential words and numbers.ModerateModerateLow
Review Service Principals using password based credentialsProtect and manage your confidential app credentials for web apps, web APIs and daemon apps. Use certificate credentials, not password credentials (client secrets).ModerateModerateLow
Review Azure AD Guest (B2B) accountsGuest accounts do not exist by default and pose a potential data exposure vulnerability if left unused. Guest accounts should only be used with a defined business need and closely monitored to ensure accounts are valid/legitimate.ModerateModerateLow
Review applications consented by adminsReview applications granted consent by admins to ensure this global configuration is desired, which results in authorization for applications to data for all users in the Azure AD tenant.ModerateModerateLow
Review applications consented by one userReview applications granted consent by a single users to ensure the configuration is desired, which results in authorization for applications to data for individual users as compared to admin consent which is global for the tenant.ModerateModerateLow
Review domain password policies that do not match defaults.Only passwords for user accounts that are not synchronized through directory synchronization can be configured for password policies. By default users do not have a password policy defined.ModerateModerateLow
Specify the usage location property for usersSome Microsoft services aren't available in all locations because of local laws and regulations. Before you can assign a license to a user, you must specify the Usage location property for the user.ModerateModerateLow
Require that users can consent to apps accessing company data on their behalf is set to noAllowing users to provide consent for third-party applications risks exfiltration of personally identifiable information (PII) such as email and phone number, as it's associated with the user's profile.HighHighModerate
Review group license errorsThese errors should be resolved and all users should be assigned expected licenses, for avoiding any loss of productivity.HighModerateModerate
Remove email / mailbox from directory role adminsTo help separate internet risks (phishing attacks, unintentional web browsing) from administrative privileges, create dedicated accounts for each user with administrative privileges with no mail enabled to make sure they do not inadvertently open emails or run programs associated with their admin accounts.ModerateHighModerate
Remove Skype address from directory role adminsTo help separate internet risks (phishing attacks, unintentional web browsing) from administrative privileges, create dedicated accounts for each user with administrative privileges with no Skype Enabled to make sure they do not inadvertently open emails or run programs associated with their admin accounts.ModerateHighModerate
Develop plan to migrate or remove legacy Service PrincipalsServicePrincipals with ServicePrincipalType of legacy are not associated with an application and should be migrated to an application to improve manageability.ModerateModerateModerate
Federated domains in Azure AD must have SupportsMFA enabled if ADFS MFA is usedWhen the configured conditional access policy requires multi-factor authentication, Azure AD defaults to using Azure MFA. If you use the federation service for MFA, you can configure Azure AD to redirect to the federation service when MFA is needed by setting -SupportsMFA to $true in PowerShell. This setting works for federated authentication services that support the MFA challenge request issued by Azure ADModerateModerateModerate
Verify all root level domainsEvery new Azure AD tenant comes with an initial domain name, domainname.onmicrosoft.com. You can't change or delete the initial domain name, but you can add your organization's names to the list. Adding custom domain names helps you to create user names that are familiar to your usersModerateModerateModerate
Review user objects no longer syncing with on-premisesUsers present in Windows Server AD and no longer syncing to Azure AD impacts users ability to use services provided by Azure AD (Password reset, access to O365 services and cloud based apps etc.) and it also poses administrative challenge in managing the account.ModerateModerateModerate

How to restrict users to specific boards in Azure DevOps

· One min read

Do you ever want to add external Microsoft Entra ID or other users to specific boards in a project, but not want to give them access to the entire Azure DevOps Project?

Using the steps below, we can restrict users to a specific board.

  1. Invite external users to DevOps org with Stakeholder access.
  2. In the project, create a new Team and do not add it to the existing security group to inherit permissions. Azure DevOps - Boards
  3. Add external users to created Team.
  4. Set permission for created Team properly. In this case, it’s to set View project-level information to Allow. Azure DevOps - Boards
  5. Create a new area path and set the permission for the created Team in Security Azure DevOps - Boards
  6. Assign the area path to the newly created Team.

Azure WebApp 500 Errors reporting from AspNetCoreModule

· One min read

Issue Description

Intermittent issues with Azure WebApp constantly stop functioning, a Stop/Start operation brings it back online.

Root Cause

Further investigation using Azure Application Insights, reveals the Azure WebApp was experiencing a few FailedRequestCount, with HTTP 500 Errors. An exception was thrown by a TaskScheduler. Exception of type 'System.OutOfMemoryException' was thrown.

Resolution

In my case, the service that was running on the Azure WebApp was using .NET Core 2.0, the fix was to upgrade to the latest version.

.NET Core 2.0 is an unsupported version and we highly recommend upgrading to the latest version (3.1). Please take a look at this information of the .NET Core official support policy: https://dotnet.microsoft.com/platform/support/policy/dotnet-core

For .NET Core applications I suggest enabling the stdout logs, as those will capture some important errors: https://learn.microsoft.com/en-us/aspnet/core/test/troubleshoot-azure-iis?view=aspnetcore-2.2#aspnet-core-module-stdout-log-azure-app-service-1

If those OutOfMemory exceptions come with a 5xx status code, I would suggest as well using the AutoHeal feature as it will allow setting rules based on that status code to capture a Memory Dump, you can check more information here: https://azure.github.io/AppService/2018/09/10/Announcing-the-New-Auto-Healing-Experience-in-App-Service-Diagnostics.html

Allow Azure DevOps Microsoft Hosted Agent to communicate with Azure KeyVault

· 3 min read

It is best practice to lock down Azure resources to be accessible by location and services that is only to what's required and, the Azure Key vault is no exception.

When using Microsoft Hosted Agents in Azure DevOps, you need to make sure that the AzureCloud IPs for the Azure DevOps regions are opened on the Firewall.

In my case, I was in the: AustraliaEast region and needed to identify and add the following 'AzureCloud' Address Ranges to the KeyVault firewall:

  • "name": "AzureCloud.australiaeast",
  • "id": "AzureCloud.australiaeast",
  • "properties": {
  • "changeNumber": 13,
  • "region": "australiaeast",
  • "regionId": 3,
  • "platform": "Azure",
  • "systemService": "",
  • "addressPrefixes": [
  • "13.70.64.0/18",
  • "13.72.224.0/19",
  • "13.73.192.0/20",
  • "13.75.128.0/17",
  • "13.104.211.128/26",
  • "13.105.16.192/26",
  • "13.105.20.128/26",
  • "13.105.52.192/26",
  • "13.105.53.128/26",
  • "20.37.192.0/19",
  • "20.38.112.0/23",
  • "20.40.64.0/20",
  • "20.40.80.0/21",
  • "20.40.120.0/21",
  • "20.40.176.0/20",
  • "20.42.192.0/19",
  • "20.43.96.0/20",
  • "20.47.37.0/24",
  • "20.47.122.0/23",
  • "20.53.32.0/28",
  • "20.53.40.0/21",
  • "20.53.64.0/18",
  • "20.53.128.0/17",
  • "20.58.128.0/18",
  • "20.60.72.0/22",
  • "20.60.182.0/23",
  • "20.70.128.0/17",
  • "20.135.120.0/21",
  • "20.150.66.0/24",
  • "20.150.92.0/24",
  • "20.150.117.0/24",
  • "20.157.44.0/24",
  • "20.188.128.0/17",
  • "20.190.142.0/25",
  • "20.190.167.0/24",
  • "20.191.192.0/18",
  • "20.193.0.0/18",
  • "20.193.64.0/19",
  • "23.101.208.0/20",
  • "40.79.160.0/20",
  • "40.79.211.0/24",
  • "40.82.32.0/22",
  • "40.82.192.0/19",
  • "40.87.208.0/22",
  • "40.90.18.0/28",
  • "40.90.30.0/25",
  • "40.90.130.80/28",
  • "40.90.130.208/28",
  • "40.90.140.32/27",
  • "40.90.142.160/27",
  • "40.90.147.64/27",
  • "40.90.150.0/27",
  • "40.112.37.128/26",
  • "40.126.14.0/25",
  • "40.126.39.0/24",
  • "40.126.224.0/19",
  • "52.108.40.0/23",
  • "52.108.83.0/24",
  • "52.109.112.0/22",
  • "52.111.224.0/24",
  • "52.113.88.0/22",
  • "52.113.103.0/24",
  • "52.114.16.0/22",
  • "52.114.58.0/23",
  • "52.114.192.0/23",
  • "52.115.98.0/24",
  • "52.120.158.0/23",
  • "52.121.108.0/22",
  • "52.143.199.0/24",
  • "52.143.200.0/23",
  • "52.147.0.0/19",
  • "52.156.160.0/19",
  • "52.187.192.0/18",
  • "52.232.136.0/21",
  • "52.232.154.0/24",
  • "52.237.192.0/18",
  • "52.239.130.0/23",
  • "52.239.226.0/24",
  • "52.245.16.0/22",
  • "104.44.90.64/26",
  • "104.44.93.96/27",
  • "104.44.95.48/28",
  • "104.46.29.0/24",
  • "104.46.30.0/23",
  • "104.209.80.0/20",
  • "104.210.64.0/18",
  • "191.238.66.0/23",
  • "191.239.64.0/19",
  • "2603:1010::/46",
  • "2603:1010:5::/48",
  • "2603:1010:6::/48",
  • "2603:1016:1400:60::/59",
  • "2603:1016:2402::/48",
  • "2603:1016:2500:c::/64",
  • "2603:1017:0:60::/59"

You only need to add the IP ranges of the Region that your Azure DevOps instance sits in.

You can find the region that your Azure DevOps instance sits in by following the article below:

You can retrieve the list of Azure IP Ranges and Service Tags from the following Microsoft JSON file:

Note: These IP ranges can change and update, depending on Microsoft removing and adding new datacenter capability, it is always worth rechecking the list if you find you start having problems with intermittent connectivity to check whether new ranges have been added that haven't been whitelisted.

Failed to delete the private endpoint. Error: Call to Microsoft.Storage/storageAccounts failed

· One min read

Issue Description

Failed to delete the private endpoint. Error: Call to Microsoft.Storage/storageAccounts failed

Root Cause

Azure Backup locks the storage account when you configure protection for any file share in the corresponding account. This provides protection against accidental deletion of a storage account with backed-up file shares.

Resolution

In my case, the Storage account I was attempting to remove the Private Endpoint from was an Azure File Sync storage account, that had Azure File Shares that were getting Backuped Up.

  • Found and removed the lock on the storage account
  • Then successfully delete the private endpoint

More info

Generally, it is recommended that keep the lock taken on the storage account by Azure Backup. If you delete the lock, your storage account will be prone to accidental deletion and if it's deleted, you'll lose your snapshots or backups.

https://learn.microsoft.com/en-us/azure/backup/backup-afs#best-practices

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources