Site icon Martin Haller, A blog about corporate IT protection and management

Moving to Azure Active Directory

martinhaller

I feel as though time is constantly accelerating. My TO-DO list is getting longer and longer. I work as the situation allows. Yet, it’s not enough to realize tasks and ideas (like moving to Azure Active Directory) faster than they accumulate.

I started writing this article before my vacation and wanted to publish it with my departure. In the end, I am completing it in a room, at four o’clock in the morning, because a six-hour “jet lag” keeps me awake… Man proposes, life disposes. This is the proverb I have had in my mind most frequently lately… I hope you will like it.

Transition to Azure Active Directory

Currently, we have the last customer who has their own on-premise MS Exchange. And even they have their own M365 tenant. Everyone else has migrated to M365, using Azure AD, Exchange, SharePoint, OneDrive, and Teams. In this respect, the IT environment has changed significantly.

I remember how, back in 2018 at an ESET partner meeting, I didn’t believe the vision of one of the ESET partners regarding M365 (then still Office 365). Back then, I couldn’t imagine that companies would want to pay hundreds of crowns per user per month just for email services. Now, almost five years later, it is the standard. In fact, contrary to my expectations, some companies even pay several times more (higher hundreds of crowns) for additional services, every month, for each user.

We at PATRON-IT also use M365. We have just had it separated from on-premise infrastructure so far (we don’t use AD FS or Azure AD Connect). Many years ago, I decided this for security reasons. We didn’t have much knowledge about AAD (Azure Active Directory), and I wanted to maintain a smaller “attack surface”.

However, we are now making a larger investment in hardware renewal (stations and servers – see the next chapter), and with it comes the opportunity to make a “big bang”. I feel that AAD is starting to mature (it has enough functionality, and bugs are fixed), so we will try to switch from on-prem AD directly to “AAD only” (we will skip the hybrid mode AD+AAD).

What We Expect from the Change

I believe that in the future, more companies that will no longer have on-prem AD will emerge. It will mainly be newly established companies that can start on a greenfield. We are already managing two such companies.

By going through this process ourselves, we will be better prepared for this situation (knowledge, experience, best practices). At the same time, I believe that, with the new possibilities that M365 brings, we will be able to achieve higher security.

What I Plan to Utilize

As MS partners, we have access to M365 E5 licenses – so we can experiment with almost everything that Microsoft offers. Therefore, the basis will be Azure AD, Conditional Access, Intune, and Defender for everything.

Azure Active Directory

Gradually, I would like to connect the authentication of other services and software to Azure AD. This way, I can manage login requirements through Conditional Access: requiring a company device for login, strength of verification, or a compliant device. At the same time, all logins will be logged to one place and evaluated (Identity Protection).

FIDO2

For logging in, I would like to use FIDO2 keys with biometric verification. It’s essentially one of the strongest verification methods that is comfortable and (so far) immune to phishing. Compared to a mobile authenticator, a hardware key cannot be remotely hacked.

I believe that this could be the method we could deploy to customers in the future:

Defender for *

In one of my previous articles (Why I want to deploy EDR to all customers), I describe searching for an ideal EDR for our use. Several times I thought I had found it – but in the end, there was always something about the product that didn’t suit us.

Now we will try it with MS Defender. We already have some experience with it as part of incident solutions. We also have a customer who uses it as their primary antivirus. Monitoring scripts for our monitoring system are ready, so I believe it will work (I described other advantages I see in Defender in the aforementioned article).

Questions That Remain in My Head

Some technical details (and decisions) are clear. However, I am still hesitant about others.

PIM, or More Accounts

We will use the O365 account to log into PCs, VPNs, and RDP. We will also use O365 accounts for more privileged operations, such as access to customer tenant management (through delegated GDAP management) and password management (Devolutions server with RDM).

Therefore, I am considering whether to do it so that everyone will have their account and will use PIM. The other option is to set up two accounts for everyone. One account for regular work and the other one for privileged work.

I’m leaning towards the second option for now. I’m afraid that when colleagues log in to the VPN on home PCs (authenticated through FIDO2), Refresh/Access tokens of that user with MFA claim will appear on those computers – which does not seem entirely appropriate… However, I still have a lot of questions and need to study a lot more. Or possibly consult with someone who has deeper knowledge in this area.

Windows Hello for Business

I consider this technology as a great enhancer, allowing secure and simple (PIN, biometrics) login to PCs. The downside is that users must configure WHfB on every PC during the first login.

FIDO2 offers equally comfortable login on all AAD Joined PCs without the need for any setup. Essentially, I just plug in the USB key and touch it (this verifies the fingerprint and logs in – I don’t even need to enter the user account).

So, I’m not sure whether to block WHfB and use only FIDO2. Again, I need to study a bit more about the “internal” workings of these things and the security impact (whether it increases/decreases security).

For example, I suspect (just thinking out loud) that logging in through FIDO2 without WHfB won’t create a PRT token – this could mean a slightly smaller “attack surface”.

FIDO2 Key Manufacturer

Currently, we are using the “Kensington VeriMark™ Guard” key for FIDO2. It works reliably (fingerprints, etc.), it’s small and durable. Perhaps only the price is not the lowest.

I’ve also bought a YubiKey Bio for lab testing. It’s also reliable (although sometimes it doesn’t recognize my fingerprint [“false negative”] – then the question remains whether Kensington doesn’t suffer from “false positive” detections), it should also be waterproof. However, its size is not so practical. My goal is for the FIDO2 key to be attachable to the office key ring so everyone can carry it around.

However, I mainly need to consider the weight I give to the country of origin of the key (and possibly its certification level). After all, we will use this key for the most important tasks (access to all passwords and customer tenants).

Given the Western world’s concerns about Chinese products in 5G networks, shouldn’t we choose a product from an “allied” country as a precaution? This question was raised by an article from Eric Woodruff “Choosing A FIDO2 Security Key”.

Local Admins / Lateral Movement

Since the transition to Azure Active Directory, I hoped to get rid of NTLM and Kerberos authentication between domain PCs (AAD Joined) and to hinder lateral movement.

Ultimately, it won’t be that simple. Both Kerberos and simple lateral movement remain, in case a PC with a logged-in privileged user is compromised.

I mean the following. If attackers compromise some workstation/server where a user, who is also an administrator on other workstations/servers, is logged in, they can immediately control it. For instance, they run psexec under that user. All they need is the ability to run their code under the existing user session (in such case, “Conditional Access” and MFA are not applied). I wrote a bit about how it works in regular AD in the article “Our Observations from Security Audits in Companies” in the paragraph “Management of Workstations and Servers by Domain Administrator”.

So, I have to figure out how to make/set up an admin account for managing workstations without endangering the rest of the network by logging that admin account onto a workstation.

Conclusion

The transition to Azure Active Directory is a given. I just have to “figure out” the details. I will be studying during the vacation, implementing upon return, then fine-tuning for a few months. Eventually, it could make for a nice lecture regarding deployment/security in an AAD environment (from a different perspective than what I’ve seen so far).

If all goes well, I would try to register it for the annual Cyb3r Days 2023 conference, organized by friends (Dan and Honza) from Cyber Rangers.

Below, I also share links to interesting blogs/articles I’ve come across. Perhaps you’ll find them interesting as well:

And as always, if you have additional insights, questions, or if I wrote something inaccurately, I will be glad if you leave a comment.

May your networks stay secure,

Martin

Do you like topics, I write about?

It is not necessary to periodically visit my blog to check if there is a new article. Subscribe below for notifications. You will be the first one who will know about new article.

Exit mobile version