Archive | May 2012

Active Directory rights delegation – part 2

 

This time, we will try to delegate rights to group of users who are responsible for creating new user accounts or new groups in a domain. In our case, we will consider this group as local HelpDesk. To allow users from HelpDesk this possibility, you need to delegate appropriate permissions to them. If you want to do that, I would strongly recommend to create appropriate groups in a domain for all tasks and put HelpDesk group into them. Please consider this group as a role!

So, let’s start. First of all, you need to create domain local security groups for all required tasks:

  • user management in each OU
  • user password reset
  • group management in each OU
  • group membership management

as reference, you can use this naming convention

  • dlg-ou-create-user
  • dlg-ou-create-group
  • dlg-modify-group-members
  • dlg-resete-user-password

Domain Local groups

then create global security groups using the same naming convention (but instead of dlg prefix use gg prefix) and make them members of appropriate domain local groups

Global groups


Now, when you have all necessary groups created, you can start delegating tasks into appropriate Organizational Units. Select desired OU and run “Delegation Control” wizard

Start delegating tasks

Delegating task

add domain local group for appropriate task (for user management) in this example it is dlg-ou-finance-create-user and go further

Selecting appropriate group

in this step, please select “Create, delete, and manage user accounts” to allow user account management

Delegating rights

and finish wizard by clicking on “Finish” button

Closing wizard

So, user management is almost done on this OU, now we need to only allow resetting user passwords. Re-run “Delegating Control” wizard and add another group and grant this permission

Password reset group

from available options, please select “Reset user passwords and force password change at next logon

Reset password permission

and finish wizard. After you did that, user management for that OU is done. Repeat this action for each OU on whch you want to grant user management permissions (with its own domain local groups!).

Now, it is time to delegate tasks for group management. Pleas run wizard on an OU where you have groups to which you want to grant access and follow below steps

Delegating group management permissions

go to user/group selection and choose appropriate group to which you are delegating rights

Selecting group

and grant selected group required permissions

Granting permissions

and finish wizard. Now we need to only grant permissions to modify groups membership. Run wizard once again and follow below steps

Modify group membership delegation task

and assign permission selected on a screen below

Permission to modify group members

finish wizard and that’s all you needed to grant for user/group management. Repeat all above steps for another OUs to which you want to grant mentioned permissions for appropriate groups. Now, it’s time to handle HelpDesk role.

Create new global group named role-HelpDesk-it

HelpDesk role

put there all users who are working on that position and should have assigned appropriate permissions that you configured previously. Now, place role-HelpDesk-it global group into each domain local group to which you delegated tasks. When you do that, role-HelpDesk-it group member will have all required permissions on specified OUs.

HelpDesk role

From now, each time you add new user into role-HelpDesk-it group he/she will be able to:

  • create users
  • modify users
  • delete users
  • resete user passwords
  • create group
  • modify groups membership
  • delete groups

Active Directory Delegating Control ss really great option as you can see!

I hope that I was able to show you a way of delegating tasks instead of granting users “Domain Admins” membership to achieve some basic AD tasks 😀

You can simply try to use another delegation task in AD environment by yourself but remember, if you do not know what you are doing, do not touch productive environment. You can always test everything in test environment.

I wish you good luck and enjoy delegated tasks!

<<< Previous part

Author: Krzysztof Pytko

Redirecting default computers location in Active Directory

 

You may wish to apply some group policies to newly joined computer in a domain. By default the only one takes affect, it is “Default Domain” policy. What if you have some GPOs which are installing software on your new computers? Do you need to manually move computer account into that OU to trigger software installation?

NO! You can change default computer accounts location after joining to the domain. You need to use redircmp command and specify new location. After that, all newly joined machines will be redirected into that OU.

Note! Redicmp is by default available on any Windows Server 2008/2008R2 Domain Controller. If you want to use that on Windows Server 2003, you need to first install Support Tools from the first CD.

Command’s syntax is very easy to understand. You need to only know Distinguished Name of an OU to which you want to redirect joined computers. In Active Directory domain, default location for new joined computers is “Computers” container.

Default computer accounts location in AD

