Archive for January, 2015

What’s New

Flexible Authentication Secure Tunneling (FAST) is part of the framework for Kerberos Pre-authentication. FAST provides a protected channel between the client and the Key Distribution Center (KDC), and it can optionally deliver key material used to strengthen the reply key within the protected channel. With FAST in place, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm.

With FAST enabled and required, brute forcing the reply key is no longer possible and the highest possible cryptographic protocols and cipher strengths are guaranteed to be used by Windows 8 clients in their pre-authentication traffic with Windows Server 2012 Domain Controllers.

When FAST is required, this enables the Compound Authentication functionality in Dynamic Access Control (DAC), allowing authorization based on the combination of both user claims and device claims.

Enabling FAST

Enabling Flexible Authentication Secure Tunneling (FAST) can be achieved through Group Policy once you fulfill the requirements. (see below)

The Group Policy you need for this is located in Computer Configuration, Administrative Templates, System, KDC and is named KDC support for claims, compound authentication and Kerberos armoring:


This Group Policy supports four possible settings after you enable it:

  • Supported
  • Not supported
  • Always provide claims
  • Fail unarmored authentication requests

When you choose the ‘Supported’ setting and link the Group Policy to the Domain Controllers Organizational Unit (OU), it’s time to enable Flexible Authentication Secure Tunneling (FAST) on the Windows 8 clients.

Point your Group Policy Management Console (GPMC), assign a Group Policy object to the Organization Unit(s) containing your domain-joined Windows 8 computers. Open the Group Policy object and navigate to Computer Configuration, Administrative Templates, System, Kerberos. Here, enable the Kerberos client support for claims, compound authentication and Kerberos armoring Group Policy:


You will have Flexible Authentication Secure Tunneling (FAST) on your network between domain-joined Windows 8 clients and Windows Server 2012-based Domain Controllers after the next Group Policy refresh cycle.

Requiring FAST

Requiring Flexible Authentication Secure Tunneling is the next step. You will still use the Group Policy Management Console (GPMC) as your tool of choice, because a couple more Group Policies need to be configured.

Assign a Group Policy object to the Domain Controllers Organizational Unit (OU) and within the Group Policy object, again, navigate to Computer Configuration, Administrative Templates, System, Kerberos. Here, enable the Fail authentication requests when Kerberos armoring is not available Group Policy.


Lastly, the above mentioned Group Policy KDC support for claims, compound authentication and Kerberos armoring, located in Computer Configuration, Administrative Templates, System, KDC needs to be configured with the Fail unarmored authentication requests setting.


Flexible Authentication Secure Tunneling can be enabled in an Active Directory environment when:

  • Sufficient Domain Controllers are running Windows Server 2012, with sufficient processing power (to additionally encrypt Kerberos messages and sign Kerberos errors on top of the baseline processing power needs) and networking connectivity (to handle the additional message exchange and increased Kerberos services tickets on top of the baseline networking connectivity needs).

When FAST is enabled Windows 8 clients will only communicate with Windows Server 2012 Domain Controllers. This might create a pile-on effect. Therefore, ensure you have sufficient Domain Controllers to prevent authentication traffic passing Active Directory site links.

  • The environment no longer contains domain controllers running Windows Server 2003. Supported Domain Controller Operating Systems include Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012.
  • Clients need to be running Windows 8

