[MUSIC PLAYING] A number of organizations, a lot of organizations when we come in and do Active Directory security assessments, there's some common things that we see. One is we see that there are group policies that are in the domain and the domain controller's OU that are linked there, [? the ?] default ones. Those often stay defaulted. A lot of organizations will just kind of ignore those. They don't realize that there's applications that can get installed in the environment that actually update those, change the user rights assignments.
I've been talking about for years the fact that the default to the main controller's policy user rights assignments is a goldmine for attackers because some of the worst delegation of permissions happens through this policy. Some of the other issues that happen in the organization is that companies and organizations are looking at what the group membership is, who's in the main admins. And you focus on the main admins and forget about administrators.
They don't look at the permissions that are delegated at the main level, which is a key identifier, or the delegation that occurs at the AdminSDHolder object, which directly through a process in Active Directory automatically updates those permissions that are on the most privileged groups and users in that environment. So through that permission delegation, groups can have rights without anyone knowing it if they're not looking at those permissions.
The other thing is that through group policy, you can deploy and add groups in Active Directory to those local groups, such as administrators. So without looking at the group policy as well to see what the restricted groups are or what the groups that are being updated with AD groups, it's difficult to know what the rights are.
So one of the challenges with Active Directory is knowing what rights all the different groups have in Active Directory without parsing through and identifying the group membership, the group policies that update local admins groups or other local groups, looking at the user rights assignments as well as the delegated permissions in the environment. So pulling all that together can be a big challenge for most organizations. And that's a tough visibility gap to overcome.
One of the biggest issues that I think every organization has when it comes to Active Directory is that there are limitations in the native tools. Group policy management has been around since the beginning of Active Directory. But there is no workflow of check in, check out, seeing who's modified things, what settings have changed. It's difficult to track that.
Now, you can do that manually through PowerShell by pulling reporting off of it, doing some comparison between the files, looking at last modified dates, so that's one way that that could be viewed. One of the things that organizations really should be doing is looking to see who has the ability to modify those group policies, especially at the domain level and domain controller's OU. And one of the biggest visibility gaps in Active Directory today is with permissions.
There are permissions that have been there since AD was deployed. So organizations that have employed AD in 2000, 2001, 2002, so-called "early adopters," often have these Active Directory permissions that have just been layered on top of layers on top layers for many, many years. And a number of times, these permissions relate to groups that aren't used anymore. But the groups still exist in AD and still have those permissions. So the native tools are not good enough for looking at the permissions.
[MUSIC PLAYING]