Preventing Cyberchaos with AD Best Practices

Chaos. It is a fundamental principle of the universe. Everything trends towards it. Yet human nature rebels against it, trying to establish order. We spend time and effort imposing order in our lives, scheduling, organizing, learning, and mimicking best practices. When we succeed, we breathe a little easier knowing that the order we have imposed is generally accepted as the best way to do things. Why not invite some of these best practices into your Active Directory (AD) environment and rest better with the certainty that you have taken significant strides to eliminate some of the most urgent threats that your company’s computers face?

While entire volumes could be written on all the best practices available to follow within your active directory environment, rather than drone on like a monologuing supervillain, this blog will cover some of the key adjustments you can follow within your AD environment. Most center around administrative rights because those are for all intents and purposes, the keys to the kingdom. Depending on the type of administrator, they can allow access to a full computer or even to every computer on every domain within your entire network.

Clearly, these accounts should be safeguarded as much as possible. What then, can be done? One of the first things you can do is to rename the local administrator accounts. These are built-in and every system has them. There is no point in making things easy for a would-be cybercriminal by leaving these accounts with the default name. Change the name of the default administrator account in the domain and then on local systems using a Group Policy Object (GPO). Once you have done this, where possible, disable the local administrator account and replace it with another account as these accounts have a well-known Security Identifier (SID) that hackers can exploit even if the accounts are renamed. Consider blocking the logons for these accounts from interactive, service, and batch job logons as well as implementing logging and alerting for changes to these sensitive accounts.

Secondly, be judicious when adding accounts to high privilege groups. Does that software developer really need to be a domain administrator to do their job? Or would making them a local administrator on several select servers be sufficient? Always question your assumptions before adding users to a privileged group – it is easier than having to undo the damage (intentional or unintentional) later. Try to keep the memberships of groups such as Domain Admins, Enterprise Admins, and Schema Admins to a minimum. Schedule a regular review (at least quarterly) to go over and adjust these lists as appropriate. Similarly review who has local Administrator rights at least on sensitive systems and preferably on all systems. You can manage this and automate it via GPO, simplifying a review of these local administrator memberships.

Finally, consider the value of creating tiered administrator accounts. Even in a smaller environment, this can help limit the damage caused by a single compromised account. Use tiers as appropriate to constrain an account to a certain set of tasks. Ideally, your everyday user account should NOT be an administrator of anything. When installing an application with your user account, ideally you should get that occasionally frustrating pop-up requesting a username and password with the appropriate rights to continue. This helps protect your account from the inadvertent installation of spyware or malware because it lacks sufficient rights and at the same time prevents a compromised administrator account from being able to read all your stored passwords and financial data.

As an environment grows in complexity, more tiers should be added as appropriate. For a few PCs in a small office with no servers, user accounts, and Workstation Administrators may be sufficient. Adding a file server? Consider creating server administrator accounts that are separate from the workstation admins. Grown large enough to need a domain? Use a separate domain administrator account for situations that require the corresponding level of access. Big enough to have a highly complex or highly secure forest? You may want to consider adding additional tiers such as accounts for Enterprise Administrators or Schema Administrators.

The concept is this: Use at least two tiers at minimum to segregate the administrative rights from the everyday user tasks. Use as many tiers as is appropriate for your security requirements and never use an account with more permissions than needed to perform the task at hand if you can avoid it. Each tier should theoretically be smaller than the tier below it, but as a hierarchy, some account types (such as server administrators and workstation administrators) may be roughly the same level and may represent roughly the same group of people. This is alright. Resist the temptation to combine these accounts for the sake of simplicity when there is a greater likelihood of one of these accounts being compromised over the other (as is the case with workstation accounts that may come in contact with the occasional infected system).

By implementing these basic best practices, you will have gone a long way towards significantly and substantially reducing your risk of introducing unwanted chaos into your network in the form of malware, compromise, and general cyber nuisances.

To schedule a consultation to help implement these and other best practices within your environment, contact Peregrine Labs today.