Discover who invited guest users with Log Analytics

Reading my posts, you will probably know that I am a bit fan of Log Analytics, so in this post we are trying to examine the AzureAD logs in order to discover who invited a specific a guest account, because sometimes can be quite a challenging question to find this information…

So first of all, we need to forward the audit logs from AAD to workspace in Log Analytics, once we have done this, we can execute the following query:

| where OperationName == 'Invite external user' and Result == 'success'


As you can see in the image, this query shows some basic information about the users, but if you want to find all accepted invitations, you can execute the following…

| where OperationName == 'Invite external user' and Result == 'success'
| extend InvitationId = tostring(AdditionalDetails[0].value)
| join (
	| where OperationName in('Redeem external user invite')
	| parse kind=regex TargetResources[0].displayName with * "InvitationId: " InvitationId:string ","
on $left.InvitationId == $right.InvitationId

Once we have done that, we can include this information in our Governance Plan or even to create some Log Analytics alerts in order to be sure that everything is doing under our umbrella os security


Monitor Azure AD Smart Lockouts with Log Analytics

Following my last post about Azure AD Smart Lockout, have you ever wonder, how to monitor those events? Of Course, we can do it with Log Analytics


Integrating the monitor and alerting of Smart Lockout is very simple, this post will explain you how to do it:

  1. In Azure Portal, Select Azure Active Directory > Diagnostic settings -> Add diagnostic setting. select Export Settings from the Audit Logs or Sign-ins page to get to the diagnostic settings configuration page.
  2. In the Diagnostic settings menu, select the Send to Log Analytics workspace check box, and then select Configure.
  3. Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
  4. Select one or both of the following:
    • To send audit logs to the Log Analytics workspace, select the AuditLogs check box
    • To send sign-in logs to the Log Analytics workspace, select the SignInLogs check box
  5. Select Save to save the setting.

Now, what we will need to do is wait, probably in 5-10 minutes we will start to have data into workspace.

The logs we are looking for are in the AuditLogs and SigninLogs tables in the workspace.

| limit 50

and click on run to get the last 50 sign-ins listed. As we are interested into the actual Smart-Lockouts (ResultType 50053), we need to add a filter criteria to our query and we probably want to limit it to the last seven days only.

| where CreatedDateTime >= ago(7d)
| where ResultType == "50053" 

And because we like to get notified, we can also set an Alert Rule on this type of query. Click on New Alert Rule, which will bring you the next blade.

Then we need to reuse and Action Group or create a new one, this is used to be alerted when the signal occurs. we have to be aware that depending of the frequency of the alert, we will be charged in €€€

Another thing to keep in mind is that we will have a lag between the alert and the action when it happens, it’s not inmediately.

that’s all, have fun!

AzureAD Smart Lockout

Have you ever wondered how Microsoft prevents password guessing attacks or brute force attacks on Azure AD? Well, it is basically the same method as you would do on your on-premises User Directory! It is just smarter!

Azure AD Smart lockout is a feature being applied to every sign-in processed by Azure AD, regardless if the user has a managed account or a synced accounts using password hash sync or pass-through authentication.
The smart part comes from the ability to distinguish valid users from attackers. It locks out the attackers while letting your users continue to access their accounts and be productive.


If you still run ADFS, there is also a Feature available named Extranet Smart Lockout but this one is not as smart as the one in Azure AD.

The default lockout setting kicks in after ten invalid login attempts for one minute. The account locks again after each subsequent failed attempt, for one minute at first and longer periods in subsequent attempts. Also, smart lockout tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password, basically, if the same bad password is entered multiple times, it will not cause another lockout.

Note: The monitoring of the same sign-in attempt is only available for the Password Hash sync scenario, as the Pass-Through password validation happens against your on-premise AD domain controllers.

Smart Lockout is always turned on for all Azure AD customers. If you want to modify the default behavior of 10 invalid attempts to trigger a one-minute lockout, then you require Azure AD P1 or P2 licenses for your users.

How to protect your identity in the Cloud

Lately, I have blogged about security in the cloud, but as many of you know, most security breaches take place when attackers gain access to an environment by stealing a user’s identity.

It is relatively easy for attackers to gain access by compromising the low privileged user accounts and then leveraging their permissions to super users.

Because of this, we must do:

  • Protect all identities regardless of their privilege level
  • Proactively prevent compromised identities from being abused

For example, Azure has the following services for Identity Management:

  •       Single sign-on
  •       Role based access control
  •       Reverse Proxy
  •       Device registration
  •       Hybrid identity management/Azure AD connect

But what about for identity protection? we can find the following features…

Azure Multi Factor Authentication

I have talked about MFA before, the use of strong passwords and the use of another layer of security, for me nowadays is essential to deploy it in companies. Therefore, even if the user’s password is compromised, hackers cannot access your data and applications.

Security Monitoring, alerts, and machine learning-based reports  

With AAD is it possible to monitor and secure the identity as well as draw reports that provide a comprehensive view of activity in the cloud. As an example, we can find the following:

  • Do you want to know who has signed-in to your cloud applications, when, to which application, and from where? Check AAD Sign-ins Report.
  • Do you want to know who has done which activity and when? Check AAD Audit Logs Report.
  • Do you want to know which identity is at risk? Check AAD Users Flagged for Risk Report.
  • Do you want to know the risk events, like users who signed in from anonymous IP address? Check AAD Risk Events Report.

Azure AD Identity Protection

In any version od AAD we can find monitoring and security reports, but only as a matter of reporting. But is you want to automate responses to detected suspicious actions is where AAD Identity Protection takes places.

You will be able to set different policies to act against the defined potential risks, like requiring Azure MFA registration, MFA authentication, or password change for risky users. Alternately, you can block the risky user from signing in.

Azure AD Privileged Identity Management

Lastly, we can find AAD Privileged Identity Management (PIM) helps you to mitigate the risk of excessive, unnecessary, or misused access rights.

PIM reduces the need for reviews. Instead, you can proactively control who or what is accessing the resources, when, where, and why. Also allows time-bound access that requires approval from predefined approvers to activate a role, and sends notification emails to you when the role is activated.

Take into account that some of these features require AAD Premium P2 license, but sometimes and extra cost is necessary, think in the money that you will lose (in money and image) if someone external to your company gain access to your data 😉

Configuring Azure MFA in ADFS: Service Principal was not found

Hi All,

Today I’m back with ADFS, the other day I needed to configure ADFS with Azure MFA for a client. In this case, first I configured the ADFS farm (in my case with WS2016), and then I was ready to configure Azure MFA in the Authentication methods for the Intranet and Extranet.

Why? Because it was a requirement for the project that all internal users use MFA in order to authenticate to O365. Thus we can integrate this with ADFS in a very simple (but tricky) steps. As you know, if you have E1 or E3 licenses, you can use Azure MFA by default, is it not necessary to purchase extra licenses in order to use this service. **First point to take into account

For the record, you will need to use the Connect-MSolService cmdlet, so be sure that you have installed the PowerShell modules in your server

Install-module MSOnline
Install-module AzureAD

Once you have installed this, you need to execute the following commands:

$tenantID = “”
$certbase64 = New-AdfsAzureMfaTenantCertificate -TenantID $tenantID

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
Set-AdfsAzureMfaTenant -TenantId $tenantID -ClientId 981f26a1-7f43-403b-a875-f8b09b8cd720

You can check the info in the following article:

But in my case, every time I was executing the command New-MSOLServicePrincipalCredential, I was receiving an error saying: “Principal Service was not found” I double checked if I was Global ADmin in the O365 and Azure subscription and I was!! So… what the hell means that error??

It means that you don’t have registered the SPN for Azure MFA, and to solve this it is very simple, you can purchase a trial of Azure MFA (P1, P2, EMS, o whatever plan where Azure MFA is included) and assign a license to one user, for example in my case, I assigned the license to the test users. It seems that you will not see “Azure Multi-Factor Auth Client” in the list of MSOL Service Principals until you have at least one account with an MFA license on your tenant.

After doing this, I needed to wait a couple of minutes and then I executed again the PS commands that I showed before… and bang!! I was able to register the Azure MFA as authentication method in ADFS Server.

I think that the short history is that using the new ADFS adapter requires MFA licenses. It doesn’t work with an MFA Provider, but MFA licenses can be purchased standalone or the ones included in Azure AD Premium and EMS

That’s all for today!

PowerShell Alternative Proxy Address


I was doing some powershelling for a client, and then I was trying to do an export from the proxyaddresses, but when I tried to export to CSV in the output file I was receiving something similar to System.Collections.Generic.List`1[System.String] in that field.

So, if you are facing an error similar to that, you need just to convert the field in order to export it. So you will need to execute something similar to that:

get-azureaduser | select-object  UserPrincipalName,@{Name=”proxyaddresses”;Expression={$_.ProxyAddresses}}, DisplayName | export-csv -path C:\export.csv

that’s all, pretty simple, isn’t it

How to check if an external user has accepted the invitation

From time to time, I receive calls from my customers saying that they send invitations from SPO to external users, but they claim that they did not receive nothing. This post will try to clarify the process, and how is it possible to check the user invitation status.

As you know, every invitation made into O365 (Teams, O365 Groups, SPO…) relies in Azure Active Directory, so our source of information will be there. So what are the steps that we need to follow?

The important thing here, is the source field. If the source field shows invited user, it means the user has not accepted the invitation. If that is the case, than you can click on resend invitation and this will trigger another invite for the user to redeem


Once the user has redeemed the external user invite, you can check the source field, because depending on the Identity Source, the field will be updated regsarding the IS.

In this case, the user has been invited to a Microsoft Account (@outlook, @hotmail)


In this other case, the user has been invited from an Organization Account (note that the source is External Azure Active Directory)


That’s all!


Introduction to Azure AD: Part 1

After having some discussions about this technology, I have decided to post a series of posts about this technology, and which options do we have depending the scenario where we are involved, so let’s start!

Today, I’m gonna talk about Azure AD, which probably everyday everyone knows, but in case of not, this is post is also for you. Azure AD is the acronym of Azure Active Directory, which basically is a cloud service identity provider or identity as a Service, in other words, it’s a simpler version of the typical Active Directory that almost every company has.

Which is the main purpose? Extend your AD to support the cloud and to allow business users to work with cloud applications. Simply as is.

How you can imagine, when we are using Azure AD we are relying on Azure, but also, when we are using O365, we are also using Azure AD to store the synchronized identities on the cloud (in case we have configured the synchronization between OnPrem and the cloud), so even if you don’t have an Azure subscription to host services, you can enter to azure portal, enter into Azure Active Directory and manage your users.


So, resuming, if we have O365, we also have Azure AD, and we can manage the users from the O365 portal and from the Azure AD portal. In addition to that, managing users in the Azure AD portal, gives us a lot of possibilities, as conditional access, identity protection, etc…  But, to use some of these features, we need a valid license.

Licenses in Azure AD, are divided into Free, Basic, Premium 1 and Premium 2, each has some interesting features, in the following link, you can have a closer look to each of these features:

As we can see, depending of what we want to use, we will need a different license, also, we have to take into account, that every user that will use this “premium” features, will need a valid license, so take in to account we you are planning to implement a service like this into your business.

As we can see, until here Azure AD is easy peasy, but now comes the funny part, have you ever realized that Azure AD is divided into Azure AD Azure B2B and Azure B2C, don’t you? So, in next post I will try to focus more in B2C and B2B to at least show my vision about this technology and possible use cases.

For more info:

Where do users change their phone number for resetting O365 password?

It seems a post very straightforward, but a client fired me this question and I thought that I was pretty sure about the answer, but no, I discovered something new for me in our marvellous O365 world.

My client wanted to change their phone and mail, when they must reset their password. If you remember, the first time that you log into O365, it asks for this data to complete your “recovery” profile. So, when he asked me to change this data, I guided him to follow this procedure:


  • Click on my profile


  • Update profile with your own/new info

Easy right?

If you follow this procedure to change your O365 password recovery data, you’re as much as wrong as I was. This procedure does not change your initial data, it only changes your profile information. So where do I have to access to change this data? Of course, Azure…

We know that every O365 tenant shares the Azure AD, so in Azure we also have the user information. In this case, the only thing that we have to do is to access to go to Azure Active Directory resource, users and groups and select the user that you need to change their information.



After doing this, you will be able to reset your password with the new data that has been introduced.

Keep in mind, that you’ll need permissions in the Azure resource in order to modify this “personal” information, if you don’t have the properly permission, this information will be greyed out.


Hope it helps!


Azure AD Premium vs. Azure AD

Many of my customers ask me that, and most of the cases I answer with the following: “If you have an Office 365 subscription, then you already have Azure Active Directory”

In addition to that, if they have Azure AD Connect enabled, will mean that their OnPremises users, passwords and groups are being synchronized to Azure Active Directory.

This is the standard case, but then many of my customers want to enable more features, but many of them are only available on Premium version, and yes it incurs an extra cost

Moreover, nowdays we have different types of Azure Active Directory licensing like:

  • Azure Active Directory Basic
  • Azure Active Directory Premium P1
  • Azure Active Directory Premium P2

But, which features has each one of the licenses?

With Azure Active Directory Basic

  • Manage users & group memberships in the cloud, and assign licensing
  • Sync your on-premises directory using Azure AD Connect
  • Cloud Users can reset their own passwords online
  • Company branding for the SSO access panel, etc.
  • 99.9% uptime SLA

Azure Active Directory Premium P1

  • MFA for cloud and OnPremises
  • Monitor AD synchronization health in the cloud
  • Cloud and OnPremise Users can change their own passwords online
  • Advanced security & usage reports
  • Self-service group & app management (dynamic groups)
  • Run Cloud App Discovery to uncover unmanaged cloud applications running in your environment

Azure Active Directory Premium P2

  • Azure Identity Protection
  • Privileged Identity Management

So, if you want to more about the Azure Active Directory, you can visit the following link, where you can find more info about it.

Till next time!