Hi, Mike here. This post was originally published in the Group Policy Team blog in September 2006—anticipating the launch of Windows Vista. Here it is again—refreshed—for the upcoming launch of Windows Server 2008.

User Account Control in Windows Server 2008 and Windows Vista requires all users run in a standard user mode; its purpose: to limit the user’s ability from changing critical operating system files or expose their computer and network to viruses and malware. Windows displays an authorization dialog box when a task requires administrative privileges, such as opening the Microsoft Management Console (MMC). You, the administrator, provide administrative credentials to “elevate” your privileges for the specific process (You can read more about User Account Control, on the Microsoft Windows Vista TechNet site http://www.microsoft.com/technet/windowsvista/security/uacppr.mspx). Windows Server 2008 and Windows Vista provide you with nine security policy settings to control how User Account Control behaves. You can locate these security policy settings in the Local Group Policy Editor under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options or Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options when editing domain-based GPOs using GPMC included in Windows Server 2008 or when using Remote Server Administration Tool on Windows Vista Service Pack 1.

 
Figure 1- UAC security policy parent node in a domain-based GPO.

These security policy settings apply only to computers running Windows Server 2008 or Windows Vista RTM or later. These security policy settings can co-exist in GPOs applicable to clients earlier than Windows Vista. Operating systems other than Windows Server 2008 and Windows Vista ignore the settings.

 
Figure 2- UAC Computer security policy settings

Before I begin, I want to tell you about another feature with security policy settings. This valuable feature is a little hard to find. Each security policy setting has “explain” text similar to registry-based policy settings. Simply double-click on the security policy setting and then click on the Explain tab to view detailed information about the security policy setting; enabled and disabled behavior; and default values. Now, let us move on to the User Account Control policy settings.

Figure 3 - Explain text in Security policy settings

Windows Vista provides nine security policy settings to control the behavior of User Account Control. You can enable these security policy settings in Local Computer and Domain-based Group Policy objects. Each security policy setting starts with “User Account Control” and then the actual name of the policy settings. The Group Policy Object Editor lists security policy settings in alphabetical order, so just scroll to the end.

The first of these policies controls the Admin Approval Mode for the built-in administrators account. When enabled, the Admin Approval mode is on for the built-in administrator account causes Windows prompts the administrators for any operations requiring an elevation in privilege. The prompt gives the administrator the choice to Permit or Deny the request for elevation. When disabled, Admin Approval mode is off. The built-in administrator account runs all applications using full administrative privileges and does not prompt for elevation.

The next two security policy settings control the type of prompt for User Account Control uses. These security policy settings are Behavior of the elevation prompt for administrators in Admin Approval Mode and Behavior of the elevation prompt for standard users. Behavior of the elevation prompt for administrators in Admin Approval Mode security policy setting provides three choices

• Prompt for Consent –provides a dialog box asking you to either Permit or Deny the request for elevation.
• Prompt for Credentials –provides an authentication dialog box asking you to provide administrative credentials to permit the request for elevation.
• Elevate without Prompting –automatically permits the request for elevation without prompting the administrator.

The Behavior of the elevation prompt for standard users security policy setting provides two choices. Prompt for Credentials and Automatically deny elevation requests where Windows denies all requests for elevation and displays an Access Denied error message.

When enabled, the Detect application installation and prompt for elevation security policy setting causes Windows to detect heuristically for installation packages that require an elevation of privilege and triggers a User Account Control prompt for elevation. Disabling this security policy setting disables detection process.

Enabling the security policy setting Only elevate executables that are signed and validated enforces Windows Vista to validate the Public Key Infrastructure (PKI) certificate chain before permitting it to run. Disabling this security policy setting does not enforce validation of the PKI certificate chain.

The next security policy setting listed is, Only elevate UIAccess applications that are installed in secure locations. UIAccess applications are applications designed specifically to assist with user accessibility. These applications typically send information to other applications. The on-screen keyboard is an example of a UIAccess application. When enabled, Windows enforces UIAccess application to run from a secure location. These secure locations include:

• …\Program Files\... including all sub folders.
• …\Windows\System32\...
• …\Program Files (x86)\... including all sub folders (64-bit versions).

Your desktop appearance changes when Windows Vista prompts you for elevation. Windows displays a gradient shade of gray over your existing desktop and then you see the prompt for elevation, in color. Actually, Windows switches your desktop to a secure desktop before prompting you for elevation. This describes the enabled behavior of the security policy setting Switch to the secure desktop when prompting for elevation. When disabled, Windows prompts for elevation on your existing desktop.

Some applications read or write registry information or files to locations that Windows protects from normal users. This usually requires the user to run the application as an administrator until an application upgrade becomes available. Windows Vista helps by providing virtualized file and registry writes to areas previously protected from normal users. This feature redirects writes destined for protected locations to locations where users have write access. The security policy setting Virtualize file and registry write failures to per-user locations provides this behavior, when enabled. When you disable this security policy setting, applications attempting to write in protected locations fail as with earlier versions of Windows.

The last security policy setting controlling User Account Control behavior is probably the most important one. Run all users, including administrators, as standard users is a security policy setting the affects all other User Account Control security policy settings. Enabling this policy turns on Admin Approval Mode and enables all other User Account Control polices to their default values. Disabling this policy turns off Admin Approval Mode and disables all related User Account Control security policy settings. Lastly, changing this security policy setting requires a reboot.

So, when you are evaluating your security policy during your Windows Server 2008 or Windows Vista deployment, look at the explain text for each security policy setting. Make sure you fully understand its impact before changing a security policy setting. Then, do not forget to include User Account Control policy settings in your security policy. These security policy settings can help you keep your computer, network, and data safe and secure.

- Mike Stephens

Here are the new Directory Services-related KB articles for the week. Also, although it isn't entirely new, I was reminded that we have the Windows Server 2008 command reference available now. So here are links to both the 2008 and 2003 versions. They are good as a quick reference when you need a command's syntax but also interesting to look at to be aware of tools you might not use on a daily basis. AD admins will want to familiarize themselves with Wevtutil and Icacls, both are new to Vista/2008.

Windows Server 2008 Command Reference

Windows Server 2003 Command-Line Reference

- Craig Landis

Hi, Ned here. If you’re a regular reader of the Filing Cabinet, you’ve probably already read about all the new features for DFS Replication (DFSR) added in Windows Server 2008. If not, trot on over here and drink your fill. Just to summarize some of these cool new features:

But there’s something missing. There’s a little history here, so walk with me down technical memory lane.

When DFSR was released on Windows Server 2003 R2 in February 2006, it had a list of file extensions that were non-compressible. These were:

WMA,WMV,ZIP,JPG,MPG,MPEG,M1V,MP2,MP3,MPA,CAB,WAV,SND,AU,ASF,
WM,AVI,Z,GZ,TGZ,FRX

When you added a file to a DFSR content set and it was at least 64KB in size, the DFSR service placed a copy of the file in the Staging folder. The file had an alternate data stream added that held the computed Remote Differential Compression (RDC) signatures. RDC is what allows DFSR to only replicate the parts of the file that have changed. But files were also compressed with a standard compression algorithm called XPRESS, which is similar to ZIP or RAR compression. Any files that ended up in staging were compressed with XPRESS unless they had an extension that was on this list. Since there was no point in trying to shrink files that were already compressed (like ZIP or JPG), we simply didn’t bother; it wasted disk and CPU resources after all.

After digging around in the product design request database here, looking at the source code, and pinging the developers, I came up short: the list was hardcoded. Rats. I wrote up a short internal article and promptly forgot about it.

Fast forward to Windows Server 2008.

You guessed it – we can do this now and here are the steps:

1. Your Active Directory forest schema must have been extended with ADPREP to Windows Server 2008 (or you have installed a new Win2008 forest). If this is not done you won’t have the new attribute necessary for this to work.

2. Setup DFSR on a few Win2008 machines (add the role through Server Manager, use DFSMGMT.MSC to configure, and let the servers pick up the new settings).

3. On one of your domain controllers run ADSIEDT.MSC as a Domain Administrator.

4. Navigate to your content set that you want to modify. So for example:

cn=Public,cn=content,cn=Shared, cn=dfsr-globalsettings,cn=system,dc=cohowinery,dc=com

5. Right-click the replicated folder (cn=public) and choose properties.

6. Scroll down a ways and edit the attribute msDFSR-DefaultCompressionExclusionFilter.

Important Notes: Any extensions we add in here will become the new rule for compression. So if we just add FOO then all files that are *.foo will no longer be compressed. We need to make sure we comma separate a list of files, and there must not be any spaces. Also, this list is destructive – if we put anything in here, then the default list of extensions like ZIP or JPG is ignored going forward unless we add them back. Finally, if the attribute is set to “<Not Set>” it will use the default extension list from above.

7. So let’s add our new extension. We have an application that creates drawing files called *.NED. These NED files are already compressed so we don’t want DFSR to waste time trying to compress them more. In the Value field of our msDFSR-DefaultCompressionExclusionFilter attribute we all of the below:

WMA,WMV,ZIP,JPG,MPG,MPEG,M1V,MP2,MP3,MPA,CAB,WAV,SND,
AU,ASF,WM,AVI,Z,GZ,TGZ,FRX,NED

8. We click ok and exit out of ADSIEDIT. We wait for AD replication to complete. We wait for the DFSR servers to pick up the change through their polling process (or run DFSRDIAG POLLAD).

Now when NED files are created or modified, they will no longer be compressed in the staging directory. Sweet! If for some reason you wanted to turn off all file compression, you can set the msDFSR-DefaultCompressionExclusionFilter attribute to contain just an asterisk. This would have the minor upside of saving some CPU and disk time when staging, but could have a significant downside in bandwidth consumption and replication time for larger files – so this is not recommended and you shouldn’t do this without significant testing in your lab environment. You cannot tailor RDC to only affect certain file types – it is limited to off/on/minimum size, just like in R2.

And yes, we have a KB article for this in the works. The beauty of blogging means you don’t have to wait for it. :)

