Active Directory – Page 2 – 2000Trainers.com

Active Directory Group Concepts

Windows 2000 Active Directory presents a number of different group options not found in the NT domain environment. The two biggest changes are the different types/scopes of groups that now exist, as well as the ability to nest groups. Group accounts for domain users are again created in Active Directory Users and Computers

First, understand that there are two types of groups: security and distribution. Distribution groups exist for the purpose of sending email, and do not have a SID. Security groups do have a SID, and as such can be used to assign permissions and rights via access control lists and policy settings.

Secondly, there are three scopes of groups: domain local, global, and universal. A quick overview of each:

Domain Local groups: domain local groups are similar to local groups in NT 4, except that they can be applied to any system within a domain, not just on the system where the group exists (since domain local groups actually reside in the AD database). These groups are usually used to assign permissions to resources.

Global groups: global groups are very similar to those found in an NT 4 domain. They are still collections of users with common needs.

Universal groups: universal groups are totally new in Windows 2000. A universal group can contain users from any domain in an AD forest. Similar to global groups, they are used as collections of users with common needs or characteristics. Only an member of the Enterprise Admins group can create a universal group.

If the option to create a Universal group is not available, this is because my domain is still in Mixed Mode. Universal groups can only be created in Native Mode. The ability to nest groups is also new to Windows 2000, and is also only available in Native Mode. Nesting refers to the ability to place a group into a group of the same type – for example placing a global group into a global group. The table below outlines group membership rules for domains in Native Mode.

Domain Local: May contain users from any domain, global groups from any domain, universal groups, domain local groups from the same domain. Can only be used to access resources in the same domain.

Global: May contain Users from same domain, global groups from same domain. Can be used to access resources in any domain.

Universal: May contain users from any domain, global groups from any domain, universal groups. Can be used to access resources in any domain.

Troubleshooting Active Directory Installation Problems

A few notes with respect to troubleshooting Active Directory installation problems:

There must be sufficient disk space to install Active Directory as outlined above. If you receive an error message stating there is not enough space, you will need to delete files to create space, or create an additional volume. Be sure that there is also an NTFS partition available, and use the convert.exe command on an existing FAT partition if necessary.
When creating a new domain, you will need to ensure that the DNS and Netbios names of the domain are unique. If they are not, the creation cannot proceed.
You must have the correct privileges to install a domain controller. To create a new forest, you will only need to be a local administrator. By default, to add a child domain to an existing forest (or any new domain), you must be a member of Enterprise Admins. To create a new domain controller in an existing domain, you must be a member of Domain Admins.
If you get a domain not found error when adding a domain controller to an existing domain, be sure that at least one domain controller is available and that it has properly registered its SRV records in DNS.
In order to remove the last domain controller in a domain, you must be a member of the Domain Admins group for that domain. The last domain controller in the root domain cannot be removed if child domains still exist.

Installing Active Directory

One of the major improvements between Windows 2000 and Windows NT 4 is the fact that the decision on whether or not a server becomes a domain controller is made independent of the actual OS installation. As such, turning a member server into a domain controller (or vice-versa) is something that can be done without needing a complete reinstallation. The tool used to install (or uninstall) Active Directory on a server is the Active Directory Installation Wizard, dcpromo.exe. The section takes a look at the various decisions to be made throughout the wizard.

Before getting started, there are a few important requirements that you need to be aware of, as listed below:

The system must be running Windows 2000 Server, Advanced Server, or Datacenter Server
AD installation requires a minimum of 200 MB disk space for the AD database, and 50 MB for the transaction log files. These can be placed on FAT. FAT32, or NTFS partitions
The server must have at least one NTFS partition, to house the SYSVOL folder.
TCP/IP installed and configured to use DNS is required
Appropriate administrative privileges are required.