If you are not sure what Distinguished Name of an OU is, you can simply use DSQUERY command to determine it.

dsquery ou -name <OU-Name>

i.e: dsquery ou -name “newcomps”

Getting distinguished name of an OU

When you know that name, you can run redircmp command

redircmp DistinguishedName

i.e. redircmp “ou=newcomps,ou=installation,dc=testenv,dc=local”

Redirecting computers location

From now, all newly joined computers will be added with that location.

New computer accounts location

In case that you delegated task of joining computers to domain also to other users than domain administrators, you need to ensure if they have “Write computer objects” permission within that location.

Checking delegated permissions

if not, you need to grant access to that group of users by delegating proper permissions over “Delegate control” wizard. Add appropriate group and follow below steps

Delegating rights

Delegating rights

in case that you also with to allow them removing computers from domain, grant them “Delete selected objects in this folder”

Delegating rights

Delegating rights

and that’s all!

Author: Krzysztof Pytko

Active Directory rights delegation – part 1

 

In my previous article we discussed methods about Active Directory rights delegation This time you will see who to change and restrict users who can add workstations to the domain.

By default in Active Directory environment, each “Authenticated User” can add up to 10 workstations to the domain. After reaching a limit, user is unable to add new workstations anymore. However, 10 workstations is really a big number and it follows into security issue. Domain Administrators should take care about that and disallow for this activity for regular domain users.

Note! Authenticated User” is each user who successfully has logged on into domain.

Note2! By default only “Domain Admins” are able to add unlimited number of workstations to the domain.

To change that behavior you need to modify one setting within “Default Domain Controller” policy. This setting is called “Add workstations to domain” and it is available under

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment

and as you can see, its default configuration value is Authenticated Users

Add workstations to domain – default value

You should consider changing this setting to secure your environment. You can simply remove “Authenticated Users” group there and put “Domain Admins” only. But in Active Directory rights delegation concept, it is good to do that a little bit different way.

I would prefer creating domain local group which is assigned in a policy and then each other global group (privileged to that action) is nested within it. In Active Directory Users and Computers, create empty domain local security group named “dlg-join-computers-to-domain” and replace “Authenticated Users” group in “Default Domain Controller” policy by the new one.

Domain local security group

Now, open Group Policy Management Console and edit “Default Domain Controller” policy

Editing Default Domain Controller policy

Navigate to node “Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment” and edit “Add workstation to domain” setting, by double click on it

Editing Default Domain Controller policy

Select available group in a windows and click on “Remove” button

Removing Authenticated Users from policy setting

Add there newly created domain local security group to allow adding workstations to the domain

Adding new group

Adding new group

Apply changes and you have disallowed “Authenticated Users” adding workstations in your domain

Adding new group

Now, you can see that in “Default Domain Controller” policy, the setting is changed

New policy setting

That would be enough except one small thing. The group is empty, there are no members 🙂 So, at least place there “Domain Admins” group to allow domain administrators adding workstations to domain

Granting domain administrators possibility to add computers to domain

At this moment, you can consider one more thing. Due to rights delegation concept, you may wish to allow also other users add possibility of joining computers into domain. Now, it is really easy task. You need to only add another allowed group into domain local security group “dlg-join-computers-to-domain“. First of all, create in Active Directory Users and computers console new global security group called “gg-join-computers-to-domain” and make it a member of “dlg-join-computers-to-domain” local group.

Creating global security group

Adding global group to local group

You need to change one more thing in AD to finalize your concept. Domain local group needs a permissions to join computer objects within domain, because when you join new workstation, its account must be created. When configuration is not changed then this is “Computer” container.

Default computer objects location

To check details about delegating control, please read my previous article

The last step is granting this group appropriate right. Please follow below steps to achieve that

Delegating rights

Delegating rights – next step

Delegating rights – next step

Delegating rights – next step

Delegating rights – next step

Delegating rights – next step

From now, you can simply control, users allowed for joining computers to domain. Add them directly into your global group called “gg-join-computers-to-domain” and that’s all.

<<< Previous part

Next part >>>

Author: Krzysztof Pytko

