Read the full series:
|
Ch.1 — Protecting the Active Directory Domain Services |
Every component of the Modern Data Center requires authentication of some form or fashion. Microsoft’s Active Directory Services contains information about individual objects within the forest and stores the necessary information in a relational database (ntds.dit). Domain Controllers are the heads of the infrastructure that controls access to resources through an authentication and login process. When a user attempts to access a file on the corporate domain-based file server, either Kerberos and NTLM are authentication protocols used to verify the identity of a computer or user. To say the least, authentication is critical to the Always-On Business.
Designing for High Availability
IT professionals and engineers take great care and perform extensive planning to carefully architect a highly available Active Directory Domain Services infrastructure to eliminate potential issues. If a single domain controller is unavailable — due to a network outage a reboot during the patch window, for example — we don’t not want all communication to stop, so we build in resiliency. Microsoft’s Active Directory Sites and Services (dssite.msc) handles the replication engine or the time interval in which replication between domain controllers occurs. This ensures that the latest changes are moved around from site to site automatically. It’s a best practice to create a “lag” site — a site in the environment that is considerably removed from the normal replication. These values are managed by a cost and interval model. The sites with the greatest cost and replication interval are lowest priority. If an organizational unit (OU) is accidentally deleted, it would be tragic to have this immediately replicated around the environment — hence the lag site.
Example 1: Active Directory Sites and Services – Cost & Interval Replication
Fortunately for those out there running Veeam Backup & Replication, we’re able to quickly, easily and reliably restore individual objects or attributes of objects in case something is edited or removed in error. This is done by leveraging Veeam Explorer for Microsoft Active Directory.
Control the Keys to the Castle
Active Directory (AD) has many built-in global security groups; some are for computer objects and others for user objects. Examples are:
- Domain Admins
- Enterprise Admins
- Schema Admins
- Domain Users
- Domain Controllers
- Domain Computers
In order to implement delegation successfully, it’s important to understand how the security models work within AD. It’s actually quite simple, in my opinion, much like NTFS. Permissions set at the top level can trickle down through nested OU’s and objects within the domain hierarchy.
Accidents happen for sure! What if John on the Service Desk accidentally deleted the OU with all of the Service Accounts for the SQL infrastructure? This would be a bad day! To protect against accidental human error or worse, malicious compromise, one must closely monitor the memberships of these groups. Periodic auditing should occur to validate which user accounts have access to which groups. It is a best practice to create service accounts (svc-xxxx) for all application based user accounts and administrative accounts (admin-xxxx) for all elevated access accounts that individual users login with. For instance, my regular domain account, cwyckoff would NEVER be permitted in the Domain Admins group. For that, I would create and use admin-cwyckoff. Also, consider using random characters such as employee IDs as user accounts (e.g., v123456 or admin-v123456). This makes guessing user account names more of a challenge for outside hackers to brute force attack based on the known naming convention.
Delegating roles to other members within IT is a great way of empowering other members of the team to perform activities. Typically, in larger IT shops the engineering and architecture teams own the Active Directory Authentication Service while delegating control and access to administrator and operator level teams. To do this, you should leverage the built-in tool within Active Directory Users and Computers (dsa.msc). It’s quick and easy to delegate access to complete common tasks to individual users or groups of users. An example of this is, “Join a computer to the domain” or “Reset user passwords and force password change at next logon.” You could also create a custom task if what you were looking to accomplish isn’t set as one of the common out-of-the-box tasks within the wizard. Listing out the tasks that each user or group of users would perform allows us to take a role-based approach. This is absolutely a best practice, and it’s a great way of ensuring that the appropriate teams have the exact permissions required to perform their job — nothing more and nothing less.
Example 2: Built-In Delegation of Control Wizard
Conclusion
Domain authentication is a mission-critical component of the infrastructure that is overlooked too often. Many times, the members running the domain services don’t have the time to sit down and think out what the specific role of each member within IT is. The easiest way out is to over-permission, giving folks too many permissions, which allows things to get quite dangerous very quickly. Building in local protection policies along with designing a highly resilient architecture allows all components to operate in the most optimal fashion. In the next post, we will discuss whole site failure and recovery components, as well as how you can leverage Read-only Domain Controllers (RODC) to secure AD environment further.