Flexible Authentication Secure Tunneling can be required in an Active Directory environment when:

  • All Domain Controllers in domains the client uses are running Windows Server 2012
    (including transited referral domains)
  • All domains the client uses are running the Windows Server 2012 Domain Functional Level (DFL).
  • Clients need to be running Windows 8
  1. Move all FSMO roles to one domain controller and configure all the DC’s as GC’s.
  2. Move the domain controller from step 1 to unique VLAN that will be isolated from the regular network.
  3. Backup the domain controller from step 1 by using backup tape backup, and some image utility.
  4. After running ADPREP /Forestprep check that Windows 2003 schema upgrade to contain new 2003 forest attributs.
  5.  After running ADPREP /Domainprep check that Windows 2003 schema upgrade to contain new 2003 domain attributs.
  6. Disable any antivirus software on the software before the upgrade process.
  7. Log on to the domain controller from step 1 with account that member of: Enterprise Admin group, Domain Admin group, Schema Admin group – and if you have Exchange System in your organization – the account should be with Full Exchange Admin permission on the Exchange organization, administrative groups (sites in Exchange 5.5 environment), Exchange Servers (and in Exchange 5.5 environment – also full control on “Configuration” container).
  8. Test this upgrade in a lab before implement it on production server.
  9.  Copy the I386 directory content from the Windows 2003 cd rom, to the local server hard disk.
  10.  Verity that the all servers in the domain have the correct time zone and the configure to be synchronization from the same server (usually this the PDC emulator).
  11.  Activate the new Windows 2003 Server before implement any changes on the system.
  12.  If you add new Windows 2003 server to the domain, make sure to configure the correct domain name and domain suffix.
  13. Don’t use forbidden characters in the domain or/and server name (etc *, _).
  14. Before you implement – Windows 2003 CA, Windows 2003 Cluster, Exchange 2003 configure at least one DC as Windows 2003 DC and GC, and configure Windows 2003 CA, Windows 2003 Cluster, Exchange 2003 to use this server as default logon server.
  15. If you have multidomain hierarchy, upgrade first the forest root domain, and only after this upgrade complete, the rest of the forest.
  16. If you have multisites hierarchy, let the changes of ADPREP command to repliacte to all other sites. Verify that each DC upgrade its schema version before you install the Windows 2003 Server.
  17. After running ADPREP command, open %systemroot%\system32\debug\adprep\logs\ADPrep.log, and see if there are error messages that might need to be resolved.
  18. Read: How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2 article before beggining the migration.;en-us;322970
  19. If you installed Exchange 2000/2003, its recommended to run Policytest.exe utility before the upgrade:;en-us;281537&FR=1&PA=1&SD=HSCH
  20. Read: HOW TO: Upgrade a Windows NT 4.0-Based PDC to a Windows Server 2003-Based Domain Controller;en-us;326209 HOW TO: Set Up ADMT for a Windows NT 4.0-to-Windows Server 2003 Migration;en-us;325851 How to Use Active Directory Migration Tool Version 2 to Migrate from Windows 2000 to Windows Server 2003;en-us;326480 Active Directory Migration Tool v3.0 How to Upgrade Windows 2000 Domain Controllers to Windows Server 2003;en-us;325379 Upgrading to Windows Small Business Server 2003 Domain Migration Cookbook Windows Server 2003 PKI Operations Guide
  21. If the upgrade process need to take more then a few hours, consider to change the domain configuration to eliminate Overloading on the First Domain Controller. How to Prevent Overloading on the First Domain Controller During Domain Upgrade

replication changes in sysvol 2008

Group Policy replication change

Before I start the SYSVOL replication changes in windows server 2008, I would like to explain how the GPO has been replicated in windows server 2003 and earlier versions
Understanding SYSVOL/GPO replication

Group policy template (GPT) and group policy container (GPC) are two types of Group policy settings, Its stored in two different locations and uses different replication technology to replicate the changes, however both should be available up-to-date on domain controller to function properly

Group policy templates are stored in SYSVOL, it’s a folder structure in SYSVOL share on a domain controller, if you create a new Group Policy it will create a Group policy templates folder on SYSVOL share for the new policy that contain the group policy setting related to this policy, GPT folder name would be Globally Unique Identifier (GUID) of the GPO that you created, you can view all the GPT folders from the below Path (it’s a default GPT path)


Group Policy template (GPT) is replicated by SYSVOL through FRS, FRS uses state-based replication. As soon as there is a change to any file under the Sysvol folder structure, replication is triggered and entire file get replicated

Group policy containers are stored in Active Directory, mostly all the GPO setting are stored in GPT (Group policy templates), GPC only have the reference information of the corresponding GPO, like GPT path, GUID of the GPO, version information, WMI filter information, and a list of components that have settings in the GPO, you can view the GPC from Active Directory Users and Computers (ADUC)


Group policy container (GPC) is replicated through Active Directory replication

Note: By default the Group Policy Management Editor console (GPME) uses the PDC Emulator so that all administrators can work on the same domain controller, if you want a different Domain controller you can change through Group Policy Management console (GPMC)

File Replication Services (FRS)

