Robert Explains - Windows 2000 and 2003 domains

Filed By: Robert Moir

Robert Explains - Windows 2000 and 2003 domains

All you wanted to know about Windows 2000 and 2003 active directory terminology

This article is aimed at people who are comfortable with basic networking, and who have probably used either Windows NT 4 or Netware in the past to deliver their network. I hope this will be of special use for RM Connect users who have either just upgraded to CC3 or who are just about to.

Before I start, I want to remind everyone who feels encouraged to "peek into the engine compartment" because of this article that while it is certainly OK to look at how things go together, you should be very careful about changing anything you do not understand. Changing the right thing can improve the way your network behaves greatly, but changing the wrong thing... well you can see where this is going, I won't labour the point.

If you are completely new to the concepts in Windows 200x domains, please see part one which explains the roles of Domain Controllers in Active Directory.

Active Directory

Active Directory, often written as just 'AD' is the name given to the domain structure used in Windows 2000 and Windows 2003 domain based networking. It is based to some degree on old X.500 directory services structure and is designed to offer greater scalability and greater performance in larger network setups than was possible with NT 4 domain structures.

Active Directory Objects

Anything that is created and or described in active directory. For example, user accounts and groups, machine accounts, printers, OUs, etc are all objects in Active Directory.

Global Catalog

A server that holds a complete replica of the configuration and schema naming contexts for the forest, a complete replica of the domain naming context in which the server is installed, and a partial replica of all other domains in the forest. The global catalog is the central repository for information about objects in the forest.

To Check which server holds the Global Catalog:

  • Open Active Directory Sites and Services console on a machine with the administration tools installed.
  • Go to Sites\[Site Name]\Servers\, expand the server you want to check.
  • Right-click NTDS Settings and choose Properties.
  • In the window that appears, see if "global catalog" is selected.

Organizational Unit

