The importance of protecting your Active Directory has already been touched on in reference to DNS security. However, that is just the tip of the iceberg when it comes to maintaining a secure environment.
As far as Active Directory security best practices go, layered security is the best method to use when planning and designing a security solution. Layered security or defense in depth is the simple concept of placing your valued assets at the center of your environment and building or deploying multiple concentric circles or rings of protection around those assets. Thus, violations to confidentiality, integrity, or availability must overcome numerous security restrictions, precautions, and protections before being able to affect your assets.
While Microsoft has increased the default security within Active Directory (especially if you have a Windows Server 2003 Active Directory installation), you still need to consider additional security settings after it is installed.
Securing your domain controllers
One of the first steps you should take involves developing a solid domain controller security policy. Protecting your domain controllers is at the core of protecting your Active Directory investment. Without your domain controllers you won't have your Active Directory network infrastructure. With exposed and unprotected domain controllers you also are at risk for attackers to enumerate shared folders and usernames, giving up valuable information that can be used to further attack the network.
Therefore, it is critical that domain controllers are running and protected in order for the Active Directory environment to remain functioning and stable. To protect domain controllers, you should consider the following areas of security protection: physical access (keeping DCs in a secure location that is only accessible by the IT staff) and network access (protecting DCs from those who might attack your network).
As an administrator, you need to be concerned with making sure internal users have proper access and that potential intruders are frustrated in their attempts to compromise a DC. One danger is for a person to be physically in the room and touch a DC even without any rights granted to them. Thus, if a person has physical access, he or she owns your computer, since physical access grants them control. Keeping DCs in a secure location is a simple way to ensure Active Direcotry security, but it is often overlooked.
As far as network access is concerned, it is important not to give domain admin privileges to someone who isn't skilled enough to handle the job or to someone you're not sure you can trust. Anyone with the ability to install/modify system files, including services/drivers (such as server operators, backup operators or print operators) owns your computer. There are many ways for this to happen. Naturally, a secure account could be compromised, giving the intruder the rights to do this, but a valid holder of these rights could cause harm unintentionally by installing an application without testing it first.
How well you handle Microsoft patch emergencies and updates is also key to the security of your DCs. You should always deploy the same patches on all domain controllers. DCs should be kept as close to mirror images of each other as possible, at least in terms of the OS configuration. This will help eliminate incompatibilities, lost or corrupted data and replication errors.
However, it is important not to patch just because Microsoft offers a patch. Every patch needs to be tested in your environment for relevance and reliability. If you don't need it, don't install it. Patches can damage your environment if the install fails to perform perfectly. You don't want to place your DCs at risk if you can avoid it.
Kerberos security with Microsoft
With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol. Not only was it much more secure and efficient than NTLM (which was used prior), but it also plays nicely with other operating systems such as Unix.
Before learning how Kerberos works in the world of Windows, it's best to first understand normal Kerberos authentication and authorization.
Authentication is the process of presenting credentials (username/password) to a service and having that service validate you. It works like this. When a user enters his or her username/password in a Kerberos environment, that information is sent to a server running the Authentication Service. The Authentication Service passes that information to a database called the Key Distribution Center (KDC). If the username/password checks out, the Authentication Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the logon process. The TGT contains a time stamp, the public key and a certificate.
Authorization is the process of granting access to resources on a server that is in the network. Continuing from the authentication discussion, once the client gets the TGT, the client can then request access to resources. The TGT is presented to the Ticket Granting Service and requests a session ticket to access a resource on, say, Server 1. If Server 1 is in the domain, the Ticket Granting Service sees that there is a valid TGT, so credentials check out, and a session ticket is granted for Server 1. The client then presents the session ticket to Server 1 for access to a resource such as a printer, file share or document. Server 1 will then check access rights on that resource to see what the user can do (read, write, etc.).
In a Windows domain, all of the Kerberos-related services just described are held by each domain controller. When a user presents credentials for authentication in a Windows domain, the same Kerberos authentication process described above is used -- with one exception. In order to find a domain controller that is also the KDC, a client must use the DC Locator process, which requires a DNS server to locate an appropriate DC and send that information back to the client. The client then passes the credentials to the domain controller, which grants the TGT and then a session ticket if the server to be accessed is in the DC's domain. The access rights are checked by the server and granted to the client.
Group Policy security settings
One of the most important steps toward Active Directory security involves Group Policy security settings. With almost 1,800 policy settings in a single Group Policy Object (GPO), it is no wonder they provide so much power, control, security, and management over an Active Directory enterprise.
There are two default GPOs in every Active Directory domain. These default GPOs are there for very distinct reasons and should be investigated to ensure they are configured properly to provide the best security for your company network. The first default GPO is the Default Domain Policy. This GPO is responsible for establishing and maintaining the account policies for the domain user accounts, which are essential for helping secure the domain user account passwords.
The second default GPO is the Default Domain Controller Policy. This GPO is responsible for establishing the baseline security for all domain controllers in the domain. The primary security settings that are established in the GPO are the user rights. Common user rights include:
* Allowing a user to logon using the keyboard attached to the computer (locally)
* Changing the system time
* Backing up files and folders
* Accessing the computer and its resources over a network
However, every network running Active Directory should have more than just the default two GPOs. The reason is that Group Policy provides an automated, centralized method for configuring and deploying security settings to all computers and users within the domain. Some common security related settings and areas of configuration include the ability to restrict which applications can be run on each computer, use IP Security to encrypt data between computers, restrict anonymous connections to computers and audit policy settings per computer.
No comments:
Post a Comment