The Active Directory installation wizard can be used for a few different purposes, and you should be aware of the reasons. These include creating a new forest (a new root domain), adding a domain controller to an existing domain, creating a new tree, and creating a new child domain. It is very important to pay attention during the wizard to ensure that you are making the correct choices, especially when creating the root domain of the forest, since this cannot be renamed for example. For the purpose of this article, I will cover the installation of a new root domain. You should familiarize yourself with the other options, however.

Pages: 1234

Configuring DNS to Support Active Directory

Aside from the details listed above, it is important to understand how to create an initial DNS zone to support Active Directory. This should be done in advanced of installing Active Directory, in order to ensure that things are configured as you wish them to be. If you do not configure the zone in advance, the installation wizard will automatically do it for you, and the installation may not meet your needs.

Configuring a zone first involves installing the DNS service via the Add/Remove Windows components wizard. After doing this, open the DNS tool and you should see the default configuration.

By default the server will act as a caching-only server, simply forwarding queries to root servers when an answer cannot be found in cache. However, in order to support AD, a zone must be created that will be authoritative for the Active Directory domain that is to be installed. A wizard does exist to walk you through the process (right click and choose Configure the Server) if you choose that method. However, right-clicking the forward lookup zone and choosing New Zone will open the New Zone wizard, which I will cover here. By default, three options exist for zone types to be created.

Note that the option for an Active Directory-integrated zone is unavailable since Active Directory has not yet been set up. Choosing a standard primary would be our only real option, since a secondary requires a primary to exist. This primary zone can later be changed to AD-integrated as we’ll see in a bit. The zone must be named, so I have chosen 2000trainers.com, which will create a zone file called 2000trainers.com.dns.

After creating a zone, ensure that the TCP/IP properties of the server you wish to promote to a domain controller point to this newly created DNS server (it may be the same system). Also note that the properties on the zone can be accessed to change settings such as the zone type (which can be changed once we install AD), support for dynamic updates (disabled by default), SOA, Name Server, WINS, and Zone Transfer information.

The properties configured for a zone are different than those configured for a DNS server, which may support many zones. Properties for a DNS server are shown below, allowing you to control elements including the configuration of interfaces, forwarders, advanced properties, root hints, logging, and monitoring.

Note that dynamic updates are not allowed by default. You’ll need to change this in order for domain controllers to automatically register their service records.

Also remember that a zone can only be compromised of domains in a contiguous namespace. As such, if you wanted to support domains called test.com and 2000trainers.com from the same DNS server, you would be required to created separate zones. However, a single zone could handle the domains 2000trainers.com and research.2000trainers.com without issue.

Although not required for Active Directory support, it is also good practice to create reverse lookup zones for all forward lookup zones created, since these provide IP address to hostname resolution services. A reverse zone name will be in a format that reverses the network portion of the IP address range in use, and appends the reverse-lookup domain name. For example, the domain name for a reverse zone that supports network 192.168.0.0 would be 168.192.in-addr.arpa. You should also enable dynamic updates for this zone in order for reverse records to be added automatically.

DNS Service Records and Locating Domain Controllers

Windows 2000 Active Directory requires DNS to function correctly. DNS support for SRV records is the only absolutely mandatory requirement for Active Directory to function. However, it is also recommended that your DNS server support dynamic updates, since domain controllers dynamically register a number of records in DNS. If your DNS servers do not support this, you would need to set up all required service records for all domain controllers manually, a potentially long and arduous process. Windows 2000 DNS supports both, as well as incremental zone updates (IXFR). IXFR is useful in that it allows DNS servers to simply replicate zone changes instead of the entire zone file as in AXFR-based implementations (NT 4 DNS, for example). It is also worth noting which versions of BIND (the popular Unix-based DNS server) support the above requirements:

BIND 4.9.7 – supports SRV records

BIND 8.2.1 – supports SRV records, Dynamic Update, IXFR

An understanding of the SRV records and related domains that you will find (or require) in a DNS implementation to support Active Directory is also important. Just to reiterate, Windows 2000 uses service records in DNS to locate domain controllers in specific domains, domain controllers in the same site, global catalog servers, key distribution centers, and more. A service record uses a standard record format, an example of which is shown below:

_service._protocol.name ttl class SRV priority weight port target

_Service represents the name of the service that a domain controller is running, such as ldap (for a domain controller), gc (for a global catalog server), kerberos for a key distribution center, and so forth.

_Protocol specifies the transport protocol used, such as TCP or UDP.

Name specifies the domain name relating to the record, for example 2000trainers.com

Ttl specifies the time to live value, in seconds

Class specifies the DNS record class value, almost always ‘IN’ for Internet.

Priority specifies the priority level of the server. Clients will attempt to contact the server with the lowest priority value.

Weight is a load-balancing feature. If multiple servers have the same priority, clients choose SRV records with higher weights.

Port specifies the port number that a particular service listens on.

Target specifies the FQDN of the host running the service

As such, a domain controller with FQDN dc1.2000trainers.com acting as a global catalog server would have a service record (as well as many others) as shown below:

_gc._tcp.2000trainers.com 600 IN SRV 0 100 3268 dc1.2000trainers.com

Domain controllers register their service records when their Netlogon service starts. As such, stopping and starting the domain controller’s Netlogon service can accomplish re-registration of all SRV records. You should also familiarize yourself with the different subdomains that are created beneath a domain in a Windows 2000 DNS implementation. The four main subdomains created are:

_msdcs – this subdomain is used to allow clients to find domain controllers providing specific services and running Windows 2000.

_sites – this subdomain is used to allow clients to find domain controllers providing specific services in a specific site.

_tcp – this subdomain lists services provided that use the TCP protocol to communicate.

_udp – this subdomain lists services provided that use the UDP protocol to communicate.

Service records and related entries can be verified by using both the DNS MMC snap-in, as well as by querying DNS using nslookup.exe. The syntax to query a DNS server for a list of all service records for a given domain is shown below:

C:\Nslookup >ls –t SRV 2000trainers.com

Planning DNS for Active Directory

Prior to installing Active Directory in a Windows 2000 environment, it is important to first design a DNS implementation that will meet both your name resolution and Active Directory requirements. Active Directory requires DNS in order to provide both name resolution as well as namespace definition, since domain names in Windows 2000 are based on the DNS naming conventions. As such, any servers on which you are installing Active Directory should have their TCP/IP properties configured to be pointing at a DNS server that you have already configured. If you choose not to do this, the installation of Active Directory will automatically create a DNS structure for you, which may not meet your needs.

Since a basic introduction to how DNS queries work was already covered earlier in the series, I am not going to repeat it here. Instead I am going to cover the main areas of DNS that you’ll need to understand in order to successfully implement the service for the purpose of supporting both name resolution and especially Active Directory.

The first concept that you’ll need to be familiar with is the use of DNS to resolve hostnames or fully qualified domain names to IP addresses. As a quick reminder, a fully qualified domain name (FQDN) provides the hostname as well as the domain name of a system. For example:

www.2000trainers.com

In this example, the hostname is the leftmost portion, or www. Hostnames can also be resolved using a HOSTS file, which is a static text file that exists in the %systemroot%\system32\drivers\etc directory on the local machine. DNS should not be confused with WINS, which maps Netbios names to IP addresses (as does the text equivalent, LMHOSTS).

DNS stores a number of different types of resource records beyond simple host or ‘A’ records. The most popular resource records that you’ll find in a zone file are outlined below:

SOA –represent the Start of Authority for a zone, and provides information about the zone including which server is the primary, who the administrative contact is, how often zone database files are checked for changes, database serial numbers, time to live values, and more.
A –represents a unique host address on the network, mapping its hostname to an IP address.
NS – outlines a domain name and the corresponding FQDN of name servers that are authoritative for that domain.
MX – designates that a given host is a mail exchanger (mail server or forwarder) for the domain specified.
PTR – provides reverse lookup capabilities by mapping the reversed IP address of a host to an FQDN. This allows the hostname associated with an IP address to be found. PTR records are found in reverse lookup zone files.
SRV – maps a particular service to one or more hosts. For example, records can indicate a server as a Global Catalog server, domain controller, and so forth.

