At a minimum, you should certainly be familiar with the basic purpose of DHCP – to provide client systems with IP addresses. The main reason for the existence of DHCP as a service is the fact that it greatly simplifies the allocation of IP addresses to clients, a process that when done manually can lead to errors, duplication, and a great deal of time spent less than efficiently. Although DHCP does the basic thing that you expect it to in Windows 2000, there is a great deal more functionality that was found in the version from NT 4, and you’ll need to be aware of the differences. Some of the ‘new’ functionality isn’t actually new – for example, DHCP supported the ability to create Superscopes in NT 4 SP2. However, since many of you probably don’t have much experience with Superscopes, I’ll describe them here. On the whole, you’ll probably be impressed with some of the new features of DHCP in Windows 2000, while being able to build on the understanding you originally acquired under NT 4. Nothing like a nice and simple topic to get us started on the last portion of the series.
Category: Windows 2000
Windows 2000 Tutorials
Remote Installation Services (RIS)
Although the basics of RIS have been covered in previous articles, you’ll need to know a little more about what it is capable of. Remote Installation Services is part of a broad group of Windows 2000 services that also go by the name Intellimirror. These technologies are meant to allow configuration management to be automated. With RIS, Microsoft has provided a technology that will allow a computer capable of booting off the network to start and automatically download its operating system image. The idea is that in combination with technologies such as group policy, a user could have their complete environment ‘rebuilt’ without necessitating that a technical support person make a physical trip to their location. Note that as far as Microsoft is concerned, RIS only distributes images of Windows 2000 Professional, not Server (or 9x, NT, etc).
As a review, remember that in order for RIS to function, 3 services must be available on the network. These include:
- DHCP (to give the OS-less client an IP address for network connectivity)
- DNS (to allow the client to find Active Directory, and subsequently a RIS Server)
- Active Directory (to control who which users / computers have permissions to access an images, which RIS server provides the requested image, and to determine the computer account placement)
There are also requirements with respect to the client computer in terms of RIS Support. In order for a client machine to be able to boot and obtain an image via RIS, the client requires PXE functionality. PXE stands for Preboot Execution Environment, a technology that allows a PC that supports the standard to obtain TCP/IP network connectivity. This is accomplished in one of three ways.
- The client computers meet the PC98 or NetPC specification
- The client computers have a PXE-compliant BIOS
- The client computers have a supported PXE-compliant network adapter card.
Note that if your client machines do not meet the specs above, there is still hope. Windows 2000 includes support for a small number of network cards that are not PXE-compliant. This support allows a boot disk to be created that allows the PXE to be emulated. In order to create this disk, the rbfg.exe utility must be used (found at \\servername\REMINST\Admin\I386\RBFG.exe).
Managing Operations Masters
Having already looked at what the operations masters roles are responsible for in previous articles, in this section we take a look at the actual management of the 5 roles, which includes the transfer or seizing of the roles. Just to quickly recap, the operations masters roles are special role held by certain domain controllers on a per domain/ per forest basis. The 5 roles are:
- Schema Master – controls originating updates to the Schema. One domain controller per forest holds this role.
- Domain Naming Master – controls the addition / deletion of domains from the forest. This system must also be a Global Catalog Server. One domain controller per forest holds this role.
- PDC Emulator – acts as the PDC for BDCs when the domain is in mixed mode, manages password changes for downlevel (pre-win2k) clients, is the focus for group policy changes, and is immediately forwarded all password changes. One domain controller per domain holds this role.
- RID Master – allocates the pool of relative identifiers (RIDs, which are the unique part of SIDs) to each domain controller in the domain. One domain controller per domain holds this role. Note that you can view the RID pool allocation using a utility called dcdiag, the domain controller diagnostic utility.
- Infrastructure Master – is responsible for updating user-to-group references between domains. This role should not be held on a domain controller which is also acting as a global catalog server – the infrastructure master will not function in this scenario because it holds a copy of all objects, and therefore has no external references. One domain controller per domain holds this role.
The ability to transfer roles is important, since a domain controller may need to be taken offline for maintenance. In this scenario, we simply transfer the role as will be described shortly. However, in the event that a DC holding an operations master role should crash, we might need to transfer the role by seizing it, a more drastic action. If you are taking a domain controller offline for a significant period of time, be sure to transfer the roles that the domain controller holds. Note that since changes to the schema and adding and removing domains are both rare, it may not be necessary to transfer these roles, even if a domain controller needed to be taken offline for a longer period of time.
Active Directory Database Management
The Active Directory database is where all information relating to the directory is stored, including domain objects and attributes, schema, configuration, and global catalog information if applicable. As such, you must have an awareness of how the database works, as well as how it can be maintained. This includes knowing how to do a backup/restore, defragmentation, as well as how to move the database.
The Active Directory database is referred to as a transactional database, which means that every change to the database is treated as an individual transaction. The transactional nature of the database helps maintain integrity in the event of a failure. The Active Directory database is actually made up of a number of files that you need to be aware of:
Ntds.dit – this is the actual AD database file, where all objects are stored. By default you will find this file (and the others mentioned here) in the %systemroot%\NTDS folder.
Edb*.log – these files are transaction logs. Before any update is written to the database, it is first written to the transaction log. Each edb.log file is 10 MB in size. By default Windows 2000 uses circular logging, meaning that once full, the log file begins overwriting the oldest changes. If circular logging is turned off once the log files are full they are renamed ebdxxxxx.log, with xxxxx representing the number of the file starting at 00001.
Edb.chk – this is a checkpoint file, used by AD to track which changes have been written to ntds.dit. This is used for recovery purposes. For example, if a domain controller crashed and information had not yet been written to the database, the checkpoint file would server as the marker/pointer as to what from the log file still needs to be written to the database.
Res1.log and Res2.log – These are reserved log files, 10 MB each. Their purpose is to allow Active Directory to continue to log changes, in the event that all disk space in filled. As such, these 20 MB of files are actually just empty files reserving space, and are not used unless needed.
Remember from our earlier look at installing Active Directory that Microsoft recommends placing the log files and database on separate disks for best performance.
Active Directory Replication
Windows 2000 implements replication much differently than Windows NT 4. In Windows NT domain environments, replication was single-master, meaning that only one domain controller actually accepted updates – the PDC. In Windows 2000, the model is multi-master, meaning that any domain controller can update Active Directory. This presents some challenges in terms of tracking changes on the network and resolving conflicts that might occur, as I’ll discuss in a moment. However, along with the challenges that Windows 2000 Active Directory replication presents, it also presents an opportunity in that replication can finally be easily controlled, through the use of sites, site links, and schedules.
I could easily have devoted this entire article to only replication, since there is so much that takes place behind the scenes. Thankfully, what is most important to understand is a handful of concepts (albeit a rather large handful), most of which are rather straightforward. Lets begin by taking a look at how replication works.
In an Active Directory environment, all domain controllers do not contact one central domain controller for changes. Instead, they create relationships with one another which track which domain controllers are sources of replication changes for them. These relationships are called connection objects, and I’ll discuss how they work and how they are created shortly. Since every domain controller can accept updates, there is actually a distinction as to which domain controller made the original update. This update is called the originating update. Any update that is received on a DC as a result of replication is referred to as a replicated update.
Kerberos v.5
Windows 2000 Active Directory relies on a different authentication protocol than Windows NT 4. Where NT 4 used the NT Lan Manager (NTLM) protocol for authentication, Windows 2000 utilizes Kerberos. The Kerberos protocol was developed at MIT, and is named after Cerebus, the three-headed fire-breathing dog that guards the gate to Hades. Why do I bother telling you this? Because it makes it easier to remember that Kerberos is a 3-pronged authentication scheme. The three parts of Kerberos are:
- Client – the system/user making the request
- Server – the system that offers a service to systems whose identity can be confirmed
- Key Distribution Center (KDC) – the third-party intermediary between the client and the server, who vouches for the identity of a client. In a Windows 2000 environment, the KDC in a domain controller running Active Directory (It could be a UNIX-based KDC also)
The way that Kerberos works can seem a little intimidating if you get into all of the tiny little details, but I’ll spare them for an overview of how things work. It is more important that you understand the process to begin with. If you want every behind-the-scenes detail, I’ve provided a link at the end of the section.
In a Kerberos environment a user provides a username, password, and domain name (often referred to as a Realm in Kerberos lingo) that they wish to log on to. This information is sent to a KDC, who authenticate the user. If the user is valid, they are presented with something called a ticket-granting ticket, or TGT. I like to consider the TGT to be like a hand-stamp admission to a country fair – it proves that you have paid admission and have proof. The TGT is helpful in that it does not require you to constantly re-authenticate every time you need to access a server.
However, if you do want to access a server, you still require a ticket for that server or you will not be able to create a session with that machine. Think of a ticket as being like the ticket you need to purchase to get on rides at the country fair – even though you’ve paid admission (proved by the hand-stamp or TGT), you still need a ticket to get into the haunted house. When you wish to access a server, you first need to go to the KDC, present your TGT as proof of identity, and then request a session ticket for the server you wish to contact. This ticket simply acts as authentication between the client and the server you wish to contact. If you are authenticated, whether or not you will be able to actually access anything on the server will depend on your permissions. The TGT and session tickets that you are presented with actually expire after a period of time that is configurable via group policy. The default value for a TGT (also referred to as a user ticket) is 7 days, while the default value for a session ticket (sometimes called a service ticket) is 10 hours.
In a single-domain environment, Kerberos authentication is pretty straightforward. However in a multiple domain environment Kerberos has more steps involved. The reason for this is that when you are attempting to obtain a session ticket for a server, it must be obtained from a KDC in the domain where the server exists. Also, you must obtain session tickets in order to traverse the trust-path to the KDC you need to contact. The example below outlines the steps necessary for a client in west.2000trainers.com to access a server in east.2000trainers.com.
- The client logs on to the network as a user in east.2000trainers.com, and is presented with a TGT.
- The client wants to communicate with a server in west.2000trainers.com. It contacts the KDC in east.2000trainers.com, asking for a session ticket for a KDC in the 2000trainers.com domain.
- After it receives this ticket, it contacts the KDC in 2000trainers.com, requesting a session ticket for the KDC in west.2000trainers.com.
- After it receives this ticket, it contacts the KDC in west.2000trainers.com, and requests a session ticket for the server in west.2000trainers.com whom it originally wanted to contact.
- Once granted the session ticket for the server, the client contacts that server directly and can access resources according to the permissions in place.
If this seems like a great deal of steps, that is indeed true. This is one of the reasons that you might consider implementing shortcut trusts, as outlined in my last article. If shortcut trusts exist, the shorter available path would be used. Kerberos is a wonderful protocol in that is makes the network much more secure, due to the necessity of authentication between clients and servers before a session can be established. It is actually much faster than you might think. For a good hands-on experiment, you might consider setting up multiple domains and then running network monitor while accessing resources between domains. Though the packets contents are encrypted, it will still give you a great idea of what is happening behind the scenes. Three utilities that you should be aware of for troubleshooting Kerberos problems are Netdom (discussed in a previous article), as well as the resource kit utilities KerbTray.exe and Llist.exe.
Active Directory Forests and Trust Relationships
As I outlined in previous articles, all domains within an Active Directory forest are capable of accessing one another due to the nature of the trust relationships that are automatically created. A transitive two-way trust relationship exists between every child domain and its parent domain, and transitive two-way trust relationships exist between the roots of all trees and the forest root. It should be noted that in some cases you will need to create additional trust relationships, both within and external to your forest.
For example, you might have a domain that is still running Windows NT 4, whose users you wish to be able to access a domain in your Active Directory structure. This would require an external trust, which is very similar to the trust relationships that you should be familiar with from NT 4. These trusts are one-way and intransitive, meaning that they can only be used to provide access to a single domain. In the scenario I described above, the trust relationship might look something like the diagram below:
Figure: Trust relationship with an external domain
In this particular example, users from the domain NT4DOMAIN would have access to resources in the asia.win2000trainer.com domain only. Of course, a two-way trust could be created between the two, allowing users from asia.win2000trainer.com access to resources in NT4DOMAIN. If users in NT4DOMAIN needed access to resources in all 3 of the win2000trainer.com domains, 3 trust relationships would need to be created at a minimum.
The tool used to create external trust relationships is Active Directory Domains and Trusts. This tool is used to create, manage, and verify trust relationships between domains. Note that the tools will show both internal and external trust relationships that exist. By accessing the properties of a domain, you can view the trust relationships that exist on the Trusts tab.
Note that the domain name, relationship (internal/external), and whether the relationship is transitive will appear on this screen. Note that like NT 4, for security purposes external trust relationship information must still be entered in both domains participating. Note that external trust relationships can connect a Windows 2000 domain with NT 4 domains, Windows 2000 domains (from different forests), as well Kerberos v.5 realms.
The second type of trust relationship that can be created is referred to as a shortcut trust relationship. This type of trust is created to shorten the path that needs to be followed for the purpose of authentication. For example, if I had a forest as shown below, getting to china.asia.2000trainers.com from europe.2000trainers.com would require crossing 3 trust relationships.
If users in europe.2000trainers.com did need to regularly access resources in china.asia.2000trainers.com, it might make sense to create a shortcut trust (as shown below) to lessen the number of trust relationships that would need to be traversed. Note that shortcut trusts are two-way transitive trusts, and that they are also created in Active Directory Domains and Trusts.
In order to verify trust relationships, you can use the edit button in Active Directory domain and trusts when a domain in the list is selected. This will attempt a secure channel query to the other domain, and will return results as to whether it was successfully able to verify the relationship or not. Further to this, another tool that you should be aware of for verifying trust relationships is Netdom.exe, a command-line utility that can be found in the Windows 2000 resource kit.
Deploying Software Using Group Policy
Since the basics of this topic were looked at in previous articles, my intention is to look at some of the more advanced options here. For the purpose of review, the basics of group policy are outlined below.
In an Active Directory environment, group policy allows us to distribute software to users and computers using a repackaged file format, .msi. When software is deployed using group policy, the user needs no special privileges, since the software is installed using the elevated privileges of policy. If a vendor does not provide an msi file for their software, you can use a repackaging program, such as WinInstall LE (found on the Windows 2000 CD) to create one. The two basic options when deploying software via group policy are to either Assign or Publish it. Software can be either published or assigned to users. If assigned, the software appears to ‘follow’ the user, regardless of where they log on. Shortcuts appear on the start menu, but the software isn’t actually installed until they click on the shortcut. When assigned to a computer, the software is installed on that computer the next time it reboots, and is available to all users of the system. When software is published (which can only be done to users, not computers), the software is available to install from Add/Remove programs, and can also be installed by document invocation (when a user click on a file type associated with that application). Publishing software makes it available to users, but doesn’t create the illusion that it is actually installed. An application can also be published using a .zap file, if an msi does not exist or if one cannot be created. Note that if a .zap file is used, the user will require a level of privilege suitable to install the application. Also note that software deployment options are only applicable for Windows 2000-based systems, and would not be applied if a user logged on to Windows 98, for example.
The Software Settings area of group policy is where the publishing or assigning options are set. When an application is deployed by group policy, the first option that must be chosen is whether the application will be published or assigned.
The advanced elements of software deployment can be set up when you originally choose to deploy the software (by choosing Advanced published or assigned as shown above), or later by accessing the properties of the deployed software. The advanced properties allow you to control a number of elements with respect to the deployment, including the addition of upgrades or patches, modifications, as well as uninstalling packages.
There are 6 property sheets associated with advanced application deployment, and you should be familiar with them. The general tab lists basic information about the package (such as the version number), while the security tab contains the ACL for the object. The deployment tab, shown below, controls whether the application is published or assigned (which can be changed). If published, you can control whether or not the application will be installed by document invocation (this option is grayed out when you choose to assign an application).
Note the option to uninstall the application when it falls out of the scope of management. If this is chosen, and the GPO that deployed the software no longer applies (for example if a user or computer object was moved), then the software would be automatically uninstalled. The installation user interface options allow you to control how much interaction the user will have during the installation process.
The upgrades tab (shown below) allows you to automate the deployment of patches and upgrades (such as newer versions) to applications that have already been deployed via group policy. If the upgrade is made mandatory (the required option is selected) then the upgrade will be applied, and the user will only be able to use the updated version. If it were not made mandatory, then the user would be able to use both the old and new versions of the software. This is potentially useful when a new application is not backwards compatible.
The categories tab allows you to create and control the way that applications are presented in Add/Remove programs. For example, you could create categories for each type of software, such as graphics applications, word processors, and so forth. This section would allow you to group the newly published application into one of those categories in order to make it easier for a user to install the correct application.
Finally, the modifications tab (shown below) allows you to further customize a package for users with special needs. For example if you wanted to deploy a language-specific dictionary for users in different offices, you could apply a modification to the package. Modifications are made in the form of .mst files (also known as transform files). For those who are interested, there is a utility provided with the Office 2000 resource kit to create .mst files.
Group Policy Inheritance
As mentioned many times in previous articles, group policy settings are applied in the order Local, Site, Domain, OU. This order controls which settings end up actually applying to a user or computer. Remember that all settings merge together by default, and that in the event of conflicting settings, the one applied latest will apply.
You may have noticed what many do when first looking at group policy application – that an administrator with control of only a single OU could possibly override settings set by a domain administrator. This is absolutely true, since OU settings will ultimately override those set at the domain level in the event of a conflict. However, this behavior can be controlled via two settings, Block Inheritance and No Override.
The Block Policy Inheritance setting may seem even worse. If an OU administrator were to set this on her OU, then all policies coming from ‘above’ would be completely blocked by default. That is, she could refuse to inherit any policy settings from the site, domain, or parent OU. Note that this feature is also a powerful capability, in that if you didn’t want any domain policies to apply to your developers, for example, you could simply block inheritance of policy at particular OU.
For those who feel uncomfortable with Block Inheritance, worry not. Another setting that can be set on a GPO is No Override, and No Override always beats Block Inheritance. As such, if I created a policy at the site level set to No Override, and the administrator of the Developers OU set the OU to Block Inheritance, the settings contained in the domain policy would still be applied regardless. Note that other policies without No Override enabled would still be blocked in this scenario. The No Override setting is set using the Options button on a GPO.
One last thing that you need to know about GPOs is that they can be filtered. That is, you can control exactly who a GPO will apply to by setting the appropriate permissions in the GPO’s ACL. For example, let’s say that you had an OU called Sales, and you wanted a GPO to apply to all users in the OU except for a user called SalesAdmin. By default, the GPO is always applied to all Authenticated Users, who have the Apply Group Policy and Read permissions set to allow. For out SalesAdmin user, we could prevent the GPO settings from being applied by giving him the Deny Apply Group Policy permission.
You should use filtering of GPOs sparingly, as it can complicate GPO troubleshooting. However, you should also recognize that it provides a powerful way to control policy application to users and groups, since GPOs cannot be linked to these types of objects.
Group Policy Overview
As described in previous articles, group policy in Active Directory allows us a great deal of flexibility in terms of how users and their Windows 2000 computing environment is controlled and managed. Things that can be done with group policy include software distribution, updating settings such as Internet Explorer’s proxy server settings, locking people out of Control Panel, and so forth. It is worth investigating the hundreds of settings that can be configured in group policy, but unnecessary to remember all (or even most) of them. However, be sure to at least familiarize yourself with the different possible settings and why they exist.
The main reason for the existence of group policy is to be able to control the user environment and make changes with the least amount of administrative effort. For example, I could remove the My Network Places icon from certain user desktops by setting up a group policy object applied to an OU. When users whose account exists within that OU would log on, the icon would not be available for them, regardless of what system they logged on to within the Active Directory forest (unless a conflicting policy had also been configured at another level, as we’ll discuss in a moment).
Although the idea behind group policy settings is pretty straightforward, it can be confusing to configure them correctly, since settings can be made at many different levels. Group policy objects (GPOs) can be applied at the following levels:
Local
Site
Domain
OU (and sub-OU)
The order listed above is also the order in which policy settings are applied. What that means is that policy settings at all levels merge with one another (with exceptions when Block Inheritance and No Override are used, to be discussed later). As such, if a local group policy says that I lose the Run command, site group policy says I lose access to Control Panel, domain group policy says my desktop wallpaper is the corporate logo, and the OU policy redirects my My Documents folder, then when I log on all of those things will happen. However, in the event that a conflict exists (for example the site policy takes away Run, while the OU policy says it should be available), then the lower-level policy settings take precedence.
Local GPOs are stored on the local system, and only one can exist on a Windows 2000 machine. All other GPOs – those applied to sites, domains, and OUs – are stored in Active Directory. Actually, a GPO is made up of two parts. The group policy container is stored in the AD database (this contains most settings), while larger ‘extras’ such as logon scripts are stored in the group policy template, which is stored within the Sysvol folder on a domain controller. The path to where policy templates are stored is %systemroot%\SYSVOL\sysvol\domain_name\Policies, where the folder name for the template is the globally unique identifier (GUID) of the GPO.
Group policy objects can be created by using the Group Policy MMC snap-in, but are usually created from within Active Directory Users and Computers. Remember that GPOs can only be configured and applied to the local system, sites, domains, and OUs. As such, you cannot be applied to the default built-in containers, such as Users or Computers. To create a new group policy object, right-click the appropriate container in AD Users and Computers and access the Group Policy tab. To create a new policy, click New, and give the policy a name.
You can also add an existing policy. This is useful, especially if you wanted to link the same GPO to many OUs that required identical settings. After you have named the OU, you need to click on Edit to actually configure the policy settings.
Note that settings fall into two major areas, Computer Configuration and User Configuration. Settings in the top portion apply to Computer Accounts and settings in the bottom apply to User Accounts. As such, if your computer account were in an OU called Desktops, the computer configuration settings would be applied according to the GPO settings from that OU. By the same token, if your user account were in the Sales OU, user configuration settings would be applied from that OU. If either part of the OU is not being configured in a given GPO, you should disable that portion, which will speed up group policy processing. This is done by clicking the Properties button on the Group Policy tab.
Note that multiple GPOs may exist linked to the same container. In this situation, it is possible that conflicting settings exist in the policies. When multiple GPOs exist at the same level, the policies are applied from bottom to top. That is, policies at the bottom of the list are applied before those above. The settings applied later always take precedence over those applied earlier. In the example above, User Policy 3 would be applied first, followed by User Policy 2, followed by User Policy. As such, if a site policy and domain policy also existed, the order of application would be:
Site
Domain
User Policy 3
User Policy 2
User Policy
Note that if any policies were applied to sub-OUs that