CRS Replicates the Access Control Entries of Deleted Accounts During ACL Replications (164802)

SYMPTOMS

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.

RESOLUTION

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.

STATUS

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:

183062 MCIS 1.0 Service Packs 1 and 2 Information