Saturday, July 31, 2010

Authoritative restore of groups can result in inconsistent membership information across domain controllers

http://support.microsoft.com/kb/280079

Article ID: 280079 - Last Review: December 3, 2007 - Revision: 11.4

System TipThis article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you.Visit the Windows 7 Solution Center
This article was previously published under Q280079
Expand all | Collapse all

SYMPTOMS
After you perform an authoritative restore of users and groups, the membership i...

After you perform an authoritative restore of users and groups, the membership in the restored groups may be inconsistent across domain controllers.

If the group is empty on the restored domain controller, but is populated on a replica domain controller, then when a user is added to the group on the restored domain controller, users are removed from the group on the replica domain controllers.

The same behavior may occur with the ManagedBy attribute, which may be empty after an authoritative restore.

For additional information about these types of issues, click the following article number to view the article in the Microsoft Knowledge Base:
840001 (http://support.microsoft.com/kb/840001/ ) How to restore deleted user accounts and their group memberships in Active Directory


Note KB article 840001 supersedes this article.

CAUSE
This issue can occur because group membership is stored as the Member attribute...

This issue can occur because group membership is stored as the Member attribute on the group object. When a security principal (user, group, or computer) is added to a group, a backlink is added to the MemberOf attribute on the principal's object. During an authoritative restore, if the group object is restored before the user object, then Active Directory removes the value from the Member attribute on the group because a user does not exist that has a matching backlink.

After the authoritative restore, the version information on the Member attribute of the restored groups is consistent on each domain controller, even though the values in that attribute are not. Whenever the membership of the group is modified, the version number is incremented, and the contents of that group are replicated out to all domain controllers. If the group is modified on a domain controller that has a valid group membership, then the complete contents of the group are replicated, and data is not lost. However, if the group is modified on the restored domain controller, then only the added users are replicated, and users are removed from the group on the replica domain controllers.

Note This issue may occur even if the users are authoritatively restored and the groups are not. If a System State restore is done and only users are marked as authoritative, their group membership will be restored on the domain controller that the restore was done on (because the forward links in the group objects would have been restored in the System State restore). If the membership of the groups has not changed since the System State backup was done, no replication for the groups will be done after the restore. This results in inconsistent group membership between domain controllers. Changing the membership to the group on one domain controller will replicate the current contents of that group on that domain controller to the other domain controllers.

RESOLUTION
Warning: Read the following information carefully before you perform the procedu...

Warning: Read the following information carefully before you perform the procedure described in this section. User and group information can be irretrievably lost if you do not follow this procedure exactly. Remember to make and verify a backup file of Active Directory on the authoritative domain controller before you proceed.

To resolve this issue, all security principal objects (users, groups, and computers) must be authoritatively restored and replicated out to all domain controllers, and then all group objects must be authoritatively restored and replicated out to all domain controllers again. When you use this procedure, all potential group members (users, groups, and computers) are in the database before the second restore, and the backlinks are maintained.

When you authoritatively restore user accounts and their group memberships, find a domain controller with sufficient information to be marked as authoritative, and then disconnect that domain controller from the network. This server becomes the authoritative domain controller.

To resolve this issue:
  1. Perform a full backup of the computer state to back up this authoritative copy of Active Directory in case an error occurs during this procedure.
  2. Disable both intra-site and inter-site topology generation. For additional information about how disable intra-site and inter-site topology, click the article number below to view the article in the Microsoft Knowledge Base:
    242780 (http://support.microsoft.com/kb/242780/EN-US/ ) How to Disable the Knowledge Consistency Checker From Automatically Creating Replication Topology
  3. Start the Active Directory Sites and Services snap-in, and then delete all the connection objects under the NTDS Settings object for the authoritative domain controller.

    When you complete this step, the domain controller is prevented from replicating any changes during this procedure. The replication partners of the authoritative domain controller still have connection objects that point to that server that enable them to pull the authoritative data from the server.
  4. Restart the computer into Active Directory Restore mode.
  5. Authoritatively restore each required account individually. For example, to restore James Smith's user account in the Accounting organizational unit in NWTRADERS.MSFT, use the following syntax:
    authoritative restore: restore subtree "cn=James Smith,ou=Accounting,dc=nwtraders,dc=msft"
    Note: Because the Ntdsutil tool can be scripted, you can generate a list of user accounts to be restored and then pass that to your script. A sample script is described in the "More Information" section in this article.

    You can also restore a whole OU here if it mostly contains users and groups.
  6. Restart the computer into Normal mode.
  7. Allow the restored users to replicate normally.

    To force partners to replicate from the authoritative domain controller, use either the ReplMon tool, or the Active Directory Sites and Services snap-in.
  8. When the users are replicated to all domain controllers, restart the computer into Active Directory Restore mode.
  9. Authoritatively restore each group account that contained the previously restored objects. For example, to restore the Web Administrator group in the ITG organizational unit in NWTRADERS.MSFT, use the following syntax:
    authoritative restore: restore subtree "cn=Web Administrator,ou=ITG,dc=nwtraders,dc=msft"
    Note: Because the Ntdsutil tool can be scripted, you can generate a list of groups to be restored and then pass that to your script. A sample script is described in the "More Information" section in this article.
  10. Restart the computer into Normal mode.
  11. Allow the restored groups to replicate normally.

    To force partners to replicate from the authoritative domain controller, use either the ReplMon tool, or the Active Directory Sites and Services snap-in.
  12. Undo the changes on the site object that you made in step two of this procedure.

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that ar...

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

MORE INFORMATION
After the authoritative domain controller has been unplugged from the network, y...

After the authoritative domain controller has been unplugged from the network, you can run the following script before the computer is started into Active Directory Restore mode to get the list of users:
List.vbs
--------
Set strOU = GetObject("LDAP://localhost/ou=layer two,ou=layer one,ou=test,dc=i,dc=j,dc=com")
strOU.Filter = Array("user")

For Each Member in strOU
Wscript.Echo Chr(92) & Chr(34) & member.distinguishedname & Chr(92) & Chr(34)
Next
Note: Make sure that you change the organizational unit path in the first line to point to the path that contains the users and groups to be restored. Also, you can use this same script to create a list of either users or groups.

To list groups, change the filter in the second line to:
oU.Filter=Array("group")
To run this script and get the output to a text file, type the following command at the command prompt (run this command in the same folder as the script):
cscript //nologo list.vbs > users.txt
After you have created the list of users and the list of groups, you can use Ntdsutil to authoritatively restore each entry:
Authrest.cmd
------------
@echo off
ntdsutil "popups off" "authoritative restore" "restore subtree %1" quit quit
To run this script for every entry in the list of users or groups, use the for command to read the entry in the list and pass it to the batch file described earlier. Type the following command at the command line (create these files in the same folder as the two text files that you created earlier):
for /f "tokens=*" %i in (users.txt) do authrest %i
This command loops through each line of the text file and authoritatively restores the user.

APPLIES TO
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Server
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Keywords:
kbprb KB280079

No comments:

Post a Comment