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
Have you ever tried to create an AzureAD application to give SSO access to an OnPrem application? I had to do it with an SAP application, the process it is straightforward, but what about giving permission to end users?
You can give nominal permission to each user who needs to access to the app or even group, but you must be aware about group limitations:
Group-based assignment is supported only for security groups. Nested group memberships are not supported for group-based assignment to applications at this time.
My Customer had a complex role based user permission model, so it was impossible for them for using AD/AAD groups. The workaround it is not being granular giving user permissions, it is to grant Everyone access to the app registration. To do this, we must select the “User assignment required” option in the “Properties” blade on the enterprise side of the app registration to no, which allows all logged in users to have access to the service.
Doing this, we rely on the permission given to the app to access
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:
Hacker will continue to try to breach in our systems and try to access by the weak link in supply chains. For this, we need to reduce privileges for internal and external accounts, and not forget about machine identities
Every business needs to reduce his own Attack Surface, to reduce the blast radius of any exposure or incident. To achieve this, tools that provide visibility into identities and activities are essential, we need to be sure of what happened and respond quickly to those incidents
Protect the data is your responsibility, try to plan and build security controls for your cloud migration roadmap
Zero Trust will continue growing, but remember to keep in touch with all the components: network, identity, permissions, configurations… The need of tools that give visibility is essential here.
Currently we put the focus on protecting our user identity with MFA controls, but what about machine identities? These identities and permissions are being exploited in every breach to make lateral attacks, so we will need to be aware of that during the next year.
For now, I think that it’s all, stay tuned to the blog and happy new year!
Probably you’re asking yourself what’s a jump host? So in simple words, is a virtual host which is not the same as you use daily to read e-mail, browse the web, install software, but is used to perform administrative tasks for one or multiple IT infrastructures.
These are some of the recommendations that I follow when I need to deploy a jump host in Azure. The first two, are the most important, you have to be sure of not doing any of these
Do NOT install any productivity tools such as Office, it’s important to keep the VM as clean as possible, it’s only a considered to be a jump Host, not a working device.
Do NOT use this VM for general internet browsing purposes
and other some recommendations…
Isolate the VM with NSG, only is need to access where it is really needed
Install the AntiMalware extension from Azure and configure Windows Defender Settings
If possible, configure JIT on the VM
Onboard the device in Microsoft Defender for Endpoint (if Possible)
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:
Resist Common attacks
Contain successful attacks
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:
Antipattern – Requiring long passwords: excessive length passwords (more than 10 characters) can result in a behaviour predictable, users tend to choose repeating patterns (heyholetsgoheyholetsgo) that meet the character length but clearly not hard to guess. We can say that this kind of passwords are hard to guess but lead to poor behaviours to guess the password.
SuperPRO Tip: You can use a long password, but in this case what I recommend is something that engineers from Microsoft do. They use a very loooooooong password, they forget it, and instead of it, they use passwordless mechanisms such as Windows Hello to sign in.
My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.
Antipattern – Require use of multiple character sets: probably you’re not in the same line as me, but I’ve seen that this rule do more harm than good. People use patterns as substitutions such as $ for s, @ for a, 1 for I. So keep it in mind
Antipattern – Password expiration: Policy expiration drive users to use very predictable password (for example, the next password can be predicted on the previous password), end users do not tend to use a new password, the tend to update the old one.
My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity
Recommendation – Ban common passwords: For me, the most important restriction is to ban the use of common password to reduce the possibility of brute force or password spray attacks
Tip: Look at my first tip 😊
Recommendation – Educate end Users not to use organization credentials anywhere else: Yes I know that educate users are difficult, but you have to do it, because the tend to reuse the same password across multiple sites. It is a common practice for cyber criminals to try compromised credentials across many sites.
Recommendation – Enforce MFA registration and enable MFA: ensure that users maintain their security information up to date, so they can respond to security challenges if needed. Doing this, I have seen that end users are more implicated concerning digital security
Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.
EndUser TIP: Consider turning on two-step verification everywhere you can
Recommendation – Enable risk-based Authentication: when the system detects suspicious activity, it challenges the user to ensure that they are the legitimate account owner. Personally, I think that this feature is great, but the only drawback that it is only included with AAD P2
Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!
SSH File Transfer Protocol is a very common protocol used by many customers for secured file transfer over a secure shell. Microsoft did not have a fully managed SFTP service in Azure, but now is it possible to do it with Azure Blob Storage.
So, you will be able to use an SFTP client to connect to that storage account and manage the objects inside and even specify permissions for each user.
But before beginning, you will need to register the SFTP feature in your subscription, to do that you have to type the following:
# Set the Azure context for the desired subscription
az account set --subscription "xxxx-xxxx-xxxx-xxxx"
# Check if the live tier feature is registered first
az feature show --namespace Microsoft.Storage --name AllowSFTP
# Register the live tier feature on your subscription
az feature register --namespace Microsoft.Storage --name AllowSFTP
Also, you can check that information in Preview Features option in the Azure Portal:
Once you have that, you will need to enable the hierarchical namespace in the storage account, note that you can’t enable that on an existing storage account…
BEFORE
AFTER
At the time of writing, I couldn’t create the FTPS service through the Azure Portal or event with template, when I select WestEurope as destination, in the future I’m sure that would be supported
Now, we can deploy the ARM template to the RG previously created in Azure, but, previously to do that, you have to decide if your user will connect through Password or a SSH Key. In my case, I decided to implement it with an ARM Template with SSH key, but first you need to generate an SSH key pair:
next I provide the two ARM templates for both types of implementation
Being able to work with external people of your organization, would be possible thanks to an update that Microsoft is being working recently.
As many of you probably know, when you are using a team in Microsoft Teams, commonly not only involve people from inside the organization, also projects includes people from other organizations, where they have to struggle to be able to catch day to day notifications and files inside those Teams.
Currently, the only method to be able to stay up to date to all the work in different organizations it was to use third party plugins or even to have multiple windows of Teams, being a nightmare to cope with that.
Thus, reduces the productivity of the employees, but also increment problems of security, not only in terms of sign-ins also in terms of information shared…
For those reasons, Microsoft has been working in two updates related with Mirosoft Teams Connect and the access capacities of AzureAD to facilitate the collaboration between orgs.
The first feature includes shared channels which allows that people and teams of different organizations could work in the same Mirosoft Teams without changing the app or event the org where the you are set, which under my point of view is simply fantastic
This feature will be release at the beginning of the next year, but if you’re working under Microsoft org with other Micorosoft Teams, you will be able to see in which direction are taking these new updates.
In my case, the screenshot is from the Microsoft corp teamd organization, but no only shows the Microsoft teams from the Microsot tenant, it also shows one of the teams from the company where I work (showing labelled as external), because I’m connected with my work account.
Also the users would be able to program a meeting in a shared channel, use other applications of Microsoft, and of course, shared the channel with up to 50 teams and external orgs.
From the IT perspective, as always it can be controlled and shut down, in order to configure the “trust relationship” between tenants, and differentiate the collaboration between orgs.
This new features have been highy demanded in the last few months, and probably it will allow Microsoft Teams to be a key tool to communicate internally and externally without problem.
Albandrod's Memory 