Usually written as "OU", an Organisational Unit is a conveniant way of grouping similar or related AD objects together. OUs are neutral (simply placing an object in an OU doesn't do anything to alter the properties or abilities of that object), but can be used to group together objects whose properties you wish to monitor and change, e.g. via group policies.

Note that this is not the same as a user group, even though OUs are obviously used to group user accounts together. Group Policy Objects are applied at the OU level.

Group Policy Object

GPOs are the development of the computer policies used under Windows NT networks which are far more flexible in both how much control they give and how you deploy them. GPOs are applied at the Organisational Unit level and flow down and apply to all other objects within that OU, including other OUs, unless you specifically block inheritence.

You can apply different GPOs at the same level, and in a series of nested OUs you can apply GPOs at lower levels that contradict settings made at the higher level. This can make figuring out how some computers and users settings are arrived at a bit compled if you over-do it, but it can provide a lot of flexability. I'm going to write more about creating your own GPOs later.

MSI

'MicroSoft Installer Package'. These are software installation packages that are designed to be distributed to machines and/or users in an Active Directory environment. In a 'traditional' Active Directory situation you can assign a package to either a machine or a user by publishing it in a GPO that contains all of the users or computers you want to have the package. In a RM CC3 network you publish MSIs to machines only, using the RM Management Console. 

Active Directory Users and Computers

Or "ADUC". This is the main console for managing users, computer accounts, groups, etc that Microsoft provide. You can also edit GPOs and assign them to OUs with this.

Group Policy Management Console

Which is inevitably written as "GPMC". This is a new Windows 2003 tool to make the creation, application, management and monitoring of GPOs easier. It also works with Windows 2000 domain controllers, but requires a Windows XP SP1 or higher computer to run from if you don't have Windows 2003. This is a free download from Microsoft that I strongly advise everyone to get. In fact there are a lot of free tools that are easily available for free from the Windows 2003 download site.

David Whitworth has pointed out to me that you also need the .net framework installed to use GPMC, which I had totally forgot about. He also points out there is also a hotfix that is required but installed by the GPMC installer automatically if you don't already have it. Thanks David!

RSoP

Resultant Set of Policy. This refers to the policies that are actually applied to a user or computer at logon as a result of the system looking at the GPOs you have configured to be applied and working out what combination of settings should apply to an object. Very important for troubleshooting when you think a user should be getting a setting thats applied in one GPO but they seem to be getting a setting thats applied in another GPO that you think you've over-ridden. Mentioned together with the GPMC as the GPMC is one of the very best tools I've seen so far for exposing this data in a simple to understand fashion.

LDAP

Lightweight Directory Access Protocol. A well known Internet Standard for working with all kinds of Directory Services, and one which works quite well for programatically querying and modifying Windows Active Directory services.

ADSI

Active Directory Service Interface. Or I've also seen it written as Scripting Interface, which according to Microsoft is incorrect but which probably gives you more of a clue as to what ADSI is and why you should give a damn. ADSI is a scriptable route into AD (and a few other things besides) which is used quite heavily if you need to write your own cute little scripts to perform jobs with user accounts or suchlike. Often thought of alongside LDAP which is why I'm mentioning it alongside LDAP.

DNS

Domain Name Services of course, and usually only associated with Internet connections. But a dynamically updatable DNS server is used quite heavily in Active Directory. If you want to get to grips with AD, make sure you understand its relationship with DNS first.

ACL

Access Control lists are the names for the rights assigned under the security tab on an NTFS file or folder, and you probably knew that already. These kinds of rights are also available for the registry, so you can control who can view what and who can amend what. These rights are also available to be set on AD Objects too, but are hidden from view in some instances where fiddling with them may prove to be especially destructive.

An example where ACLs will often be set (and which is used to very good affect by CC3) is on GPOs: You can set an ACL on GPOs that controls which users and groups it will be applied to, and as normal with ACLs you can set both permit and deny rights on an object so its possible to build up quite complex setups with just a bit of planning.

Forest Root

There can be some confusion here because both Microsoft and Research Machines use that term to mean different things. When talking about domain controllers, "Forest root" is a name RM use, and it applies to the first CC3 server in a domain which holds all the extra CC3 bits and pieces.

When Microsoft talk about a "Forest Root", they mean something quite different and are referring to your AD design layout, not your actual domain controllers.

FSMO Role

FSMO is an acronym and stands for 'Flexible Single-Master Operations'. A 'FSMO role' refers to several special jobs that are done by domain controllers in an Active Directory forest and/or domain.

In Active Directory all of the domain controllers are peers. As I said in part one there are no PDCs and BDCs.

The ability of all DCs in a Active Directory domain to update their copy of an AD object and then replicate it out to the other DCs, is referred to as Multimaster Replication. All Active directory DCs contain a writable replica (or copy) of the Active Directory Database as opposed to Windows NT's domain model where the only writable copy of the domain information was held on the PDC and the BDCs just had readable copies.

So why are there FSMO server roles?  Since each DC in a Windows 2000 domain can update their own copy of the Active Directory and then replicate it to all othe DCs, what happens if more than one person is making the same change to Active Directory at the same time? There are certain rules that are followed to prevent conflicts in updating the AD database, but some changes are to important to the domain to be left to these rules.

These very important roles are referred to as Flexible Single Master Operations server roles.  The servers that hold these FSMO roles are responsible for updating certain aspects of Active Directory.  By making designated servers responsible for certain updates instead of allowing every server to make all updates, you prevent conflicts in Active Directory updates.

In an AD Domain environment there are 5 FSMO roles that are necessary for the proper functioning of Active Directory. Two of the server roles exist at the Forest level and three exist at the Domain level. In a single-domain operation that means all 5 roles are held on your domain controllers. In a multi-domain operation, every domain will have the three domain roles, and the two forest roles will be held by a DC somewhere in the forest.

PDC Emulator (One per domain)
RID Master (One per domain)
Infrastructure Master (One per domain)
Schema Master (One per forest)
Domain Naming Master (One per forest)

To find out which servers in a domain hold the FSMO roles, use the netdom command from the server support tools. Using the command 'NETDOM QUERY FSMO' should return the FSMO role holders.

I'm sure that I've missed no end of stuff out so this may expand over time. The next bit in the "series" will cover simple GPO creation and manipulation.

Top