Are you responsible for Azure AD in your org? Are you aware of the next AzureAD deprecations?
Use the following table to learn about changes including deprecations, retirements, breaking changes and rebranding. Also find key dates and recommendations
Security Essentials in Microsoft 365 are a must, probably, most of this recommendations are being followed by most of us, but just in case and as a reminder:
Are users configured with multi-factor authentication? Multi-factor authentication is necessary control for users that protects them from password attacks such as password guessing and credential theft. If a Microsoft 365 user account is compromised, an attacker may gain access to the user’s emails, files, chat history, and other sensitive data. So imagine if this happens to an admin… probably: GAME OVER
If the organization’s on-prem Active Directory is synchronized with Azure Active Directory, are only necessary objects synchronized? Organizations will commonly synchronize their on-prem AD with Azure AD. However, it is a best security practice to only sync those AD objects that require use within Azure AD
Is the number of users configured as administrators in Microsoft 365 appropriate for the size of the organization? Having more than one administrator in Microsoft 365 ensures that if one administrator is unavailable, another user can make changes to the tenant. as always my recommendation and Microsoft is that should be no more than five Global Admins (remember to have emergency access account as well)
Are dedicated administrative accounts used? Separate administrative accounts from personal accounts, and something important administrative personnel should use their privileged accounts only when it is required.
Are tenant Global administrators configured with working email addresses? Microsoft 365 Global Admins receive a variety of important email notifications that include service status, security events, and other information. So, it is important that organizations ensure that global admins use an email address that is configured to a working address.
Are Azure AD User Settings configured from non-default settings? By default, non-administrative users may access the Azure AD administrative portal and perform several different actions including:
• Register custom-developed applications for use within Azure AD
• Access the Azure AD administrative portal
• Allow user to connect their Azure AD accounts with their
LinkedIn account
• Invite external guest users
• Invited guest users can invite additional guest users
Each of these settings may have a security impact, depending on how the organization. If the your organization has not tackled any of these default settings to be more restrictive, you’ll need to do it, there are a lot of configurations to be done
Are users restricted from creating auto-forwarding rules within Outlook? When a user creates an auto-forwarding rule, emails sent to the account are automatically forwarded without user notification to an email box that the organization does not control. This may expose the organization to risk of loss of sensitive data.
As always, there a lot of best practices to follow, the previous recommendations are only a few of them, but it’s up to you to apply them or be in the risky way, stay safe!
I want to drop some lines about my experience deploying several projects of Azure Conditional Access
Always exclude your emergency accounts from the conditional access policies (remember if you don’t have an Emergency Account, you’re late), this is something that I always tell to my customers and I will never give up
Don’t enable new policies without communicate properly to the organization, and also to foresee the impact in the users (you will save a lot of tickets from the customer service)
Don’t enable policies that requires compliant or hybridAzureAdJoin devices without verifying the state of the devices in the Azure Portal (same as before, you will save tickets and system interruption from the end users)
Careful with including in the policies the application “all apps”, is it possible to have a disgusting surprise (in my case, it happened to me in Azure, I put some exclusions, but it seems that sometimes the portal calls randomly to other APIs that cannot be controlled (and do not exist in AAD), so the user received a block in the portal even if the policy makes sense for you)
If you go ahead with the policy with “All Cloud Apps” for the policies bases on devices, be sure to exclude in the policy the app “Intune Enrollment” or you won’t be able to enrol new devices in the portal
It is very easy to include multiple cases in one policy, but if you want to troubleshoot of what is happening, is it easier to segment the policy in multiple policies. Eat the elephant bite by bite, we have to put in the balance having and managing several policies or be able to troubleshoot correctly.
Is it recommended to include a naming convention in your policies, in a bird’s eye, you will be able to know what is the use for each policy (user, device, administrator, guest)
So, this is all, probably you’re following most of these recommendations, but if not, don be a fool 😉
More than 99 percent of password spray attacks use legacy authentication protocols
More than 97 percent of credential stuffing attacks use legacy authentication
Azure AD accounts in organizations that have disabled legacy authentication experience 67 percent fewer compromises than those where legacy authentication is enabled
Disabling legacy authentication for users is a must-do on your identity security checklist
Why? becasue is a security gap and Microsoft took a lot of effor to promote Modern Authentication. So, you can disable now this basic Authentication in very simple steps:
If you don’t want to use this option, you can block the access to those protocols by using Conditional Access, understanding in a very simple way the impact of the policy.
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 two keys are configured, you’re ready to setup them in AzureAD MFA (https://aka.ms/setupmfa)
K33 process
I have explained the process of how to initially configure the K33 key, but I strongly recommend to follow the steps mentioned in K33_Microsoft_Services_Guide.pdf (ftsafe.com) to pair the key with your laptop.
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.
To enforce Azure AD Connect to use TLS 1.2 only, run the following Windows PowerShell script in an elevated PowerShell window on each Azure AD Connect server:
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.
SigninLogs
| 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.
SigninLogs
| 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.
Albandrod's Memory 