In this short blog I will show you how to look into if users are using Multifactor Authentication based on earlier posts on how to monitor and collect logging for your Azure AD.
So first of all – You need to setup Azure AD logging. Have a look at this blogpost to se how easy it is to setup. “Monitor Azure AD”
SigninLogs
| where TimeGenerated > ago (14d)
| summarize ['Single-factor Auth.']=countif(AuthenticationRequirement == "singleFactorAuthentication"), ['MFA']=countif(AuthenticationRequirement == "multiFactorAuthentication") by bin(TimeGenerated, 1d)
| render timechart with (ytitle="Amount", title="MFA vs non-mfa last 14 days")
This query will give you an output like this when used. You can then use this in your monitoring solution to visualize the usage of MFA.
A pre-requisites for monitoring sensitive accounts in Azure AD is to have setup a Log Analytics Workspace and your Azure AD logs sent to Log Analytics. If you want to know how that`s done then have a look at this blog post to se how easy it is to enable in your tenant “Monitor Azure AD”
Query
So to be able to monitor sensitive accounts we first need to locate/determine what accounts that you want to monitor. I always recommend to monitor the Break-the-glass administrator account so that you or your team is alerted whenever the account is used.
So in the Log Analytics query below here you see that we are searching the “SigninLogs” for a specific UserPrincipalName and we are only looking at ResultType 0. (ResultType 0 is equal for Success).
SigninLogs
| where UserPrincipalName == "julian.rasmussen@idefix365.no"
| where ResultType == "0"
So with that in mind let`s create a Alert Rule from this query so that we are notified every time “julian.rasmussen@idefix365.no” doing a successful signin.
Log Analytics Workspace with query for a specific username and success login
So when clicking the “New Alert Rule” button we are headed into a new page with several settings. here I have changed only two tings; Operator: Greater than or equal to Threshold value: 1
Click Next to go to “Actions”
Action Group
An action group is how and who is getting notified when the alert is fired. So we create a new action group for this scenario and setup a email warning to an administrator.
You can choose to also send a payload to a Azure Function, Webhook and more within the Action pane of the Action group – in this scenario we are only using the notification part so let`s skip to the “review and create” part and create the Action Group
Alert
We then give the alert a “Alert rule name” and a description. This is what`s in the email notification sent to the user or users in the Action group
Jump over to “Review + create” and create the Alert rule.
Conclusion and result
We have gained monitoring and notification by doing a Query in Log Analytics.
From the Logs pane we can easily create a new Alert rule
We created a Action Group where we spesified who and how to get notified
And the result looks like this when there is a sign-in from that account and the Alert rule is fired!
So now a days many have enabled MFA for their accounts. And that’s great! It show`s that what we have been working on the last years is working. According to Microsoft, MFA can prevent 99,9% of attacks to your accounts. But there is a attack vector that not many think of.
Do you have full control over the process of onboarding new users?
We often se that users are created and activated several days before the user is actually starting to work. That means that in most of the onboardings the user account is not protected to MFA until the user is sign in in and enters the security information needed for activating MFA on the account.
What we see now is that hackers are executing brute force attacks on username and password of accounts that had never logged on into Azure AD.
So to protect us from this we need to establish a Conditional Access policy preventing users from the ability for enrolling to MFA except from when they are seated at the company (Location whitelist).
Steps for protecting your users
Login to portal.azure.com and navigate “Azure AD” then head into “Security” -> “Conditional Access” -> “Named Locations” and create a new “IP ranges location”
Main goal for this blogpost is to gain more knowledge on how to collect logs from Azure AD. By default you`ll get 30 days audit and sign-in logs stored within Azure AD. To be able to interact / automate on the logs we need to move the logs to a Log Analytics Workspace. So by doing so we gain these and much more features on our log data:
Ability to automate actions based on logs
Increase retention time on logs
Connect Microsoft Sentinel
Speaking of retention time you can choose from 30, 31, 60, 90, 120, 180, 270, 365, 550, and 730 days within the Azure Portal on the Log Analytics Workspace.
Log Analytics
First of all you need to create a Log Analytics Workspace and to do that you need to have a Azure Subscription in place (and you need Contributor access to it). – Create a “Resource Group” – Create a “Log Analytics Workspace
Here i have created a Resource group and added a Log Analytics Workspace to that group named “idefix-sentinel-log-analytics”
Azure AD configuration
When the LAW (Log Analytics Workspace) is ready then you can configure Azure AD to send log`s directly to it. Head into Azure AD and navigate to “Audit Logs” or “Sign-in logs” and from there click the “Export Data Settings”
Azure AD -> Audit Logs -> Export Data Settings
Here you click on “Add Diagnostics Settings” and give it a name, point it to the log analytics you created and choose what to store into that LAW.
Choose all categories you want to store
After you save it you should wait about 15-20 minutes before trying to query the logs, just to be sure that new log`s have been streaming into LAW.
Test query in Log Analytics
To query your data you need to navigate to your Log Analytics Workspace and head into the “Logs” pane and from there you can add a Query to search the log`s with.
Log Analytics Workspace -> Logs
This query gets all login entries for users whose name contains Julian
SigninLogs
| where Identity contains "Julian"
To be more specific, use UserPrincipalName:
SigninLogs
| where UserPrincipalName == "julian.rasmussen@idefix365.no"
All sign-ins for Julian in the last 30 days
SigninLogs
| where UserPrincipalName == "julian.rasmussen@idefix365.no"
| where TimeGenerated > ago(30d)
I have been strugling with a “Set-CalendarProcessing” cmdlet to be able to restrict booking of meeting room using the -BookInPolicy setting.
After some (ALOT) of testing it`s clear that this setting only supports regular “Distribution groups” and therefore i cannot use the already created dynamic group created.
I therefore created this little script for copy-ing members from the Dynamic group over to the regular group!
### Copy members from dynamic distribution group to regular group"
Connect-ExchangeOnline -UserPrincipalName julian.rasmussen@idefix365.no
$users = Get-DynamicDistributionGroupMember -Identity "xAuto Meetingroom bookers"
foreach ($user in $users) {
Add-DistributionGroupMember -Identity "xManual Meetingroom bookers" -member $user.PrimarySmtpAddress
}
In order to optain a secure infrastructure you need to have controll over your MFA settings. There are several settings you need to configure and know how it works.
In this post I`ll go through all settings like
Notifications
Maybe the easiest setting but yet som important. You need to configure who will get the notification whenever there is a issue with one of your users. To do this please go here and and your desired address: Azure Active Directory > Security > Multi-Factor Authentication > Notifications
Fraud Alert
Fraud alert is verry important to configure! This feature will block signins for the end-user when the user is deny’ing a unknown or suspicious MFA promt on their Authenticator app or phone. The user is blocked in 90 days or until a Administrator un-blocks the user. Head into – Azure Active Directory > Security > MFA > Fraud alert And enable the “Fraud alerts” settings on your tenant.
Account Lockout
So this Multi-Factor feature will let you configure your environment to handle MFA request attacks. Meaning that you can configure the Account Lockout settings for how many denials before triggering a account lockout and also you can configure how many minutes until the counter resets.
The settings are set here: Azure Active Directory > Security > MFA > Account lockout
These are my recomended settings for this.
Block/Unblock users
So the Block / Unblock feature is a feature that allows you to block a user it their device is stolen or lost. The user you put on this block list is blocked for 90 days or until a Administrator unblocks the user.
Block a user: Azure Active Directory > Security > MFA > Block/unblock users. Write in UPN and a reason for blocking.
Unblock a user: Azure Active Directory > Security > MFA > Block/unblock users. Select unblock on the user you want to unblock and write a reason for unblocking.
So these day`s we all uses MFA right? But not all MFA methods are as good as we think.
There have been several cases where “SIM Swapping” or “SIM Hijacking” has been the case and therefor – can we trust using SMS for Multi-Factor Authentication?
In short notes this is how SIM Swapping is done.
You loose personal information.
Your information is used to gain trust at the mobile carrier to convice them to switch from current to new SIM card (the new SIM is already in the hands of the bad guy)
With controll of mobile number the bad guy log`s onto your services with one-time password or completing MFA challenge.
Your account is compromised
With that said, you should disable SMS as an authentication method. See my other blog post on how that`s done!
Since you now uses Microsoft Authenticator as your primary MFA factor you get a push notification with “Allow” or “Block” access whenever the authentication is done. At this point the bad guy start using a method called “MFA Fatigue attacks” and blasts lot`s of authentications against you, and somethimes a user clicks on “Allow” and thinks; “It`s most likely my phone or tablet or something…”.
But with the new capabilities from Microsoft within using Azure MFA you can now add “Number matching” and “additional context” to the signin (both features are in preview at the momemt (04.05.2022).
OK – so here`s how it looks!
So you see that when ever the authentication is done a number is shown and it needs to be matched on your Microsoft Authenticatior application. In addition we also see a map and location of where the authentication is getting from!
Here`s how you can configure it!
Head over to portal.azure.com
Navigate to Azure AD -> Security -> Authentication methods and click on “Microsoft Authenticator”
Hit “Add users and Groups” and add a group or user to test with and click “Select”
Then open the settings of the group and “Require number matching” and “Show additional context in notifications”
There you have it! Next time you authenticate with a user that`s configured to this setting you will get a number matching 🙂
Ever thought about your end-users really think before clicking?
How often does your end users (who have local administrator rights in some way) just install stuff without thinking?
To start with, your end-users should not be local administrators on their machines, but many still are. If they are not all the time lot`s of companies have sollutions where end-users can elevate them self for a certain time frame.
But let`s make them think an extra time before actually installing stuff that require administrator privilegdes on their machine by forcing them to type their username and password instead of just “Yes/No”.
One way to change this is to use the Registry and force the UAC to prompt username / password.
for several of my customers I deploy this registry setting to the end-user using Endpoint Manager (Intune), and this is really easy!
Head into Endpoint Manager (Intune)
https://endpoint.microsoft.com
Dive into “Device” and and choose “Scripts” and hit “+ Add”
3. Give it a “name” and “Description” hit next. 4. Upload the script (see code block over and save it as .ps1) 5. Lett all settings be at “no”
6. Assign it to “All Devises”, next and add!
Now all your devices will get this deployed and after the next reboot your users will need to provide both username and password to be able to install something that requires administrative rights.
Ever stubled over the need of changing a guest`s sign-in information on one or more guest accounts? Well, this has been a issue for several companies and the way forward was to delete the guest accounts and re-invite them.
When doing this all access to Teams, SharePoint Online and OneDrive for business for that guest account was also deleted and they needed to be added to the resources again with the new guest account.
A new configuration within Azure AD now gives you the ability to change the E-mail address for the user and reset the sign-in information – and it`s quite easy!!
Let`s go through the config changes and change a guest account`s sign-in information.
So! I have 1 guest account “jr@ptaken.no” and this guest account have access to 1 Team.
I want to change the sign-in information for this user (at the same time as the PTaken.no company changes the UPN on their side.
So let`s change it at our side,
We edit the guest account and set the new UPN on the user on the “email” and “alternate email” attribute like this – (the old UPN was jr@ptaken.no).
When this is changed we can go ahead and re-send the guest invitation to the new address by clicking the “Invitation Accepted” button and reset invitation status.
The guest now get`s a new invitation that needs to be accepted
Now when the guest is signed into for example Microsoft Teams the account will show that he is logged in with the new UPN.
After two years of “blog silence” from me, i`m no working on several new blog posts and are accelerating my community work again!
2020 and 2021 was two years where the work presure was very very high and automaticaly community work was not prioritized due to high prio on family life on all ours available after delivering my working hours.
anyhow! All that behind – and 2022 will be “The year of community” for me!
With several blog post ready, the planning of several in-person “Office 365 User Group Agder” meet-ups and also several call-for-paper delivered to conferences and communities!
