Microsoft Entra will verify all types of identities and secure, manage, and govern their access to any resource. The new Microsoft Entra product family will:
Protect access to any app or resource for any user across hybrid, multicloud, and beyond;
Secure and verify every identity including for employees, customers, partners, apps, devices, and workloads;
Provide only necessary access by discovering and right-sizing permissions, and managing access lifecycles for any identity; and
Simplify the human experience with simple sign-in, intelligent security, and unified administration.
But, what it is really Microsoft Entra? A unified portal for securing and managing every identity – The admin center for Microsoft Entra facilitates identity and access management, multicloud permissions management, and administration of verifiable credentials, all in one place.
When Entra will take place? In May 31st
And what happens to my AzureAD? Azure AD continues to be the foundational infrastructure for all new products in Microsoft Entra family. Innovation and investment in Azure AD continues, including the popular Application Gallery, Conditional Access, multifactor authentication, passwordless, and more.
Will I still be able to access my Azure AD Admin portal? short answer yes, long answer see below:
The Azure AD admin center (aad.portal.azure.com) will continue to function for the next 12-18 months, and then redirect to entra.microsoft.com in 2023 after extensive customer notice.
The Azure portal at portal.azure.com will also continue to offer Azure AD for Azure customers.
The M365 portal Azure AD admin page will be redirected to entra.microsoft.com later this summer.
So, can I Buy Microsoft Entra? Microsoft Entra is a product family. Products within Microsoft Entra are available for sale but there is no Entra bundle to purchase
This new product family has an impact on licenses or billing? No, but if you’re interested in sing Microsoft Entra Permissions Management will need to obtain a license for the solution. Microsoft Entra Verified ID is a free service but some scenarios, integrated with Azure AD capabilities, may require an Azure AD P1 or P2 license as a pre-requisite.
Currently, we could say that Legacy Authentication is one of the most compromising sign-in, luckily for us, older protocols have been replacing with modern authentication services, taking the advantage that MA supports MFA, while Legacy Authentication refers to all protocols that use Basic Authentication, and only requires one method of authentication.
So, it is important thar for security reasons we need to disable legacy authentication in our environments, why? Because enabling MFA isn’t effective if legacy protocols are not blocked. For example, the following options are considered legacy authentication protocols:
Authenticated SMTP – Used by POP and IMAP clients to send email messages.
Autodiscover – Used by Outlook and EAS clients to find and connect to mailboxes in Exchange Online.
Exchange ActiveSync (EAS) – Used to connect to mailboxes in Exchange Online.
Exchange Online PowerShell – Used to connect to Exchange Online with remote PowerShell. If you block Basic authentication for Exchange Online PowerShell, you need to use the Exchange Online PowerShell Module to connect.
Exchange Web Services (EWS) – A programming interface that’s used by Outlook, Outlook for Mac, and third-party apps.
IMAP4 – Used by IMAP email clients.
MAPI over HTTP (MAPI/HTTP) – Used by Outlook 2010 and later.
Offline Address Book (OAB) – A copy of address list collections that are downloaded and used by Outlook.
Outlook Anywhere (RPC over HTTP) – Used by Outlook 2016 and earlier.
Outlook Service – Used by the Mail and Calendar app for Windows 10.
POP3 – Used by POP email clients.
Reporting Web Services – Used to retrieve report data in Exchange Online.
Other clients – Other protocols identified as utilizing legacy authentication
How can we monitor the usage of legacy authentication in Azure AD?
Thanks to Log Analytics, Insights and workbooks, we are able to monitor the use of those protocols, for instance:
And check the non-interactive sign-ins (be careful with ADConnect sync accounts):
In this case, I am testing out the K33 and K44 products
The initial setup of the tenant is covered in my previous post, so I will skip the details of how to do it.
To configure the K33 key you will need to download the app “BioPass FIDO2 Manager” from the Windows Store:
And connect your K33 key via USB to the laptop (otherwise won’t be possible to configure), the configure your preferred PIN, and finally configure your fingerprints. The process to the K44 is similar, but in this case, I am using and Ipad, and the app to download is “iePassManager”
Once the key has been paired, the process to configure it is simple, the only thing that you must take into account is that even it is Bluetooth Key, you must configure it as an USB key (but remember, it must be paired first with the device).
Authentication with K33
K44 Registration Process
Once again, it is needed to set up the PIN for the Key, in my case, it has been done with the Ipad, but the registration process, is easy as the video shows:
The sign in process is very similar as we’ve seen before, so I do not want to cover this, but as you can observe, the registration and use of Fido2 Keys is pretty simple.
Inclusion, MFA keys and particularly, Fido2 Keys from Feitian are great!! But now, something that you must consider when implementing Fido2 keys in your environment:
There’s no way to enforce PIN policy in Azure AD: Every user can set up their own PIN to use their key. There is no centralized way to manage PINs, but Windows Hello for Business blocks simple PIN codes by default. The bad news is, if you add the key directly to your Azure AD account, these settings are overridden ☹
Feitian offers multiple options for connecting your key, so you’re sure to find one that works for you. Among the available connections are USB-A, USB-C, NFC, Bluetooth, PIN, biometrics, and more.
Biometrics requires app installation: you need to download the manufacturers’ application that enables fingerprint scanning, which is additional software that you must consider to install
Again, I want to thanks Feitian for providing the security keys to test out the use cases
A device is said to be hybrid joined if it has both an AD object and an Azure AD (AAD) object, which allow users of that device to sign in with an AD user account, which provides access to resources which are protected by either the AD or the AAD user.
A hybrid joined computer is joined to both AD and AAD, but the AD join is primary because the device initially uses AD authentication. Only Windows devices can be hybrid joined. The benefits of having Hybrid Azure AD Join devices are
The computer has a device object in Azure AD, which enables a variety of capabilities including:
Microsoft 365 Apps device licensing is possible
Azure AD Conditional Access features based on device conditions are possible
There is a reduction in user sign ins because user sign in gets both an NETID AD token and AAD token
But what If you want to disable that Hybrid Join?
You can disable hybrid join by preventing one of the requirement elements from triggering hybrid join registration:
Modify the Hybrid Azure ADJoin from the AADConnect (Recommended)
Use the following registry in the computers to block: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: “BlockAADWorkplaceJoin”=dword:00000001
Modify the Scheduled Task which triggers AAD device registration. See Task Scheduler > Microsoft > Windows > Workplace Join > Automatic-Device-Join. See the following 3 items for details:
Deleting the Scheduled Task seems to work reliably.
Disabling the Scheduled Task does not work reliably; the disabled task will still run after a user signs in.
Modify both triggers from an Enabled status to a Disabled status; this works reliably.
Add a firewall block for https://enterpriseregistration.windows.net, to prevent the computer from connecting to the Azure AD Device Registration Service (AAD DRS). See the following item for possible side-effects:
This should only affect the ability to AAD join. If you have Office installed on the Windows device, this might have an undesirable impact on AAD device registration (different from AAD device join) which is required per user for Microsoft 365 Apps (was Office 365 ProPlus) sign-in.
Add a firewall block for the UW ADFS server, sts.domain.com, to prevent the computer from getting an ADFS token to authenticate to the AAD DRS. See the following item for possible side-effects:
Note: this option will only work for as long as you continue to have federated authentication for AAD, which is planned to be removed. This option may be undesirable if there is any interaction with Azure AD applications like Office 365 from the device–those interactions would be blocked.
Ok, that’s great but what if I want to unjoin a Hybrid AzureADDevice? For hybrid Azure AD joined devices, make sure to turn off automatic registration. Then the scheduled task doesn’t register the device again.
Next, open a command prompt as an administrator and enter dsregcmd.exe /debug /leave. Or run this command as a script across several devices to unjoin in bulk.
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
HOW TO MONITOR SMART LOCKOUT?
Integrating the monitor and alerting of Smart Lockout is very simple, this post will explain you how to do it:
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.
In the Diagnostic settings menu, select the Send to Log Analytics workspace check box, and then select Configure.
Select the Log Analytics workspace you want to send the logs to, or create a new workspace in the provided dialog box.
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
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.
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.
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.
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)
Yes, you’re reading well, MS have launch the preview of AzureAD in the new Azure Portal. As you know, when you need to configure something of AzureAD in the new portal, automatically redirects to manage.windowsazure.com.
It was very confusing and it was simply stupid, but from today we can enjoy the new AzurePortal:
I hope that MS will be improving the user experience of this new feature, but for this time this are great news 🙂
If you want to hear more info about this, you can visit the following Technet Blog