Why you should block legacy authentication

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):

What we can do to avoid this?

The best way to block or report legacy authentication for users is use Conditional Access policies (Does my organization need Azure AD Conditional Access? – Albandrod’s Memory (albandrodsmemory.com) & Enabling zero trust security in your environment – Albandrod’s Memory (albandrodsmemory.com)

But the best way is creating a CA policy:

My final advice

Legacy authentication must be disabled to protect our environments, but first, start small and analyse the impact in your organization.

Till next time!

PassWordless Authentication with Fido 2 Keys – Part 2

This is a second part of my blog about reviewing Fido2 Keys from Feitian (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))

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

Till next time!

How to disable Hybrid Azure AD Join

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:

  1. Modify the Hybrid Azure ADJoin from the AADConnect (Recommended)
  2. Use the following registry in the computers to block: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: “BlockAADWorkplaceJoin”=dword:00000001
  3. 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:
    1. Deleting the Scheduled Task seems to work reliably.
    2. Disabling the Scheduled Task does not work reliably; the disabled task will still run after a user signs in.
    3. Modify both triggers from an Enabled status to a Disabled status; this works reliably.
  4. 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:
    1. 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.
  5. 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:
    1. 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.

How to enforce Azure AD Connect to use TLS 1.2 only

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:

$RegPath1 = "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"


New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

Hope it helps!

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

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:

  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.

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.

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.

smartlockout

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. https://support.microsoft.com/en-us/help/4096478/extranet-smart-lockout-feature-in-windows-server-2016

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 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

inv

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)

inv1

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

inv2

That’s all!

 

AzureAD admin is in the new Azure Portal!

Hi there!

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:

azuread.PNG

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

Cheers!

 

Update DirSync to AAD: Part 3

Once you have installed your new AAD, it will start a synchronization, but a really cool feature that Microsoft guys have added is when you install AAD, it creates an scheduled task in the local machine, so if you need to change the sync interval o need to run manually the synchronization is it possible!

The only thing that you will need to do is to access to scheduled tasks and modify the programability of the task to adjust the frequency. Once that is done, is enough!

Hope that helps!