Do I Have Weak Passwords In My Organization...?

Hi Everyone,

 

Zoheb here again with my colleague Peter Chaukura from Microsoft South Africa and today we will be sharing some details on how we helped one of our SMC customers reduce the attack vector by enabling Azure AD Password Protection.

 

If you have not read the 1^st blog which covers the background do give it a read now before continuing here. How the Microsoft Mission Critical Team helped secure AAD

Hope you found the initial blog a valuable read.

 

Let me continue our story about Protecting your Passwords in Azure AD.

 

The Problem:

Through internal audits our customer had found that there is a high usage of “Common Passwords” in their organization. They discovered that password spray attacks were on the rise and had no solution other than the “password meets complexity requirements” setting under the password policy in their Active Directory environment.

 

This SMC customer urgently needed a way to block weak passwords from the domain and understand the usage of these weak passwords across the organization as well as the impact these may have.

In other words, they were looking to find out how many users have weak passwords in the organization before enforcing Password Protection in their environment.

 

The Solution:

As the Mission Critical Trusted Advisor, we stepped in and informed our customer that it is possible to block weak passwords by using Azure AD Password Protection. We also had the answer to their more critical question “is it even possible to view how many users have weak password in my organization?”

 

Before I share details on how we helped implement this, let us try to understand the basics of this feature.

 

Azure AD Password Protection detects, and blocks known weak passwords and their variants from a global Microsoft curated list. In addition, you can specify custom banned words or phrases that are unique to your organization. The on-premises deployment of Azure AD Password Protection uses the same global and custom banned password lists that are stored in Azure AD, and it does the same checks for on-premises password changes as Azure AD does for cloud-based changes. These checks are performed during password changes and password reset events against on-premises Active Directory Domain Services (AD DS) domain controllers.

 

There are two modes in Azure AD Password Protection as described below:

 

AUDIT MODE: Microsoft recommends that initial deployment and testing always starts out in Audit mode.

• Audit mode is intended to run the software in a “what if” mode.
• Each DC agent service evaluates an incoming password according to the currently active policy.
• “bad” passwords result in event log messages but are accepted.

 

ENFORCE MODE: Enforce mode is intended as the final configuration.

• A password that is considered unsecure according to the policy is rejected.
• When a password is rejected by the Azure AD password protection DC (domain controllers) Agent, the end user experience is identical to what they would see if their password were rejected by traditional on-premises password complexity enforcement.

 

Read more details here. Ban-Weak-Passwords-on-premises

 

The Solution

 

Our SMC customer was specifically looking at enabling Password Protection and some mechanism which can give more details on the present weak password status before enforcing “Azure AD Password Protection” feature.

 

We told them events has more details. to see the sample events please refer the blog below. https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-monitor

 

Peter also gave an option of Get-AzureADPasswordProtectionSummaryReport cmdlet generates a summary report as shown.

 

But customer was not happy with the above output and they were looking for something more and detailed, they asked Peter that they needed something with the below capabilities: -

1. Status of Weak Passwords across Domains in Forest
2. Password Compliance report based on Microsoft banned Password list.
3. User details who have weak passwords
4. Did users change Password or reset?
5. Password Policy count
6. Visual dashboard which can be updated regularly/Automatically.

 

Clearly nothing is built by default which can help us give a visual view of organization “Password compliance".

 

So, Peter helped build PowerBI Dashboards to ingest data extracted from domain controller event logs \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin.

 

NOTE: This dashboard gets fully populated only after all/most of the users have reset/Changed password at least once, so you can assume this may take a full Password Life cycle of your organization to get an overview of weak Passwords in your organization.

 

The Custom Azure AD Password Protection Power BI Dashboard

 

How do we collect the data and build the dashboard?

 

• We collected events(10024, 30010) from all domain controllers where the Azure AD Password Protection DC agent is installed and exported them into a csv file.
• The collection of event log entries is done via a PowerShell script that is configured to run a scheduled task.
• Further ingests the Csv into a Power BI dashboard.
• Build a dashboard view in Power BI using this data as shown below!

 

If you are new to Power BI and not sure how to create a dashboard using data from an Excel file, go check out this small video and the blog on step by step instructions to do this. https://docs.microsoft.com/en-us/power-bi/create-reports/service-dashboard-create

 

POWERB dashboard break down.

 

Result Count

 

The view shows the overall status in terms of total statistics relating to account with weak passwords and policy compliant passwords.

The default view shows the result without any filters turned on and will change when filters are applied, like the domain filter, as shown below.

 

Username Count by Operation

 

Azure AD Password Protection operations take place whenever a password is changed or reset and this view helps to draw a nice picture around how many passwords are being set and changed, as well as the total.

A password change is when a user chooses a new password after proving they have knowledge of the old password. For example, a password change is what happens when a user logs into Windows and is then prompted to choose a new password.

A password set (sometimes called a password reset) is when an administrator replaces the password on an account with a new password, for example by using the Active Directory Users and Computers management tool.

 

 

User details

 

This view shows all the details about the operations to answer questions like:

• Which user account?
• On which domain controller?
• At what time?
• What password policy applied for?
• Was it a password set or change operation?

 

The information can easily be exported to csv from the PowerBI to leverage the data for further analysis or targeting specific users for training around weak passwords.

 

Password Policy Count

 

 

Publishing the Dashboard

 

PowerBI allows you to publish the dashboard via the PowerBI gateway, which allows users and administrators with permission to view the dashboard from any location or device.

We assisted the customer to publish this Dashboard and with the data being updated daily via the scheduled task it allows for most recent data to viewed.

 

This can also be implemented on free Power BI Desktop version.

 

Indicators

 

• A lot of password sets operations resulting in failures to comply with policy might be an indicator that password admins\service desk is setting initial weaker passwords for users.
• Many operations for password sets compared to password changes might be an indication that the Service Desk is resetting passwords and not checking the “change password at next logon" tick box.
• High failure rate means greater impact of Policy change in the environment, ideally try to reduce the failure count before changing AAD Password Protection to Enforce mode
• Many passwords matching the customer policy might indicate a greater risk of password spray attacks from internal bad actors using commonly used passwords in the environment.

 

 

CONCLUSION

 

In conclusion, we tremendously raised the awareness about Password Security at our customer and their Identity Admins can view the status on their Password Security from anywhere with our Power BI Dashboard.

 

If you want this to be implemented for you, feel free to contact your Microsoft Customer Success Account Manager (previously known as TAM) and someone can help you.

 

Hope this helps,

Zoheb & Peter