Azure AD Conditional Access Policies - Go through

Conditional Access Policies – ( Azure AD Premium P1 or P2 feature)

As name suggests its policy based on certain condition which needs to met to access your organization resources or application if not then certain challenges need to fulfill  like MFA or Password reset or access blocked.

Conditional Access policies are enforced after the first-factor authentication has been completed. Conditional Access is not intended as an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but can use signals from these events to determine access.

Based on certain situations as defined below conditional access policies decide either to grant access or block access if grant then what else needed to confirm that you are who you say you are.

Situations –

·        User logging in with unknown location or not from office.

·        Organizations can create trusted IP address ranges that can be used when making policy decisions if request not coming from that range the Policy applies.

·        Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies.

·        Azure AD ID Protection can trigger the policy on case of Sign-in risk & many more.

Conditional Access Policies – Decisions:

Block Access – Off course that’s restrictive if you don’t want to provide access if conditions are odd.

Grant Access – In this situation, need to fulfill certain conditions like –

• Require multi-factor authentication
• Require device to be marked as compliant
• Require Hybrid Azure AD joined device
• Require approved client app
• Require app protection policy (preview)

Commonly applied policies -

Many organizations have common access concerns that Conditional Access policies can help with such as:

• Requiring multi-factor authentication for users with administrative roles
• Requiring multi-factor authentication for Azure management tasks
• Blocking sign-ins for users attempting to use legacy authentication protocols
• Requiring trusted locations for Azure Multi-Factor Authentication registration
• Blocking or granting access from specific locations
• Blocking risky sign-in behaviors
• Requiring organization-managed devices for specific applications

So as discussed above - Conditional Access policy is an if-then statement, of Assignments and Access controls. A Conditional Access policy brings signals together, to make decisions, and enforce organizational policies. Lets create and talk about all the components simultaneously.

Lets go to Azure Active Directory and click on Conditional Access as shown :- 

Once you hit the conditional access and you would landed on this page where it shows all the relevant components and add button for policy. (Shown Below)

Under Manage you will see Named location where you can define the region like you head-office or branches along with the IP range as a known location or secure location as shown below -

Next component is Terms of use which provides a simple method that organizations can use to present information to end users. You need to click on terms of use and click New terms.

Below is the template and you can even upload the pdf and all. To now more click below link - 

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/terms-of-use

Now lets click on New Policy at the top and check what all options we have and configure it with policy that would allow you to login without MFA if you are in head-office and if not the MFA.

Under assignment we have users and groups that you want your policy to apply , you can choose all or selected and we do have option to exclude as well. Be cautious because you can lock yourself out if you apply this to all user including yours that what the exclamation says at the bottom highlighted

The assignments portion controls the who, what, and where of the Conditional Access policy.

(below picture)

Second option that we have is cloud apps and you can choose cloud applications that will be subjected to the policy again be cautious it also include Azure portal if you choose all apps.

Now its time to define conditions and we have multiple conditions here to define. 

First one is Sign-in risk which comes from Azure AD ID Protection and the risk detection's generated there can influence your conditional access policies as shown below -

Now its time to define the locations -

Location data is provided by IP geolocation data. Administrators can choose to define locations and choose to mark some as trusted like those for their organization's network locations.

(below picture)

Next option is in preview - client apps (shown below)

By default Conditional Access policies apply to browser apps, mobile apps, and desktop clients that support modern authentication.

This assignment condition allows Conditional Access policies to target specific client applications not using modern authentication.

Now its time to check the Device state which is in preview -

This control is used to exclude devices that are hybrid Azure AD joined, or marked a compliant in Intune. This exclusion can be done to block unmanaged devices.

Now all conditioned defined and lets check the Access controls i.e. Block access and Grant access.

    The Grant control can trigger enforcement of one or more controls.

• Require multi-factor authentication (Azure Multi-Factor Authentication)
• Require device to be marked as compliant (Intune)
• Require Hybrid Azure AD joined device
• Require approved client app
• Require app protection policy

Session controls can limit the experience

Use app enforced restrictions

• Currently works with Exchange Online and SharePoint Online only.
  • Passes device information to allow control of experience granting full or limited access.

Use Conditional Access App Control

• Uses signals from Microsoft Cloud App Security to do things like:
  • Block download, cut, copy, and print of sensitive documents.
  • Monitor risky session behavior.
  • Require labeling of sensitive files.

If you worked on Powershell , you must be aware of what if ,  its exactly the same just to check if policy build is correct or applied correctly to the users

In below snippet you can see at the bottom "policies that would apply"

Alright folks so we at the end of this post and we learned what Azure Ad conditional access policy is how to create and apply ad what all are the components. Well this post is not all its just a pass through and if you want to know more please check the MS docs , reference link below 

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/

