Latest posts by Andrew Fitzgerald (see all)
- How to rename the local administrator with Group Policy - Mon, Nov 2 2015
- Active Directory authoritative restore with Windows Server Backup (wbadmin) - Fri, Oct 9 2015
- Best practices for securing Active Directory - Fri, Oct 2 2015
Granting administrative rights ^
First, you should make sure that all users in your domain aren’t local administrators of their computers unless there is a specific business reason they need this type of access. Even domain admins shouldn’t log in to their desktop using their admin account. IT staff should have two accounts: one for logging in to their PC as a user with basic privileges and one for performing administrative tasks (for example, logging in to servers) as a domain admin. This practice lowers the risk of any potential attacks on your network; a virus that infects computers while admins are logged in with their domain admin account could cause a lot of harm within your network.
One way to achieve this is to set up a GPO for restricted groups to determine the users with administrator rights.
Logging in to servers ^
Another best practice is to limit who can log in to servers. Admins shouldn’t need to log in to servers to perform their admin tasks. Admins can perform most of their tasks using the remote administration tools, which they can install on their desktop or on a dedicated terminal server that all admins use to perform admin tasks.
If you want to limit who has remote access to your servers, you can apply this GPO and filter the login access to a specific security group.
Renaming the Admin account ^
You should rename your local administrator accounts on all your desktops and servers. This lowers the chance of an attacker trying to guess the password of your administrator accounts if he doesn’t know the username. You can achieve this by creating a GPO that renames your local admin user accounts. You should also disable the guest user account as this is never used.
Enforcing passwords ^
Follow this best practice for enforcing password policy for your users. Make sure to set up your default domain password policy correctly, with the following options:
- Enforce password history
- Maximum password age
- Minimum password age
- Minimum password length
- Passwords must meet password complexity requirements
- Store password using reversible encryption for all users
Password Policy in the Group Policy Management Editor
You should set the values according to what your business needs and how secure you want your environment. This guide will show you how to set those values.
Securing domain controllers ^
If you have physical servers for your domain controllers, it is a good idea to lock them away somewhere secure where no one can access them. If you have remote domain controllers in a remote office with no administrators, it is a good idea to configure these as read-only domain controllers (RODCs). Another good idea is to set up your domain controllers as core Windows servers without the GUI.
Remote domain controllers as RODCs
Limit the number of users you have in your domain admin and enterprise admin groups. Limit the number of applications and services you have running on your domain controllers. You should have no other applications running on your DCs. You should have no other applications or services running on your DCs.
You can also limit which ports you have opened on your domain controllers. Only those ports that are needed for communication should be opened between a domain controller and your computers.
Configuring Windows Firewall
Following are the ports that Active Directory uses for specific Active Directory communication, including MS traffic, DNS, Kerberos authentication protocol, Lightweight Directory Access Protocol (LDAP), and LDAP ping activity:
|Communication Type||MS Traffic||DNS||Kerberos||LDAP||LDAP Ping||NETLOGON|
|User network logon over a firewall||TCP 445|
|Computer logon to a domain controller||TCP 445|
|Verification of trust relationships between domain controllers||TCP 445|
TCP 686 (SSL)
|UDP 389||UDP: 137, 138|
|Creation of a trust relationship between domain controllers located in different domains||TCP 445|
TCP 686 (SSL)
Securing your Active Directory installations ^
Microsoft has a great guide you can follow to secure your Active Directory installation. The guide’s several chapters cover the following:
- Planning in-depth Active Directory security
- Establishing secure Active Directory boundaries
- Deploying secure domain controllers
- Strengthening domain and domain controller policy settings
- Establishing secure administrative practices
- Securing DNS
Follow Microsoft best practice for securing your active directory installation.
Setting up auditing in your domain ^
Auditing is a very useful tool to monitor what is happening in your domain and to keep a record of any changes. You should audit failed logons and successful and failed account management tasks, object access, and policy changes. Useful guides are Security Auditing Overview and Monitoring and Auditing.
Audit Policy in the Group Policy Management Editor