Azure Active Directory

Step-by-Step Guide: How to use Azure AD custom attributes with user flows ?

Attributes can explain an object more precisely. Active Directory object types have predefined attributes which can use to store values and use later (query) when required. Active Directory schema also accepts custom attributes. Based on business requirements some time organizations will have to introduce custom attributes to object classes. On most occasions, it is related to application integration requirements with Active Directory. If it’s a hybrid environment, it may also require syncing these custom attributes values with Azure AD. In one of my previous blog posts, I explained how we can sync custom Active Directory attributes with Azure AD – Step-by-Step Guide: How to sync Custom Active Directory Attributes to Azure AD?
But this is for corporate users. In certain situations, we may also need to collect attributes values for guest users. As an example, let’s assume we have an application that is open for guest access. We enable self-signup process for the guest users. Each guest user is issued with an organization id and unique user token value. We need to collect this information during sign-up so we can identify the users based on the organization. However, there are no such attributes available in Azure AD. Then how we can do this? We can create custom attributes in the Azure portal and use them with user flows now. This will allow collecting these custom attributes values during the guest user sign-up process and storing data in Azure AD. Then later we can use Microsoft Graph API to read/update these values as necessary. In this blog post, I am going to demonstrate how we can add custom attributes to user flow.

Create Custom Attributes

In my demo environment, I have an enterprise app(rebeladminapp01) which is allowed for guest user access. This is already configured as an enterprise app in Azure AD. During the guest user sign-up for the first time, I like to collect values for two attributes called, “Organization ID” and “User Token“. These will help later for the user identification process.
Before we use these custom attributes first, we need to add those to Azure AD. To do that,

1) Login into Azure as Azure AD Administrator
2) Go to Azure Active Directory | External Identities

3) Then click on Custom user attributes

4) This will list down the list of built-in attributes. Click on + Add to create a new attribute.

5) In the new window, type the name of the attribute and provide the data type. It is also recommended to a provided brief description of the attribute for future references.

After the settings are in place, click on Create.

6) Using the same method, I created the second custom attribute I needed.

Step-by-Step Guide: How to sync Custom Active Directory Attributes to Azure AD?

Active Directory schema accepts custom attributes. Based on business requirements some time organizations will have to introduce custom attributes to object classes. On most occasions, it is related to application integration requirements with Active Directory. In one of my previous blog posts, I explained how we can add a custom attribute to Active Directory. You can access it using https://www.rebeladmin.com/2017/11/step-step-guide-create-custom-active-directory-attributes/

In a hybrid setup, Azure AD Connect can sync attribute values from on-premise Active Directory to Azure AD (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized). Apart from default attributes, sometimes there can be business requirements to sync custom Active Directory attributes to Azure AD. We can sync these custom attributes to Azure AD by using the Azure AD Connect “Directory extension attribute sync” feature.

In this demo, I am going to demonstrate how to sync the custom Active Directory attribute to Azure AD. To simplify the process, I already installed Azure AD Connect and configure it to sync. I also created a custom AD attribute called “nINumber” and added it to the user class.

Figure 1 : Custom Attribute Values

Figure 2 : Add attribute to user class

Figure 3 : Custom Attribute under user account

Let’s go ahead and see how we can configure Azure AD Connect to sync custom attributes. [Read more…] about Step-by-Step Guide: How to sync Custom Active Directory Attributes to Azure AD?

Step-by-Step Guide: How to configure user risk-based Azure conditional access policies?

In my previous blog post, I explained how to set up sign-in risk-based Azure conditional access policy. This article can be accessed using this link. As I explained in the article, sign-in risk is calculating based on user access behavior. If the user access behavior is flagged as risky, most probably the user account is also compromised. Most of the time, these compromised accounts are sold or shared on the dark web. Now with help of Microsoft, we can check if the corporate accounts are appearing in risky places. Microsoft uses various sources to identify risky user accounts. Such as,

Public paste sites
Dark web research groups
Law enforcement agencies

We can use Azure conditional access policies to verify if the sign-in request is coming from a known compromised account. User account risks are calculated offline, which means it can take 2- 24 hours to appear in reports.
Let’s go ahead and see how we can create a user risk-based Azure conditional access policy.

Configure Azure conditional access policy

