1

Lets say you have a user in AD. They get all sorts of rights granted over time. They also get access in a remote domain that trusts your domain, to resources.

Then they leave the company and you delete their object. The deleted object becomes a tombstone object, which is meant to preserve the SID in case you wish to 'undelete' them, sort of.

So what happens to the ACE's that had their SID in it? Within the domain, my guess is after the tombstone expires it will get cleaned up. Since after all, what is the point of preserving the SID if all references to it are already gone.

What happens to the ACE's in the remote trusting domain? How does it clear up orphaned SIDs in ACE's and whatnot?

geoffc
  • 2,135
  • 5
  • 25
  • 37

1 Answers1

2

So what happens to the ACE's that had their SID in it?

Any ACL containing an ACE for a deleted user will display the orphaned SID instead of user name. This ACE will not be removed after the tombstone lifetime.

Within the domain, my guess is after the tombstone expires it will get cleaned up. Since after all, what is the point of preserving the SID if all references to it are already gone.

The ACE is, itself, and explicit reference to the SID. An orphaned SID's ACE will remain "forever" in the ACL unless removed.

What happens to the ACE's in the remote trusting domain? How does it clear up orphaned SIDs in ACE's and whatnot?

Same situation as above. There is no automatic "clean-up" of which I am aware.

This "problem" is one of the many reasons for granting permissions/delegations per group rather than per user for most everything. When the users leaves the company, you delete their user object. Granting their replacement the same permissions throughout the domain is as simple as adding the new hire into the existing group.

jscott
  • 24,204
  • 8
  • 77
  • 99
  • +1 for 'This is one of the reasons you never apply a user directly to an object's ACL' – Chris Thorpe Nov 04 '10 at 12:04
  • @Chris: Never is such an absolute. While you generally never want to assign permissions on a user basis, there are cases when that's necessary. – joeqwerty Nov 04 '10 at 12:28
  • @joeqwerty: Yes. Our most common exception, using per-user ACEs, is for user profile directories. – jscott Nov 04 '10 at 12:35
  • Or My Documents redirection, or user home directories, etc., etc. ;) – joeqwerty Nov 04 '10 at 12:42
  • However, if you delete a group, same exact problem. All you do by using Groups instead of Users is make it a smaller problem set. – geoffc Nov 04 '10 at 12:45
  • 1
    @geoffc You model your AD groups after your company's required roles/positions. You populate the groups with the user(s) which fulfill those roles. You should only need to delete the group when the role/position is eliminated. So it's a *less frequent* "problem". However ACLs are not self-cleaning regardless of the object type (user, group, computer, etc) in the ACE. – jscott Nov 04 '10 at 12:53
  • @jscott but of course things change. The only certainty in life is change. That just seems like a really short sighted design decision. AD has backlinked attributes (References) that can clean themselves up already, shame they did not implement it for SID's in ACEs as well. – geoffc Nov 04 '10 at 13:08
  • @joe quite right, sorry about that. I have a tendency to deal in absolutes :D – Chris Thorpe Nov 04 '10 at 21:25
  • @Chris: I absolutely understand ;) – joeqwerty Nov 04 '10 at 22:27