As you probably know, the Active Directory is completely dependant on the DNS services. However, DNS was originally designed as a mechanism for resolving host names into IP addresses on the Internet. Although the task of resolving host names on the Internet is procedurally very similar to the task of resolving host names for the Active Directory, the fact is that the DNS services were not originally intended to handle the demands of an Active Directory environment.
DNS has traditionally been a static mechanism. In an Internet environment, a DNS Server’s records (for which the server is authoritative) only change when an Administrator adds, deletes, or modifies a record. This usually only happens if a new domain name is registered, a server changes IP addresses, a domain name is relinquished, or in other similar situations.
By comparison, Active Directory environments are much more dynamic. Any time that a new workstation or server is added to an Active Directory domain, a corresponding DNS entry must be created that associates the PC’s name with it’s IP address. The problem is that DHCP servers are commonly used to dynamically assign IP addresses to workstations. This means that a workstation’s IP address can change on a frequent basis. To keep the Active Directory functioning correctly, the DNS record that corresponds to a machine must be updated every time that the machine’s IP address changes. Since this would be nearly impossible for an administrator to keep up with manually, Microsoft includes dynamic DNS services with Windows servers.
In a traditional DNS environment, only the Administrator makes changes to DNS servers. In a dynamic DNS environment however, every workstation on the entire network has the authority to make changes to the DNS server’s record set. The trick is therefore to prevent changes from being made to DNS records that might be incorrect or malicious.
Microsoft solved this problem by designing the DNS services so that they supported multiple zone types. A normal DNS server supports primary, secondary, and stub zones. A Windows based DNS server supports these same types of zones, but gives you the option of creating Active Directory integrated zones (assuming that the DNS services are running on a domain controller).
For the most part, an Active Directory integrated zone functions similarly to a zone that isn’t integrated into the Active Directory. The main difference is that an Active Directory integrated zone stores its records within the Active Directory rather than in a zone file. This allows zone information to be portable, but there is a more important reason for the Active Directory integration.
A traditional DNS server does not maintain any type of zone security. By moving zone information to the Active Directory, it becomes possible for Windows to associate an access control list (ACL) with the zone. Of course, all of this happens behind the scenes when you initially setup Active Directory. Windows automatically configures the ACL so that authenticated users have the Create All Child Objects permission. This allows a DNS entry to be created when a workstation comes online (assuming that the entry doesn’t already exist), without giving users sufficient rights to do anything destructive. Domain Admins, Enterprise Admins, and Domain Controllers have higher levels of access that allow full DNS management.
The reason why it is important to know about this is because Windows allows you to convert an Active Directory integrated zone into a non Active Directory integrated zone, and visa versa. Granted, this isn’t exactly something that you would do on a daily basis, but converting to a non Active Directory integrated zone allows zone information to be exported to a file. This is a common requirement in DNS related disaster recovery scenarios. When you convert an Active Directory integrated zone into a non Active Directory integrated zone, Windows removes the zone’s ACL. This means that there is no longer any security protecting the zone.
As I mentioned earlier, you can convert a zone into an Active Directory integrated zone. If you do this and your DNS Server is running Windows Server 2003, then the ACL is automatically reconstructed (with default values). However, there is a bug in Windows 2000 Server that causes the ACL not to be created if a zone is converted into an Active Directory Integrated zone. Therefore, if your DNS server is still running Windows 2000, it might be worth your while to check out your zone’s ACL to make sure that it isn’t empty. To do so, just right click on the zone within the DNS console and select the Properties command from the shortcut menu. The zone’s ACL is located on the Security tab.
Good read, via msd2d.com
No comments:
Post a Comment