Active Directory rights delegation – overview

 

Very often administrators ask, how to grant other users from IT department some specific rights in Active Directory without giving them to much permissions.

Microsoft allows us to do that in few ways, using:

  • default built-in groups
  • Active Directory Delegation wizard
  • ACL of Active Directory objects

The last option may be done over:

  • Active Directory Users and Computers console
  • ADSI Edit console
  • DSACLS coomand-line tool (out of scope in this article)

The first method is very simple for some predefined tasks but it also grants users much more permissions than they sometimes need. So, the proper method in this case is granting users rights over AD Delegation wizard or other mentioned method above. This way also allows us to more granular permissions assignment.

Some tasks cannot be predefined using mentioned methods but we can do that modifying appropriate policies in Group Policy Object (GPO).

Note! I can see very often that administrators add users into “Domain Admins” group to grant them necessary privileges. This is the most simple way but for sure not the proper one! I know, delegating rights require some administrative effort but it’s really worth implementing. After delegation rights implementation, you can be sure that no one would destroy accidentally your environment. Give it a try!

Active Directory Delegation wizard

This wizard is available when you open Active Directory Users and Computers console and select Organizational Unit (OU) or domain on which you want to start delegating privileges. Click right mouse button and choose “Delegate Controll…” option. You should see a wizard

Delegation Control wizard

Follow with the wizard and choose desired options. At the first screen, you will be prompted for user or group to which you want to grant permissions.

Selecting user or group to grant permissions

Note! It is good practice to not add users directly in Delegation Control wizard. Instead of adding them directly, please create dedicated group and grant permission to it. Put each user who requires permissions into that group.

Defined group for task delegation

as you can see on above screen, I have used domain local group named dlg-reset-user-password. Its name tells, what is the purpose of it. In this case I will grant reset users password permission in a domain to that group.

Note! I would strongly recommend naming groups the way you can simply evaluate what is its function (use also description field to put more detailed information about the group).

Next step of delegating permissions

Now, you need to select appropriate permissions which will be assigned to specified group. You can use one of predefined roles from the list or select more granular permissions.
To use one of predefined roles, select a checkbox next to it (you can select more than one) and go to the next step to finish the action.

Selecting delegated task for group of users

In case that you want to create a custom task to delegate, choose the second option and click “Next” button

Custom task to delegate

choose “Only the following objects in this folder” option and select appropriate object(s) from the list

Custom task delegation – next step

Now, you need to select granular permissions to assign. Before you will do that tick also “Property-specific” option to have more attributes.

Selecting more attributes

From the list, choose:

  • Reset password
  • Read lockoutTime
  • Write lockoutTime
  • Read pwdLastSet
  • Write pwdLastSet

and click “Next” button

Assigning permissions

and finish the action. Now, you have delegated users password reset to specified group

Rights delegated

To verify if rights are delegated, you need to check ACL of a location on which  you have done this action. If you want to see ACL (Security tab) on that location, you need to enable “Advanced Fetures” option in ADUC console

Advanced Features option in ADUC

After that, you can simply check if task delegation has been finished successfully. Click right mouse button on a domain or OU (depends where you have done delegation) and choose “Properties. Under the “Security” tab verify if you can see group to which you assigned permissions

Veryfing delegated permissions

Veryfing delegated permissions

Veryfing delegated permissions

That’s all about this method. Now let’s see another way.

ACL of Active Directory objects

As you saw in the previous part of this post, I showed you how to delegate rights using Delegation Control wizard. This time you will see how to do that using ACL (Security tab).

Open Active Directory Users and Computers console (make sure that “Advanced Feature” option in “View” menu is sel ected) and go to an OU or domain to which you want to grant permissions. Click right mouse button and choose “Properties“. Go to “Security” tab

Delegating rights over ACL

Delegating rights over ACL

click “Advanced button and group to which you want to assign permissions

Delegating rights over ACL

Delegating rights over ACL

In “Permissions Entry” window from “Apply to” drop down list choose “This object and all descendand objects” and select “Create computer objects

Delegating rights over ACL

That’s all in this method. The next option you can use is granting privileges over ACL using ADSIEdit

