- 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 UDP 445 |
TCP 53 UDP 53 |
TCP 88 UDP 88 |
UDP 389 | ||
Computer logon to a domain controller | TCP 445 UDP 445 |
TCP 53 UDP 53 |
TCP 88 UDP 88 |
UDP 389 | ||
Verification of trust relationships between domain controllers | TCP 445 UDP 445 |
TCP 53 UDP 53 |
TCP 88 UDP 88 |
TCP 389 TCP 686 (SSL) |
UDP 389 | UDP: 137, 138 TCP: 139 |
Creation of a trust relationship between domain controllers located in different domains | TCP 445 UDP 445 |
TCP 53 UDP 53 |
TCP 88 UDP 88 |
TCP 389 TCP 686 (SSL) |
UDP 389 |
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
Hello, please take note about more “vectors” to exploit that need our attention:
https://adsecurity.org/?p=1929
Search too any relate to Pass-the-Hash (or mimikatz or WCE)
Regards!
please,Make video steps
So, from a security perspective, unless I am misunderstanding, I would say do not enable ‘Store password using reversible encryption for all users’ Disabling that setting if enabled would be the best option if possible (some apps require this)
Hi Andrew.
Great article.
Just wanted to give you a heads up – your site (networkangel) might have been hacked (and serving some malware), and is now blacklisted on Quttera, Sucuri and Fortinet.
HI Anon, yes good point. As you say it depends on your environment and what your applications require
Eliad Tech, thanks for your message. Ive cleared any malware on the site 🙂
You should have mentioned the use of Microsoft Security Compliance Manager to harden security on Domain Controllers through group policy.