Credit: Dreamstime
Once upon a time, the boundary that I worried about and considered that I was responsible for stopped at my Active Directory domain and at the firewall that protected it.
Then the boundary of my network moved from the computers under my control to the internet and the connected devices and cloud applications that I now have access to and am linked into.
We went from where the stakeholders of the firm were resistant to anything being in the cloud, to where we are now where we know we are half in the cloud and half still on premises.
No longer can I merely worry about the computers listed in my Active Directory users and computers snapped in, now I need to be concerned about applications and APIs that could create authentication links into apps that are inside my domain.
These days, usernames and passwords form the security boundary I need to be just as worried about. Where are these being used? Are they logging into a cloud application and resource that is connected into my network resources? Are my Active Directory authentication credentials also being used to authenticate via single sign-on? Are they syncing my data to a cloud resource?
You need to worry about more than just your domain
Now consider if you use various consultants and managed service providers. If they have access to your network either via having a username and password in your domain or a management tool that allows them remote access, you’ve just moved your security boundary to their security defenses. Get the idea that you no longer can stop at worrying about just your domain?
Just recently, the MOVEit vulnerability showcased that you can attempt to be as secure as can be and still be impacted by a piece of software you use in your domain. Notifications are now going out from agencies regarding the impact to customers.
Microsoft recently interviewed Sean Metcalf, an expert in Active Directory security, who showcased that the boundary we need to worry about no longer stops with Active Directory.
In the article, he touches on what ails many of our networks: we have set them up over a long time, and with many mergers and acquisitions impacting permissions and forest levels (sets of one or more domain trees that don’t form a contiguous namespace).
If your network is like mine, it was probably established years ago and migrated from an Active Directory that was set up when we didn’t worry about the security issues we have now. Show me a large firm and I’ll guarantee that its current Active Directory has accounts or services that have been set up with permissions that are too permissive.
Forest-level settings can impact security
Also, be aware that something that seems so minor as setting a forest level may impact the security posture of your firm.
Case in point, if you have a Domain Functional Level less than Server 2008, when KrbtgFullPacSignature enforcement goes into effect with July’s Windows security updates, you will see impact.
The AES keys for the krbgt account will be required. If you migrate up to a domain forest level above Server 2008, the krbgt account AES keys will be automatically generated.
n fact, if your Active Directory team can’t remember the last time you rotated your krbtg account passwords, now is the time to schedule this into your items of scripts to run on a domain and to do it on a regular basis.
The Active Directory evaluation tool called Purple Knight recently released a report on the typical issues they find when a security evaluation is made of a domain. In the report, they cite several key issues:
- Organisations are failing to adequately secure AD environments primarily because they lack visibility into risky configurations.
- Large organisations fare the worst because of legacy applications and complex environments.
- Lack of in-house AD expertise hampers AD hygiene efforts, particularly in small businesses or vertical markets with fewer resources.
They noted that larger organisations (5,000 or more employees) also had more critical indicators of exposure than smaller companies, with 63% reporting non-default principals with DCSync rights on the domain and 53% reporting permission changes on the AdminSDHolder object. Large organisations may even have anonymous access to Active Directory enabled.
Good security means checking the effect of network changes
Often in large organisations, there are users in your network who have the equivalent of Domain administrative rights and are not even aware of this. Your firm may have even inherited the setup of the domain with original accounts and permissions set for a Novell network that was migrated from years before.
Often the difference between a firm with better security and one with poor security is having a staff that takes the additional time to test and confirm that there will be no side effects in the network if changes are made. Take the example of unconstrained delegation; this is a setting that many web applications need to function, including those that are internal only to the organisation.
But this setting can expose the domain to excessive risk. Delegation allows a computer or server to save the Kerberos authentication tickets. Then these saved tickets are used to act on the user’s behalf. Attackers love to grab these tickets, as they can then interact with the server and impersonate the identity and in particular the privileges of those users.
This type of delegation was easy to set up and was originally the only type of delegation supported on servers. It’s these older legacy authentication methodologies that showcase that one cannot leave Active Directory as is and you have to continually look to how you can embrace new technologies without introducing more risk.
Older accounts need to be reviewed after implementing Azure AD
Enter Azure Active Directory and single sign-on. Many of us started our journey to Azure AD by wanting to merely sync our existing infrastructure into the cloud. Azure AD Connect is how many of us started our journey. We deployed it to our existing AD infrastructure and only after the synchronization was made, did we consider that possibly not all those accounts should have been synchronized.
Some firms still may have many of these accounts still synchronised that should be reviewed. Then attackers are finding new ways to enter our hybrid systems. Back in April, Microsoft indicated that attackers are finding ways to go after the Azure AD connector account and the AD DS Connector account.
If there is a local administrator on the server running the Azure AD Connect service, they will have the ability go find out what the password is to these two highly privileged accounts. A tool called AADInternals was used to gain access. If your firm is like many that migrated from older domains and used the DirSync tool and then upgraded to Azure AD Connect, that service account will still have Global Administrative rights.
Being a hybrid Microsoft customer means that you need to be aware that your legacy settings may be impacting your future security posture. Take the time to review what your past selections may be doing for your future security.