ADSI Edit

In Windows Server 2003 to be able to use ADSIEdit you need to install “Support Tools” from the first CD. On Windows Server 2008/2008R2 it is automatically available on each Domain Controller.

Note! Be careful! ADSIEdit is powerful tool and you can destroy your domain environment. Do not choose any other option, you do not know. First, check that in test environment.

Some options/attributes are unavailable in “Security” tab over ADUC console then we can set up them using this tool. Log on to Domain Controller or other domain member server on which you have available ADSIEdit and run it.

Running ADSIEdit console

within ADSIEdit connect to “Default naming context”

Choosing context in ADSIEdit

Choosing context in ADSIEdit

All other steps are the same as in the previous method (ADUC console).

That’s all in this overview article.

Next part >>>

Author: Krzysztof Pytko

Domain Password Policy

 

I can see very often that people ask questions about Domain Password Policy in Windows Server 2003 or Windows Server 2008/2008R2 that after they create new Group Policy (GPO) with password settings, it is not applied to computers.

That’s because in Active Directory you can only use one Group Policy with predefined password settings which by default are configured within “Default Domain” policy. When you want to modify these settings then you have to edit “Default Domain” policy and go to

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies ->Password Policy

Default password settings in “Default Domain” policy

all required options are available in this node. This is the same situation with Account Lockout settings which need to be also modified in the same policy under

Computer Configuration -> Policies -> Windows Settings -> Account Policies -> Account Lockout Policy

Default account lockout settings in “Default Domain” policy

When you will do changes there you can be sure that password policy would be applied within your environment.

Note! One more important thing! Password policy must be applied at domain level, so that’s why it is put within “Default Domain” policy by default. This is the only one GPO applied to all users/computers in a domain after Active Directory is created.

Domain Policy GPO link

Information! You can only use one password policy in a domain in “classic” way. However, when your domain functional level is at least Windows Server 2008 mode you are able to use Fine-Grained Password policies. More about this policies at Microsoft article

http://technet.microsoft.com/en-us/library/cc770394%28v=ws.10%29.aspx

In other case you need to create sub-domains (if different password policies are required) and migrate users and their computers into that sub-domain. Then you can apply another password policy settings.

To get more details about setting up “default domain password policy” and other tips related with this topic, please check that article on my blog at Setting default domain password policy

Author: Krzysztof Pytko

Global Catalog on additional Domain Controller

 

Sometimes, we need to select additional Domain Controller as Global Catalog and we are wondering how to do that. This is always necessary to add this feature to Domain Controller running Windows Server 2003 after promotion it to DC. This feature is not automatically added.

When we use Windows Server 2008/2008R2 as Domain Controller then during promotion process we can make it as Global Catalog (if we do not turn off default options). However when we disable it during promotion process or you are promoting Windows Server 2003 then you need to enable that feature later.

This short article shows you how to do that.

Important! In single forest, multiple domain environment you need to ensure first, if all of your Domain Controllers are Global Catalogs. If not, you cannot place Global Catalog on a DC with Infrastructure Master Operation role!

To select additional Global Catalog in your domain, you need to use Active Directory Sites and Services console. This tool is located under “Administrative Tools” (even though, it is done on Windows Server 2003, all the same steps are valid for Windows Server 2008/2008R2)

Active Directory Sites and Services console

Navigate to Site in which desired Domain Controller is located and expand “Servers” node. Select that server and in the right pane, click right mouse button on “NTDS Settings” and choose “Properties”

NTDS Settings

Under “NTDS Settings” in “General” tab check “Global Catalog” checkbox.

Configuring Global Catalog

Configuring Global Catalog

Confirm by clicking on “OK” button and that’s all!

Author: Krzysztof Pytko

Raising Forest Functional Level

 

Introduction

This article describes how to raise Forest Functional Level and how to do that. But at the first stage, we will focus on prerequisites for this action.

Forest Functional Level determines which features are available in a forest (each domain within a forest) and which operating systems may act as Domain Controllers. This is really important to understand it appropriately before you start raising FFL.