- Ned Pyle

Hello there. Bob Drake here to discuss how Windows Server 2008 “Read Only Domain Controllers” (RODC’s) authenticate users differently from the way Windows Server 2003 and Windows Server 2008 standard domain controllers do. The “Read Only Domain Controller” is new to Windows Server 2008 and allows for the installation of a domain controller to accommodate common scenarios where users are authenticating over a wide area network (WAN) or there is a physical security concern for the domain controller, such as installations at branch office locations. Another new feature to Windows Server 2008 RODC’s is “Password Replication Policy” and depending on how they are configured determines how an RODC authenticates a user.

To understand the authentication difference between a standard domain controller and an RODC, we need to review the “How interactive Logon works” and “Kerberos authentication” TechNet articles. In the section Domain Login (How interactive logon works article), a user’s credentials are received by Winlogon and passed to the LSA (local security authority) which negotiates Kerberos and contacts the domain controller. The domain controller then returns the logon success to the local computers LSA which generates the user’s access token. The Kerberos authentication is seen in the following diagram (taken from the Kerberos authentication article):

To see the authentication on the wire, we would need to install a network capture application such as Netmon3.1 (or Wireshark, Ethereal, Packetyzer). In the following network trace, we see a client machine authenticate to a domain controller and is granted access with the “KRB_AS_REP” and “KRB_TGS_REP”:

