This article describes an issue that occurs when you resolve SIDs on Windows Server 2012 R2 domain controllers. A hotfix is available to resolve this issue. This hotfix has a prerequisite.
Symptoms
This issue occurs when the following conditions are true:
-
You migrate the object, such as a groups or a user, to another domain and then migrate them back to the original domain. For more information, see the detailed explanation of the issue.
-
You use the PsGetSid tool to look up the security identifier (SID) against a Windows Server 2012 R2 DC.
Additionally, when you view file permissions on a computer that connects to a Windows Server 2012 R2 domain controller, the file permissions show SIDs instead of user or group names.Note If you use the PsGetSid tool to look up the same SID against a Windows Server 2008 R2 DC, the SID is resolved successfully.
Cause
This issue occurs because Windows Server 2012 R2 DCs cannot resolve the SID from the SID history.
Resolution
To resolve this issue, install the hotfix on Windows Server 2012 R2 DCs.
Hotfix information
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. If the hotfix is available for download, there is a "Hotfix Download Available" section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix. Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:
http://support.microsoft.com/contactus/?ws=supportNote The "Hotfix Download Available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Prerequisites
To apply this update, you must have update 2919355 installed in Windows Server 2012 R2.
Registry information
To use the hotfix in this package, you do not have to make any changes to the registry.
Restart requirement
You may have to restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace a previously released hotfix.
The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.
Windows Server 2012 R2 file information and notes
Important Windows 8.1 hotfixes and Windows Server 2012 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under "Windows 8.1/Windows Server 2012 R2" on the page. Always refer to the "Applies To" section in articles to determine the actual operating system that each hotfix applies to.
-
The files that apply to a specific product, milestone (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table:
Version
Product
Milestone
Service branch
6.3.960 0.17 xxx
Windows Server 2012 R2
RTM
GDR
-
GDR service branches contain only those fixes that are widely released to address widespread, critical issues. LDR service branches contain hotfixes in addition to widely released fixes.
-
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the "Additional file information" section. MUM, MANIFEST, and the associated security catalog (.cat) files, are very important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x64-based versions of Windows Server 2012 R2
|
File name |
File version |
File size |
Date |
Time |
Platform |
|---|---|---|---|---|---|
|
Lsadb.dll |
6.3.9600.17564 |
198,144 |
06-Jan-2015 |
05:23 |
x64 |
Additional file information
Additional file information for Windows Server 2012 R2
Additional files for all supported x64-based versions of Windows Server 2012 R2
|
File property |
Value |
|---|---|
|
File name |
Amd64_e4945a4e0ffd3c6d2035f11f29d5fcee_31bf3856ad364e35_6.3.9600.17566_none_dfccd51a6738b404.manifest |
|
File version |
Not applicable |
|
File size |
715 |
|
Date (UTC) |
08-Jan-2015 |
|
Time (UTC) |
07:46 |
|
Platform |
Not applicable |
|
File name |
Amd64_microsoft-windows-d..ctoryservices-lsadb_31bf3856ad364e35_6.3.9600.17566_none_8e0c2c42b1f2e3b5.manifest |
|
File version |
Not applicable |
|
File size |
8,666 |
|
Date (UTC) |
08-Jan-2015 |
|
Time (UTC) |
00:31 |
|
Platform |
Not applicable |
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.
More Information
Detailed explanation of the issueConsider the following scenario:
-
You have Windows 2012 R2 domain controllers in the environment.
-
You migrate an object, such as a group or a user that has an "X" object SID, from domain A to domain B. Therefore, the object obtains a new "Y" object SID, and the sIDHistory attribute of the object contains the "X" object SID from domain A.
-
You migrate the object back to domain A. In this situation, the object obtains a new "Z" object SID. The sIDHistory attribute of the object contains the "X" object SID from domain A and the "Y" object SID from domain B.
-
You have resources that are permitted by the original "X" object SID of the object in domain A.
In this scenario, the "X" object SID of the object is not resolved. Therefore, the file permissions show the SID.Note Access to the resources that are permitted by the original "X" object SID still works and is not affected. However, you cannot read and determine permissions of the resources because the SIDs are not resolved to object names.
