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

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
Problem and mystery solved!
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:
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!
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!
Nobody can doubt that 2021 has been the year to adopt the cloud (due to COVID of course), mostly because most of us needed to work from home. We can say that business has changed and “Probably” will never go back to was it was.
Remote work will continue growing, so in 2022 we will need to protect our assets much better, and for this, here are my predictions/concerns for the next year:
For now, I think that it’s all, stay tuned to the blog and happy new year!
The following are recommendations and thoughts that I extracted by working with several customers, maybe you will find it obvious, but for other people could be useful. So, let’s begin:
In the identity plane, we could say that exists 2 categories:
I don’t want to enter of how to resist or contain attacks, because probably I covered some of these topics in other blog entries, but for me, there is another category which is: understand the human nature.
Nothing more that understand that almost every rule that we impose to the end users, result in degradation of security. Why? Because we force users to use long passwords, with special characters, and in the end, users tend to reuse passwords which makes easier to guess or crack passwords for malicious actors.
So, in the post I will resume some of my experiences as AntiPatterns and recommendations:
My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.
My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity
Tip: Look at my first tip 😊
Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.
PRO TIP: Use Conditional access with FIDO2 security key (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (albandrodsmemory.com))
EndUser TIP: Consider turning on two-step verification everywhere you can
Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!
Do you want to check out my last collaboration with the spanish magazine “CompartiMOSS“, I’am talking about the changes in licensing for Azure AD External Identities
I hope you enjoy it!
If you want to audit or strenght your security posture in AzureAD, OnPrem or M365, Microsoft has published a guide with which points you have to tweak in order to improve your (or your customers) security: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/security-operations-introduction
Sometimes it happens, users syncronized from OnPrem to AzureAD, are not being soft matched, and it’s necessary to do a hard match, in this post I will explain the basic steps to do it:
Start-ADSyncSyncCycle -PolicyType Delta
Remove-MsolUser -UserPrincipalName <user> -RemoveFromRecycleBin
ldifde -d "CN=username,CN=Users,DC=domain,DC=local" -f C:\user.txt
objectGUID::
in c:\user.txt
Set-MsolUser -UserPrincipalName <upn> -ImmutableId <objectGUID>
Start-ADSyncSyncCycle -PolicyType Initial
With this, what we are doing id a hard match for the user, once is done, you’re ready to go
This is something I wanted to test some time ago, and now thanks to Feitian I was able to do it. So let’s dig into detail what is passwordless with Fido2 Keys, how we can configure it in AzureAD, and what advantages provide as an end user. ¡Let’s begin!
But before dig in depper, let me explain the basics: A security key is a piece of hardware that you can connect to your computer or phone to verify your credentials when logging, unlike a password, it’s completely safe, because the configuration is different for each system.
So, what does Fido2 Keys? As you probably know, logging into a resource requires a username and password, and with MFA, it usually requires a username/password combination plus one other authentication factor, like a time-based one-time password. In this case, FIDO2 is a standards-based method of user authentication that is passwordless, supporting PIN and biometrics in security tokens
For starters, with FIDO you can:
What about the preparation of AzureAD?
For IT, At high level there is only two tasks to accomplish:
Easy, isn’t it?
What about the registration for end users?
In my case, how the security Key is a biometic security Key, what i needed to do first is to register my fingerprint. Once I did this (manufacturer provide details, you’re ready to go with next steps).
In order to register the security token with AzureAD, the user will need to access to https://aka.ms/setupsecurityinfo where will be able to see all the authentication method available for them:
And once the user have selected the security key option, the process of registration will begin. In my case, I selected USB device and then… I needed to provide a PIN for the security Key:
Things that you have to keep in mind, is we user have to set up their own PIN to use their key, it cannot be enforced or centralized way to manage PIN, so is probably that your users end up using PINs like 123456.
ONce you have registered the key, it will appear in the security Info Panel:
Ok, it’s great what you’re are explaining, but how it is used?
With the following video, I want to show how the process of passwordless authentication in AzureAD is done:
As you can see, the login was done without entering any user or password. If you’re conviced, and you want to start deploying Fido2 Keys in your organization, think first about the following points:
Registration
Issuance
The organisation needs policy control over:
Lifecycle Management
Authentication
As you can see Fido2 Keys are great, and what is better, not only works with AzureAD, it can be used to authenticate with oter services like twitter, Instagram, etc…
Register your key at https://aka.ms/mysecurityinfo
If you are a Microsoft 365 admin, use an interactive guide at https://aka.ms/passwordlesswizard