Do’s and don’ts concerning security for Identity part 6

Continuing with the do’s of Identity and supposing that you are in part of your journey that you have either Hybrid or fully cloud-based identities.

In the last part I covered how you can create your own roles and use Privileged Identity Management and Privileged Access Groups to secure the existing and new roles.

And also how to use that group to make an M365 Group and keep the communication between the corresponding admins.

In this part we will see how to secure your applications with Conditional access and other methods.

Create custom security attributes

This feature is currently under Preview but it can help you with the following:

  • Extend user profiles, such as add Employee Hire Date and Hourly Salary to all my employees.
  • Ensure only administrators can see the Hourly Salary attribute in my employees’ profiles.
  • Categorize hundreds or thousands of applications to easily create a filterable inventory for auditing.
  • Grant users access to the Azure Storage blobs belonging to a project.

And you can enable it to the assets:

  • Azure AD users
  • Azure AD enterprise applications (service principals)
  • Managed identities for Azure resources

To good with Custom security attributes is that they are available tenant-wide​, support different data types (Boolean, integer, string​), you can add single or multiple values or user-defined free-form and predefined values

You can also assign custom security attributes to directory synced users from an on-premises AD.

How to create them?

You can create them from https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/CustomAttributesCatalog

Then use them with …

Filtering permissions for applications

Custom security attributes must be managed by delegated users since they are security-sensitive. Custom security attributes do not even have default permissions for global administrators.

Users who handle or report on these attributes should be given one or more of the following roles.

Role nameDescription
Attribute assignment administratorAssign custom security attribute keys and values to supported Azure AD objects.
Attribute assignment readerRead custom security attribute keys and values for supported Azure AD objects.
Attribute definition administratorDefine and manage the definition of custom security attributes.
Attribute definition readerRead the definition of custom security attributes.

Where to enable?

When you create a new Conditional access policy, you will find it under Cloud apps or actions.

But you could also …

Use Conditional Access authentication context

Instead of only at the app level, Conditional Access authentication context (auth context) enables you to apply specific controls to sensitive data and actions. While reducing user friction, making users more productive, and increasing the security of your resources, you may improve your Zero Trust policies for least privileged access.

You need to have E5 licenses to use context with SharePoint sites.

How to create?

Create context from CA control plane.

Then create a new policy

And open Compliance portal and assign the policy https://compliance.microsoft.com/informationprotection?viewid=sensitivitylabels

Or with PowerShell

And now when we are talking about Conditional access, we can also talk about MFA. Did you know that …

On-premises MFA is deprecating

This was excepted move from Microsoft and makes complete sense. Multifactor authentication requests will no longer be supported after September 30th 2024, which could result in authentication failures for your organization.

What can I do?

You can setup MFA NSPS extension and use the migration tool to transfer your users MFA methods to the cloud.

See more from my previous post.

And once your transform is done, how about to …

Enable Secure authentication methods

For push notifications in Microsoft Authenticator in all tenancies, number matching is a nice illustration of protection for an authentication technique that is currently optional. Customers have the option to enable or disable number matching for push notifications for users and groups in Microsoft Authenticator. Users cannot opt out of number matching, which is already the default behavior for passwordless alerts in Microsoft Authenticator.

Where to enable?

What Microsoft Managed is?

Microsoft Managed means Azure AD can enable or disable protection based upon the current landscape of security threats. Customers can choose whether to allow Microsoft to manage the protection. They can change from Microsoft managed to explicitly make the protection Enabled and not mentioning to Disabled as this will be enabled by default in 27th of February 2023

And also use …

Identity risk protection

Microsoft’s Identity Protection combines the knowledge it has gained from its roles in gaming with Xbox, enterprises with Azure Active Directory, and the consumer market with Microsoft Accounts to safeguard your users. Microsoft analyzes trillions of signals every day to spot risks and defend consumers.

User-risk

Identity Protection performs a real-time analysis of hundreds of signals during each sign-in and determines a sign-in risk level, which expresses the likelihood that the particular authentication request isn’t permitted. After Conditional Access receives this risk level, the organization’s specified policies are reviewed.

Sign-in risk

By examining user account signals, Identity Protection determines a risk score depending on the likelihood that the user has been compromised. Identity Protection will evaluate these signals to determine the user risk level if a user exhibits dangerous sign-in behavior or if their login credentials have been compromised.

Where to enable?

You can enable it with Conditional access for enforcement.

And enforce MFA if you chose User and Sign-in risks as conditions Authentication strengths

If you choose “Require password change” you can only use user-based risks.

And to monitor your users with Identity protection Overview page.

If you want to see more on what are the different detection methods for risks.

Service Principals aka Workloads

But you can also see the risky behavior from your App registrations, they can be used to escalate permissions if not protected correctly.

With Conditional access you Block and Grant access based the the risk detection

And more information here,

Closure

In this part we discovered how we can protect your applications from leaking content. Keep your Identities secure and how to keep using MFA after on-premises MFA Server will not work anymore.

Once you have protected your users and admins, it will be equally important to protect your applications for external threats.

In the next part more Identity do’s and don’ts, Stay tuned!

Links to previous parts

Hackers don’t break in – they log in.

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *