What is a “Custom Security Attribute”
Simply, the custom security attribute lets you stick a Post-It Note with anything you want written on it onto an Enterprise app, a user, or any other Azure or Azure AD resources. Once you’ve tagged it, you can use that tag for things like applying conditional access policies or exempting apps or users from the policy.
How are Custom Security Attributes used with Azure Active Directory Conditional Access policies
Custom security attributes allow an administrator to tag an application or web service with a special flag. This flag could be used like a group membership for applications, or it can be used to apply policies to an application which would not normally be subject to conditional access rules like native/mobile App registrations like those used with Jamf Connect.
In these examples, we will:
- Use a custom security attribute to mark an exception to a policy to require multi-factor authentication for the Jamf Connect application to avoid erroneous login “failures” which could mark a user login as risky in Microsoft Entra.
- Use a custom security attribute to make a policy that requires that a user have a device marked as compliant and managed if accessing a service deemed to be a medium or high risk to the organization.
- Use a custom security attribute as the scope of a conditional access policy that blocks access to a high risk application if the originating IP address range is coming from an unexpected country outside of our normal business operations.
Navigation
Conditional access policies are located in portal.azure.com under the service named Azure AD Conditional Access. Custom security attributes are created in the service named Azure Active Directory and are applied to applications in Azure Active Directory under Enterprise applications.
Applying an exception to an policy created for “All cloud apps”
Policies applied to All cloud apps provide a simple “catch everything” rule that applies a policy to all current and future applications used with Azure AD. Often, an administrator will create a policy to apply minimum security requirements for the organization like requiring multi-factor authentication or disabling access for basic auth.
Some applications, like Jamf Connect’s periodic checking of a user’s macOS password against Azure AD, may need to be exempted from this policy.
Navigate to portal.azure.com → Azure Active Directory Conditional Access. Your organization may have one or more policies already created, or you can create default policies based on templates. In this example, we will look at the default policy created by a template to apply multi-factor authentication to all users for all services called “CA004: Require multi-factor authentication for all users”.
If we wanted to apply an exclusion to the policy for the Jamf Connect application, we would see the app does not appear in a standard list of Select excluded cloud apps. Because the App registration is designed for desktop/mobile applications, conditional access policies do not show these apps in the list. This is because Conditional Access policies set requirements for accessing cloud services and APIs – therefore they are applied to desktop apps when those desktop apps try to access a protected resource, not simply sign in themselves without any attempt to access a resource.
We can, however, apply a custom security attribute to the Jamf Connect app to assign it as an app that should be exempt from this policy. Select Edit filter (Preview) and configure the filter to use our caExemptFromMFA attribute to look for all applications where the value equals Exempt.
Select Done and Save the policy to continue.
Testing the policy
While in Report-only mode, conditional access policies appear in the list of evaluated rules in a Sign-on log, however the enforcement is skipped. This is important to test your policy thoroughly to avoid being locked out of the Azure portal without recourse. Consider applying the policy to only a test user.
To confirm that the policy was evaluated or skipped, in this case attempt a login to the Jamf Connect application either with the Jamf Connect menu bar app, the Jamf Connect Configuration app, or logging into a Mac configured with Jamf Connect login.
After a short time, the sign-in logs will appear for the login attempt. Navigate to Azure Active Directory → Enterprise apps and look for the name of your Jamf Connect app. Select Sign-in logs from the navigation bar under the section marked Activity.
Note: Logs may take up to 2-5 minutes to appear from the time of sign-in to the application. See Microsoft's documentation here for more information.
Selecting the individual sign-in attempt reveals additional information about policies applied to the sign-in. Select the tab Report-only to determine if the policy was applied as expected.
As shown in the Report-only tab, the policy was not applied. Selecting the … option shows further details.
Applying a conditional access policy to require a private access network based on risk
In addition to templates, Azure Active Directory Conditional Access can create complex policies that can restrict access based on a country location or an originating IP address range. This can be used in conjunction with tools like Jamf Trust and private network routing rules.
Navigate to Azure Active Directory Conditional Access and select the option for Named locations.
In this scenario, we will create a list of known egress endpoints for the Jamf Trust application. Select + IP region location to add a list of IP addresses.
IP address ranges can be named and marked as “trusted” locations for additional conditional access rules. For Jamf Trust, a list of all egress locations can be found here.
Administrators can also upload a list of IP addresses in a text file.
Tip: Save the list of IP addresses you will use for your Jamf Trust private network egress points in CIDR format as a csv text file. Open the text file in your favorite text editor and do a find/replace to replace the comma , character with a new line character. Upload this new txt file add all the Jamf Trust endpoints.
After defining a location, select Policies to create a new conditional access policy. In this example, we already marked our sample application, an instance of Jamf Pro, as needing high security.
We’ll select our Cloud apps or actions section, apply the policy to Cloud apps, and instead of selecting individual apps from a list instead use our Edit filter option and apply to all applications where the security team determined the risk to be medium or high.
Note in the filter, you can select complex logical evaluations of the attributes with and/or statements. In this case, because we want to apply to both Medium and High risk applications, we select the option to pick anything that is marked either Medium or marked High.
In the section called Conditions, we have several other options like Locations:
(Note: Jamf Private Access is now referred to as Zero Trust Network Access)
In this scenario, we’re going to BLOCK users from accessing the application UNLESS they were in a trusted location. Therefore we select to include Any location and we put an exception for either selected locations or All trusted locations if we marked our location as trusted.
In the Access controls section, select the section for Grant and select to Block access:
Unless a user is coming in from a known, trusted IP address range, any application marked as high or medium risk will now be blocked.
Applying a conditional access policy to block access to high risk applications from specific country IP address ranges
In addition to self defined IP address ranges, Microsoft Azure Active Directory Conditional Access can set up a Named Location based on estimates of which IP addresses are assigned to which geographical locations.
In this scenario, we would like to block a list of countries from accessing our resources with a general block policy. Also available is a wildcard of “unknown” IP address ranges which may add additional restrictions.
Navigate to Azure Active Directory Conditional Access → Named locations. Select + Countries Location to create a new set of locations. In this scenario, we will make a list of currently embargoed countries and select multiple locations.
Using the search feature allows us to search for specific countries and regions. Select as many countries as you wish to block. In this example, we also selected the “unknown” IP address region as well. Select Save to save the list of countries.
Navigate to Azure Active Directory Conditional Access → Polices. Create a new policy and name it something that fits its purpose - “Block access from embargoed countries” for example. Under Users or workload identities, select the option for All users. Under Cloud apps or actions apply the policy to Cloud apps and Select apps. A new option will appear for Edit filter.
We can now select a group of applications that have been tagged by our security team as being high risk. Configure the filter to select our application risk level tag, operator is equals, and the value is set to High. Select Done to save and continue to Conditions.
Conditions allow us to add additional requirements for the policy like checking the originating IP address under locations. We can pick a defined location like our embargoed countries list:
Under Access controls, we will want to mark traffic as blocked if originating from an embargoed country:
Create the policy and watch logs while in Report-only mode to validate that no organization login attempts are coming from an unexpected resource.
Once your security team has determined that no IP addresses used by the organization fall under the login range, switch the policy to On to automatically block all logins from the country IP address range. Note this filter is not perfect. For maximum security, consider using a tool like Jamf Trust and Zero Trust Network Access to restrict logins to specific trusted IP address ranges instead of relying on a block policy.
5 Comments