Microsoft's official enterprise support blog for AD DS and more
Mike here. PolicyMaker customers rejoice—Microsoft has a way for you to migrate from PolicyMaker 2.x to the new Group Policy preferences released with Windows Server 2008 and included in the Remote Server Administration Tools for Windows Vista Service Pack 1 or higher.
Download GPPMIG: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=35791cb6-710b-48c4-aaa1-90db170bcf2a
If you’ve been using PolicyMaker then you already know how to use Group Policy Preferences. It is all managed using the Group Policy Management Console included with Windows Server 2008 or, using Windows Vista Service Pack1 by installing the Remote Server Administration Tools. However, Group Policy preferences cannot process PolicyMaker data and vice versa. Therefore, you need to have a strategy to migrate from PolicyMaker to Group Policy Preferences. Hopefully, this should help. Everything discussed below is also included in the GPPMIG installer as the ‘GPPMIG Migration Guide'.
I want to take a few minutes to discuss some of the prerequisites before we jump right into the migration strategy. We have two categories Management and Client.
Policymaker’s management looks and feels the same as managing other Group Policy setting. The same look and feel returns using Preferences. One thing to consider is-- each instance (PolicyMaker or Group Policy Preferences) cannot edit the others data. For this reason, you may need to leave one or more Windows XP computer, with the PolicyMaker administrative tools installed, until you’ve completed your migration. If your migration follows a staged approach, then you may encounter a small period of time where you may need to manage using both Windows Vista and Windows XP. Or, you may be the weekend warrior type and have your migration complete from Friday to Monday. The choice and freedom are there, but the requirement remains—PolicyMaker administrative additions can only edit PolicyMaker items. Server 2008 and the RSAT tools can only edit Preferences. Read Microsoft Knowledgebase article 941314, Description of Windows Server 2008 Remote Server Administration Tools for Windows Vista Service Pack 1 for more information.
The critical component that actual makes PolicyMaker and/or Preferences work is the client side extensions (CSEs), which you must install on the client computer. The CSEs make normal Group Policy processing PolicyMaker/Preferences aware. The same rules apply to the client portion—PolicyMaker CSEs only process PolicyMaker data and Preference CSEs only process Preference data. Also, installing the Group Policy Preference CSEs automatically removes PolicyMaker CSEs. The new Group Policy preference client side extensions installs on
Both Windows Server 2003 and Windows XP require the installation of XmlLite prior to installing the CSEs. Preference CSEs are included in Windows Server 2008. Read Microsoft Knowledgebase article 943729, Information about new Group Policy preferences in Windows Server 2008 for more information.
It goes without saying—you can never test enough and this scenario is not any different. Make sure you have backups… and they actually work. If you are going to use GPMC to backup your GPOs, then remember to use the correct version. GPMC backups are not interchangeable. If you backup with pre-Server 2008 GPMC, then you must restore with the same version. Back up some of your most complex or important GPOs and then important them into isolated test GPOs in a test OU with a single user and computer. Run through your entire migration strategy—noting what works and what does not— refining the plan with each pass. All efforts spent in planning usually pay off during implementation.
Now that we have the planning stuff out of the way—on to the good stuff. GPPMIG is a console application developed with version 3.0 of the .NET framework. Use GPPMIG to migrate PolicyMaker items to Group Policy Preference items into the same or a different Group Policy object. GPPMIG does not migrate PolicyMaker Application or Mail Profile data as Group Policy Preferences do not included client-side extensions for these items.
Let us take a few moments to discuss how GPPMIG works. For starters, GPPMIG always uses the domain of the currently logged on user. You’ll want to remember this so you can log on with domain administrator account for the domain GPOs you want to migrate. And, you must be a domain administrator as GPPMIG write to SYSVOL and Active Directory. One last point is that GPPMIG always connects to the PDC of the user domain—for reading and writing to Active Directory and SYSVOL. So, you’ll want to run GPPMIG from a computer close (same subnet) as the PDC emulator.
With GPPMIG, you can target a single GPO to migrate or, you can choose to migrate all GPOs. GPPMIG performs a paged LDAP query to the PDC to retrieves a list of all the Group Policy objects in the user’s domain. GPPMIG then filters out any GPO in the list that is not configured for PolicyMaker items. Then, GPPMIG iterates through each GPO in the final list, looking for PolicyMaker specific client side extensions in each GPO. The entire GPO is evaluated before moving to the next. If a PolicyMaker setting is found, then GPPMIG ensures there is not an equivalent Group Policy Preference configuration, as it will not migrate PolicyMaker items into existing Group Policy Preference items. When GPPMIG completes its search for PolicyMaker items in the GPO, it then updates the Group Policy object to included Group Policy Preference client side extensions and then increases the version number for the user, computer, or both depending on what PolicyMaker items it migrated. In no way does a migration alter any PolicyMaker items for the GPO. All PolicyMaker items remain configured and available in the GPO. GPPMIG creates a migration log in the directory from which it ran.
You can use GPPMIG to migrate to Group Policy Preferences in staged approach or, you can create brand new GPOs to hold your new Group Policy Preference items and migrate to those new GPOs. The staged approach is a planned migration strategy and is the approach I’ll document here. After reading this, you should be able to alternate this strategy to best suit the needs of your environment. Generally, you’ll migrate from PolicyMaker to Group Policy Preferences in three stages (after you’ve done your testing).
GPPMIG contains four basic commands:
Begin your migration process by identifying GPOs containing PolicyMaker items. You can do this by using the –whatif command. Use the –all command afterwards to search all the GPOs in the user’s domain or, you can use the –name command and provided the display name of the GPO. Use GPMC to backup all of the GPOs identified to have PolicyMaker items.
Next, you’ll want to migrate PolicyMaker items to Group Policy Preference items. You have a choice to migrate the setting within the same or to a different Group Policy object.
Note The migration does not modify PolicyMaker items, regardless of the migration action you choose.
Use the –migrate command to migrate PolicyMaker items to Group Policy Preference items within the same GPO. Use the following syntax:
Gppmig –migrate –name:gpo_name
Alternatively, you replace the –name argument with –all to migrate all the GPOs in the users domain that contain PolicyMaker items.
Figure 1 GPPMIG In-place Migration
You may prefer to keep PolicyMaker GPOs separate from Group Policy Preference GPOs. You use the –migrateTo command to accomplish this task
Important You must create the target GPO before using the -migrateTo command. GPPMIG does create the target Group Policy object.
Figure 2 - GPPMIG Source-target Migration
The –migrateTo command requires two additional arguments: -source: and –target: follows by the display name of the Group Policy object. Enclose the name of the GPO in quotes if the name contains spaces. Also, the –migrateTo command does not support the –all argument.
You’re now ready to deploy the Group Policy Preference client-side extensions after you’ve migrated all of your GPOs to include Group Policy Preference items. The migration does not modify any PolicyMaker items; so clients with the PolicyMaker CSE and the Group Policy preference CSEs process the same data
Note GPPMIG does not migrate Application or Mail PolicyMaker items. Therefore, Group Policy Preference CSEs do not apply these items to users or computers. Leave the PolicyMaker CSE installed on computers that require these items and do not install the Group Policy Preference CSEs as the installation removes PolicyMaker CSEs).
You can apply Group Policy Preferences to several Microsoft operating systems. The minimum operating system requirements are:
Group Policy Preference client-side extensions are included in Windows Server 2008. You can use the links above to download the client-side extension installation packages. Or, you can download the extensions as an optional update from Windows Update.
Important Remember-- installing Preference client-side extensions removes PolicyMaker Client Side Extensions.
The last stage in the migration process involves verifying your items migrated and apply correctly. Use GPMC to view the Group Policy object to which you migrated your items. Click the Settings tab to show the Preference items included in the GPO.
Figure 3 GPMC Settings Tab
Next, you'll want to apply the Group Policy object to your client computers. For in-place migrations, you'll want to apply the GPO to computers using PolicyMaker CSEs and computers using Preference CSEs. Also verify user PolicyMaker and Preference items apply to the appropriate user. GPOs that are targets of in-place migrations should apply items to both (PolicyMaker and Preferences). Source-target migrations migrate the PolicyMaker items to Preference items in the newly created GPO. This allows you to keep your existing PolicyMaker GPOs separate from your Preference GPOs. You apply GPOs containing Preference items to computers are users using the Group Policy Preference CSEs.
Use the Resultant Set of Policy (RSOP) management console to confirm PolicyMaker items are applying to computers or users. Use the Group Policy Results feature within GPMC to confirm Preference items are applying to computers or users.
Figure 4 GPMC Group Policy Results for testuser
The actual migration from PolicyMaker to Group Policy Preferences is complete. Computers running either Preferences or PolicyMaker should be applying their respective items. Source-target migrations contain both PolicyMaker and Preference items. After you've transitioned your client to use the Group Policy Preference CSEs, you'll want to remove the PolicyMaker data, which remains in the GPO. You can use GPPMIG with the -remove option to remove overlapping PolicyMaker and Preference items.
Figure 5 Removing PolicyMaker settings
Note GPPMIG does not remove PolicyMaker Application and Mail items from the Group Policy object.
Source-target Migrations do not included PolicyMaker items. Therefore, once you've completed transitioning your client computers to use Preference CSEs, you can delete the source version of the GPO, which contains only PolicyMaker items.
You should consider backing up your Group Policy objects after you've completed your migration and cleanup of Group Policy objects. Use the Group Policy Management Console included in Windows Server 2008 and the Remote Server Administration tools to backup all of your Group Policy objects before you proceed with any further changes.
- Mike Stephens
Hi, this is Bobby from the Microsoft Directory Services support team. Today we are going to discuss some confusing behavior that I’ve observed regarding inconsistent DFS access. While the root of this is issue is easy to remediate, it can be difficult to find the offending servers.
When first presented with this issue, I was asked to help determine the nature of users getting prompted to connect to a DFS root. DFS roots are defined in “How DFS Works as”
The starting point of the DFS namespace. The root is often used to refer to the namespace as a whole. A root maps to one or more root targets, each of which corresponds to a shared folder on a separate server. The DFS root must reside on an NTFS volume. A DFS root has one of the following formats: \\ServerName\RootName or \\DomainName\RootName.
The dialog was as follows:
Prior to calling Microsoft support, the customer was able to successfully connect to the NETLOGON and SYSVOL share of the domain without issue (\\contoso.com\sysvol and \\contoso.com\netlogon) Rebooting the client machine or having the client logoff would at times alleviate the problem. After a random period of time, users could access the DFS root, would later lose access, and users who did not work before would start working.
Investigating the issue, it was noticed that the "Distributed File System" MMC would change as time passed. For reference, I have included a picture of what it should look like when all is ok.
Using the "Distributed File System" MMC to check the status of the root would provide differing results at different times.
In this picture, it appears that three of the four root targets are inaccessible. When the MMC was checked later (or the user logged off and then back on) the results changed:
When using the “DFS Management” MMC from 2003 R2, The display is different, but the behavior is the same:
When we began troubleshooting the issue, we started to look at the output of “dir” and dfsutil /pktinfo. This was to test the access to the DFS root and connectivity to the root shares.
At this point, each target appeared accessible. This was an unexpected result. I would have expected that we would get access denied to all of the targets. If we could reach each target, why were getting random “access is denied” when attempting to get a directory listing of the root?
We used the dfsutil /pktflush command to purge the referral cache thus forcing a request for new referrals. Then we ran the dir commands again that returned different results:
Using Netmon, we took a trace to see what we can find.
The first thing we attempted was to request a DFS referral for \\contoso.com\root
We were returned four targets for the root.
This was represented in the pktinfo as follows:
At this point we attempted to create a connection to the first server returned in the referral.
However we were returned: Status_access_denied.
Normal troubleshooting would be to attempt to connect to the share \\2003-02\root. In this case, we executed dir /b \\2003-02\root.
When we attempt to do this, we received more unexpected results:
I would have actually expected this to get an “access is denied” too.
Looking further in the network trace, we noticed that we received a new referral when we attempted to connect to 2003-02 server directly. To illustrate this, I have several screenshots of the referral network traffic.
The DFS service returned the following (note that ‘TargetPath: Index:1’ is not 2003-02 but another server):
Again the pktinfo:
When connecting to the path \\2003-02\root, we were instead accessing the root share on 2003-01, as detailed in the trace:
When connecting to a root DFS share, the DFS service returns referrals for all of the participants on the root target set. So when we executed the command dir \\2003-dc1\root, the DFS service on 2003-dc1 then responded with a new DFS root referral for the path \\2003-dc1\root. This behavior accounts for the entries in the referral cache for paths to each root (i.e. \\2003-dc1\root, \\2003-01\root, \\2003-02\root, \\2003-03\root). DFS referrals are retuned in a random order for servers in the site of the client. This will cause differencing results for each time the client requests a referral.
The root cause of the issue was actually incorrect share permissions on the “root” share of 2003-02. This can be observed locally using net share sharename
Comparing this to the same output of 2003-01, we see the problem:
In small environments, connecting to the server and examining the share permissions is an acceptable method, however in large environments this can prove cumbersome. I prefer to use subinacl to verify the permissions remotely. (Subinacl can be downloaded here: http://www.microsoft.com/downloads/details.aspx?FamilyID=E8BA3E56-D8FE-4A91-93CF-ED6985E3927B&displaylang=en)
To fix this we could connect to the server and add the permissions. Or it could be altered remotely with the following:. The syntax is : subinacl /share \\2003-02\root /grant=everyone=r
Note: Read is the default share permission in 2003 and later. Your permissions may be different based upon your business needs.
Using DFSGUI.MSC to check the status of the DFS root targets has been deprecated and is no longer available in 2008. This however does not change the behavior of the referrals that are returned.
Using DFSdiag.exe from Windows 2008 does not return any additional information as to the root cause.
For more information about the technologies discussed here, please refer to “How DFS Works” http://technet.microsoft.com/en-us/library/cc782417(WS.10).aspx
Hey everyone, Rob Greene here back after a long hiatus from blogging. I had an interesting case come through that I thought many of you IT pros would be interested in.
Background
The customer had an issue with using Cisco VPN and Cisco ASA concentrators and authenticating the user with Kerberos authentication. After they upgraded all their Windows 2000 domain controllers to Windows Server 2003 domain controllers, users could not authenticate through the VPN.
After doing this they gave Cisco a call and they were told to start DSA.MSC and check the box under Account Options to “Do not require Kerberos preauthentication” for all user accounts that need to connect through the appliances. When they did this as a test it did allow the user to start authenticating through the devices. However the customer did not like this option since:
1. This change lowers the security of Kerberos authentication by disabling password replay attack protection. 2. Everything had worked previously with Windows 2000.
1. This change lowers the security of Kerberos authentication by disabling password replay attack protection.
2. Everything had worked previously with Windows 2000.
If you want to learn more about preauthentication you can click here and look under the section:
Example AS Administration.
If you search Cisco’s website you will find that they have older documentation stating that you must disable this feature on the user’s account before the VPN will start working.
I don’t have real network traces (as I can’t show you a real customer’s network!), but I can tell you what we saw in the traces that led us to a potential workaround.
VPN Appliance --> UDP Port 88 / KRB5 AS-REQ --> Windows DC VPN Appliance <-- UDP Port 88 / KRB5KDC_ERR_REAUTH_REQUIRED <--Windows DC VPN Appliance --> UDP Port 88 / AS-REQ (with Pre-Auth Data) --> Windows DC VPN Appliance <-- UDP Port 88 / KRB5KDC_ERR_RESPONSE_TOO_BIG <-- Windows DC
VPN Appliance --> UDP Port 88 / KRB5 AS-REQ --> Windows DC
VPN Appliance <-- UDP Port 88 / KRB5KDC_ERR_REAUTH_REQUIRED <--Windows DC
VPN Appliance --> UDP Port 88 / AS-REQ (with Pre-Auth Data) --> Windows DC
VPN Appliance <-- UDP Port 88 / KRB5KDC_ERR_RESPONSE_TOO_BIG <-- Windows DC
A KRB5KDC_ERR_RESPONSE_TOO_BIG means that the requested Kerberos data was larger than the maximum default datagram size of 1465 bytes. The next step here usually would be for the client to start the Kerberos ticketing process over using TCP rather than UDP. If this was a Windows XP client instead of the Cisco VPN appliance we would have the customer implement the registry key change outlined in the below KB article.
244474 How to force Kerberos to use TCP instead of UDP in Windows http://support.microsoft.com/default.aspx?scid=kb;EN-US;244474
So basically the real issue is that the Cisco appliance is being asked by the KDC to use TCP instead of UDP to do the AS-REQ with pre-authentication data present. However, the Cisco appliance does not continue at this point. I spent the past few weeks working with Cisco directly (big shoutout - they have been great!), and they have published the following new articles:
Cisco VPN 3000: CSCed27444 - VPN3000 does not switch to TCP upon receiving Kerberos error code 52 Cisco ASA platform: CSCsi32224 - ASA does not switch to TCP upon receiving Kerberos error code 52 CSCtd92673 -- "Kerberos authentication fails with pre-auth enabled"
Cisco VPN 3000: CSCed27444 - VPN3000 does not switch to TCP upon receiving Kerberos error code 52
Cisco ASA platform: CSCsi32224 - ASA does not switch to TCP upon receiving Kerberos error code 52
CSCtd92673 -- "Kerberos authentication fails with pre-auth enabled"
Unfortunately, the Cisco VPN 3000 concentrator has been discontinued so there is no update available for the Cisco VPN 3000 to add this functionality. Also, you will need a support contract from Cisco to logon to those two articles and read them.
Please contact Cisco directly to find out more information about the issue, and with what IOS version it will be included in; we have provided this information to make it easier to find the content.
In the Meantime
So now the question becomes this: If that is what is going on, then how did it work when a Windows 2000 domain controller was used? And what can you do about it until an IOS update is released?
There was a change in the default datagram reply packet size used by the Kerberos Key Distribution Center (KDC) between Windows 2000 and Windows Server 2003. In Windows 2000 the default size is 2000 bytes, where it is 1465 bytes in Windows Server 2003. For those interested you can review the below KB article and find the registry key of MaxDatagramReplySize.
837361 Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb;EN-US;837361
So that means this customer’s Kerberos ticket size for the user accounts is less than 2000 bytes, but more than 1465 bytes. Keep in mind that if you are reading this blog, your environment may still not work with the registry key setting at 2000. This is because the Kerberos ticket size is going to vary based on the number of groups that the user belongs to. You can review the KB below to learn more:
327825 New resolution for problems with Kerberos authentication when users belong to many groups http://support.microsoft.com/default.aspx?scid=kb;EN-US;327825
The only workaround that we can give a customer is to modify the MaxDatagramReplySize registry value to the size of your user’s largest Kerberos ticket size. It really depends on the group membership size of the user attempting to authenticate because of the PAC data that is included in the TGT. For those customers that have used the MaxTokenSize registry value should equal that value and restart the KDC service. If none of these acronyms are making sense you might want to check out my older blog post Kerberos for the Busy Admin.
Hey wow, this sounds like a pretty easy fix right? Well, you can actually have other problems because of this change. If your networking gear (switches, routers, firewalls) cannot handle large UDP packets without fragmenting them then all Kerberos authentication could start to fail in your environment. See KB244474 under more information to learn more about this.
Please keep in mind what you are doing when you implement the MaxDatagramReplySize registry value. You are in fact telling the KDC to never request the client send KRB5KDC_ERR_RESPONSE_TOO_BIG message back to a Kerberos client, and you should consider implementing the custom group policy setting included in KB244474 on all domain-joined machines to use TCP for Kerberos authentication always. If you are running purely Vista/2008 or later though, this is on by default.
Lastly, if you have to set this value very high, and you know that your networking gear will not support the packet sizes that had to be implemented, you may have to put a domain controller on the same IP subnet as the Cisco appliance to successfully get Kerberos tickets.
- Rob ‘I mean, you know’ Greene
Ned here again. The DFSR development team has posted a new series for anyone wanting top learn more about the new DFSR clustering capabilities in Windows Server 2008 R2. It's pretty indepth and walks you through the entire process.
Nice stuff, Mahesh!
- Ned Pyle
Mike here. The Group Policy security client side extension can distribute security descriptors on files and registry keys. This extension is difficult to troubleshoot because it is considerably durable when it comes to failures. In most situations, it completes processing, but not without leaving behind the ever popular SCECLI 1202 event.
Event Type: Warning Event Source: SceCli Event Category: None Event ID: 1202 Date: 21/09/1999 Time: 18:15:14 User: N/A Computer: MachineName Description: Security policies are propagated with warning. 0x4b8 : An extended error occurred. Please look for more details in TroubleShooting section in Security Help.
You can start your troubleshooting by following Microsoft Knowledge base article 324383 Troubleshooting SCECLI 1202 Events. Unfortunately, the return code 0x4b8 is ambiguous because it serves as generic alert of a nondeterministic problem-- it means something happened; but what happened was not catastrophic. Therefore, the security extension keeps processing,
Security extension processing has many facets. Using the previously mentioned knowledge base article should help you understand the general area within security processing that is failing. However, it's not enough evidence to confirm Professor Plum, did it in the library with the candlestick. But you should be able to determine the misbehaving portion of security processing from the winlogon.log. Scan the log file for the Configure File Security... section. It may look like:
----Configure File Security... Configure c:\. File Security configuration was completed with one or more errors.
----Configure File Security...
Configure c:\.
File Security configuration was completed with one or more errors.
If you suspect your file system security settings as the culprit, then you may want to use Process Monitor to help further determine where in the failure occurs. It's difficult to provide prescriptive guidance when there are many reasons for the resulting error. However, one scenario where we see this problem is in the case of a nested file or folder containing a null discretionary access control list (DACL).
NOTE: You can read more about the differences between null and empty discretionary access control list by reading the Null and Empty DACLs ASKDS blog post.
The scenario we encounter usually involves using the security policy extension to assign file permissions to a particular folder. Files and folders residing beneath the targeted folder inherit the permissions that are assigned to the targeted folder, unless that file or folder specifically blocks inheritance. If one of the underlying files or folders beneath the targeted folder contains a null DACL, then the security extension halts processing the remainder of file system security. Furthermore, an entry appears in the winlogon.log stating the configuration completed with one or more errors and, an event with the event ID 1202 appears is recorded to the event log. The return code reported in the event log is 0x4b8. Lastly, the winlogon.log file does not contain information on the file or folder responsible for stopping the process. The parent folder is the only item listed in the log. This means that one or more files or folder beneath the folder listed in the log file is responsible for halting security processing. The problem now is how to identify those files or folders. But, let's explain why security processing halts.
I previously mentioned that permissions we assign to folders through security policy processing propagate to all files and folders hosted within the targeted folder. Propagating security is known as inheritance, where a file or folder beneath a folder receives subset of the permissions from the containing folder. Windows must calculate the subset of permissions to apply to files and folders beneath the targeted folder. Windows derives these permissions by combining permission from the targeted folder and the file or folder beneath the targeted folder. Permission from the targeted folder are known as inherited permissions. Permissions on the file or folder residing in the targeted folder are explicit permissions. The problem with security processing occurs when the file or folder residing in the targeted folder contains a null DACL. Explicitly, this file or folder does not have any permissions. So Windows cannot determine how to propagate inherited permissions to the object because the object itself does not actually have permissions ( see ASKDS blog post Null and Empty DACLs).
The security extension must compute inheritance. Computing inheritance, is essentially asking the security extension to figure out how to add permissions from the parent object to the a child object that does not have room to store permissions. This would require the security extension to make arbitrary decision on intent. Is the null DACL on purpose? When does the extension observe the null DACL and when does it not? These are a few reasons why the security extension halts permission processing when it attempts to propagate inherited permissions after encountering a null DACL; it is not clear what the resulting permissions should be. Therefore, the security extension halts file security processing and moves forward with the next phase of Group Policy security processing. The recorded event is a warning, not an error. It is a warning because Group Policy security processing processed as a whole-- meaning none of the events that occur were catastrophic to the entire processing phase. However, one or more subcomponents did experience errors.
Detecting a null DACL is challenging. The Windows ACL editor interpret a null DACL for you; so your unaware if the DACL is null, or Everyone has Full Control. Windows includes CACLS.EXE, which reports if permissions are not set. This is an effective way to determine a null DACL exists but, you must have an idea of the file or folder containing the null DACL.
Identifying the a nested file or folder with a null DACL within a deep folder structure is difficult. Manually investigating these files or folders is not practical. Fortunately, ADSI provides a security descriptor interface we can use through scripting to recursively search folders, sub-folders, and files that may have a null DACL. Below is a sample script that can be copied and pasted into a text document.
'========================================================================== ' ' VBScript Source File ' ' NAME: CheckNullDacl.vbs ' ' AUTHOR: Mike Stephens , Microsoft Corporation ' DATE : 7/15/2003 ' ' COMMENT: ' '========================================================================== ' Microsoft provides programming examples for illustration only, without warranty either expressed or ' implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a ' particular purpose. This sample assumes that you are familiar with the programming language being ' demonstrated and the tools used to create and debug procedures. Microsoft support professionals ' can help explain the functionality of a particular procedure, but they will not modify these examples ' to provide added functionality or construct procedures to meet your specific needs. ' =============================================================================
Option Explicit Const ADS_PATH_FILE = 1 Const ADS_SD_FORMAT_IID = 1 Const SE_DACL_PRESENT = &h4 Const Dbg = False
Dim oArgs : Set oArgs = WScript.Arguments
If Not (oArgs.Count >= 1) Then WScript.Quit(0) End If
WScript.Echo VbCrLf & "Recursivly searching " & oArgs.Unnamed(0) & " for NULL DACLs..." & vbCr
SearchSDsInFolder oArgs.Unnamed(0)
WScript.Echo VbCrLf & "-=[Complete]=-" & VbCrLf
WScript.Quit(0)
Sub IsNullDacl(fileArg, bFolder) Dim fso : Set fso = CreateObject("Scripting.FileSystemObject") Dim sdUtil : Set sdUtil = CreateObject("ADsSecurityUtility") Dim sd : Set sd = CreateObject("SecurityDescriptor") Dim dacl
Dim sdControl, sdObject, DaclAceCount
If(bFolder) = False Then If(fso.FileExists(fileArg)) = False Then Exit Sub Else Set sdObject = fso.GetFile(fileArg) End If Else If(fso.FolderExists(fileArg)) = False Then Exit Sub Else Set sdObject = fso.GetFolder(fileArg) End If End If
Set sd = sdUtil.GetSecurityDescriptor( sdObject.Path, ADS_PATH_FILE, ADS_SD_FORMAT_IID)
' Get the SD Control sdControl = sd.Control
' Get the SD DACL Set dacl = sd.DiscretionaryAcl On Error Resume Next DaclAceCount = dacl.AceCount If Err.Number = 424 Then DaclAceCount = –1 Err.Clear End If On Error GoTo 0
If(sdControl And SE_DACL_PRESENT <> SE_DACL_PRESENT) Then WScript.Echo "- Null DACL detected on " & cStr(sdObject.Path) & "." Exit Sub ElseIf(DaclAceCount = -1) Then WScript.Echo "- Null DACL detected on " & cStr(sdObject.Path) & "." Exit Sub Else DebugPrint "Processed " & cStr(sdObject.Path) End If End Sub
Sub SearchSDsInFolder( folderArg) Dim fso : Set fso = CreateObject("Scripting.FileSystemObject") Dim flder, folder, folderCollection Dim file, fileCollection
Set flder = fso.GetFolder(folderArg)
If(flder.SubFolders.Count > 0) Then Set folderCollection = flder.SubFolders For Each folder In folderCollection SearchSDsInFolder(folder) Next End If
IsNullDacl flder.Path, true
Set fileCollection = flder.Files For Each file In fileCollection Dim f : Set f = fso.GetFile(file) IsNullDacl file.Path, False NextEnd Sub
Sub DebugPrint( text) If( Dbg = True) Then WScript.Echo text & vbCr End If End Sub
Use cscript.exe to start the script. Provide a single argument when starting the script. This argument is the folder at which the search for null DACLs begins. The search is recursive; therefore, it searches all nested folders and files. Files or folders identified as having a null DACL are printed to the screen.
Most null DACL scenarios identify only one or two files (or folders) containing a null DACL. You can change a null DACL by using the ACL editor, ICACLS, CACLs, or other permission utilities. A large quantity of files or folder containing null DALCs may require a scripted solution using the previous mentioned utilities.
- Mike “#14” Stephens
Ned here again. I recently came across a peculiar SYSVOL migration behavior with DFSR, and I thought I’d fill you in so you don’t chase your tail on this someday.
The Scenario
You can migrate Windows Server 2008 SYSVOL share from using legacy FRS to DFSR. You begin the migration by replacing or upgrading your old DCs with Windows Server 2008. Next, fire up DFSRMIG.EXE, and go to town using our migration guide. It’s simple and straightforward.
You should check your progress at each stage of the migration. It may puzzle you to find this little gem in your event log after the Prepared of the migration (using dfsrmig.exe /setglobalstate 1):
Log Name: DFS Replication Source: DFSR Date: 5/20/2009 10:54:56 AM Event ID: 6804 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: 7132-srv-01.consolidatedmessenger.com Description: The DFS Replication service has detected that no connections are configured for replication group Domain System Volume. No data is being replicated for this replication group. Additional Information: Replication Group ID: 07003670-2807-4D5B-89BD-FFF3DA94F2C6 Member ID: F2679227-2489-4A6D-A92C-2050E4ED4ACD
Oh snap, that doesn’t look good. So you run a DFSR Diagnostic health report and see:
Errors: "No connections exist for Domain System Volume."
Server Details: "No connections exist for Domain System Volume. Affected replicated folders: All replicated folders on this server. Description: The DFS Replication service has detected that there are no connections configured for replication group Domain System Volume. No data for this replication group is being replicated to or from this server. Event ID: 6804 Last occurred: Wednesday, May 20, 2009 at 10:54:56 AM (GMT-5:00) Suggested action: To resume replication, create connections using the DFS Management snap-in or the Dfsradmin.exe command-line tool."
Ack! You've checked replication by creating a test file in the new replicated SYSVOL_DFSR folder. To your surprise; the file replicates to all the DCs. That’s not possible though, as without connection objects there’s no way for DFSR to replicate anything. And, for extra weirdness, not all of the DCs report this issue – even DCs you know have direct replication partnerships with DCs that report the issue.
What the heck is happening?
The Cause
There are actually two things going on here:
1. A 6804 warning event is actually an expected entry under some circumstances, based on AD replication convergence. During creation of a new customer Replication Group you can see this event as well. So that’s no big deal.
2. However, a 6806 event should follow, which reads:
Log Name: DFS Replication Source: DFSR Date: 5/20/2009 10:55:56 AM Event ID: 6806 Task Category: None Level: Informational Keywords: Classic User: N/A Computer: 7132-srv-01.consolidatedmessenger.com Description: The DFS Replication service has detected that connections are configured for replication group Domain System Volume.
Unfortunately, this event does not appear when migrating SYSVOL due to an issue with the DFSR migration code.
The Solution
So the solution I give you here is an easy one that anyone can implement – just ignore it. :-) This event is harmless long as:
1. The 6804 event only occurs during a SYSVOL migration. 2. It only happens once. 3. And, it only references the Domain System Volume replication group.
1. The 6804 event only occurs during a SYSVOL migration.
2. It only happens once.
3. And, it only references the Domain System Volume replication group.
If you want the diagnostic health report event to go away, simply restart the DFSR service on any DCs reporting the event. You won’t see it again. Or don’t restart the service – it’s perfectly ok to ignore the event here too.
We’re looking into a more permanent solution for this, of course. But I figured you’d rather read it here first rather than opening a support case to be told ‘yes, we know’.
Now get back to migrating. Don’t you know how much I hate FRS?
- Ned ‘Blinders’ Pyle
Mike here. Windows uses the concept of a security descriptor to allow or deny security principals (user or groups) access to specific resources. A security descriptor is a data structure that contains:
An access control list (ACL) is a list of memory locations to access control entries (ACEs). An ACE contains information such as an action - is the action allowed or denied - and the security principal to which the allowed or denied action applies. ACEs are mostly commonly referred to as permissions. Windows uses discretionary access control lists to prevent or allow actions against resources for a specific user and/or group. Windows uses system access control lists to audit actions performed against an object by a specific user or group.
The DACL controls that type of access to a resource and who is taking that action. Windows allocates memory when creating a DACL. The security descriptor stores the memory location of the DACL. Windows uses the DACL memory location to identify where it should store the location of ACEs associated with the DACL. Therefore, the DACL exists but is empty and remains empty until an ACE is created and assigned to the DACL. This is an empty DACL.
A null DACL is often confused with an empty DACL; however, they both refer to two distinct entities. As mentioned earlier, the security descriptor contains the memory location of the DACL when a DACL is created. However, it is possible to create a security descriptor without the memory location of the DACL. The security descriptor is valid; however, the memory location of the DACL does not exist; it is null. This means that Windows did not create a DACL. This also means that it is not possible to add an access control entry to the DACL until the DACL is created and a valid memory location is provided in the security descriptor.
Windows' security defines two specific actions with regard to handling a null or empty DACL. These actions occur when Windows performs an access check. An access check occurs when a user attempts access to a resource. The access check occurs on the computer hosting the resources. Windows checks the access token created on the resource computer with the security descriptor protecting the resource. Windows grants full access to any requesting user, bypassing any further security checks. The resulting effects of a null DACL is similar to granting the Everyone group Full Control permissions.
An empty DACL provides the opposite effect of a null DACL. An empty DACL is similar to denying Full Control permissions to the Everyone group; effectively preventing anyone from accessing the resource. It's important to understand that Windows only accommodates null or empty DACLs during the access check; not when the null or empty DACL is saved to the security descriptor.
- Mike “Rubbin’ is Racin’“ Stephens
Ned here. After much strife, here is the hotfix to get RSAT AD Users and Computers to include tabs for:
• Terminal Services Profile • Environment • Sessions • Remote Control
960890 Some tabs are not available in the properties of a user account in the Active Directory Users and Computers MMC snap-in after you install Remote Server Administration Tools (RSAT) on a computer that is running Windows Vistahttp://support.microsoft.com/default.aspx?scid=kb;EN-US;960890
If you have been hacking away at this previously to make it work, make sure to unregister and remove your server DLL's before installing this update.
Linda Taylor rules.