ID: Q164802
The information in this article applies to:
If an account that is granted permissions on a file is deleted, the corresponding SID is marked as "deleted" in the Microsoft Windows NT security accounts manager (SAM). However, even though the permissions will not show up for that account in File Manager or Windows Explorer, that same Windows NT security identifier (SID) still exists in the ACL of the file. The SID will continue to exist in the access control list (ACL) until any permissions are modified on the file. When this ACL is replicated, Content Replication Server (CRS) will treat the access control entry (ACE) like any other and will try to find a valid SID for the ACE at the target computer.
If you use the SAM of the deleted account when assigning a valid SID, there is no problem. However, if the file is replicated to a computer running Windows NT Workstation or non-trusted domain, the SID for a local account of the same name may still get assigned to the ACL.
In addition, if the ACE is an access denied ACE, all the ACEs in the ACL will be stripped, and the Administrator will be given full control. This is expected behavior for any access denied ACEs that cannot find a valid SID on the destination computer.
The Winsock function controlling this has been corrected in the smail.dll file. To fix, install MCIS 1.0 Service Pack 1, which will update the smail.dll file. Now, CRS strips the SIDs of deleted accounts from the ACL at the source, before replicating the ACL.
Microsoft has confirmed this to be a problem in Microsoft Commercial Internet System version 1.0. This problem has been corrected in the latest U.S. Service Pack for Microsoft Commercial Internet System version 1.0. For information on obtaining the Service Pack, query on the following article in the Microsoft Knowledge Base:
ARTICLE-ID: Q183062
TITLE : MCIS 1.0 Service Packs 1 and 2 Information
Version : WINNT:1.0
Platform : winnt
Hardware : ALPHA x86
Issue type : kbbug
Solution Type : kbfixLast Reviewed: April 16, 1998