Important! The most important thing is that raising FFL into higher level is one time action and cannot be reverted using the same console to previous state or lower mode. You need to restore your forest from backup. So, before doing that, please consider it wisely.

Note! There is one scenario when you can go back with Forest Functional Level without using backup. This situation is when you have Windows Server 2008R2 FFL and you did not enable Active Directory Recycle Bin. Only then you can go back.

You can raise Forest Functional Level using this tool:

  • Active Directory Domains and Trusts

To be able to raise FFL, user account on which you want to do the action, must be a member of “Enterprise Administrators” group.

We have currently 8 Doman Functional Levels available:

  • Windows 2000 Native
  • Windows Server 2003 Interim
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008R2
  • Windows Server 2012
  • Windows Server 2012R2
  • Windows Server 2016

and mentioned beta FFL Windows Server 8 Beta (which probably would be changed to Windows Server 2012 in final release)
Each Forest Functional Level introduces new features in a forest. So, that’s why it is worth raising. This short brief shows what kind of features we have in each FFL:

Windows 2000 Native mode [1]

  • Domain Name change
  • Universal Distribution Groups
  • Group Nesting for Distribution Groups
  • Group Nesting for Domain Local Security Groups which can contain Global Security Groups as members

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows 2000 Native FFL, all domains in a forest must be operating at Domain Functional Level Windows 2000 Native mode (more about DFL in my previous article)

Windows Server 2003 mode [1]
All Windows 2000 Native mode features plus:

  • Forest trust
  • Domain rename
  • Linked-value replication
  • The ability to deploy a read-only domain controller (RODC)
  • Improved Knowledge Consistency Checker (KCC) algorithms and scalability
  • The ability to convert an inetOrgPerson object instance into a User object instance
  • Deactivation and redefinition of attributes and classes in the schema
  • Domain-based DFS namespaces running in Windows Server 2008 Mode

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows Server 2003 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2003 mode (more about DFL in my previous article)

Windows Server 2008 mode [1]
All Windows Server 2003 mode features. There is no new features introduced.

In this mode, you can only use these Operating Systems as Domain Controllers in whole forest (in each domain):

  • Windows Server 2008
  • Windows Server 2008R2

To be able to set up Windows Server 2008 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2008 mode (more about DFL in my previous article)

Windows Server 2008R2 mode [1]
All Windows Server 2008 mode features plus:

  • Active Directory Recycle Bin

In this mode, you can only use Windows Server 2008R2 as Domain Controllers in whole forest. There is no possibility to run the older operating systems as Domain Controllers in this mode.

To be able to set up Windows Server 2008R2 FFL, all domains in a forest must be operating at Domain Functional Level Windows Server 2008R2 mode.

Windows Server 2012 mode [1]
All Windows Server 2008R2 mode features but no additional features.

All domains that are subsequently added to the forest will operate at the Windows Server 2012 domain functional level by default.

Windows Server 2012R2 mode [1]
All of the features that are available at the Windows Server 2012 forest functional level, but no additional features.

All domains that are subsequently added to the forest will operate at the Windows Server 2012 R2 domain functional level by default.

Note! Simply saying, the lowest Domain Functional Level within a forest, the highest possible Forest Functional Level

That’s all about theory, now we will see, how to do that.

We know everything what we should know about FFLs and we can start raising it.

 

Scenario

This is a single forest, multiple domain environment where testenv.local is forest root domain. There are also two other child domains: child.testenv.local and child2.testenv.local.

Domain Functional Level each of them is:
testenv.local              – Windows Server 2008R2 mode
child.testenv.local    – Windows 2000 Native mode
child2.testenv.local  – Windows 2000 Mixed mode

as in my forest there is no more Windows NT4, Windows 2000 Server and I do not plan to use them anymore, I would raise my forest Functional Level into Windows Server 2003 mode. But first of all, my child domain’s DFL must be raised up.

For child.testenv.local I will raise DFL into Windows Server 2008R2 (as there are only Windows Server 2008R2 Domain Controllers)
For child2.testenv.local I will raise DFL into Windows Server 2003 (as there are no older Domain Controllers that 2003, and I cannot raise it higher because server 2003 is still used for DCs)

