CRS Replicates ACEs of Deleted Accounts During ACL Replication

• Microsoft Commercial Internet System, version 1.0

SYMPTOMS

If an account that is granted permissions on a file is deleted, the corresponding SID is marked as "deleted" in the 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 SID still exists in the ACL of the file. The SID will continue to exist in the 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 attempt 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. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

Version           : 1.0
Platform          : WINDOWS
Issue type        : kbbug