The second main concept you’ll need to be familiar with is that of a zone. A zone is basically an area of the DNS namespace that functions as an administrative unit. That is, a group of name servers are responsible (have authority) for the records relating to a certain domain and/or subdomains. I like to refer to zones as areas of responsibility. For example, I could create a zone for the domain 2000trainers.com, and create 2 servers that would be responsible (authoritative) for holding records for the defined zone. I could then create a different zone, to be managed by someone else, for the domain asia.2000trainers.com, and have 2 other servers (maybe in Asia) that are responsible (authoritative) for the records in that zone. However, a zone can also encompass a number of domains, as long as they fall within a contiguous namespace. For example, 2000trainers.com and asia.2000trainers.com could be part of the same zone, and have a number of servers responsible for holding records relating to the two domains. If a query was sent to these DNS servers looking for a record ending in 2000trainers.com or asia.2000trainers.com, these name servers could answer the query, since they are authoritative for the zone, which includes the two domains. The main reason for having multiple zones usually relates to administrative authority, as well as zone transfer traffic. For example, perhaps I have one DNS administrator in Canada and one in Asia. Then, two zones may be warranted. By the same token, if I had only one zone, then all DNS servers (perhaps two in Canada and two in Asia) would all need to participate in zone transfers in order to receive updates. This may cause an unacceptable level of WAN traffic.

As a general rule, 5 main types of DNS servers exist which you should be familiar with. These are primary, secondary, active-directory integrated, forwarding, and caching-only. Each is described below:

Primary DNS Server – a primary DNS server is the name server that is authoritative for a zone. Essentially what this means is that this is the only server on which updates to the zone database can be made.

Secondary DNS Server – a secondary DNS server contains a read-only copy of the information stored on the primary name server, and obtains updates via zone transfers. A single secondary is the minimum suggested requirement, but many more can be created for the purposes of load-balancing and fault-tolerance.

Active Directory Integrated – limited to Windows 2000-based DNS servers, this implementation of DNS stores the zone file as an object within Active Directory instead of a series of files on the hard drive. In this scenario, every domain controller running DNS essentially acts as a primary DNS server, allowing updates to the zone file, and handling zone file synchronization via directory replication. As such, if any DNS server should fail, any other AD-integrated server can continue to make updates.

Caching-Only – a caching only DNS server is not authoritative for any zone. As such, it simply takes client queries, performs queries on other DNS servers, caches the results, and passes the answers to clients. By default, a caching-only DNS server will forward all queries for information not found in cache to DNS root servers.

Forwarder – DNS servers can be configured to sent queries that they cannot resolve to other specific DNS servers, referred to as forwarders. The forwarders will then work to resolve the query, instead of the individual DNS servers. This allows the number of requests sent to find hosts (on the Internet for example) to be reduced over time, as the forwarder handles these requests and caches the results, which are subsequently returned to the DNS servers making the request. The can improve both speed and efficiency.

Active Directory Logical and Physical Components

Active Directory can be considered to have both a logical and physical structure, and there is no correlation between the two. The logical parts of Active Directory include forests, trees, domains, OUs and global catalogs. Each element of the logical structure of Active Directory is defined below:

Domain – a domain in Windows 2000 is very similar to a domain is Windows NT. It is still a logical group of users and computers that share the characteristics of centralized security and administration. A domain is still a boundary for security – this means that an administrator of a domain is an administrator for only that domain, and no others, by default. A domain is also a boundary for replication – all domain controllers that are part of the same domain must replicate with one another. Much like NT 4, trust relationships can exist that allow users from one domain to access resources in another. Domains in the same forest automatically have trust relationships configured, but you should also note that you could create trust relationships to external domains (including NT 4-based domains) if necessary. In Active Directory, domain naming follows DNS naming conventions – domain.com as an example.

