The Importance of a Domain - Domain and Forest Modes
(Page 11 of 11 )
When you first install the Active Directory, it is possible to have NT 4 BDCs participate in the domain but obviously the Active Directory can offer far more than what was possible previously. To keep compatibility with the older NT 4 BDCs some of this functionality has to be disabled. This is known as running in mixed mode.
Once all domain controllers are Windows 2000 or above, you want to enable this new functionality by switching to an Active Directory native mode and with Windows 2000 these were the two domain options: mixed or native mode.
Windows 2003 Active Directory offers yet more abilities. So now, when all domain controllers in a domain are running Windows 2003 there is a Windows Server 2003 mode that enables the new abilities and once every domain in the entire forest is running Windows 2003 you can switch to a Windows 2003 forest mode.
Windows 2003 also introduced another domain and forest mode, known as "Windows 2003 Interim mode". This mode is available when upgrading from NT 4 to Windows 2003 directly and as we will see, overcomes some of the limitations of the Windows 2000 Active Directory implementation.
A brief overview of the changes between the various domain and forest modes is given overleaf. It is important to remember that switching to a higher domain mode is a one-way operation, you can never downgrade your mode: for example, you cannot go from native to mixed mode.
Domain Modes
Let's consider the domain modes:
Mixed Mode
This is the default domain mode when performing a fresh installation of Active Directory or when performing an upgrade and allows Windows 2000 and Windows 2003 domain controllers as well as NT 4 BDCs.
Windows 2000 Native Mode
In native mode, no NT 4 BDCs but only Windows 2000 and Windows 2003 domain controllers can be present.
This mode has additional functionality including nesting groups, Universal groups, and support for SID history and group conversions.
Windows Server 2003 Interim Mode
In 2003 interim mode, only Windows 2003 and NT 4 BDCs domain controllers (no Windows 2000 domain controllers) can be present in the domain.
This mode does not add any real extra functionality; it is used for the 2003 interim forest mode that fixed some problems with groups over certain sizes and site connectivity.
This domain mode can only be set when upgrading from Windows NT 4 to Windows 2003 and is set while running the DCPROMO utility on the first domain controller to be upgraded.
Windows Server 2003 Mode
In 2003 mode, only Windows 2003 domain controllers can be present. This has additional functionality over 2000 native mode, such as:
- Domain controller rename
- Password on InetOrgPerson objects
- Ability to redirect the default Users and Computers container
- Last logon timestamp attribute
Forest Modes
The forest modes:
Windows 2000
In Windows 2000 forest mode, all versions of domains and therefore all types of domain controllers (NT 4 BDC, 2000/2003 DC) are allowed. This is the default forest mode.
Windows Server 2003 Interim Mode
In Windows2003 interim mode, only Windows 2003 and NT 4 domain controllers can be present. This has additional functionality over the Windows 2000 mode including:
- More than 5000 users in a group via linked value replication (LVR)
- Improved ISTG (Inter Site Topology Generator), which is responsible for creating the replication topology between different locations
- Additional attributes added to Global Catalog
Windows Server 2003 Mode
In Server 2003 Mode, only Windows 2003 domain controllers can be present. This mode has additional functionality over 2003 Interim including:
- Dynamic auxillary classes, which allow the creation of objects with an associated Time To Live (TTL) that are automatically removed once that time has expired
- The ability to convert User objects to INetOrgPerson (and vice versa)
- Schema de-/reactivation
- Domain rename
- Forest trusts
- Basic and Query-based groups
- 15 second intra-site replication frequency (with a 3 second offset)
- Linked Value Replication.
Linked Value Replication now allows individual elements of a multivalued attribute to be replicated instead of the whole value. This is a great improvement for Universal Group replication, which earlier required the replication of the entire group content each time a single change to its' membership occurred. This should also reduce the chances of normal group membership changes within a group. This can happen if administrators on different domain controllers modify the same group; one will overwrite the other. Now, the changes will be merged.
The overall goal of your environment is to get to Windows Server 2003 domain and forest modes, which opens up all the functionality in the most efficient way.
One vital point to understand is that forest mode restricts what versions of Domain Controllers can participate in the domain. They cannot be normal member servers or workstations. Even in a Windows Server 2003 mode domain, you can have NT 4 member servers and clients; the modes are only used to restrict the participating DCs so that all DCs can support the newly enabled functionality to stop any corruption of the database or variation in the service that clients receive.
Group Policy
Under Windows NT 4 domains, we had System Policies that could be modified and created with the supplied Group Policy Editor tool. A number of restrictions could be configured, which could be saved in a file called NTCONFIG.POL, placed in the netlogon share on each domain controller, and applied when users logged on to the policy.
This was not very advanced, however, and all these policies were basically registry settings which 'tattooed' the registry—even after the policy was turned off, the registry change would still be in effect on the client machines.
A high level of granularity was also not possible. Policies could be applied to users, groups of users, or computers.
With the Active Directory, we no longer have System Policies, we have Group Policy, which really is a giant step past what we had under Windows NT 4, and its target is to meet the following ideal:
"The ability for the Administrator to state a wish about the state of their Users environment once, and then rely on the system to enforce that wish." |
To achieve this, the Group Policy implementation (like the Active Directory) was rewritten from the ground up. While it still has a large portion based around the registry (although it no longer 'tattoos' the registry; if a policy setting is disabled or the policy deleted, all the changes it made are undone by default), group policies can also do much more including:
- Deploy applications on a per-user or machine basis in certain sites, domains or OUs; these deployed applications can be self-healing when using the Microsoft Installer Format (MSI files)
- Run logon/logoff/machine-startup/maching-shutdown scripts
- Redirect folders
- Configure local machine policies and rights
- Configure certificate, IP sec policies, etc
- Set the membership of local groups: for example, setting the members of the local Administrators group on machines to which the group policy is applied
- Enforce software restriction, which can prohibit certain applications from running (Quake can finally be wiped off your network!)
A Group Policy Object or GPO is a specific group of settings configured from the entire group policy scope: for example, it could contain some registry settings, some application deployment, and some folder redirection.
Group Policy Objects are split into two main branches, the User Configuration and the Computer Configuration, which, as the names suggest, apply to either the computer or the user.
Once the Group Policy Object is defined, it is then linked to a target container (since we are linking a GPO that can be linked to multiple containers while maintaining only one copy of the GPO itself).
GPOs can be linked to:
- A site
- A domain
- An organizational unit (at any level of the OU hierarchy)
The policies are applied in this order: first, the GPOs linked at the site the computer belongs to are applied, then the GPOs linked to the domain of the computer/user are applied, and then the GPOs linked to the OUs the computer/user are in are applied. For the Organizational Units, the GPOs at the top of the hierarchy are applied first and then the next layer until finally any GPOs linked at the actual OU the object is in are applied.
The GPO application is accumulative; you don't just get the policy 'closest' to the user/computer. It applies all of the policies but in case of a conflict the setting applied last takes precedence. There are some options that override this default behavior, but we will worry about that later.
You do not have to link policies at each level (in fact it is not that common to link GPOs at site levels) and you should try to minimize the various layers that GPOs are linked to, as this can adversely affect startup/logon times, as each GPO has to be processed.
Because the GPOs are linked, it is possible to actually link multiple GPOs at each applicable layer. The order of the application is set to ensure that the correct policy at each level takes precedence.
There is one other layer of policy; each machine has a local policy that can be modified using the Local Security Policy MMC snap-in. These settings are applied first, which means any setting applied via the Group Policy will override a local setting, which can be made on one of two local policies (Local Security Policy and the Local Group Policies).
The way to remember the application is LSDOU:
Local > Site > Domain > Organizational Unit
The application of group policy is shown in the following figure, which demonstrates policies applied at all the possible levels and the order in which they are applied:
In this figure, firstly, the local machine policy (1) is applied, then the group policy (2) linked at the site level. GPOs linked at the domain (3) are applied, followed by GPOs applied at the top layer of the OUs (4) and finally the GPOs are linked at the actual OU the object resides in (5).
Unlike NT 4 policies, which were applied at logon time, the Group Policy is actually refreshed periodically on the machines (every 90 minutes by default). However, the software deployment and folder redirection are not updated; if these were changed, it could have a very negative effect on your session.
Group Policy is extremely powerful and a great feature of the Active Directory, which you will undoubtedly use in your environment.
Summary
Under NT 4 domains there were not many design choices to make; the requirements dictated the technical solution. The Active Directory has many different architectural components with each having its own advantages and appropriate usage situations.
If your infrastructure was a house, the Active Directory would be its foundation. If your AD implementation is well designed, you will have a very strong foundation for everything that sits atop, implicitly driving everything towards a best-practice implementation. If your AD implementation is weak, then no matter what you do with the rest of your components, their foundation will be weak and in the long term require a lot more maintenance and sticky tape!
We saw in the schema section how many products modify the schema to store additional information pertinent to their products. However nearly all products (even those that do not modify the schema) utilize the Active Directory service in some fashion because it is the core building block of everything in your infrastructure.
More and more companies are leaning towards a Service-Orientated Architecture (SOA), which can benefit greatly from the Active Directory. During your analysis, therefore, it is vital to get everyone involved from the onset of the project and ensure that they know their participation is vital to the success of the project.
In the following chapters, we will emphasize on the importance of a thorough analysis of your current technical implementation and business structure. This is vital to ensure that the final design meets all the requirements in the most efficient way possible while having the flexibility to meet the needs of tomorrow without having to go back to the drawing board.
We have covered many principles in this chapter and have laid out the basics that will be explored in more detail, in our designs that follow. If there are concepts that are not crystal clear right now, don't panic, we'll be going over them again.