Azure AD SSPR "Self Service Password Reset" - Go through

Well as name suggest this is a great feature which gives you ability to reset your password rather calling service desk or bothering AD Admins.

Before we go ahead and see how to enable this feature, lets understand the pre-requisite of this feature first. We have few scenarios to understand with respect to password reset, change , unlock or write back incase of hybrid identity and their AD license requirement -

·        Self-Service Password Change for cloud users

o   I am a cloud-only user and know my password.

§  I would like to change my password to something new.

o   This functionality is included in all editions of Azure AD.

·        Self-Service Password Reset for cloud users

o   I am a cloud-only user and have forgotten my password.

§  I would like to reset my password to something I know.

o   This functionality is included in Azure AD Premium P1 or P2, Microsoft 365 Business, or Office 365.

·        Self-Service Password Reset/Change/Unlock with on-premises writeback

o   I am a hybrid user my on-premises Active Directory user account is synchronized with my Azure AD account using Azure AD Connect. I would like to change my password, have forgotten my password, or been locked out.

§  I would like to change my password or reset it to something I know, or unlock my account, and have that change synchronized back to on-premises Active Directory.

o   This functionality is included in Azure AD Premium P1 or P2, or Microsoft 365 Business.

Before people could register themselves for SSPR we need to enable this feature and to enable to we need to go to Azure Active Directory and select password reset as shown.

Once you hit the password reset you would landed into the below page where under settings you could see whether you want to enable this feature for selected users or all or none hence select accordingly. (shown below)

We have selected all users in our demo as shown above and now we need to set the authentication method you can select 1 or 2 methods. We have selected Email and mobile phone as authentication methods and we have selected 1 in no. of methods required to reset. as shown below -

Most important thing is we are now registering all users to select there authentication method for SSPR so make sure you have send the communication to all of your users. As shown in below snippet we have 180 days to enable it.

Now we have enable the SSPR registration for all the users with email and mobile phone as authentication method and from now onward whenever user login they would get prompt to set this up as shown below -

Once you hit next you would see both the authentication method that we have selected. (shown below)

Now once you have selected the authentication method in SSPR and its time to check the registration hence click on cant access your account and it would ask you to verify id so that it could prompt you SSPR authentication method as shown below -

Below is the snippet where you would enter your ID and captcha -

Enter you mobile no. to receive the code for the verification and you can reset your password in the next screen.

Reference links below -

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-deployment

https://azure.microsoft.com/en-us/pricing/details/active-directory/

Azure AD Identity Protection - Go through

Azure AD Identity protection helps to Automated response to "risk and vulnerabilities" & you need AD P2 license.

Well as name suggests it helps to make your environment more secure by increasing the security of user identities by –

·        Detecting potential vulnerabilities affecting user identities. (user has history to login from certain place now if he logins in from other places or VPN instead of office )

·        Configuring conditional access policies to automatically respond to suspicious actions. ( this a wonderful feature that you can enable with conditions like asking for MFA if location is unknown or not in office)

·        Investigating suspicious incidents and resolving them automatically. (no constant auditing and overcome admin work and harden user identities)

What AD Identity Protection is?

Stolen user identities are the number one cause of security breaches. Attackers leverage phishing attacks and malware to gain access to systems. (Get emails from known places like MS and they ask your information and it could easily leak from allowing access to your phone when you install app. )

Admins must protect all identities , no matter the privilege level or low level and ensure that compromised identity do not gain access.

This typically involves full-time awareness and monitoring of all user identities. The administrative effort is huge and most of the time its completely reactive in nature.

Azure AD Identity protection removes much of this effort by providing comprehensive solution that is :- 

·        Proactively prevents compromised identities from accessing resources.

·        Provides recommendations to improve security by analyzing vulnerabilities, such as user and sign-in risk levels and risk events, as well as environmental factors

·        Notify admin of risk events.

·        Allows admin to create policies to automatically mitigate risk events.

Azure AD Identity protection Components: -

Lets understand these components one by one -

1)     Notifications

2)     Machine Learning

3)     Vulnerabilities

4)     Policies

5)     Risks

Machine learning – Azure AD uses ML to detect risk or anomalies or suspicious incidents which could indicate potentially compromised identities. 

Using this data. Identity protection generates reports and alerts, enabling you to evaluate the detected issues and take appropriate mitigation or remediation actions. 

This data also used when evaluating conditional access policies to determine automatic remediation of user or sign-in risks.

Vulnerabilities – are weakness in an environment that can be exploited by an attacker. 

Azure AD identity Protection identifies these vulnerabilities and presents then in the Overview Dashboard. Clicking on each one provides more information and recommendations on how to re-mediate them, strengthening the security score of the organization.