Tree – a tree is a collection of Active Directory domains that share a contiguous namespace. In this configuration, domains fall into a parent-child relationship, which the child domain taking on the name of the parent. For example, I could create a child domain named Canada under company.com – making the full name of the domain Canada.company.com. Child domains automatically have a transitive two-way trust relationship configured with their parent. This means that the trust relationship can be used by all other domains in the forest as a means to access the domain. Note that Canada.company.com is still a separate domain in this example, which means that it is still a security and replication boundary. As such, an administrator from company.com cannot administer the Canada.company.com domain unless explicitly granted the ability to do so.

Pages: 123

Active Directory Distinguished Names

Active Directory is the directory service of Windows 2000. A directory service is a store of information used for the purpose of both accessing information about objects (such as users, computers, domains, etc) as well as providing authentication and security services. Active Directory is very similar to other X.500-based directory services such as Novell’s NDS and Sun’s Directory Service, both in terms of basic structure and the services that it provides.

A wide range of objects can be created in Active Directory. An object represents a unique entity with the directory, and is usually made up of many attributes, which help to describe and identify it. For example, a user account is an example of an object. This type of object can have many attributes, including a first name, last name, password, phone number, address, and many others. In the same way, a shared printer can also be an object in Active Directory, and can have attributes such as a name, location, and more. The attributes of an object not only help to identify the object, but also allow us to search for it in the directory. For example, I could search Active Directory for a list of all users with first name Mark (perhaps to find his phone number), and would be returned with a list of all users whose first name attribute value is equal to Mark. Keep in mind that there are many different types of objects to be found in Active Directory – everything from domains, to users, to servers, to sites, to printers, and more. Objects are defined in something called the Schema – this is basically the ‘blueprint’ that defines the types of objects that can be created in Active Directory. However, you should be aware that it is also possible to define new types of objects and attributes by extending the Schema to meet the needs of your organization. This could include adding a babysitter’s phone number attribute to user accounts, or creating a whole new object type called Company Vehicles, for example. Much more on extending the schema later in the series.

Pages: 12

Active Directory and Group Policy

As noted earlier, the basic difference between a built-in container and an OU is that OUs can have group policy settings applied to them. Another benefit is the fact that OUs can be nested, which provides benefits in terms of the inheritance of group policy. Note that an OU can be moved within a domain, just like any other domain object. Simple right-click the OU and choose to move it. Be careful about deleting an OU, however, since you will also be deleting all of the objects it contains (at least you get a warning!)

OUs exist primarily for the purpose of organization of resources according to administrative needs. For example, I can delegate control over an OU called Servers to the server support team, and not grant them administrative access to anything else. By the same token, I can apply policies to an OU (such as one containing all bank teller user accounts), which would allow me to lock down the desktop environments of these users specifically. As mentioned in a previous article, group policy can be applied at 4 levels, in the following order:

Local
Site
Domain
OU followed by sub-OUs, if any

The order of application is very important. All group policy settings that apply merge together, unless there is a conflict. In the case of conflicting settings, the settings at the lower level apply. For example, if a setting at the domain level said that users were to have the Run command disabled, and a policy at the OU level specifically enabled it, the user would have access to the Run command. The order followed is the one described above. By the same token, it is possible that conflicting settings would exist in different policies applied to the same OU.

In this case, it is important to note that policies are applied from bottom to top. That is, first Policy A is applied, followed by Policy B, and then Policy C. As such, if there were a conflict between Policy C and Policy A, the settings from Policy C would apply. You can change the order of policies at a given level by using the up and down arrows on this screen.

Pages: 12

Active Directory Computer Accounts

Active Directory requires that computer accounts be created for both Windows 2000 and Windows NT-based operating systems. Similar to NT 4, Windows 9x-based systems do not require this, on account on the fact that these systems do not have a SID. Computer accounts can be created in the built-in Computers container or other containers in advance. If you create the computer account as part of joining a domain, the account will automatically be placed in the Computers container. Of course, it can be moved at any time, according to your management and administration needs.