After that, the lowest DFL in my forest will be child2.testenv.local which is Windows Server 2003. So, the highest possible Forest Functional Level is Windows Server 2003.

I will only show you, how to raise Forest Functional Level. For information about raising DFL, please read my previous article about that.

Raising Forest Functional Level using Active Directory Domains and Trusts console

Open Active Directory Domains and Trusts console from “Administrative Tools” and select root node

Active Directory Domains and Trusts console

Click right mouse button on it and choose “Raise Forest Functional Level…” option from the list

Choosing an option to raise FFL

From the drop down list choose suitable Forest Functional Level (in this case it is Windows Server 2003) and click on “Raise” button

Available FFL options

FFL selected

confirm that you are sure what you are doing

Confirmation

Congratulations! Your Forest Functional Level has been raised up!

FFL has been raised up

Current FFL mode

That’s all!

<<< Previous part

Author: Krzysztof Pytko

[1] http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28WS.10%29.aspx

Raising Domain Functional Level

 

Introduction

This article describes how to raise Domain Functional Level and how to do that. But at the first stage, we will focus on prerequisites for this action.

Domain Functional Level determines which features are available in a domain and which operating systems may act as Domain Controllers. This is really important to understand it appropriately before you start raising DFL.

Important! The most important thing is that, raising DFL into higher level is one time action and cannot be reverted using the same console to previous state or lower mode. You need to restore your forest from backup. So, before doing that, please consider it wisely.

You can raise Domain Functional Level using these tools:

  • Active Directory Users and Computers
  • Active Directory Domains and Trusts

both consoles allow for DFL change and they show the current Domain Functional Level.

To be able to raise DFL, user account on which you want to do the action, must be a member of “Domain Admins” or “Enterprise Administrators” group.

We have currently 6 Doman Functional Levels available(7 including Windows Server 8 Beta 🙂 but this article doesn’t count this OS as this is beta version):

  • Windows 2000 Mixed mode
  • Windows 2000 Native mode
  • Windows Server 2003 Interim mode
  • Windows Server 2003 mode
  • Windows Server 2008 mode
  • Windows Server 2008R2 mode

and mentioned beta DFL Windows Server 8 Beta (which probably would be changed to Windows Server 2012 in final release)

Each Domain Functional Level introduces new features in a domain. So, that’s why it is worth raising. This short brief shows what kind of features we have in each DFL:

Windows 2000 Mixed mode [1]

  • Domain Name change
  • Universal Distribution Groups
  • Group Nesting for Distribution Groups
  • Group Nesting for Domain Local Security Groups which can contain Global Security Groups as members

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows NT4
  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2

higher OSes are unavailable because Windows Server 2008 and above doesn’t support Windows NT DCs. If you want to use Windows Server 2008 then you need to migrate all of your NT4 DCs at least to Windows 2000 Server and raise Domain Functional Level to Windows 2000 native mode.

Windows 2000 Native mode [1]

  • Universal Groups for all types (Security, Distribution)
  • Group Nesting allowed for all groups (Global, Universal, Domain Local)
  • Group type conversion
  • SID History enabled

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows 2000 Server
  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4 Domain Controllers in this mode. So, if you have not any Win NT DCs in a domain and yo do not plan use any of them in the future, you can simply raise Domain Functional Level into Windows 2000 Native mode.

Windows Server 2003 mode [1]
All Windows 2000 Native mode features plus:

  • Domain Controller name change
  • Domain name change
  • Possibility to change default location of newly created user/computer objects
  • logonTimestamp and lastLogonTimestamp attributes update
  • InetOrgPerson password set up on userPassword attribute
  • Selective authentication for users/groups/computers from trusted domains

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows Server 2003
  • Windows Server 2003R2
  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4 and Windows 2000 Server Domain Controllers in this mode. So, if you have not any Win NT and 2000 DCs in a domain and you do not plan to use any of them in the future, you can simply raise Domain Functional Level into Windows Server 2003 mode.

