In the past, security decisions were rarely included in the planning when it came to combining networks after companies merged — just getting the two systems up and running and talking to each other came first and foremost.
It was standard procedure to disable workstation firewalls, enable server message block (SMB v1) protocols and in general do everything the C-suite wanted. But in doing so, we made choices that not only added complexity but increased weaknesses in our networks.
Case in point was the long-standing tradition of setting up domain trust — migrating or joining the existing domain was just not done; rather, a domain trust and possibly multiple forests were set up and you went on with your business. The larger the firms, the more likely you merely connected the multiple systems by whatever means possible.
But neglecting to take time to review the existing infrastructure, folding in what worked and throwing out what didn’t, introduced complexity, insecure permissions, and typically a lack of understanding of network infrastructure.
Merged systems should ideally get a top-to-bottom review
In an ideal world, all network settings and options would be reviewed before businesses are integrated. Clearly none of us live in an ideal world, and unfortunately security teams must often plead the difficult case to a business that resources need to be taken from other projects to review infrastructure that is already working.
First and foremost, plan that you will be compromised, not that you might. Secondly, ensure that you identify your key Active Directory assets and consider the worst-case scenario of having to rebuild an Active Directory infrastructure from scratch — a daunting task. Ideally you will have an offsite and offline backup and have practiced the recovery of your domain. As with any recovery process, the more complicated it is, the harder it will be to recover from an attack.
Ideally if you have more than one Active Directory forest with trusts, you would use the time afforded to you by a temporary trust relationship with the new acquiring company to review all of the settings with a top-to-bottom assessment.
Review forest levels to determine available security features
Review the existing file permissions, applications, management tools, users, and prepare an analysis of what Active Directory components are legacy and should be removed. Especially review the forest level of the firm to determine what security features you can now implement if the schema is updated.
Certain security features are only available with certain domain and forest functional levels. For example, with Server 2016, Privileged access management (PAM) using Microsoft Identity Manager (MIM) are available with Server 2016 forest functional levels. Server 2016 Domain functional level allows domain controllers that can support automatic rolling of the NTLM and other password-based secrets on a user account configured to require PKI authentication.
This configuration is also known as “smart card required for interactive logon.” Domain Controllers can support allowing network NTLM when a user is restricted to specific domain-joined devices. Finally, Kerberos clients successfully authenticating with the PKInit Freshness Extension will get the fresh public key identity SID. These are not available if you have a server domain infrastructure based on Server 2012 R2.
If your domain is based on a Server 2012 R2 domain functional level, you can implement domain controller-side protections for protected users. Protected users authenticating to a Windows Server 2012 R2 domain can no longer authenticate with NTLM authentication, use DES or RC4 cipher suites in Kerberos pre-authentication, be delegated with unconstrained or constrained delegation, or renew user tickets (TGTs) beyond the initial four-hour lifetime.
For authentication, server 2012 R2-based domains can use forest-based Active Directory policies that can be applied to accounts in Windows Server 2012 R2 domains to control which hosts an account can sign-on from and apply access control conditions for authentication to services running as an account.
An authentication policy silo controls which accounts can be restricted by the silo and defines authentication policies that apply to its members. A forest-based Active Directory object can create a relationship between user, managed service, and computer accounts to be used to classify accounts for authentication policies or for authentication isolation.
Review group policies from each company
You’ll want to review each companies’ group policy and what is used by each former entity. Consider removing any old group policy settings that either no longer do what was intended or were originally built for older operating systems. My recommendation is to review any group policy setting that was first introduced in older operating systems.
If the setting indicated it works on Windows XP and later, flag it and review whether you still need that setting or if it no longer works in your network. Teams will often discover that group policy settings a domain was once built around are in fact no longer doing what they were intended to. Windows update policies in particular are often out of date and no longer providing an optimal user experience.
Also investigate if the organizations still have on-premises Exchange or email implementations. It is to the point now that hosting your own email is no longer a reasonable option for businesses to take. In addition, the addition of older Exchange releases can introduce settings and permissions that not only add insecurity but complexity as well.
Review whether an Exchange server has ever been installed
Don’t forget to determine if your network has ever had an Exchange server installed. The Exchange Active Directory schema changes introduce permission changes that could have long-term impact on a network.
For those networks that no longer host Exchange, teams should run a Github script to ensure that the network is no longer impacted by the vulnerability noted in CVE-2021-34470. If you have a hybrid network, you’ll want to also review the impact to your network as noted by the Microsoft Exchange team in a blog post.
Of course, I would be remiss if I didn’t also remind you of a key deployment that everyone should be doing at this time, or at a minimum reviewing if you need to upgrade to the latest version of it, the Local Administrator Password Solution (LAPS).
Microsoft recently introduced Windows LAPS in updates to various platforms. Be sure to install updates to platforms including Windows 11 22H2 – April 11 2023 Update, Windows 11 21H2 – April 11 2023 Update, Windows 10 – April 11 2023 Update, Windows Server 2022 – April 11 2023 Update and Windows Server 2019 – April 11 2023 Update.
Note that Windows Server 2016 is not included, legacy LAPS can be utilized. LAPS manages the risk of common shared local administrator passwords to ensure that attackers can’t obtain or guess one and then gain the credentials for all domain joined systems in the network.
Take the time and invest in the long-term security of your network by having your Information technology team review the foundations of your network. You might be surprised what you find.