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 OVERIf 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 ADIs 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 😉
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:
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
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.
Hi! I will participate in the Spanish track of the GlobalAzure event, I will talk about security, AzureAD and best practices. If you want to knowmore, check out the agenda: https://globalazure.es/#schedule
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
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
Albandrod's Memory 