Now let’s take a look at the “Password Replication Policies” and how they affect the RODC authentication behavior. With the installation of an RODC, there are four new attributes and two built-in groups to support RODC operations:

• msDS-Reveal-OnDemandGroup. This attribute points to the distinguished name (DN) of the Allowed List. The credentials of the members of the Allowed List are permitted to replicate to the RODC.
• msDS-NeverRevealGroup. This attribute points to the distinguished names of security principals that are denied replication to the RODC. This has no impact on the ability of these security principals to authenticate using the RODC. The RODC never caches the credentials of the members of the Denied List. A default list of security principals whose credentials are denied replication to the RODC is provided. This helps ensure that RODCs are secure by default.
• msDS-RevealedList. This attribute is a list of security principals whose passwords have ever been replicated to the RODC.
• msDS-AuthenticatedToAccountList. This attribute contains a list of security principals in the local domain that have authenticated to the RODC. The purpose of the attribute is to help an administrator determine which computers and users are using the RODC for logon. This enables the administrator to refine the Password Replication Policy for the RODC.
  
  ------------------
• Allowed RODC Password Replication Group. This group is added to the msDS-Reveal-OnDemandGroup.
• Denied RODC Password Replication Group. This group is added to the msDS-NeverRevealGroup.

Note: The “Allowed RODC Password Replication Group” has no members by default, and the “Denied RODC Password Replication Group” contains all the ‘VIP’ accounts (Enterprise Administrators, Cert Publishers, Schema Administrators, Etc). As with most things, Deny always trumps Allow.

