Taking Ownership Remotely May Set Owner Incorrectly

This article was previously published under Q183054
This article has been archived. It is offered "as is" and will no longer be updated.
When you take ownership of a file or directory remotely, it is possiblethat the new owner of the object may not be the user that you would expectit to be. To illustrate the issue, consider the following scenario:

You have two domains, DOMAINA and DOMAINB. There is no trust relationshipbetween them. You log on interactively to a Windows NT client in DOMAINA asa regular domain user, for example, DOMAINA\Fred. You then connect to ashared folder on a server in DOMAINB, using the DOMAINB\Administratorcredentials. At the client, take ownership of a shared file or folder onthe computer in DOMAINB.

When you check ownership of the file at the remote server, you see that theowner is recorded as DOMAINA\Fred. Note that, in order to reproduce thisbehavior, you must know the administrator account name and password forDOMAINB.


If the user attempting to take ownership of the file or folder is a memberof the local administrator's group, you will receive the following error:

The following error occurred applying security information to
\\server\share\directory. This security ID may not be assigned as the
owner of this object. Do you wish to continue.
The client computer does not look up the user name that was used to connectto the remote system. This behavior is inconsistent with file creation; forexample, when you create a file on a remote system having connected in themanner described above, ownership of the file is set to the account withwhose credentials you connected.

Note that this inconsistency is only made possible by the fact that, bydefault, administrators have the Restore Files and Directories(SE_RESTORE_NAME) privilege. Having this privilege allows a process to setthe ownership of the file or folder in this way.
To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack

Alternatively, if the user was a member of the local administrators group,remove him from the local admin group or obtain the above hotfix.
Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.
wrong acl restore

Article ID: 183054 - Last Review: 10/07/2013 21:11:48 - Revision: 1.3

Microsoft Windows NT Server 4.0, Terminal Server Edition, Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows NT Workstation 4.0 Developer Edition, Microsoft Windows NT Server 4.0 Enterprise Edition

  • kbnosurvey kbarchive kbhotfixserver kbqfe kbbug kbfix kbqfe KB183054