Microsoft has created new conditional access policy templates for protecting identities. Two of them are particularly good ideas to limit how a domain can be accessed and will create significant hurdles for criminals. One of them also can create a significant hurdles for remote administration too.
Block access for unknown or unsupported device platform
Block access for unknown or unsupported device platform is a great way to block criminals from the network. Logs demonstrate that criminals try to disguise their devices and have the report as unknown very often.
In the example above the Device type: Unknown(BAV2POPC) would be blocked by the this new conditional access policy. Over time, I have noticed that most non-legitimate attempts at logon come from devices identifying as Unknown.
This policy has the ability to limit access from known device OS’s too. Using this policy we can choose which OS’s we’re going to allow on the network at all. As in the policy below we’ve unchecked Windows Phone, MacOS and Linux because this domain isn’t expecting any of those devices. Now Azure AD will simply reject them.
Limited the device types that can join the domain is not only smart but it can also help with compliance. Most compliance regulations require that you track new devices on the network. This policy will help make that job smaller.
Require compliant or hybrid Azure AD joined device for admin
Require compliant or hybrid Azure AS joined devices for admins, means that an administrator must be using a joined computer to perform tasks. Very unlikely that a criminal is going to want to join their computer to the domain. That’s a level of commitment that is likely to expose them, even if they use a virtual machine.
This policy has two grants and both actually end up requiring that the machine be joined to the domain. One is a check within Intune and the other a check in Azure AD.
There’s a hurdle for remote management
Most remote management by IT firms is done from a device which is not joined to the domain. This creates a pretty big hurdle to overcome.
The solution would be to use an app that has oAuth permissions sufficient to do administrative work. That in itself creates risk because now a third-party application has those god-like powers in your domain.
The second solution would be for the remote management to take place on a virtual machine as the policy suggests. But to do so would generally require the MSP to have a bunch of virtual machines setup with one joined to each of their client’s domain.
Challenges with using virtual machines for admin tasks
Windows has Hyper-V built-in now and creating virtual machines for tasks is free so an MSP could do this without adding licensing cost. The Ubuntu machines are good for 5 years, or 90 days depending on the version selected and the Windows 11 dev environment is good for 90 days. The main hurdle might be simply where to store the virtual machines securely.
Once you’ve created your virtual machines, joined them to the domains and store them in a secure location. The final hurdle will be removing them from the domain when the time comes.
In Azure AD machine wipe can handle this task. Leave the user account enabled until the wipe has initiated. As seen in the figure below, there are two options for the Wipe action. Once will retain user data and the other does not and also remove the machine from Intune.
With the two conditional access policies in place and keeping admin management stations in the off-state except when needed will significantly reduce the likelihood of admin credential abuse. There’s nothing needed on the remote admin machine other than a browser and all of the usual MFA and account credentials still apply.
All we do is support IT professionals. Microsoft 365 technical assistance, Super Secret News, Security community, MSP Legislation community, EndPoint, Defender and Lighthouse community, Peer groups, Kits, papers, Business consulting and more. https://www.thirdtier.net
