Group Policy Settings Are No Longer Applied to the Original Windows NT 4.0 Group After You Migrate the Group to Active Directory (328448)


The information in this article applies to:

  • Microsoft Windows 2000 Advanced Server SP3
  • Microsoft Windows 2000 Advanced Server SP2
  • Microsoft Windows 2000 Advanced Server SP1
  • Microsoft Windows 2000 Server SP3
  • Microsoft Windows 2000 Server SP2
  • Microsoft Windows 2000 Server SP1
This article was previously published under Q328448

SYMPTOMS

After you migrate group and user accounts from a Microsoft Windows NT 4.0 domain to the Microsoft Active Directory directory service in a Windows 2000 domain, user rights that you configured for members of a Windows NT 4.0 group by using Group Policy settings are no longer applied to members of that original Windows NT 4.0 group.

CAUSE

This problem occurs if both of the following conditions are true:
  • You use the Local Security Settings policy editor (Secedit.msc) on the local Windows 2000 server to apply user rights settings to the Windows NT 4.0 group.

    -and-
  • You migrate the Windows NT 4.0 accounts by using the migrate sIDHistory option, and both the source and the target accounts are enabled.

    Note When you use the migrate sIDHistory option, this migrates the account SID history into the sIDHistory attribute in Active Directory.

RESOLUTION

Service Pack Information

To resolve this problem, obtain the latest service pack for Microsoft Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

260910 How to Obtain the Latest Windows 2000 Service Pack

Hotfix Information

A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next Windows 2000 service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=support

NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel. 

Date         Time   Version            Size    File name
-----------------------------------------------------------
16-Feb-2003  20:30  5.0.2195.6613     124,176  Adsldp.dll
16-Feb-2003  20:30  5.0.2195.6601     130,832  Adsldpc.dll
25-Feb-2003  14:02  5.0.2195.6667      62,736  Adsmsext.dll
16-Feb-2003  20:30  5.0.2195.6660     377,616  Advapi32.dll
16-Feb-2003  20:30  5.0.2195.6611      49,936  Browser.dll
16-Feb-2003  20:30  5.0.2195.6663     135,952  Dnsapi.dll
16-Feb-2003  20:30  5.0.2195.6663      96,528  Dnsrslvr.dll
16-Feb-2003  20:30  5.0.2195.6661      46,352  Eventlog.dll
16-Feb-2003  20:30  5.0.2195.6627     148,240  Kdcsvc.dll
20-Feb-2003  20:11  5.0.2195.6666     204,560  Kerberos.dll
02-Dec-2002  23:09  5.0.2195.6621      71,888  Ksecdd.sys
24-Jan-2003  18:40  5.0.2195.6659     509,712  Lsasrv.dll
24-Jan-2003  18:41  5.0.2195.6659      33,552  Lsass.exe
05-Feb-2003  12:59  5.0.2195.6662     109,328  Msv1_0.dll
16-Feb-2003  20:30  5.0.2195.6601     312,592  Netapi32.dll
16-Feb-2003  20:30  5.0.2195.6627     360,720  Netlogon.dll
25-Feb-2003  14:02  5.0.2195.6669     929,552  Ntdsa.dll
25-Feb-2003  14:01  5.0.2195.6666     392,464  Samsrv.dll
25-Feb-2003  14:01  5.0.2195.6671     131,344  Scecli.dll
25-Feb-2003  14:01  5.0.2195.6671     306,448  Scesrv.dll
10-Feb-2003  19:22  5.0.2195.6663     166,912  Sp3res.dll
16-Feb-2003  20:30  5.0.2195.6601      51,472  W32time.dll
16-Aug-2002  09:32  5.0.2195.6601      57,104  W32tm.exe
25-Feb-2003  14:01  5.0.2195.6666     125,200  Wldap32.dll
24-Feb-2003  19:24  5.0.2195.6659     509,712  Lsasrv.dll   56-bit


WORKAROUND

To work around this problem, do not use the Local Security Settings policy editor on the local server to assign user rights for the Windows NT 4.0 group. Instead, configure the Group Policy settings as computer policies. To do this, add the server to an organizational unit, and then create a Group Policy object in the organizational unit to apply the Group Policy settings to the server. When the user account is migrated together with the sIDHistory attribute, the user rights assignments policy is applied to both the source and the target accounts.

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft Windows 2000 Service Pack 4.

MORE INFORMATION

The following sample scenario demonstrates this problem in greater detail:
  1. You have a member server that is named example.com in a Windows 2000 domain, and you want to configure access for administrative users from a Windows NT 4.0 domain.
  2. In a Windows NT 4.0 domain that is named domain, you create a group that is named admingroup.
  3. On the Windows 2000-based member server, you create a local security policy to grant the "Log on locally" user right to members of the Windows NT 4.0 domain\admingroup group (by using a trust). Members of the Windows NT 4.0 admingroup group are now permitted to log on locally to the Windows 2000 member server.
  4. You migrate to Active Directory the Windows NT 4.0 group and the Windows NT 4.0 user accounts that have the sIDHistory attribute and that also have both the source and the target accounts enabled. This is a typical scenario when administrators are migrated.
After the migration process is complete, the policy displays "example\admingroup" as the group that the user rights assignments apply to when you view the local security policy that you created. This is an expected behavior because the Local Security Settings utility resolves the SID in the access control entry (ACE) to the newly migrated group name instead of to the original group in the former domain (domain\admingroup). For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

307521 An Access Control Entry May Seem to Be Displayed Incorrectly with the sIDHistory Attribute

However, an unexpected issue occurs where the policy settings that you configured are no longer applied to members of the source group (in this case, domain\admingroup). This means that members of the example\admingroup Windows 2000 group can log on locally, although members of the original domain\admingroup Windows NT 4.0 group cannot. Additionally, members of the original domain\admingroup Windows NT 4.0 group who were not migrated can no longer log on locally to the Windows 2000 server. For additional information about how to obtain a hotfix for Windows 2000 Datacenter Server, click the article number below to view the article in the Microsoft Knowledge Base:

265173 The Datacenter Program and Windows 2000 Datacenter Server Product

Modification Type:MinorLast Reviewed:10/10/2005
Keywords:kbHotfixServer kbQFE kbWin2kSP4fix kbWin2000preSP4Fix kbfix kbbug KB328448 kbAudITPRO
©2004 Microsoft Corporation. All rights reserved.