Important!
When you raise your Domain Functional Level into Windows Server 2003 Interim mode then you can only use Windows NT4, Windows Server 2003 and Windows Server 2003R2 Domain Controllers! This DFL mode cannot be directly set up using the same consoles as for other modes. For that you need to use ADSIEdit tool and raise Forest Functional Level to Windows Server 2003 Interim mode.

For more information about that, please visit Microsoft Technet and read this article

Windows Server 2008 mode [1]
All Windows Server 2003 mode features plus:

  • DFS replication support for Windows 2003 SYSVOL
  • Domain-based DFS namespaces running in Windows Server 2008 Mode
  • AES 128 and AES 256 support for the Kerberos protocol
  • Last Interactive Logon information
  • Fine-grained password policies
  • Personal Virtual Desktops

In this mode, you can use these Operating Systems as Domain Controllers:

  • Windows Server 2008
  • Windows Server 2008R2

Look, this is no possibility to run Windows NT4, Windows 2000 Server, Windows Server 2003 and Windows Server 2003R2 Domain Controllers in this mode. So, if you have not any of these DCs in a domain and you do not plan to use them in the future, you can simply raise Domain Functional Level into Windows Server 2008 mode.

Windows Server 2008R2 mode [1]
All Windows Server 2008 mode features plus:

  • Authentication mechanism assurance
  • Automatic SPN management

In this mode, you can only use Windows Server 2008R2 as Domain Controllers. There is no possibility to run the older operating systems as Domain Controllers in this mode. So, if you have not any of them and you do not plan to use them in the future, you can simply raise Domain Functional Level into Windows Server 2008R2 mode.

Windows Server 2012 mode [1]
All Windows Server 2008R2 mode features plus:

The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level.

Windows Server 2012R2 mode [1]
All Windows Server 2012 mode features plus:

  • DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longer:

– Authenticate with NTLM authentication
– Use DES or RC4 cipher suites in Kerberos pre-authentication
– Be delegated with unconstrained or constrained delegation
– Renew user tickets (TGTs) beyond the initial 4 hour lifetime

  • Authentication Policies

New forest-based Active Directory policies which can be applied to accounts in Windows Server 2012 R2 domains to control which hosts an account can sign-on from and apply access control conditions for authentication to services running as an account.

  • Authentication Policy Silos

New forest-based Active Directory object, which can create a relationship between user, managed service and computer, accounts to be used to classify accounts for authentication policies or for authentication isolation.

That’s all about theory, now we will see, how to do that.

We know everything what we should know about DFLs and we can start raising it.

Scenario

This is a single forest, multiple domain environment where testenv.local is forest root domain. There were Windows 2000 Server Domain Controllers which were replaced by the new ones with Windows Server 2008R2 OS. All the old DCs are decommissioned but the Domain Functional Level is set up as Windows 2000 Native mode. Now, I know that I have no any 2000,2003 and 2008 DCs and I do not plan to use them in the future, I can raise DFL to Windows Server 2008R2 mode.

Raising Domain Functional Level using Active Directory Users and Computers console

Open ADUC console from “Administrative Tools”

ADUC console

Select DNS domain name at the top of console and click on it right mouse button. Choose “Raise domain functional level…” option from the list.

Choosing option to raise DFL

DFL available options

From the drop down list, select appropriate Domain Functional Level. In my case, it is Windows Server 2008R2

Choosing DFL mode

and click on “Raise” button. Confirm that you are sure to do that

Confirmation

Congratulations! Your Domain Functional Level has been raised!

Information about raised DFL

Information about current DFL

Raising Domain Functional Level using Active Directory Domains and Trusts console

Open Active Directory Domains and Trusts console from “Administraive Tools”

Active Directory Domains and Trusts console

From available domains list select that one on which you want to raise DFL. Click on it right mouse button and choose “Raise domain functional level…” option from the list.

Option to raise DFL

From the drop down list, select appropriate Domain Functional Level. In my case, it is Windows Server 2008R2

Available DFLs

and click on “Raise” button

Raising DFL

Congratulations! Your Domain Functional Level has been raised

DFL has been raised

Current DFL mode

That’s all!

Next part >>>

Author: Krzysztof Pytko

[1] http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28WS.10%29.aspx