http://www.minasi.com/forum/topic.asp?TOPIC_ID=16842
Basically here's what happens, and why it doesn't get cleaned up. Apologies if some of this is too basic.1) Accounts and SIDS in a domain: typically you create a user account or a group not locally but on a domain controller. Every user account has a number of characteristics, but the two we're interested in here are:
SID -- Security ID, a UNIQUE identifier for a user account. Looks like S-1-5-21-8989239-232787-1321897-1079 or something like that. The S-1-5-21 shows up on all user accounts, the three big numbers following that are common for all SIDs in a given domain, and the final number (1077) is the only thing about YOUR SID that is different from everyone ELSE's SIDS in the domain.
The important part is that THIS is your true name on the domain.
Friendly Name -- the Microsoft word for what you call yourself. So while I might think that my account name is "mminasi," and if I log in as "mminasi," as far as Windows cares this is nothing more than window dressing, a mildly interesting characteristic about me, like my height, weight, eye color or the like.
2) Permissions:
Permissions are created and stored on the object that they refer to. So, for example, let's say that I've got a DC named DC1 and a member server called MS1. Suppose further that I create a share called STUFF on MS1, and a global group on the domain called COOLGUYS. I want only COOLGUYS to be able to access \ms1stuff.
So I go to the MS1 server and tell it either via GUI, NET SHARE or whatever to create an access control entry that says "the global group COOLGUYS has Full Control of the STUFF share."
Let's review what's happened under the hood.
COOLGUYS: this is a thing that lives on DC1, as it's a domain group. It has, let us say, a SID of S-1-5-21-8989239-232787-1321897-1115 and, of course, a friendly name of COOLGUYS.
STUFF share: lives on MS1. Sitting somewhere on MS1 is a piece of information called an "access control entry" or ACE saying "the account with SID S-1-5-21-8989239-232787-1321897-1115 has full control of the STUFF share."
Notice two things there. First, DC1 knows NOTHING about the share. Data on that share, including its permissions, are all stored locally on the member server. Second, the information on MS1 DOES NOT CONTAIN THE FRIENDLY NAME OF COOLGUYS. All it remembers is the SID.
So now let's suppose you decide to fire up Explorer while sitting at MS1 and take a look at the permissions on share STUFF. What happens? MS1 says "dang, that user person wants to see the share permissions, but I'm not supposed to show him that SID thing. Gotta look up the friendly name, so I'll open hailing frequencies to DC1 and ask him... ah, he tells me that it's 'COOLGUYS,' so I'll report that."
But what if DC1 doesn't respond? Then MS1 just shows you the SID next to an empty user head (no jokes here please<g>) with a question mark in the head. Sometimes you will see that change to a normal head and a friendly name before your very eyes, if the network clears up and the member server finally gets the friendly name.
Let's keep "but"-ing...
What if you, the domain admin, delete the COOLGUYS group? Then the object's gone from DC1. Does DC1 give MS1 a heads-up on this? Nope, it can't... remember, the domain basically doesn't know anything about the share, so it couldn't if wanted to. (Yes, you can publish a share in AD but that doesn't change things.)
So now what happens when you go to look at the permissions on \MS1STUFF? Simple: MS1 asks DC1 for S-1-5-21-8989239-232787-1321897-1115's friendly name, and never gets an answer. Result: empty heads.
Subinacl will optionally do a friendly name lookup for every ACE on a system, and delete any ACEs that cannot produce a friendly name. Clearly you should only do this when the connectivity to the DC is good!<g>
Again, sorry if some of that was basic but I hope it helped someone.