AzureAD Deprecations

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

Functionality, feature, or serviceChangeNew tenant change dateCurrent tenant change date
Microsoft Authenticator app Number matchingFeature changeFeb 27, 2023Feb 27, 2023
Azure AD DS virtual network deploymentsRetirementMar 1, 2023Mar 1, 2023
License management API, PowerShellRetirementNov 1, 2022Mar 31, 2023
Azure AD Authentication Library (ADAL)RetirementJun 30, 2023Jun 30, 2023
Azure AD Graph APIDeprecationJun 30, 2023Jun 30, 2023
Azure AD PowerShellRetirementJun 30, 2023Jun 30, 2023
Azure AD MFA ServerRetirementSep 30, 2024Sep 30, 2024

More info at: https://learn.microsoft.com/es-es/azure/active-directory/fundamentals/whats-deprecated-azure-ad

Also, if you want to check out the Azure Deprecations in interactive view, you can visit the following link: https://azurecharts.com/timeboards/deprecations

Advertisement

Seven Essential Security Configurations for Microsoft 365

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!

 

Conditional Access Tips From the Trenches

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 😉

Till next time!

OATH Hardware Tokens for AzureAD

As you probably have been reading in my previous posts, I’ve been talking about FIDO2 keys, and how it can be used as a secondary authentication when signing in AzureAD.

Today, I want to talk about OATH hardware Tokens, known as Time-based One Time Password Tokens as well.

As you are aware, some authentication methods can be used as the primary factor when you sign in to an application or device, such as using a FIDO2 security key or a password. Other authentication methods are only available as a secondary factor when you use Azure AD Multi-Factor Authentication or SSPR.

The following table outlines when an authentication method can be used during a sign-in event:

But, OATH TOTP is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes. OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token.

In this post, I will show you how the OTP C200 token from Feitian can be configured in Azure AD and how it works.

First of all, what you have to do is to register the key in Azure AD, in order to do this, you will need the Serial Number from the Key, and the secret key provided by the manufacturer, and then you need to create a CSV file with all the information:

Once you have done this, these keys must be input into Azure AD: Multifactor authentication – Microsoft Azure

Upload the file, and activate the key in the portal, once it is have been done, it will show you a screen like the following:

If you have any error during the upload, it will be shown in the portal itself:

You must consider that you can activate a maximum of 200 OATH tokens every 5 minutes.

Also, as you probably figure out, users may have a combination or OATH Hardware tokens, Authenticator App, FiDO Keys, etc…

Be aware that users con configure their default sign in method in the security info web: My Sign-Ins | Security Info | Microsoft.com

So, once the key has been configured for the user, which is the flow to access to the account?

I have compared the Authentication flow with the Fido2 Key Flow, the difference that you can appreciate is with FiDO2 Keys is not necessary to include my password

Finally, check out the following table from Microsoft, where you can see different persona cases and which passwordless technology can be used for each one of them

IMHO, FiDO Keys are great, but thinking as an end user they have problem: the first setup: We must rely on end user about how they configure the key and associate it with azure AD (remember the previous table). FiDO keys has the advantage to be able to be used to sign in instead of using a password in the computer.

In the other hand, OAUTH keys are great, because you as an administrator, can configure the keys in the AAD Portal, and once have been activated provide them to end users, without necessity to do any other action from the end user perspective, and the most important part, are very easy to use

Thanks to Feitian for providing such amazing tokens

You should remove that basic authentication from Exchange…

Now more than ever, you should disable your legacy authentication in Exchange Online, last year Microsoft announced that they will remove that basic Authentication next October (https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-deprecation-in-exchange-online-may-2022/ba-p/3301866)

Did you know that:

  • 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
thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							New tools to block legacy authentication in your organization

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.

What are you waiting for?

Meet Microsoft Entra

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:

  1. 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.
  2. The Azure portal at portal.azure.com will also continue to offer Azure AD for Azure customers.
  3. 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.

More info at: Secure access for a connected world—meet Microsoft Entra – Microsoft Security Blog

The mystery of non-access to DevOps

This history began with a new dev project, we needed to be included in a DevOps Project inside the customer organization.

We were first invited to the Teams group to collaborate, upload the documentation and so on, so our users were first created in the AAD of the customer, till here, no problem.

But then, the customer created the DevOps project, and he invited us to collaborate in the project, we received the mail, but when we tried to access, we were receiving the following error message:

We were pretty sure, that we had access to the project, we were checking with the customer the access, and we were having access, we waited some time to replicate the permissions change, but nothing, so where was the problem?

The error page shows that we do not have access, so after digging a while with the problem, I realized that when I tried to navigate to the organization URL, in Edge was showing the error message that could lead us to something:

So, the problem is that guests are not allowed to access to the organization (TF909091), so how we can solve that problem?

Pretty simple, we need to ask the customer, to go to the organization settings and modify the security policies:

Also, to check if in the policies of the project, the check was allowed:

After doing that, we were able to access to the DevOps project, and start working

Problem and mystery solved!

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!