Using the commands for “Repadmin.exe” (this is built into Windows Server 2008) an administrator can modify the Password Replication Policy groups. To view the current PRP for a specified user:

Repadmin /prp view <RODC> {<List_Name >|<User>}

The following shows the settings for the groups on the RODC through several commands:

Awesome information here! We can see who is on the allowed list (msDS-RevealOnDemand), who is on the deny list (msDS-NeverRevealGroup), who is actually revealed (msDS-RevealedList) and who actually has authenticated to the RODC (msDS-AuthenticatedToAccountlist).

The configuration of a Password Replication Policy is pretty straight forward. Open Active Directory Users and Computers snap-in and select the RODC in the Domain Controllers organizational unit. On the “Password Replication Policy” tab, there are the two groups: “Allowed RODC Password Replication Group” and “Denied RODC Password Replication Group”. A user can be added to either of the desired groups.

Another really cool feature is the “Prepopulate the password cache for an RODC” button. This button (pictured) allows an administrator to pre-add users that will be authenticating to the RODC.

An administrator could also use the “Repadmin” utility to populate the password cache with the following command:

Repadmin /rodcpwdrepl [DSA_LIST] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished name> <User2 Distinguished Name>…].

The following shows the user “Ned Pyle” being added to the password cache using Repadmin:

So how does this affect the RODC? When a user authenticates to an RODC a check is performed to see if the password is cached. If the password is cached, the RODC will authenticate the user account locally. If the user’s password is not cached, then the RODC forwards the authentication request to a writable Windows Server 2008 Domain Controller which in turn authenticates the account and passes the authenticated request back to the RODC. Once the user account is authenticated, the RODC makes another request for the replication of the user’s password in a unidirectional replication providing the account has been configured to allow replication.

This finally brings us to seeing the difference in authentication. For the following NetMon 3.1 trace, I have configured a user account whose password has been denied replication to the RODC. The user authenticates to the RODC (2k3DOM2k8DC2) and the RODC forwards the request to the writable domain controller (2k3DOM2k8DC). We see the extra traffic since the user’s password has not been cached:

For the last trace I have allowed the user password to be cached by configuring the Password Replication Policy. The user authentication is the same as above, with the exception to what the RODC does after authenticating the user. Now see the RODC make the request for the user’s password to be replicated, but in subsequent logins the password replication request would not be seen since it has been cached:

Note: If the Wide Area Network (WAN) is down and the user account and password has NOT been cached, then the user account will fail to authenticate.

To wrap it up, when a user account is not cached, the RODC forwards the authentication to a writable Domain Controller which does the authentication. If the Users password is allowed to be cached, then the RODC will pull that through a replication request. Once the user has been authenticated, and their password has been cached, any subsequent login can then be handled by the RODC alone. Some people may see an increase in Wide Area Network (WAN) traffic with the introduction to an RODC, but after caching user passwords there should be a significant reduction in traffic and a more secure environment. In my next blog I will discuss how account lockout thresholds affect this process and what Administrators might run into with them.

-Bob Drake

