Alert on Password Writeback Outage
I’m taking a break from a busy schedule to begin writing a series of simple Azure monitoring and alerting articles. The scope of these articles will cover simple, built-in, Azure monitoring and alerting tools businesses (of any size) can immediately begin using. This series should also help raise awareness on extremely simple, but rudimentary, built-in monitoring and alerting practices. Any business, with an Azure tenant, can rapidly begin using these extremely powerful monitoring and alerting tools. Those reading this series will undoubtably gain a more rich and dynamic understanding of Azure Log Analytics monitoring and alerting. Your feedback is always welcome.
Welcome to my series of Azure Log Analytics use-cases and instructions.
Customers routinely request rudimentary alerting features for their most basic Azure Infrastructure services, login details, etc. Unfortunately Azure Log Analytics can be slightly daunting. However, let’s jump in.
Azure Log Analytics is a simple but powerful tool to monitor the health of your Azure cloud environment
Azure Log Analytics collects, analyzes, and acts on telemetry data fed to it from your Azure infrastructure, Azure AD (identity, devices, etc.) along with perhaps your on-premises environment(s) – such as servers, workstations, etc. Anyway, it’s quite powerful. Here is a great link providing a good overview of use (link).
In this article, we wont be performing a deep-dive into Azure Log Analytics instructions. Microsoft has published some marvelous How-To documentation. Herein, I minimally want to provide a simple plug – Log Analytics is fairly straight forward to begin using to begin obtaining information and alerts across your critical Azure services, including user login details – and a whole lot more. Although Microsoft typically explains the how-tos, they don’t always capture the whys thus omitting pertinent use-cases. To get warmed up, here is the first of several blogs capturing a known use-cases. Hope this helps.
Use Case 1 – Alerting on STATE-CHANGE for AAD Connect Password Writeback
We’ll be starting with capturing and alerting on a service STATE-CHANGE for Azure Password writeback.
When working with cloud-only accounts within Azure AD, the self-service password reset portal does not involve the use of Password writeback to on-premises. This important writeback service only comes into scope when providing cloud password reset services for on-premises (synchronized) accounts – known as hybrid accounts. This is where folks are able to conveniently reset their passwords from any browser, and then have these immediately written to their on-premises Active Directory. (Plan an Azure Active Directory self-service password reset deployment)
Password reset and writeback, in such a hybrid scenario, have several layers of dependencies (which we won’t cover here). However, once these dependencies are configured harmoniously and in production use, IT executives will want to ensure these services remain up and healthy.
On occasion, during routine operational tasks, such as upgrading or implementing changes to Azure AD Connect primary and staging roles, one will sometimes discover later (mysteriously) the Password writeback service is DOWN or UNAVAILABLE. Although Password writeback, within the AAD Connect wizard, clearly shows enabled, a failed password change or visual review within the Azure Portal demonstrates otherwise.
This isn’t a new or unheard of challenge. A quick solution is to disable and reenable Password writeback via the Azure AD Connect wizard. This however DOES NOT solve the challenge of being notified when or if this services becomes disabled.
Administrative fat-fingering errors, on the staging server, had been found where the Password writeback tick-box had a.) never been enabled or b.) had been inadvertently disabled. Upon then switching the primary role to this staging server subsequently (as silently) disabled password writeback (shocking huh?).
A Log Analytics alert solves this particular challenge. Obtain immediate alerts (from Azure AD > Audit Logs) if there is a service STATE-CHANGE to your password writeback service. The following steps assumes Azure AD Audit Logs are being sent to an appropriate Log Analytics workspace (see link instructions).
Alert Setup Instructions:
>Log Analytics Workspace > [name of workspace] – Monitoring Section > Alerts
- New Alert Rule
- For the Scope, ensure you’re targeting the correct Resource Group and Resource type (pretty simple)
- For the a Condition signal, use a Custom log search
- For your search query, use:
AuditLogs | where LoggedByService == “Self-service Password Management” and Category == “DirectoryManagement”
- Set your alert logic to the following: Based on: Number of Results – Operator: Greater than – Threshold Value: 0
- For the Evaluated based on, leave the default values
- For actions, setup a notification for your administrators
- Under Customize actions, input an appropriate email subject – e.g. ACME – Detected service state change for Password Writeback
- Beneath Alert rule details, fill in an appropriate Alert Rule Name & Description.
- Set your severity and click Create Alert Rule (at the bottom)
During a maintenance window, test your newly created ALERT by disabling on-premises Password Writeback.
Let us know how this works for you.
Contact our team at DTS Inc. for any needed assistance. We’re at your disposal.
Warmest Regards – Shawn May
Checkout our latest youtube video.