1. Log in to Azure Portal (https://portal.azure.com/) as Global / Security / Conditional Access Administrator
2. Then go to Azure Active Directory

3. On the Azure Active Directory page click on Security

4. On the Security Home page, click on Conditional Access

5. Then click on + New Policy

Step-by-Step Guide: How to configure Sign-in risk-based Azure conditional access policies ?

Some time ago I wrote an article about sign-in risk-based conditional access policies. But things have been changed over time and I thought it is time to update it with new content.

Let’s assume we have a web application that is published via the internet. To access the services, the user has to provide a user name and password. If one of the users’ accounts compromised, how the system can differentiate legitimate access and illegal access? From the system’s point of view, as long as someone provides a valid user name and password system will allow access. But if we can analyze user access behaviour and detect anomalies, potentially we will be able to detect illegal access attempts. As an example, let’s assume the user is always log in from Canada. The user logged in to the system at 10 am successful. By 11 am the system detects another authentication attempt from UK for the same user. As we can see this behaviour is suspicious and if the system can detect this automatically, we can prevent a possible illegal access attempt.

Sign-in risk-based Azure conditional access policies help organizations to review user sign-in behaviours and detect risks. Then, based on risk levels, organizations can either block the user or enforce actions such as multi-factor authentication to prove their identity.
Azure categorizes sign-in risks into four levels.

High
Medium
Low
No risk

We can use one or more sign-in risk levels with a conditional access policy.

Due to security reasons, Microsoft does not provide exact details about how the risk levels are calculated. However, Microsoft says the following events contribute on risk level calculation.

Risk Detection Type	Description	Detection Type
Anonymous IP address	This risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN)	Realtime
Atypical travel	This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behaviour.	Offline
Malware linked IP address	This risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server.	Offline
Unfamiliar sign-in properties	This risk detection type considers past sign-in history (IP, Latitude / Longitude and ASN) to look for anomalous sign-ins.	Realtime
Password spray	A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been performed.	Offline
Admin confirmed user compromised	This detection indicates an admin has selected ‘Confirm user compromised’ in the Risky users UI or using risky Users API.	Offline
Malicious IP address	This detection indicates sign-in from a malicious IP address.	Offline
Suspicious inbox manipulation rules	This detection is discovered by Microsoft Cloud App Security (MCAS). This detection profiles your environment and triggers alerts when suspicious rules that delete or move messages or folders are set on a user’s inbox.	Offline
Impossible travel	This detection is discovered by Microsoft Cloud App Security (MCAS). This detection identifies two user activities (is a single or multiple sessions) originating from geographically distant locations within a time period shorter than the time it would have taken the user to travel from the first location to the second, indicating that a different user is using the same credentials.	Offline

Source : https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#user-risk

As we can see above, there are two detection types. Realtime detection will take 5-10 minutes to show the results. Offline detection can take up to 24 hours to show the results.
Let’s go ahead and see how we can create a conditional access policy.

Configure conditional access policy

1. Log in to Azure Portal (https://portal.azure.com/) as Global / Security / Conditional Access Administrator
2. Then go to Azure Active Directory

3. On the Azure Active Directory page click on Security

Step-by-Step Guide: How to setup Facebook federation with Azure AD?

Facebook federation with Azure AD allows external users to use their Facebook accounts to access corporate applications. In this demo, I am going to demonstrate how we can initiate federation with Facebook.

Before start configuration, make sure you have a valid Azure AD Subscription, an Application published through Azure AD, and a Facebook account.

Enable Self-service sign-up for guest users (preview)

Before we initiate federation with Facebook, we need to enable Self-service sign-up. To do this,

1. Log on to Azure Portal as Global Administrator
2. Click on Azure Active Directory

3. On the Azure AD properties page, click on User settings

4. Then under External Users, select Manage external collaboration settings

5. In the External collaboration settings page, Set the Enable guest self-service sign up via user flows (Preview) option to Yes. Then to apply settings click on Save.

Azure Active Directory

Step-by-Step Guide: How to use Azure AD custom attributes with user flows ?

Create Custom Attributes

Step-by-Step Guide: How to sync Custom Active Directory Attributes to Azure AD?

Step-by-Step Guide: How to setup Facebook federation with Azure AD?

Enable Self-service sign-up for guest users (preview)

Recent Posts

About Rebeladmin.com

Azure Active Directory

Create Custom Attributes

Configure Azure conditional access policy

Configure conditional access policy

Enable Self-service sign-up for guest users (preview)

Footer

Recent Posts

About Rebeladmin.com

Social Media

Tags