Policies – in order to take advantage of risks and vulnerabilities detected by Azure AD Identity Protection. There are three policies we can configure to automate responses to these potential threats.

  
1) MFA authentication registration policy –

·        This policy is used to require registration to the Azure MFA service.

·        The Azure MFA service should be configured beforehand.

·        User communication should occur before implementing this policy

  
2) User risk Policy

·        Automatically responds to a user risk (identity compromise)

·        Policy can be configured to block access to your resources or require a password change.

  
3) Sing-in risk policy

·        Used to react to suspicious actions that come along with the user sign-in

·        Can be configured to block the account or require MFA

Both policies User risk and sign-in risk work to automate the response to risk detection's in your environment and allow users to self-remediate when risk is detected.


If your organization wants to allow users to self-remediate when risks are detected, users must be registered for both self-service password reset and Azure Multi-Factor Authentication

Microsoft's recommendation is to set the user risk policy threshold to High and the sign-in risk policy to Medium and above.

Notifications – Azure AD ID Protection send two types of automated notification emails to help admin manage user risk and risk events.

1)     Users at risk detected email

Emails are sent per incident, risk levels and recipients are adjustable, email contains Users flagged for risk report. Once notification received user should immediately be investigated as only one email would be received 

1)     Weekly digest email

Email sent once a week to all Global administrators, security admins and security readers which contains a summary of new risk events & includes – User at risk, suspicious activities, detected vulnerabilities & links to the related reports in identity protection.

Risks –

 there are two type of risks Sign-in risk and user risk –

Sign-in risk means most likely the authentication request isn’t authorized by the identity owner.

·        Two evaluations of sign-in risk – Real time and aggregate sing-in risk.

User risk means most likely the identity is compromised & calculated by –

·        All risky sign-ins

·        All risky events not linked to a sign-in

·        The current user risks

·        Any risk remediation or dismissal actions

Types of risk events: -

·        Atypical travel

·        Anonymous IP addresses

·        Unfamiliar sign-in properties

·        IP addresses linked to malware

·        Leaked credentials

User sign-in flow can be traced in below snippet -

Azure AD ID Protection flow – As user tries to login AZ AD ID Protection uses all methods available to make up the service to determine whether it require MFA , change password , block or grant him access to his service. Flow chart below -

 Below are the snippets that you can follow as demo or to configure your Azure AD Identity protection. Steps involved in configurations are -

·        On-board Azure AD identity Protection.

·        Configure MFA registration policy (optional but recommended)

·        Configure User risk policy.

·        Configure sing-in risk policy.

·        Test the configurations.

   To utilize Azure AD ID Protection you should have Azure AD Premium P2 license & you need to on-board this from marketplace as shown below. 

Once you select Az AD ID Protection make sure the directory is the one that you want it for and click create. Once you click on Create it would be on boarded and you wouldn't get notification.

Now when you go to A Ad Id Protection you would see all the components that we discussed above and on overview you can find all the events generated due to policy in place under configure. 

Now lets configure MFA registration first so that you could utilize this during the user and sign-in risk policy creation. To configure this click on MFA registration >> and fill the information required in the snippet. Select the users that you want to register the MFA and you can also exclude Users.

Under Access its Challenging MFA hence select require Azure MFA registration as shown below

Once access is selected slide enforce policy to ON as shown and its all set for MFA registration. Below snippet also says MFA registration Policy only affects cloud-based Azure MFA. If you have MFA server it will not be affected.

Now its time to configure the User risk-policy just like MFA we need to select the users first and then choose the conditions when this policy would be applicable and finally under controls select the access action either blocked or password change. Below are the highlighted points.

Below snippet is of Conditions and Controls where we select which action in what conditions.

Now finally it looks like this when all the fields are configured and now enforce the policy by sliding it to ON.

Just like MFA and User risk-policy we will also define Sign-risk policy and it would look something like this after selecting all the fields but here we chose require MFA if condition matches.

Now we have defined all the policies and register MFA. In order to perform the demo we can used anonymous try to login with the help of  Tor browser and it should detect by Azure AD ID Protection and apply the relevant policy. Its more like if we try to access via Tor browser Azure AD ID Protection would consider this as a threat and if MFA is not enable then it would block the access and MFA is enable already that it would challenge the MFA to grant access. Below are the related snippets.

MFA is not enabled hence access is blocked as shown bwlow

          We are trying on MFA enabled User then this happens and you can opt for verify by MFA to get the access.

Since there is some activity and one of the user got blocked and another one challenged for MFA hence few events generated and those would show under Overview. You can see at the begining when we on-boarded this feature it was zero and now we got one.

We are all set and the policy defined to make the maximum use of this feature however we also configure alerts for these scenarios under settings -

Along with alerts we can also configure the weekly digest for Security admins and global admins.

Hope this would informative for you and below link is the source of information 

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