I will try to explain step by step, let say you modify the Policy A from Server001 and how this change get replicated to Server002 (Server002 is a downstream replication partner for server001)

  • Once you modify the Policy A from server001, the corresponding GPT folder on SYSVOL gets updated on the server001 (also updates the Group policy containers in Active Directory on server001)
  • NTFS will change the USN journal according to the file and folder change.
  • FRS monitors the USN journal for changes on the SYSVOL folder
  • FRS updates the inbound log on server001, FRS not only updates the local changes on inbound log, also updates the inbound log for the changes from entire upstream replication partner (all inbound partners)
  • FRS creates a file in staging folder on server001 by using APIs (backup application programming interfaces) based on the change.
  • This change has been updated on outbound log on server001 by FRS. And also send change notification to entire downstream replication partner about the change (all outbound partners)
  • Server002 get the change notification from Server001 and store the change order in inbound log, Server002 copies the staging file from Server001 to the staging folder on Server002. Server002 then update outbound log so other outbound partners can pick up the change
  • Using Restore APIs, Server002 reconstructs the file and folder in the preinstall folder, and then FRS renames the file or folder into the replica tree

In FRS replication process the entire changed file and folder get replicate to source to destination server

What is NTFS USN journal?

Logs all the changes to an NTFS volume, including file creations, deletions, and changes, Separate log on each NTFS volume and it has a size limit (Windows server 2003 SP2 & Windows server 2008 is 128 MB) if require you can increase the size up to 2 TB, however MS Recommends increasing by 128 MB for every 100,000 files/folders

What happens when the NTFS USN change journal fills up?

If the USN journal log fills up then NTFS will be overwrite the old entry’s, that’s why in some scenarios before the change get updated, NTFS delete the entries in USN journal log, it’s called journal_wrap

USN journal wrap Error

An error that occurs when large numbers of files change so quickly that the USN journal must remove the oldest changes (before FRS has a chance to detect the changes) to stay within the specified size limit, to resolve this issue you have to perform a non-authoritative restore also called D2

Morphed folder

Replication conflict will occur if identically named directories are created in different servers, to resolve this conflict FRS create a folder and this folder called morphed folder

Let’s say two identical directories are created in different replication members, FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of “_NTFRS_xxxxxxxx,” where “xxxxxxxx” represents eight random hexadecimal digits.

Version vector join (vvjoin)

Till now we are discussing about the SYSVOL replication, how the SYSVOL replication works for the newly added replication partner, newly added replication member doesn’t have any updates, and it should build the folder structure from the beginning, this process is called vvjoin, in which a downstream partner joins with an upstream partner for the first time.

Vvjoin is a CPU-intensive operation that can affect the performance of the server and increase the replication traffic

Distributed File System (DFS)

Now we are coming to the point, how the SYSVOL replicating using DFS and how it’s been improved to provide better replication performance, to use this feature you should have Windows Server 2008 domain functional level that means all the domain controller has to be Windows Server 2008

SYSVOL replication using DFS is called DFS-Replicated SYSVOL (DFSR)

DFSR is a multimaster replication engine and changes that occur on one of the replication member are then replicated to all of the other servers in the replication group

DFSR also monitors the NTFS for the update sequence number (USN) journal to detects changes on the volume, and then DFSR replicate the changes only after the file closed

And before sending or receiving a file, DFSR uses a staging folder to stage the file

If any changes in SYSVOL share, FRS replicate the entire file unlike the DFSR, DFSR replicates only the changes blocks and not the entire file, sounds like a attribute level Active Directory replication, it compare the source and destination file using remote differential compression (RDC), it reduce the SYSVOL replication traffic

Other improvements are… (Difference between DFRS and FRS)

• DFSR and Journal Wraps, DFSR also monitors the NTFS change journal, but DFSR always heals itself hence no Journal Wrap error

  • Morphed files and folders automatically taken care of
  • FRS silently fails if the volume SYSVOL resides on < 1GB of free space
  • Copies the changes on files and folder not entire files and folder
  • Uses Version Vector tables to confirm the changes, also to resolve the conflicts
  • Support read-only replication on a particular members in which users cannot add or change files
  • You can also make the changes to the SYSVOL folder of an RODC

• DFSR does not require the version vector join (vvjoin) operation