Are you looking for an opportunity to work on the cutting edge of Windows Server technology?  Do you love supporting and administering Windows environments?  Are you looking for a challenging opportunity to develop your skills further? Do you want to be a part of a global team supporting Windows for the world?  If you said yes to these questions then we are looking for you and your talents.

We have openings on the Windows Server Support team.  If you want to work for a company that is listed by Fortune Magazine as one of the 100 Best Companies to Work For in 2007 and one of the World's Most Admired Companies then this may be the opportunity for you! We currently have opportunities in Los Colinas, TX and Charlotte, NC. Click the links below for more details.

Positions in Los Colinas, Texas USA
Positions in Charlotte, North Carolina, USA

For more information, please contact:

Mike O'Reilly and Rusty Gray

Here are the new KB articles for this week that relate to Directory Services. There is an update to Icacls.exe (which is a replacement for CACLS/XCACLS/XCACLS.VBS, etc. for setting NTFS file permissions), updates to TCPIP.SYS and LSASRV.DLL, a Bitlocker update, and a workaround to resolve slow RDP or SMB connections between 2003 SP2 and Vista machines.

- Craig Landis

Hi, Dave here. Today, I will cover the process by which domain DFS namespaces can be migrated from one domain to another, important considerations both during and after the migration, and some helpful tips along the way.

My post assumes that you have some working knowledge of DFS and related terminology. Don’t worry if you are new to DFS… we have excellent documentation over on the Windows 2003 Server Technical Reference website. I’ll wait right here until you get back.

To begin with, we know that DFS is used to build a unified namespace for files scattered throughout your Windows environment. This way, users don’t need to know which servers contain their data and the names of any particular share. They only need to know the root of your DFS namespace to begin locating their files and get silently referred to the required file server. This is all well and good, but what happens when you move your files shares to a new domain or environment and want bring your elaborate DFS namespace along with the data? Or what if you simply wish to make another copy of an existing DFS namespace? The answer is with the DFSUTIL.exe support tool.

DFSUTIL is a command-line tool provided within the Windows Server 2003 Support Tools package. With it, you can export a specified DFS namespace to an XML text file and later import this information back into a new DFS root.

Before using these commands, ensure that you have the latest version of the Support Tools installed on your system where you will be exporting/importing the DFS configuration. Please note the process by which the data or file servers are migrated between the environments is beyond the scope of this blog.

It is also recommended to create a full system-state backup of your domain controller(s). This way, any accidental deletions or overwrites of your DFS configuration can be easily recovered.

The steps below detail the process by which a DFS root called “public” was migrated from the domain “contoso.com” to a new “public” root in the domain “fabrikam.com”. A two-way trust exists between these domains and network communications between them is fully functional. Although this environment is simplistic, the process is applicable to namespaces with hundreds of folders and targets.

Here is a screenshot of the Public namespace within contoso.com:

Step1 - Exporting a Namespace:

The command to export the namespace is “dfsutil /root:\\domain.com\rootname /export:exportedroot.txt /verbose

As you can see, I exported my domain DFS root named “public” to a file named “publicroot.txt”. My root happens to contain 3 folders, named “accounting”, “utilities”, and “documentation”. “Accounting” has two folder targets, and “utilities” and “documentation” each have a single folder target. All target file servers, FS1 and FS2, are in the Contoso.com domain.

The publicroot.txt file contains:

<Root Name="\\CONTOSO\Public" State="1" Timeout="300" Attributes="64" >
    <Target Server="CONTOSOROOT1" Folder="Public" State="2" />
    <Target Server="CONTOSOROOT2" Folder="Public" State="2" />

    <Link Name="Accounting" State="1" Timeout="1800" >
        <Target Server="fs1" Folder="accounting" State="2" />
        <Target Server="fs2" Folder="accounting" State="2" />
    </Link>

    <Link Name="utilities" State="1" Timeout="1800" >
        <Target Server="fs1" Folder="utilities" State="2" />
    </Link>

    <Link Name="documentation" State="1" Timeout="1800" >
        <Target Server="fs2" Folder="documentation" State="2" />
    </Link>

</Root>

There, that was easy enough! Now that the root has been exported, some edits to this data is required before import.

