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.