Author: Carlos A Lopez (Twitter: @CLopezDC)

Enable self-service Password reset with Azure AD Premium (Best Practice 4/10)

Carlos A Lopez (Twitter: @CLopezDC) Office365

Self-Service Password Reset (SSPR) enables users to quickly get unblocked and continue working no matter where they are or the time of day. By allowing users to unblock themselves, your organization can reduce the non-productive time and high support costs for most common password-related issues.

Best practice: Set up self-service password reset (SSPR) for your users. Use the Azure AD self-service password reset feature.

Best practice: Monitor how or if SSPR is really being used. Monitor the users who are registering by using the Azure AD Password Reset Registration Activity report. The reporting feature that Azure AD provides helps you answer questions by using prebuilt reports. If you’re appropriately licensed, you can also create custom queries.

Best practice: Extend cloud-based password policies to your on-premises infrastructure. Detail: Enhance password policies in your organization by performing the same checks for on-premises password changes as you do for cloud-based password changes. Install Azure AD password protection for Windows Server Active Directory agents on-premises to extend banned password lists to your existing infrastructure. Users and admins who change, set, or reset passwords on-premises are required to comply with the same password policy as cloud-only users.

Enabled the functionality of Conditional Access (Best Practice 3/10)

Carlos A Lopez (Twitter: @CLopezDC) AAD Connect, Azure, Cloud Security , , , , ,

The idea of the cloud is to allow users to access the resources by using a variety of devices and apps from anywhere at any time. Since the perimeter of the network is no longer the edge but the identity, IT administrators face the challenges, therefore controlling the devices and making sure that these devices meet the standards for security and compliance, is a very effective way to protect the cloud implementation.

The trade between security and productivity here plays an important role. IT admins need to think about how a resource is accessed before they can make a decision about access control. With Azure AD Conditional Access, IT administrators can address this requirement. With Conditional Access, IT admins can make automated access control decisions based on conditions for accessing your cloud apps.

Best practice: Manage and control access to corporate resources. Configure Azure AD Conditional Access based on a group, location, and application sensitivity for SaaS apps and Azure AD–connected apps.

Best practice: Block legacy authentication protocols. Attackers exploit weaknesses in older protocols every day, particularly for password spray attacks. Configure Conditional Access to block legacy protocols. See the video Azure AD: Do’s and Don’ts for more information.

Image result for conditional access

 

 

*Image from Official Microsoft Website – Credit: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Types of conditions:

  • Sign-in risk: Azure AD Identity Protection detects sign-in risks. How do you restrict access if a detected sign-in risk indicates a bad actor? What if you would like to get stronger evidence that a sign-in was performed by the legitimate user? What if your doubts are strong enough to even block specific users from accessing an app?
  • Network location: Azure AD is accessible from anywhere. What if an access attempt is performed from a network location that is not under the control of your IT department? A username and password combination might be good enough as proof of identity for access attempts from your corporate network. What if you demand a stronger proof of identity for access attempts that are initiated from other unexpected countries or regions of the world? What if you even want to block access attempts from certain locations?
  • Device management: In Azure AD, users can access cloud apps from a broad range of devices including mobile and also personal devices. What if you demand that access attempts should only be performed with devices that are managed by your IT department? What if you even want to block certain device types from accessing cloud apps in your environment?
  • Client application: Today, you can access many cloud apps using different app types such as web-based apps, mobile apps, or desktop apps. What if an access attempt is performed using a client app type that causes known issues? What if you require a device that is managed by your IT department for certain app types?

Enable single sign-on for the Microsoft Cloud and all other Cloud Services (Best Practice 2/10):

Carlos A Lopez (Twitter: @CLopezDC) Office365

We live now in a mobile-first, cloud-first world and to simplify the authentication process it is recommended to enable single sign-on (SSO) to devices, apps, and services, allowing the users to access cloud resources from anywhere. The challenge we have seem with the end-users it’s that when you have multiple identity solutions to manage, this becomes an administrative problem not only for IT but also for users who have to remember multiple passwords. By using the same identity solution for all your apps and resources, you can achieve SSO. And your users can use the same set of credentials to sign in and access the resources that they need, whether the resources are located on-premises or in the cloud.

Best practice: Enable SSO. Azure AD extends on-premises Active Directory to the cloud. Users can use their primary work or school account for their domain-joined devices, company resources, and all of the web and SaaS applications that they need to get their jobs done. Users don’t have to remember multiple sets of usernames and passwords, and their application access can be automatically provisioned (or deprovisioned) based on their organization group memberships and their status as an employee. And you can control that access for gallery apps or for your own on-premises apps that you’ve developed and published through the Azure AD Application Proxy.

Organizations that don’t create a common identity to establish SSO for their users and applications are more exposed to scenarios where users have multiple passwords. These scenarios increase the likelihood of users reusing passwords or using weak passwords.