Step 2 – Editing the configuration file

First off, you see that the “root name” value is “\\CONTOSO\Public”. Because the root configuration needs to be imported into the Fabrikam domain, this must be manually modified. The modified portion of the namespace file will look like this:

<?xml version="1.0"?>

<Root Name="\\FABRIKAM\Public" State="1" Timeout="300" Attributes="64" >

The remainder of the file will remain untouched, for reasons which will be discussed below. This file should be saved (I named it publicrootmodified.txt)

Step 3 – Create the new namespace in the new environment/domain

Before a DFS configuration file can be imported, the target namespace must be manually created—DFSUTIL won’t create the root for you.

The command to import the configuration is as follows:

dfsutil /root:\\domain.com\rootname /import: publicrootmodified.txt /set /verbose

NOTE! The import process will overwrite any DFS configurations in the target namespace. Please ensure you enter the path of a root you are prepared to replace.

If you try an import without first creating the DFS root, you will get the following error:

System error 1168 has occurred.
Element not found.

Likewise, attempting to import the configuration file before changing the “Root Name” value within it to match the namespace will result in the error:

System error 2 has occurred.
The system cannot find the file specified.

A successful import will appear as follows:

The new DFS namespace in the fabrikam domain:

Notice how the root targets “CONTOSOROOT1” and “CONTOSOROOT2” don’t show up under the “Namespace Servers” tab. This is because DFSUTIL ignores any root targets listed in the configuration file. You have the option to configure additional namespace servers in the DFS Management tool either before or after you import the configuration file. In my example, I had a single namespace server in the Fabrikam domain called “fabrikamroot1”.

If you take a peek at the dfsutil.exe command syntax, you may notice there is also a “merge” option in addition to “set”. Merge can only be utilized if your configuration XML specifies folders and targets which are not already present in the namespace. This may be useful if you want to incrementally import portions of the namespace, but requires careful manipulation of the XML configuration files and isn’t generally recommended.

Let’s take a few moments to review what we have done. First, we exported DFS configuration information, changed the value for the new namespace/root name, and then imported it into a new namespace. Because of the domain trust, clients in both domains can now seamlessly access any of the 3 folders via either the “\\contoso.com\pubic” or “\\fabrikam.com\public” namespaces—both namespaces will issue referrals to the folder targets which still reside in the consoto.com domain.

It is likely that your migration requires making the shared data part of the other domain. Through beyond the scope of this blog post, this may entail simply joining file servers to the other domain, copying the data to a completely new server in the other domain, consolidating many target folders to a single file server in the other domain, or using a domain migration tool such as the Active Directory Migration Tool (ADMT) to migrate the server(s).

Lastly, here are a number of considerations to ensure this process goes smoothly:

• Don’t enable FRS or DFSR replication until the folder targets all exist within the same domain or forest, otherwise it won’t work.
• Using dfsutil.exe to migrate namespaces doesn’t preserve FRS or DFSR replication configurations.
• If after importing the namespace clients have problems accessing the namespaces or any of the folders, check to see if they can directly access the root and folder targets via \\server\share to determine if the namespace or something else is at fault.
• Access to resources between the domains is highly dependant on the health of the domain trust--verify the trust’s status and ensure name resolution is functioning correctly.
• If any folder (link) target server names or share names are changed, the migrated namespaces will need to be manually updated to reflect this. This is most likely to happen if DFS is configured to use DNS names rather than NetBIOS names and file servers are moved to the other domain.
• DFS configuration changes may not be immediate. Client's cache referral information which won’t be updated until it expires. Additionally, Active Directory replication latencies may also cause namespace servers to only detect changes after they poll domain controllers for changes (60 minutes by default).

Also note that the steps detailed here can be applied to standalone DFS Namespace servers. The process of exporting, modifying, and then importing the namespace will be much the same.

And there you have it—a complete migration of DFS configuration in 3 easy steps. They should prove useful when wishing to rename a namespace, making a copy of the namespace for use in a test environment, and backing up the namespace in the event that the namespace is accidentally deleted or modified.

- David Fisher