Recently, I got a question from a customer to list all users that already enrolled in Azure MFA (through, for example, the url https://aka.ms/mfasetup.
The following PowerShell code lists all non-disabled users that already enrolled in Azure MFA:
Connect-MsolService
Get-MsolUser -All | Where-Object {$_.StrongAuthenticationMethods -ne $null -and $_.BlockCredential -eq $False} | Select-Object UserPrincipalNameAlso during (a somewhat different) spring, Microsoft is keeping its promise by delivering webinars to introduce new and improved technology.
Be sure to mark the dates!
| When | About |
| April 15 | MCAS: Enabling Secure Remote Work |
| April 20 | MSSP Support |
| April 22 | Threat Hunting on AWS using Sentinel |
| November 21st | Using Sigma to accelerate your SIEM transformation to Azure Sentinel |
Details and registration information can be found on https://aka.ms/SecurityWebinars
When logging in to a customers Exchange Server 2013 environment recently, a pop up caught my eye, indicating the following errror:
An expired certificate as such obviously isn’t such a weird event. However, when zooming into the error, the server that the error referred to was an old, already decommissioned, Exchange Server!
The following locations were checked, to no avail:
After some googling searching the web with Bing, I found a solution on the web.
Get-Mailbox -Arbitration | Search-Mailbox -DeleteContentKeep in mind, to run the command, specific permissions are required. A management role needs to be created with Mailbox Import Export assigned role. Assigning the Discovery Management role is not enough!
Azure AD has the capability to enable end-users to perform a self-managed reset of the password, in case one does not remember it anymore.
Configuration is fairly easy, and can be done both through Intune and by adding a registry key. Detailed steps on how to do so can be found on https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-windows .
When configuring this on my home tenant, I received the following error:
All usual suspects were covered: the correct licenses were assigned, password writeback was configured and showed up in the portal as working, so no issues there. When opening the SSPR section in the Azure Portal, the following error was shown:
Digging into the Event Viewer on the Azure AD Connect Server revealed the error: The password could not be updated because the management agent credentials were denied access.
Following best practices from Microsoft, the account that was configured in the Azure AD Connect management agent did not have elevated permissions, and therefore did not have the possiblity to reset passwords.
Assigning delegated permissions to reset the password of the OU containing the synced users, solved the issue.
When your organization has multiple Azure Subscriptions and you are entitled to work with them, selecting the correct subscription becomes an important thing to do.
Different approaches exist. I will have a look at the two most straight forward ones.
Using an argument to Connect-AzAccount
Connect-AzAccount holds specific attributes than can help you, namely SubscriptionName or SubscriptionId. If you know the Subscription name you want to connect to, issuing the following command directly connects to the correct subscription, after which you can start scripting:
Connect-AzAccount -SubscriptionName "Microsoft Partner Network"To check to which subscription is linked, the command Get-AzContext can be issued.
Switching to another subscription in an active session
Switching to another Azure Subscription in an active session is also possible. This can be achieved by issuing the following command:
Set-AzContext -Subscription <subscription name> or <subscription id>Useful PowerShell references