Active Directory : Design Considerations and Best Practices
Introduction
Active Directory (AD) is one of the most critical components of any IT infrastructure. In a Windows-based environment, almost all the applications and tools are integrated with Active Directory for authentication, directory browsing, and single sign-on. An outage in Active Directory can stall the entire IT operations of an organization.
Due to this criticality, the first priority of an AD Admin is to ensure the stability, availability, and security of the Active Directory environment.
In this article, we will discuss some of the design considerations and best practices which would keep your AD environment healthy and stable.
Please note that this is not a comprehensive list, and one can write an entire book on Active Directory design and management. However, this is the list which I have prepared during my journey as an AD architect, and we kept some big environments healthy by following these best practices. But please treat this as a generic guideline, which would help you to prepare your own list of best practices based on your environment.
It is assumed that the reader is already having a fair understanding and working knowledge of Active Directory management.
Forest and Domain Layout
The most simple approach is a single forest single domain design. However, for most enterprises which are spanned across multiple locations and regions across the world, a more practical approach is a single forest multi-domain model.
• In a single forest multi-domain model, typically the root domain should act as the Resource Domain. A Resource Domain is a domain which typically hosts other critical infrastructure which works closely with Active Directory. Some of the most common candidates of root (resource) domain are MS Exchange, Lync Server, Certificate Authority (CA) Servers , ADFS Farm .
• Also, Forest Root Domain typically hosts some Group Policies which are applied / enforced to all the child domains.
• Typically, Forest Root Domain should not host users and groups, unless Enterprise Admins and Certificate Admins. From User / Group perspective, Forest Root Domain should be a Null Domain.
• Domain Controllers of Forest Root Domain should be spread across multiple regions.
Now that we have covered the root domain, let's discuss the design of child domains.
• For large enterprises which are spread globally, the domains should ideally be based on regions. For example, an organization which is having offices at US, EU & APAC, they can create 3 child domains based on regions.
• For Disaster Recovery (DR) purpose, each region should host Domain Controllers of other regions. For example: most of the Domain Controllers for us.corp.org would be hosted within US region, but very few Domain Controllers can also be hosted in EU & AP regions for redundancy purpose. This will give another advantage when an employee from US would be working from EU office, the user authentication request would be served locally instead of traffic traveling back & forth between regions.
• User, Group, GPO, Computer objects in a region would be stored within the Domain partition of child domains, which are region specific. For a large enterprise, this approach is better than having a single domain single forest model. This regional domain separation offers more flexibility on segregating roles and responsibilities between regions. It also reduces replication burden up to a great extent.
AD Site Layout
Now that we have covered the Forest and Domain design model, let's cover the design of AD Sites.
Designing AD Sites is one of the most crucial parts of overall AD Design. Please remember, the Inter-Site Replication is completely dependent on the AD Site topology. The DC Locator process, which helps us to find the nearest Domain Controller & DFS Server, is also dependent on AD Site design.
• Your AD Sites and Subnets should represent the actual datacenter locations, offices, and network topology, as closely as possible. By placing a Domain Controller under a particular site, you are telling a Domain Controller "This is your location". By placing a Domain Controller under a particular subnet, you are telling a Domain Controller "This is the network where you belong".
• Never create a Replication Island. This means each AD Site should be logically connected to at least two different sites. Otherwise, if Site A is down, Site B will be detached with rest of the Forest because Site B connects (replicates) through rest of the Forest only through Site A. Please avoid this kind of design.
• Always create "Catch All Subnets" in each region, to ensure that your traffic never leaves geography for authentication. For example, the IP range for your US region is 192.168.0.0/16. In this case, create a matching subnet with 192.168.0.0/16. You do not need to put any Domain Controller within this subnet. Why it is necessary? Let's say a client system belongs to a new subnet 192.168.5.0/24 and there is no such matching subnet created in AD. In such a case, the client would be authenticated by any Domain Controller in the forest, including Domain Controller from other regions. To restrict the authentication request going outside the region, this bigger subnet would be useful. In this case, the client subnet would find the nearest match with 192/168.0.0/24 and would contact any Domain Controller within the US region.
Global Catalog Placement
• Please ensure that each site must have at least one Global Catalog (GC). For larger sites, there should be more than one GC. GCs are heavily used a during cross-forest login. MS Exchange is a big consumer of Global Catalog Servers.
• You can also make all your DCs act as a GC. Please note that if you make all Domain Controllers within a Domain to act as Global Catalog, the Infrastructure Master Operations Master role would be suppressed.
• You might be aware that not all attributes are being replicated to Global Catalog, but only the most common attributes. If there is any attribute / custom attribute which is heavily used in your organization, please make sure that it is being replicated to Global Catalog. If not, you can edit the attribute property and ensure that it would be replicated to all GCs across the forest.
OU Management
You should carefully plan the layout of OUs and Sub-OUs within each AD Domain. I have seen cases where administrators do not plan it well in advance, and later they have to spend hours in redesigning the OU structure.
• Please remember, your OU design will impact your Group Policy deployment. So when you are designing OU structure, please keep Group Policy in mind.
• There are different strategies which can be adopted while designing an OU. The most common strategy is to follow the Department / BU followed by Location, followed by System Type. Example: India > Bangalore > Accounts> Servers, India > Bangalore > Sales > Workstations so on.
• Do not mix users and computers under the same OU. This will make the deployment of GPO complicated.
• Do not keep users / computers in the default containers. They should be moved to appropriate OU, where they will be governed by appropriate GPOs. There should be a regular activity to ensure that no object is left in the default container.
• Please enable the feature called "Protect Accidental Deletion". This will prevent the accidental deletion of a large OU. I have prepared a PowerShell Script, which checks and enables these settings for all OUs within a Domain.
• Generally, location-specific sub-OUs are managed by junior IT Administrators. So please pay proper attention in OU Delegation to restrict control.
AD Group Management
This is another area which should be planned meticulously. There are few thumb rules which are as follows :
• Use Domain Local Groups for Application / Folder permission. Add Domain Local groups into applications / folders and fine tune the access.
• Use Global Groups to club users and other groups.
**
**
• Now, add Global Groups within appropriate Domain Local groups, either in the same domain or different domain, so that group members would get appropriate permission to access application and folders.
• Avoid using Universal Groups. The members of Universal Groups are part of Global Catalog which will increase the replication load. If you need to use Universal Groups, use them carefully.
• Try to use nested groups, rather than adding same user / computer account into multiple groups. This will simplify the group management tasks.
• For every large (root) folder, create separate groups for Read/Write/Modify while creating the folder, and give appropriate permission. Example: The AD Groups "FolderA_RW" will have Read and Write access on root folder A. This will simplify the Folder permission management. Once this is configured, all you have to do in the future is to add / remove users from the permission groups without tampering the actual folder permission.
• When you create a new AD Group, please update the "Managed By" field. This will help other administrators to contact the right person regarding that group.
• Addition of users to sensitive groups should be backed by proper approval and reference number. You should mention the reference number in the comments section of the group. This will be useful during a future audit.
• Groups should follow a stringent naming convention, which should clearly reflect their purpose. By looking at the group name, you should understand which one is the user group, which one is the permission group, which one is Domain Local Group and so on.
Access Groups and User groups
This approach simplifies the AD Group and Access management up to a great extent.
User groups are the groups where you will add users.
Typically , your user group should represent a team or group of people who have something in common. For example, SQL_DBA_Offshore, which represents all SQL DBA team members at offshore.Access Groups are the groups which have specific access on a particular environment. ** For example: Prod_DB_SQL_Sysadmin.** Once you create this group, you will add it to all SQL Databases as Sysadmin.
Now, add the user groups to appropriate access groups, based on the scheme of access.
There are multiple benefits of this approach :
- Easy to grant and revoke access. Next time a new AD group needs SQL DB access in Production environment, all you need to do is to add it to the AD group Prod_DB_SQL_Sysadmin**.** You do not need to login to each SQL database and grant / revoke the access.
- In this approach, it is very easy to determine which user group has what of access in the environment, by looking at the 'Member of' tab. If you directly add a user group to any database / server / application, it is very difficult to determine overall access.
Therefore, avoid granting a user group direct access to any object. Instead, configure access groups and nest user groups within access groups.
Some of the common use cases of access groups are :
- Server Local Admin access groups
- Database access groups
- File / Folder permission access groups
- application access groups
Domain Controller Deployment and Management
Needless to say that it is one of the most critical design. Let's cover a few best practices :
• There is a common misconception that more Domain Controllers would create a better and more stable AD environment. On the contrary, you should restrict to a minimum number of Domain Controllers which are absolutely necessary to manage the workload. More Domain Controllers mean more attack surface, more complex replication topology and more management overheads.
• You should start with a minimum number of Domain Controllers and gradually increase the number based on workload. You can monitor the CPU and Memory utilization of existing Domain Controllers during peak hours for some days, to decide whether you need to deploy additional Domain Controllers. If the process lsass.exe consumes high CPU for a long time, then that is an indication of a large number of authentication requests. Additionally, users might complain about slow login or login refusal during peak hours.
• Always ensure the physical security of your Domain Controllers. Otherwise, you may consider deploying a Read Only Domain Controller (RODC). However, please avoid RODC if it is not required.
Now, a few points related to Domain Controllers health management. There are two aspects of Domain Controller's health management.
**The first aspect is the health of the Domain Controller Server. **
• Domain Controllers should be patched on regular basis, two minimize security vulnerabilities and to increase stability.
• Make sure they are stable from the Hardware and OS perspective.
• Sufficient disk space should be available in system drive and all other drives.
• System Event Logs should be checked on a regular basis.
• Real Time monitoring and alerting is a must for Domain Controllers, which includes disk space, CPU, memory utilization, services, events etc.
The second aspect is the health monitoring of AD Database, which is NTDS.DIT. For that, the built-in utility is DC Diagnostic Tool or DCDIAG.
I have published a PowerShell Script called MultiDCDiag, which generates the DC Diagnostic reports of multiple Domain Controllers and stores the result in a central repository. You can integrate the script with scheduled task. The script will only display the errors, if there is no error in any DC then the output will be blank.
Also, the Directory Service Event Logs and DNS Event logs should be monitored on a regular basis.
There are a few more best practices which can help to maintain a healthy Domain Controller :
• Restrict membership of critical groups like Administrators, Schema Admins, Enterprise Admins, Domain Admins.
• Avoid direct login to Domain Controllers for day to day work. Use Remote Server Administration Tools (RSAT) for AD and DNS Management.
• You can configure LDAPS (Secure LDAP) on each Domain Controllers. This is not required for Windows systems, as their communications are already encrypted. But this is more useful for non Windows systems to communicate Domain Controllers securely.
AD Replication
As Active Directory works on multi-master replication model, we should ensure that all Domain Controllers maintain a consistent database. The database consistency of Domain Controllers is one of the key factors of Active Directory health.
There are a few best practices, which helps to keep a healthy AD Database up to a great extent :
• Intrasite topology is automatically generated by KCC, and we do not have any role to play there. The KCC ensures that no domain controllers within a site are 3 hops away from each other.
• Inter-site topology is designed by AD Administrators, when they create AD sites and site links, along with link cost. So careful planning is required to ensure that sites replicate with each other within a certain interval.
• Monitor Replication Report for the entire forest on a regular basis. For a large environment, monitor regular summary report at least twice daily, and monitor full replication report once a day. Store the reports in a single repository for future reference. I have created two PowerShell scripts, one for Replication Summary Report and another for Full replication Report, which would run the report, email the result and store the report in a date-wise folder. Once you integrate these two scripts with scheduled tasks, no further manual intervention is required. You can also use 3rd party monitoring tools to accomplish this.
• The most common cause of Replication error is Domain Controller unavailability due to some hardware, network or firewall issue. However, sometimes an error in replication indicates more serious problem including the presence of Lingering Object(s) in AD Database. So please do not neglect Replication errors, and try to solve it as early as possible.
• Make sure Strict Replication Consistency is enabled on each Domain Controller. If not, enable it in the Domain Controller Group Policy. Enabling this policy would help in avoiding the replication of a lingering object between Domain Controllers.
• Do not keep a Domain Controller powered down for an extended period of time. If a Domain Controller is powered down for a long time (especially beyond its tombstone lifetime), then do not power it on at all. Just disconnect the Domain Controller permanently from a network, decommission it and do Metadata cleanup on AD Database to remove that Domain Controller from AD Database.
• When you demote a Domain Controller, do post demotion cleanup. I have published an article on this topic, where I have published a generic checklist on cleanup tasks.
• AD Replication is not dependent on Domain Controller system time, because it uses USN and few vectors to maintain the database consistency. However, if the Domain Controller system time is inaccurate and differs significantly from its partners, then other Domain Controllers might choose not to participate with this DC for replication. So please ensure that your Domain Controllers maintain accurate time on their system clock. We will discuss on time sync in detail in an upcoming section.
Time Synchronization
Active Directory Domain Controllers act as a time source for all member servers and workstations which are members of AD Domain. Therefore, it is important that the Domain Controllers maintain correct system time.
I have published an article on AD Time Sync, which you can refer here.
We will now discuss a few best practices related to Time Sync :
• Ensure that an external and reliable time source is configured for the forest root Domain PDC Emulator. Refer this Link for the configuration steps.
• Ensure all Domain Controllers, Member Servers and Workstations are configured to follow Active Directory Time Hierarchy. You can deploy a GPO and link it to appropriate OUs, to ensure that all system follow Active Directory time hierarchy. Only Forest Root Domain PDC emulator should be sync with an external clock.
• Additionally, virtual machines should not sync time with their host.
• Compare Forest Root Domain PDC Emulator Time with an external clock on a regular basis. You can use https://www.timeanddate.com/ for the comparison. If PDC emulator time is not correct, that will impact all other Domain Controllers, which will, in turn, impact all other systems.
• Validate Time Skew Reports between all Domain Controllers. You have to run this report for each domain. This report would display the time skew (difference) between domain controllers, which should be less than 1 second.
• I have prepared a PowerShell script, which captures Time Skew report and emails the report. You can integrate the report with a scheduled task, and monitor the result for each domain.
Active Directory Backup
We will discuss two types of AD backups, object level and service level (database level).
• For object level backup, you have to enable Active Directory Recycle Bin in advance. You can recover deleted AD objects if AD Recycle Bin was enabled before deletion. With the help of AD Recycle Bin, you can also restore deleted AD-integrated DNS zones using this PowerShell script.
• In addition, you can enable the prevention of OU accidental deletion using this PowerShell script.
Please note that to enable AD Recycle Bin, the Forest Functional Level should be Windows Server 2008 R2 or above.
The above two settings are enough for the object level backup plan. However, in case AD Database becomes corrupted and goes beyond recovery, object level backup will not be useful. So we should have a solid backup policy for the Active Directory Backup.
Before we proceed, it is important to keep below points in mind:
1. Restoring Active Directory Backup should be the LAST option for any Disaster Recovery.
2. For a single Domain Controller failure, the recommended option is to demote the Domain Controller, wait for a few hours to replicate the demotion, and then promote it back again.
3. There is no need to restore Active Directory Backup to restore/recover a single Domain Controller. Active Directory backup restoration is required only when the AD Database needs to be recovered/restored for some reason.
4. Do not restore Active Directory backup to recover deleted objects. We have already discussed AD Recycle Bin which should be used for object level backup and recovery.
I have published an article on AD Backup, and I strongly encourage to refer to that. In that article, I have demonstrated how can you create an effective backup policy for your domains, and how can you automate the daily backup.
Below table summarizes our backup policy :
Backup Approach |
System State Backup |
Backup Tool |
Windows Server Backup (WBADMIN.EXE) |
Operating System |
Windows Server 2012 R2 |
Backup Frequency |
Daily |
Domain Controllers to Backup |
At least Two DCs per Domain, one of those should be FSMO role holder |
Backup Method |
Through Scheduled Task (1 Full > 14 Incremental > 1 Full > 14 Incremental ) |
Where to Store the Backup |
In a non-system disk, mounted as a local disk. Not in network share. |
Backup Versioning |
Versioning will be managed automatically by the backup tool. |
Disk Space Management |
Will be managed automatically by the backup tool. |
Service Account |
NT AUTHORITY\SYSTEM |
• Once you configure AD Backup, you can also configure the automatic notification of backup success / failure by referring this article.
• You should ensure that AD backup in happening on regular basis in all Domain Controllers where you have configured it.
• You can also do a test restoration in a separate environment, which is completely isolated from your production environment.
Forest Trust Considerations
An Active Directory (AD) Forest is the security and administrative boundary for objects and entities. Due to some business need, if we want to establish a bridge between two AD Forests, we need to configure Forest Trust between those forests.
However, you have to be very careful while configuring the Forest Trust, as it will open the security boundary before another AD Forest, which might belong to a different organization or entity.
I have published an article which captures some attention points, which should be considered while creating a Forest Trust. I strongly recommend to refer to that article, where you can find a checklist and action plan for creating Forest Trust.
Few important points :
• **Always consult key stakeholders, security team and take their written approval before configuring a Forest Trust. **
• Remember, when you create a Forest Trust between two AD Forests, that trust is established between all Domains within the Forests. To configure trust between two domains in two different forests, you can consider External Trust.
• Document all the information related to Trust creation, which might include signing authorities from both sides, justification of trust creation, direction of trust, SID filtering status, authentication level and any other information which might be relevant. You can refer to the article which I previously mentioned to get the checklist.
• Do not disable SID Filtering unless there is a business justification. The most common reason for SID Filtering to allow users to access resources in an old forest, who's AD accounts have been migrated to a new forest. In such cases, please take business and security approval to disable SID filtering for a temporary basis until the migration is over. Please note that disabling SID filtering is a security risk.
• If you are creating a forest trust to access an application which is hosted in some other environment, please check whether this can be achieved by Federation solution such as ADFS.
• Create matching AD Site at Trusted Forest, to facilitate Automatic Site Coverage. If there is no matching site, authentication request will go to any Domain Controller at Trusted Forest. This will create multiple problems, and you cannot decide on which Domain Controllers firewall ports need to be opened for Forest Trust. In my article about Forest Trust, I have discussed this feature elaborately.
Group Policy Management
One of the reasons behind Active Directory's wide adaptation is its ability to control the IT environment through Group Policy. Using Group Policy, administrators can control thousands of users and systems the way they want.
When we configure a GPO, we need to consider two things, what and where. This means, what the policy is all about and where it will be applied, and where it will not be applied.
Once we finalize a GPO, we need to plan for its deployment. Here are a few thumb rules :
• Always test a GPO before deploying in Production.
• Always deploy GPOs is phases. Do not link it to an OU which is having thousands of users or computers. First link it with a smaller OU or sub OU having fewer users or computers, to minimize any possible impact. The same approach is applied when you are de-linking a GPO from a large OU.
• There are multiple ways we can control a GPO target, and those are as follows:
1) Security Filtering along with Delegation
2) WMI Filtering
3) Item Level Targeting
I have published an article called Group Policy : Filtering and Permission, which you can refer to understand how can we fine-tune the target of Group Policy.
• Take Regular Backup of GPOs. You can use some script to automate that.
• You can create a GPO in one domain, and extend it to other domains within the same Forest. So you should follow that approach rather than creating multiple GPOs for the same purpose. Such GPOs which are being used by all domains can be created in the Forest Root Domain.
SPNs and UPNs
As an Active Directory Administrator, you must ensure that your AD Database does not contain duplicate Service Principle Name (SPN) or User Principle Name (UPN). Duplicate SPN / UPN can caused Authentication issue, as Kerberos service relies on SPN and UPN for authentication.
• You should check periodically and ensure that your AD Domains do not contain duplicate SPN or UPN.
• Domain Controllers running Windows Server 2012 R2 block the creation of duplicate SPN and UPN.
You can refer this Microsoft article: SPN and UPN uniqueness
Role Based Access Control
You should try to limit the membership of high privileged groups like Domain Admins, Enterprise Admins, Schema Admins, Certificate Requester. Instead, you should create a RBAC policy for your organization.
The RBAC model requires sufficient planning, and it is organization specific. But a general approach as follows:
- Segregate the IT environment in Tiers. For Example:
- Tier 1 denotes Active Directory, Exchange, CA Servers, ADFS etc.
- Tier 2 denotes Member Servers like Application Servers, Database Servers etc.
- Tier 3 denotes workstations and other user devices.
Next **you can then create different roles using Active Directory Delegation. Each role will have different level of access in different Tiers. **
Once your roles are defined, the next step is to add users / groups to appropriate roles.
In this way, you can create role based access control for your administrators, rather than using high privileged sensitive groups.
DNS Management
So far, we have discussed some best practices related to Active Directory design. However, it is not possible to discuss Active Directory without discussing DNS. Not only AD is heavily dependent on DNS for its functionality, but also AD and DNS go together very well.
**I strongly recommend using Domain Controllers as your DNS Servers. In fact, you can use all Domain Controllers as DNS Servers. **
AD Integrated DNS zones offer multiple benefits , which are as follows :
• With AD Integrated DNS Zones, all your DNS Servers become writable. There is no "Secondary DNS Server" for an AD integrated DNS zone.
• Your DNS Zones would be stored within AD Database, which would participate in multi master replication, as a part of AD replication.
• Each DNS Zone and DNS Record becomes an Active Directory object. You can leverage AD Recycle Bin to recover deleted DNS zones or records.
• You can secure your zone from dynamic update (DDNS) of DNS records only when your zone would be AD integrated.
Let's discuss some of the best practices related to DNS. I assume that all zones in your environment are AD Integrated.
• Always create a new DNS zone as AD Integrated; be it Forward Lookup Zone, Reverse Lookup Zone, Stub Zone or Conditional Forwarders.
• **While creating a new AD Integrated Zone, please change the dynamic update type as "Secure Only". **This will ensure that the records within that zone would only be updated by trusted entities. Changing this settings later would impact record permission and can cause outage, so please make the zone "Secure Only" as soon as it is created.
• To ensure that all DHCP servers can create and update records in a secure only zone, leverage " DnsUpdateProxy" group. Put all your DHCP servers under DnsUpdateProxy built-in AD group and configure credential for dynamic update.
• Please refer my article Windows Server : Integration between DNS and DHCP for better understanding and best practices on this topic.
• **When you integrate your zone within AD, please select the zone replication scope carefully. **A zone can be replicated within Domain or throughout an AD Forest. If a given zone is mostly used only by a single domain, there is no need to replicate it to the entire forest, as that would increase replication traffic. For occasional use, you can configure DNS forwarders in other domains, which would point to DNS Servers in this Domain for that zone records.
• **Carefully design your reverse lookup zones, and refer your network design and subnets while designing reverse lookup zones. **It is not necessary to have a separate reverse lookup zone against every forward lookup zone, you can combine few forward lookup zones with a bigger reverse lookup zone.
• **Avoid creation of Static DNS Records as much as possible. **It is difficult to manage static DNS records, and over the time it will become a huge burden for DNS Administrators to identify and cleanup stale static records.
• Starting from Windows Server 2008, all Domain Controllers register their records as static, during DC promotion. This is by design, and no action is required on that.
• **You can configure scavenging of stale records after a certain period , to automate the cleanup process. However, please plan this carefully to ensure that it would not delete live records. **Please check your DHCP lease duration for corresponding scopes, which configuring ageing.
Planning DNS Server Query
By default, DNS Servers send all queries to Internet root DNS servers, which cannot be resolved by local DNS Servers. However, as a DNS Administrators, you would like to control the traffic and can change this default behavior. It is not necessary that every DNS server should directly talk to root servers for external name resolution.
• Designate few DNS Servers in your environment, which would send the traffic to Internet (root DNS servers or any other external DNS Server). Typically, you can choose few DNS servers in your root domain to do this job.
• **You can also create few "Caching Only DNS Servers" in each region, where no DNS zone would be hosted. **The purpose of those DNS Servers would be to contact external DNS Servers for name resolution and cache the response for future use. For better security, you can keep the caching only DNS Servers in DMZ zones.
• For other DNS servers in your organization, configure DNS Forwarder and point it towards those DNS Servers which you have designated for external name resolution. In this way, very few DNS servers in your environment would talk to external DNS servers and you would have better control on external DNS traffic.
External DNS Zones
In addition to internal DNS servers, most of the organizations also need to host few zone externally, to make the zone and corresponding records available globally.
Typically, organizations subscribe external DNS service from popular service providers like GoDaddy or UltraDNS. These service providers host the zones in their environment and provides a management console to organizations, from where DNS Administrator manages those external zones and records.
• Try to create minimum number of records in the external DNS zones.
• ** If a zone is used both internally and externally, you can go for split-DNS approach. **In this approach, the same zone would be hosted in external DNS servers as well as internal DNS servers, which are completely independent on each other. In the external zone, you create only those records which need to be available globally. In the internal zone, you create all records which are required externally and internally. That way, you do not need to expose all records externally.
Few more best practices related to DNS
We have almost covered DNS best practices, lets add few more and move on to the next topic.
• **Always create DNS records with lower TTL value. **A higher TTL value will ensure that the record would be retained in the resolver cache for a longer time. If you need to change record value urgently, this will create problem as the new value will take more time to reflect, causing DNS client to be diverted to the old value. Sometime this can also pose security issue.
• For Active Directory Domains, always try to use internal domain name which is not globally resolvable. Your SMTP domain name (which should be globally resolvable) should be different than AD domain names.
• **Although you should use internal, non-resolvable domain names for Active Directory; but some organizations buy and reserve those domain names to ensure that no other organization can use the same domain names as public domain. **
Summary
Area |
Design Considerations & Best Practices |
Forest & Domain Layout |
1) In a single forest multi-domain model, typically the root domain should act as the Resource Domain, which hosts critical infrastructure like CA servers, Exchange, Lync, ADFS etc. 2) Forest Root Domain typically hosts some Group Policies which are applied / enforced to all the child domains. 3) Forest Root Domain should not host users and groups, unless Enterprise Admins and Certificate Admins. 4) Domain Controllers of Forest Root Domain should be spread across multiple regions. 5) For large enterprises which are spread globally, the domains should ideally be based on regions. 6) For High Availability (HA) purpose, each region should host Domain Controllers of other regions. 7) User, Group, GPO, Computer objects in a region would be stored within the Domain partition of child domains, which are region specific. |
AD Site Layout |
1) Your AD Sites and Subnets should represent the actual datacenter locations, offices, and network topology, as closely as possible.
2) Sites and subnets structure is valid for the entire AD Forest, you cannot create domain specific separate site & subnet structure. 3) Never create a Replication Island. 4) Always create "Catch All Subnets" in each region, to ensure that your traffic never leaves geography for authentication. |
Global Catalog Placement |
1) Please ensure that each site must have at least one Global Catalog (GC). |
OU Management |
1) Your OU design will impact your Group Policy deployment, so plan accordingly.
2) Do not mix users and computers under the same OU. 3) Enable OU Accidental Deletion Protection feature. 4) Pay proper attention in OU Delegation to restrict control. |
AD Group Management |
1) Use Domain Local Groups for Application / Folder permission.
2) Use Global Groups to club users and other groups. 3) Add Global Groups within appropriate Domain Local groups, either in the same domain or different domain. 4) Avoid using Universal Groups. 5) Try to use nested groups, rather than adding same user / computer account into multiple groups. 6) For every large (root) folder, create separate groups for Read/Write/Modify while creating the folder, and give appropriate permission. 7) When you create a new AD Group, please update the "Managed By" field. 8) Addition of users to sensitive groups should be backed by proper approval and reference number. 9) Groups should follow a stringent naming convention, which should clearly reflect their purpose. |
DC Deployment & Management |
1) Start with a minimum number of Domain Controllers and gradually increase the number based on workload.
2) Always ensure the physical security of your Domain Controllers. 3) Domain Controllers should be patched on regular basis. 4) Real Time monitoring and alerting is a must for Domain Controllers, which includes disk space, CPU, memory utilization, services, events etc. 5) Run DC DIagnostic test (DCDIAG) regularly for all Domain Controllers. 6) Restrict membership of critical groups like Administrators, Schema Admins, Enterprise Admins, Domain Admins. 7) Avoid direct login to Domain Controllers for day to day work. Use Remote Server Administration Tools (RSAT) for AD and DNS Management. 8) You can configure LDAPS (Secure LDAP) on each Domain Controllers. |
AD Replication |
1) Carefully plan the design of AD Site, site links and cost. These factors impact Inter Site Replication.
2) Monitor Replication Report for the entire forest on a regular basis. 3) Make sure Strict Replication Consistency is enabled on each Domain Controller. 4) Do not keep a Domain Controller powered down for an extended period of time. 5) When you demote a Domain Controller, do post demotion cleanup. |
Time Synchronization |
1) Ensure that an external and reliable time source is configured for the forest root Domain PDC Emulator.
2) Ensure all Domain Controllers, Member Servers and Workstations are configured to follow Active Directory Time Hierarchy. 3) Virtual machines should not sync time with their host. 4) Compare Forest Root Domain PDC Emulator Time with an external clock on a regular basis. 5) Validate Time Skew Reports between all Domain Controllers. You have to run this report for each domain. |
AD Backup |
1) For object level backup, you have to enable Active Directory Recycle Bin in advance.
2) You can enable the prevention of OU accidental deletion. 3) For Service Level backup, you have to configure System State Backup of Domain Controller. 4) Two Domain Controllers from each Domain should be backed up on a regular basis. 5) Restoring Active Directory Backup should be the LAST option for any Disaster Recovery. 6) There is no need to restore Active Directory Backup to restore/recover a single Domain Controller. 7) Do not restore Active Directory backup to recover deleted objects. |
Forest Trust Considerations |
1) Always consult key stakeholders, security team and take their written approval before configuring a Forest Trust.
2) Consider External Trust if it is required only between two Domains. 3) Document all the information related to Trust creation. 4) Do not disable SID Filtering unless there is a strong business justification. 5) Create matching AD Site at Trusted Forest, to facilitate Automatic Site Coverage. |
Group Policy Management |
1) Always test a GPO before deploying in Production.
2) Always deploy GPOs is phases. 3) There are multiple ways we can control a GPO target. 4) Take Regular Backup of GPOs. 5) You can create a GPO in one domain, and extend it to other domains within the same Forest. |
| SPNs and UPNs |
1) You should check periodically and ensure that your AD Domains do not contain duplicate SPN or UPN.
2) Domain Controllers running Windows Server 2012 R2 and above block the creation of duplicate SPN and UPN. |
| RBAC |
You should try to limit the membership of high privileged groups like Domain Admins, Enterprise Admins, Schema Admins, Certificate Requester. Instead, you should create a RBAC policy for your organization. |
DNS Considerations |
1) You can use all Domain Controllers as DNS Servers.
2) Always create a new DNS zone as AD Integrated. 3) While creating a new AD Integrated Zone, please change the dynamic update type as "Secure Only". 4) To ensure that all DHCP servers can create and update records in a secure only zone, leverage " DnsUpdateProxy" group. 5) When you integrate your zone within AD, please select the zone replication scope carefully. 6) Carefully design your reverse lookup zones, and refer your network design and subnets while designing reverse lookup zones. 7) Avoid creation of Static DNS Records as much as possible. 8) You can configure scavenging of stale records after a certain period , to automate the cleanup process. However, please plan this carefully to ensure that it would not delete live records. 9) Designate few DNS Servers in your environment, which would send the traffic to Internet. 10) You can also create few "Caching Only DNS Servers" in each region, where no DNS zone would be hosted. 11) For other DNS servers in your organization, configure DNS Forwarder and point it towards those DNS Servers which you have designated for external name resolution. 12) Try to create minimum number of records in the external DNS zones. 13) If a zone is used both internally and externally, you can go for split-DNS approach. 14) Always create DNS records with lower TTL value. 15) For Active Directory Domains, always try to use internal domain name which is not globally resolvable. 16) Your SMTP domain name (which should be globally resolvable) should be different than AD domain names. 17) Your organization should buy and reserve the public counterpart of their internal domain names as well, so that others cannot but it and misuse it. |
Tasks Summary
Sr no |
Activity |
Suggested Frequency |
Method |
1 |
Monitor AD Replication Summary Report for the entire Forest. |
Daily twice |
|
2 |
Monitor AD Replication Full Report, for all NTDS Partitions. |
Daily once |
|
3 |
Monitor DC Diagnostic Report |
Weekly once |
|
4 |
Monitor Domain Controller Health |
Real Time monitoring |
Free Disk Space, Automatic Services, OS patch consistency, Antivirus policy, Event Logs. |
5 |
Check accuracy of PDC Emulator and other Domain Controllers of Forest Root Domain system clock. |
Once in every fortnight |
Check PDC emulator time and other DC time with some reliable clock. You can use www.timeanddate.com |
6 |
Check Time Skew Report for all Domain Controllers within a Domain |
Weekly once |
|
7 |
Monitor AD Backup Success / Failure Report |
Daily |
|
8 |
Ensure there is no stale record in AD Database |
Monthly once |
There should not be any stale Domain Controller present in AD Database. This includes: |