Identity Management: Password management and on-prem protection | Azure Active Directory


[MUSIC] Oana Enache: Welcome back to the Azure AD Architecture Deep Dive Series. I’m Oana Enache and I’m a Program Manager on the Azure AD Engineering team at Microsoft. Grace Picking: Hi. My name’s Grace Picking and I’m also a Program Manager on the Azure AD Engineering team here at Microsoft. Oana: We are part of the Customer Experience Program and we help enterprises and businesses from all over the world to deploy our service and get to the cloud. We get a lot of questions about how Azure AD works under the hood, which we will share with you throughout this architecture series. In this video, you’re going to learn how Azure AD Password Protection can help your organization eliminate weak passwords on-premises. Grace: So, my first question is, why should customers care about enabling Azure AD Password Protection for their on-prem Active Directory? Oana: There are many benefits customers get when they enable Azure AD Password Protection for on-premises. Most of our customers live in a hybrid environment and they are all confronted with the same issue—users tend to choose weak or variations of weak passwords, something like Winter2020! would comply with the general Active Directory password policies and would normally get accepted, however, these passwords are predictable and easy to guess by attackers. In a previous video, we talked about how Azure AD Password Protection helps your organization by detecting and blocking these known weak passwords and their variants and how some organizations may want to improve security even further by blocking additional weak terms that are specific to their organization. Such terms can include brand names, product names, different locations or company specific internal terms. With Azure AD Password Protection for on-premises, the same security benefits get extended to your on-prem Active Directory environment via the installation of lightweight on-prem infrastructure. And then the same checks will be performed during a password change or reset regardless of how the flow was initiated, from the SSPR portal or via the Windows login screen. Grace: That sounds great. I’m sure my customers would be really interested in learning more about how the same logic applies for their on-prem passwords. So, how does that work? Oana: There are three main players involved in this process. First, we have the Azure Active Directory Password Protection Service. This service runs on any domain join machine in the current Active Directory forest and its role is to retrieve the most recently configured password policy whenever a request is received from a domain controller from any domain in the forest. The proxy service instance advertises itself to the domain controllers in the forest by creating the service connection point object in Active Directory. Second, we have the DC Agent service. This service is responsible for periodically calling the Azure AD Password Protection Proxy Service to retrieve new versions of the password policy from Azure AD. And then we have the DC Agent Password Filter DLL. This DLL receives password validation requests from the operating system and forwards them to the Azure AD Password Protection DC Agent Service that’s running locally on the domain controller. The DC Agent of a domain controller locates an Azure AD Password Protection Proxy Service by querying the forest for proxy service connection points objects. Here in Step 1 when an available proxy service is found, the DC Agent sends a password policy download request to the proxy service which in turns sends the request to the Azure AD backend service. During Step 2, the Azure AD backend service retrieves the policy from the core store and then returns the response. In Step 3 after the DC Agent Service receives a new password policy from Azure AD, the service stores the policy in a dedicated folder at the root of its domain svsvol share. The DC Agent Service checks the age of the current local available policy. This process kicks in every hour. If the policy’s older than one hour, then the DC Agent will request a new policy from Azure AD via the proxy service as we described previously. If the current policy is not older than one hour, then the DC Agent will continue to use that policy. Grace: All this sounds great, but how does this protection come into play when a user tries to change their password on-premises? Oana: So here in Step 4, we have a user who initiates the password change request. This can be a user going to Control Alt Delete on their laptop or perhaps we have an admin who goes in the Active Directory users and computers snap-in and attempts to reset the user’s password. Then in Step 5, the Password Filter DLL of the DC Agent receives the user validation request from the operating system and forwards it to the DC Agent Service that’s running locally on the domain controller. Then in Step 6, the DC Agent Service Password Protection receives the password validation request from the password fields or DLL of the DC Agent and processes it by using the current locally available password policy. At this stage, our Cloud Password Protection kicks in. Cloud Password Protection includes the combination of the Microsoft Global Banned Password List and per-tenant and Custom Banned Password List. As part of this process, the new password is normalized, so all upper case letters are changed to lower case, and then we perform common character substitutions, such as dollar for S, @ for A or 1 for L. Then on the normalized password, we do matching to identify whether that password is found on either Microsoft’s Global Banned Password List, which it sorts from real world security telemetry on actual password spray attack, or on the Custom Banned Password List and then we score the password by giving one point to each banned password that is found in a user’s password and one point for each remaining character. To get accepted, a password must have a score of five points or more. The end result is that it will efficiently detect and block millions of the most common weak passwords from being used in your enterprise. Customers who choose to add organization specific terms to the Custom Banned Password List also benefit from the same algorithm. If successful, then the password is finally changed by Azure AD. It’s important to note here that the traditional Active Directory policies are also evaluated as part of this decision. Grace: Some of my customers already have other password filter based products. Can they still use Azure AD Password Protection? Oana: Absolutely. Azure AD Password Protection will act as a supplement to the existing Active Directory password policy, not a replacement. This includes any other third party Password Filter DLLs that may be installed. Active Directory will always require that all password validation components agree before accepting a new password. Grace: Excellent. Most of my customers also want to be able to understand what is the impact before enforcing a new feature in their production environments? How can customers validate they’ve got the implementation right before users start calling the help desk? Oana: Now, by default, Azure AD Password Protection for on-premises runs in audit mode during the initial setup. This means that passwords which would normally get rejected by the Global and Custom Banned Password Lists can continue to be set and passwords that would be blocked are recorded in the event log. This audit stage turns out to be eye opening for many organizations and customers find out that they need to improve user education and how to choose more secure passwords. Some organizations were even able to determine that more than 50% of the passwords that users chose during a password change or reset were weak and easily guessed by attackers. Grace: Wow. That’s very impressive. So, here’s what I’m taking away for my customers. Once Azure Active Directory Password Protection for on-premises is deployed and enforced, all users receive equal security benefits as cloud only users or users changing their password through the Azure AD portal. This is a great way for customers to defend against the commonly used password spray attacks by modernizing their password policies. And it can significantly reduce the attack surface. The list of these commonly used passwords is a dynamic global list that is constantly updated based on new attacks and is one of the items used by Azure Active Directory Password Protection Service. Oana: That sounds right. We hope you found this video useful. We will be adding videos on different topics like authentication provisioning, governance, and many more. If you want to get a copy of the diagrams we used today or want to give us feedback and help us figure out what to cover next, please check out the links in the description of this video. Thank you for joining us. [MUSIC]

Leave a Reply

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