This product is becoming very popular among my customers specially when they’d purchased Microsoft 365 E5 LIcenses, but, let’s have a look how we can implement this technology in our business.
But first, What is Defender for EndPoint? It’s an enterprise endpoint security platform designed to help enterprise networks prevent, detect, investigate, and respond to advanced threats. Also we can onboars servers and devices indepently to the service, which is great.
What is very cool, MDE is not only available for Windows, also for iOS, Linux and Android, so we can cover almost all the spectrum of corp devices.
And most important, Microsoft Defender for Endpoint integrates seamlessly into Microsoft Endpoint Manager. You only must activate the Intune integration ones during the initial setup and your reports will flow into MEM. This allows you create and configure Security baselines, which are pre-configured groups of Windows settings that help you apply the security settings that are recommended by the relevant security teams.
If you’re using an existing AV solution, you can check out the following guidelines to migrate to MDE:
If you have an existing AV, configure Defender as an exclusion
Onboard devices to MDE
Run detection test
Update MDE database
Final Phase: Microsoft Defender also recommends activating different features in order to increase the security level of your desktops in the Security recommendations tab. In there, you can find multiple settings that you can directly enable and push into Intune when you set up the connection correctly to your Intune tenant environment. But for me the most important are:
As you probably now, phising is being a great threat to every organization, we receveid a lot of malicious contacts, from email to SMS, or lateley even phone.
In the blog, I’ve been taling about technology and how this technology can help administrators to avoid certain threat, but what about the end users? Can we help them of how to identity phising attempts? Yes, of course, let’s talk about some of them:
First of all, I want to talk about corporate branding, do not think in terms of marketing deparment, think about helping users to identify phising. For example, every tenant has the same identical login page, but doing some customization with:
with these easy configurations, we will help users to identify threats
Another thing that I strongly recommend to my customers is to use the Microsoft Report Message Add-In, which allows them to report malicious messages directly to Microsoft.
This addin can be deployed centrally to all users 🙂
Finally, if you have the proper license I strongly encouraged you to run regular phising campaigns inernally. With Microsoft Defender for M365 it is very easy. The main point here it is not to catch users, is to awarn them about the threats of clicking in a email.
That’s all, as you probably know, technical solutions does not prevent all situations that we have everyday, so what it is most important is user awareness which will be the first point of security of your organization.
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:
Improve security with crypto-secured passwordless authentication
Remove the helpdesk costs associated with forgotten passwords by replacing them with a simple PIN or fingerprint
Remove the user-experience annoyances of long passwords to create, remember and reset so that your workforce can get on with their role simply and seamlessly.
What about the preparation of AzureAD?
For IT, At high level there is only two tasks to accomplish:
Enable the new authentication method registration on AzureAD
Enable FIDO2 as an authentication method
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:
Control to ensure that the employee has been through sufficient identity checks to create a trusted identity.
The organisation needs policy control over:
The type of FIDO device used (external USB / Bluetooth)
The organisation needs to consider the type of user verification required (Fingerprint / NFC)
The end user needs a simple experience during registration of a FIDO credential
The organization needs to trust the genuineness of the FIDO device being used for the FIDO credential
Vision of who has been assigned which FIDO Credentials
Ability to simply revoke access to all systems accessed by the FIDO Credential
Ability to manage lost devices / replacement devices / back up devices
The end user needs a simple experience to authenticate to systems, usernameless aids this process.
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…
Consider how the authentication process has traditionally worked: Organizations require users to supply a user ID and password. Then, the user can go on to access all the data, applications and other resources they’ve been granted permissions for. But what about if an attacker has stolen a user’s credentials? How can we reduce these risks? It is where Conditional access takes place 🙂
But the question is, do I really need it? It depends your case or scenario 😛 but let’s dig in depending in what you’re using:
Security Defaults: To help organizations establish a basic level of security, Microsoft makes security defaults available to everyone at no extra cost. This feature automatically enforces the following policies:
All Users must register for AzureAD MFA
Users must complete MFA challenge when they authenticate using a new device or application
Administrators must complete an MFA step every time they sign in. This policy applies to nine key Azure AD roles, including Global Administrator, SharePoint Administrator, Exchange Administrator, Conditional Access Administrator and Security Administrator.
Any user trying to access the Azure portal, Azure PowerShell or the Azure CLI must complete additional authentication
All authentication requests made using older protocols are blocked
Azure AD COnditional Access: But as you can imagine, in some organizations these security defaults are not enough, they want to have more fine-grained controls, so to do this we need Conditional Access, which allows us to:
create a policy to require administrators — but not regular business users — to complete an MFA step
Use the user location and the type of protocol being used to restrict the access
Deny all requests that comes from a particular country, and require MFA for the rest
As you can see, you can create multiple policies that work together to put guardrails in place exactly where you need them
Azure AD Conditional Access is an extremely valuable tool for helping you implement a Zero Trust model, protecting the three cores of the strategy:
Least privilege — Helps to grant the right access at the right time to only those who need it by enabling trusted locations and IP ranges, implement stronger controls for privileged users, and control access to sensitive applications and content.
Verify explicitly — Continually verify identities as users move around the network by requiring MFA when users appear on new devices and from new locations.
Assume breach — Weak passwords, password spraying and phishing all but guarantee malicious actors are inside your network. It allows to block legacy authentication and putting stronger access controls in front of your most valuable resources.
As you can see, Azure AD Conditional Access is a powerful tool for strengthening security and ensuring regulatory compliance
In this ocassion I will talk about my experience working with the new version of AADJoin for AVD which is finally in public preview. So with this approach we can eliminate the need to have a domain controller or AADDS in place for your AVD deployment to work, but as you can imagine it has some drawbacks.
First important thing that you have to be aware of implementing this type of scenario is that when you’re adding the VMs to the HP, it is necessary to select the following option:
Also is important to check wether is we want to join the VMs to Intune or not, in my case I selected yes, and after a few moments of the VM creation, I was able to see it in the endpoint portal:
After you have created the HP, my recommendation would to configure it, you can use the following advanced RDP properties:
use multimon:i:0 which basically Determines whether the session should use true multiple monitor support when connecting to the remote computer
To access Azure AD-joined VMs using the web, Android, macOS, iOS, and Microsoft Store clients, you must add targetisaadjoined:i:1 to the HP. These connections are restricted to entering user name and password credentials when signing in to the session host.
But, what is more important for me, and it was driving me crazy at first, it was the authantication in AVD AADJoined:
The following configurations are currently supported with Azure AD-joined VMs:
Personal desktops with local user profiles.
Pooled desktops used as a jump box. In this configuration, users first access the Azure Virtual Desktop VM before connecting to a different PC on the network. Users should not save data on the VM.
Pooled desktops or apps where users don’t need to save data on the VM. For example, for applications that save data online or connect to a remote database.
So, don’t break your head trying to authenticate with your current user as in WVD Joined Domain, you will need to use a Local profile for AzureAD Joined VMs, if not you will receive an error like the following which will drive you nuts:
But after using the local user in the VM you will be able to log in the VM.
Once you log in to the VM, you can check the dsregcmd to see the status:
And also how the machine is enrolled in Intune, you can check the information regarding the enterprise registration 🙂
For me AVD AADJoin, it is a pseudo Windows365 but with custom images and without paying the full license to access to the resource itself. The other things about AVD and AADJoin are pretty the same as Domain Joined, so have fun with them
While I was doing a PoC about Defender For Identity in one of my costumers, I decided to take one step further and try to work with all the Defender capabilities enabled in the VM.
In this case, I was preparing Defender for Identity, but also Defender for EndPoint was enabled on the VM, so… I started playing:
The first thing, is when I tried to run mimikatz on the VM:
I leaved intentionally Windows Defender on, and not only it blocked the program, it was erased from the VM, so first thing cool.
Also, this execution fires some alerts in the defender for endpoint portal:
Wow, a lot of information to start… So iesn order to carry on my tests, it was necesary to deactivate Windows Defender Protection:
But once I have everything in place, and I have executed my test, what I can see from the different security products is the following:
Azure Defender has been talking a lot with all the products, firing a lot of alerts in my environment, I have to say that not only I have Defender for Identity, also Defender for Endpoint and Sentinel, so all my alerts are being correlated in my workspace.
So I can dig into the alerts in order to know what is really happening in my environment:
For me, all the variants of Defender & Sentinel, are great tools to protect our environments from external threats 🙂