MCITP 70-640: Active Directory Domain Functional Levels


Uploaded by itfreetraining on 05.01.2012

Transcript:
Welcome to the next free video for the 70-640 Active Directory course. This video looks
at domain functional levels. The domain functional level determines which features you can use
in your domains. The higher the domain functional level, the more Active Directory features
there are. However, there is a catch. In order to go to a higher functional level, you must
have only domain controllers of that functional level or higher in your domain. For example,
if your domain functional level is Windows Server 2003, you will not be able to use any
domain controllers for Windows Server 2000. The domain functional level only applies to
domain controllers. Regardless of the domain functional level, you can have any client
or server operating system join your domain. For example, you could have a Windows 2000
computer join the domain even if you are running the currently highest functional level of
Windows Server 2008 R2. You could also join other operating systems like Mac or Linux
to the domain. The functional level only applies to domain controllers.
The first domain functional level that I want to look at is Windows 2000 native. Windows
2000 native is the lowest domain functional level that Windows Server 2008 R2 supports.
In order to raise your domain functional level to Windows 2000 native, you must remove all
domain controllers from your network that are running Windows NT 4. Since Windows 2000
native is the lowest domain functional level that Windows Server 2008 R2 supports, this
is why you cannot have Windows NT 4 domain controllers on your network.
If you select Windows 2000 native, you basically get Active Directory. There are no special
features at this domain functional level that are worth mentioning.
The next domain functional level is Windows Server 2003. When your domain is at this domain
functional level, all the domain controllers in your domain must be Windows Server 2003
or above. If you attempt to add a lower level domain controller like Windows Server 2000
later on, the operation will fail. With the Windows Server 2003 domain functional
level, you do get some new features. The first feature is the ability to rename a domain
controller. Previously you would have had to remove Active Directory from the domain
controller, rename the domain controller, and then promote the server back to a domain
controller. With the Windows Server 2003 domain functional level, you don’t have to demote
the domain controller to a server in order to rename it.
The second feature adds new attributes to Active Directory. One new attribute is last
login time stamp. This is a useful feature that allows you to determine when a user last
logged on to the domain. Using this feature, you can run a query on your domain, helping
you to find any users that have not logged in for a long time. With this information
you can use it to clean out some inactive users.
Every object in Active Directory has attributes. To demonstrate how these work I will quickly
open ADSI edit from administrative tools. This tool allows you to view and edit attributes
in Active Directory. If I open the user’s folder and open the
properties of the administrator account, this will show all the attributes that are assigned
to the administrator account. If I go down to Last Logon Time Stamp, I can see the date
and time the administrator last logged in. This is only one of the attributes each user
has. You can see how Active Directory can be expanded to include new attributes.
Windows Server 2003 domain functional level also includes support for an additional attribute
called user password. This is added to an object called INetOrgPerson. The INetOrgPerson
object is a storage object for a user from a non Active Directory system. If you use
another directory service, you may want to migrate to Active Directory or use both systems
together. The problem with using another directory service is the user password and other attributes.
This domain functional level adds support to store a password from a 3rd party directory
service inside the INetOrgPerson object. This essentially means that you can import a user
and their data from another directory service into Active Directory via the INetOrgPerson
object. Since this now contains a user password attribute, Active Directory can use the password
in the INetOrgPerson object to log the user on to the domain. Previously the user would
have needed to have their password reset or they would have needed to use two passwords,
one for Active Directory and one for the other system. With the new user password attribute,
linking other directory systems with Active Directory is a lot easier.
The next feature that this domain level offers is constrained delegation. To understand what
this does, you first need to understand what delegation is. Consider this example where
delegation would come into play. An administrator wants to install an application
on a user’s computer. They send their username and password to the client’s computer which
allows them access. The administrator then sends a command to the client’s computer
telling the client to connect a file server to get the install files.
In order for the client’s computer to do this, it needs a username and password to
access the file server. In order to protect the install files, you would want to make
them available only to an administrator. This is where the problem comes in. In order for
the client’s computer to access the file share, it needs to pass on the administrator’s
credentials to the file server. When this occurs, it is called delegation.
The problem with delegation is that potentially a virus on the client’s computer could get
the administrator’s username and password and use it to access any computer on the network
and then leap frog to other computers. This is why delegation in this form is disabled
by default. With the Windows Server 2003 domain functional
level, you can enable delegation but restrict it to which services it can access. This provides
a safer way to use delegation than previously. To illustrate delegation, I will open Active
Directory Users and Computers from the start menu.
I will navigate to the computer’s OU and select the properties for one of the computer
accounts. From inside properties select the delegation tab, I can see the current delegation
is set to off which is the default. The next option is to trust delegation but only when
using Kerberos. Kerberos is a great security protocol but
a problem could occur if the administrator’s computer was to become compromised and this
computer was trusted for delegation. This computer could then be used as a stepping
stone to access any computer on the network. The next option is added by the Windows Server
2003 domain functional level. This allows you to trust the computer for delegation but
to specify which services are allowed. If a hacker were to take advantage of delegation,
they would be limited to the services listed and thus the possible damage they could do
is reduced. By default Kerberos will be used, but if you
need to, you can change the option to accept any valid protocol. If I now select add, I
can select the users or computers that I want this computer account to be trusted to use.
If I only wanted the computer account to be trusted to read install media stored on DC1,
I would select CIFS which is the protocol used by Windows File Sharing. What this means
is that an administrator could send their username and password to this computer telling
it to install an application. The application install files are located on DC1. In order
to access these files DC1 will need a username and password. Since the work station is trusted
for delegation for file sharing only and only to DC1, it can pass the administrator’s
username and password to DC1 to access the files.
For ultimate security you could make the file share on DC1 read only. Thus the only damage
a hacker could do would to be able to read your software install media. You can see how
having granular control over delegation is a lot more secure at this domain functional
level. Previously you would have had to give out the keys to the kingdom, so to speak,
in order to use delegation. The next feature added is selected authentication.
This feature allows you to specify the users and groups from a trusted forest who are allowed
to access resources. This allows you to put more controls on access when you work with
multiple forests. The last feature that Windows Server 2003
domain functional level adds is support to store authorization manager polices. Authorization
manager is a flexible framework for integrating access controls into applications. With this
domain functional level, you can now store authorization manager polices in the Active
Directory database. The next domain functional level is Windows
Server 2008. You may be wondering why there is no Windows Server 2003 R2 domain functional
level. The reason for this is that the installation discs for Windows Server 2003 and Windows
Server 2003 R2 are identical. What is different is when you start Windows
Server 2003 R2 up for the first time, you will be asked to insert Windows Server 2003
R2 disk 2. This will allow you to add additional R2 features to Windows Server 2003 R2. If
you wanted to, you could cancel the wizard and not install any additional features. The
difference between 2003 and R2 is basically some additional add-on software. This is why
there is no Windows Server 2003 R2 domain functional level because there is no significant
difference to the way the operating system works or to Active Directory.
In order to raise your functional level to Windows Server 2008, all your domain controllers
in that domain must be Windows Server 2008 or above.
Windows Server 2008 domain functional level includes support for the use of DFS for replication
of the SysVol share. This share contains all the group policy and login scripts for the
domain. DFS is a much more efficient system of replication, so using it should save you
some bandwidth. Window Server 2008 domain functional level
also supports advanced encryption security or AES for Kerberos. The security currently
used for Kerberos is quite good; however, if you want even better security you can use
AES. This comes in both 128 and 256 bits. Also added with the Windows Server 2008 domain
functional level is support for last login details. With the domain functional level
2003, you have support for last logon time stamp. With Windows Server 2008, this adds
supports for the number of incorrect logins from that user.
The next feature is fine grained passwords. This allows you to configure different password
lengths and complexity requirements for different users. Consider this example. In the past,
if you had a commercial network and then a secure network, the only way a pre Windows
Server 2008 domain functional level could have had different password requirements for
different users was to create a different domain.
As shown here a secure and a commercial domain needed to be created to meet this requirement.
If you did not want to create an extra domain, you basically had to make a decision on which
set of password requirements to use. With Windows Server 2008 domain functional level,
you can combine the two domains like this. Now the secure domain is simply another organization
unit or OU in the same domain. With the users separated into different OU’s, you can assign
one set of password requirements to the commercial OU and one to the secure OU.
The last domain functional level is Windows Server 2008 R2. In order to raise your domain
to this functional level, all domain controllers must be running windows server 2008 R2. If
you do decide to go to this functional level you gain two features.
The first is Authentication Mechanism Assurance. What this allows is compatible services to
look at a Kerberos ticket and determine what was used to authenticate the user. For example,
if you had a secure document you may only want people to access it who were authenticated
using smartcards. The next feature is Automatic SPN management.
When you install certain software you may have been asked to supply a service account.
When the software is running it will use this service account to access resources on the
computer. A lot of software will commonly allow you to run the software with a built
in account like the system account. The problem is that when you start using enterprise
solutions like Exchange you want to isolate Exchange to its own user account to run rather
than using an account like the system account. The service account is like any other Active
Directory account has a password that will expire one day. You could tick the box in
Active Directory that prevents the password from ever expiring but this is not very secure
in the long term. Automatic SPN management is a system in Windows
that takes over the Management of passwords for service accounts like these. Automatic
SPN management also allows the account to be delegated to other administrators as well.
Without a system like this you would need to create an account to run a particular application,
which is common practice. Later on you may find that the password for this user account
changes or the account password expires. When this occurs the software will no longer be
able to run. If this account is linked to your Exchange system, your e-mail could be
potentially down until you realize the password has changed or expired.
That’s it for all the domain functional levels. Just for the sake of completeness,
if you ever see domain functional levels with mixed or interim in it, these are domains
that are in the process of being upgraded from Windows NT4. If you no longer have any
NT domain controllers on your network, then raise your domain functional level to one
of the levels that I have mentioned in this video.
The last point I want to make about domain functional levels is that once you raise the
domain functional level, you can’t go back to a lower domain functional level. For this
reason ensure that you will never add any domain controllers of a lower functional level
before you raise the domain functional level. Also you need to ensure that any down level
domain controllers have been upgraded or removed from the network before you raise the domain
functional level. That’s a lot of theory. I will now change
to my Windows Server 2008 Domain controller to demonstrate how to raise the domain functional
level. I promise this will be quick. First of all, open Active Directory Users
and Computers from administrative tools under the start menu. Right click your domain and
select the option raise domain functional level. Notice at the top the Domain functional
level is set to Windows Server 2003. To select a new domain functional level, select the
pull down. In this case I can choose between Windows Server 2008 and Windows Server 2008
R2. Once I select my domain functional level and
press raise, Windows will give me a warning reminding me this process can’t be reversed.
Once I press o.k. I will be informed that changes may be delayed until replication has
had time to occur between all the domain controllers in my domain.
That’s it for domain functional levels. In the next video, as you may have already
guessed, I will be covering forest functional levels. As always, if you have any questions
about the video please feel free to leave them in the comments below. Once again, thanks
again for watching our always free videos.