I have a case, where a user once had access to a directory and that user has been removed now. In fact their account has been deleted out of the AD entirely.
Typically when one sees a user deleted, but having an explicit ACL defined on a directory, then their will be a SID left behind noting the ACL is there, and no longer has reference to all of the other AD attributes like name, etc. Essentially an orphaned ACL entry, left there I assume by design in case you needed to undelete the user.
However I have a case of something different, if I look at the directory properties / security tab, the user in question nor the SID of the user is present.
However if I check the access property of object returned by the CMDLET Get-ACL I get a different result.
If I execute the command on the file server, I actually get the DOMAIN\username having an explicit permission
If I run the exact same command on the same directory from another server (like the domain controller) I get the samne list, but in all other instances than local, the user shows up as the SID. So I have to assume that the file server simply has his SID to UN cached somewhere, this accounts for that variance, however it does not account for the fact that the security tab does not show this same permissions entries.
Worse still, is if I go multiple levels deeper, and check sub objects of this directory using powershell, I see the same results, this permission defined, but only in powershell, windows still shows nothing.
So I went for a third opinion and used accessenum from sysinternals, it does NOT show the extraneous ACL, however CALCS does! so now we are back to a 1-1 ratio of does/does not have the setting with no evidence to support the validity of either.
The directory is directly on the root of a drive, no method powershell, CACLS, etc show this permission defined on the drive itself, nor do I have any reason to suspect it would have been in the past.
I am hesitant to try and do something like remove the ACL with powershell or CACLS without understanding what is going on here. Likewise, the typical enforce ownership/inheritance down the directory tree, remove all permissions and redefine will be a huge undertaking because there is a large file structure UNDER this directory whose ACLs fork many places.
Just to make sure I was not dealing with disk corruption or invalid data, I did a CHKDSK on the drive in question, which reported no error.
I am thinking this either has to be a bug, or corruption somewhere, but at a loss for where to look further, maybe hex editor on the disk itself?
So have I found some bug, error, or just overlooking something glaringly obvious?
