How can I check access of a Group/User in AD before I delete it?

I'm cleaning up an inherited domain that is not well documented. How can I check that a particular group or user has no ACEs across the AD?

Things like searching DACL/SACL for AD objects and file server objects. Do administrators even do that kind of due diligence?

[Edit] I can't add comments yet but I want to thank Ben and Jim for their responses. It takes a long time to prepare such thoughtful answers so I respect their generosity and willingness to share their experiences.

Thank you for the list of places to check for AD-based permissions - very helpful.

I appreciated the suggestions to retain empty groups for re-population if access is inadvertently removed. I have already written some C# code to enumerate group membership so I have that backup. (I find it easier to work with than PowerShell.) I also use the sysinternals tools like ShareEnum.

The Notes/Description fields - what are they? Seriously, I know what they are but my predecessors did not use them. Neither did they use nested groups.

This is hard. Very hard. You could do something like write a script to iterate over a filesystem and evaluate permissions but it would be somewhat cumbersome - you'd have to run it on each server and it may take a long time depending on how many files are on the server.

Look at the group members. Are they primarily a group of people from one department? That may point you in the right direction, and if you have a cryptic group name (e.g HSGD Super Users where HSGD is a departmental LOB app) you could ask if it means anything to them.

Check the Notes field of the group to see if it contains anything helpful (hint: that field is VERY useful and I would recommend you use it going forward).

For this to be a thorough check, you're going to have to check other things than filesystem permissions though. Anything that is capable of using Windows permissions will need to be checked, and unfortunately I can guarantee you will forget something (everyone always forgets hardware appliances). Off the top of my head though:

• Filesystem permissions
• SQL Server
• Microsoft Exchange
• Your antivirus software (mainly the server management console, if applicable)
• Scheduled Tasks
• Windows Services
• Active Directory delegated permissions
• Permissions granted on individual workstations for a particular AD user/group
• Backup software logon accounts
• Hardware appliances (authenticates using an AD account)
• Linux machines/services (similarly, a service running on them may use LDAP and authenticate with a dedicated account)
• Any and all LOB apps you use

I should also call out something very important, which is you shouldn't forget a users indirect group memberships from nested groups. Believe me, that's a real kicker - I've done it before.

Finally, I was being somewhat flippant when I said this in a comment to your question, so make what you will of this bit of advice. If you've got a group you want to delete, make a note of the group members and simply take them all out of the group. It's important you don't immediately delete the group because if this group has permissions granted all over the place and you cause serious breakage you will want to quickly fix it by adding everyone back in. If you delete the group, you first have to figure out where the permissions are granted (which you don't know) and apply the exact same permissions as before, which may not be default permissions (again, which you don't know).

Ben's got a good list of things that could go Very Wrong(tm). So no, in general admins don't do proper diligence before deleting files. Usually when taking over a new environment I spent some quality time documenting what groups the users and other admins know about (adding notes and descriptions to AD for each group) then develop a plan to start whacking groups that look obviously unused (empty groups, groups that only contian disabled users etc). After that I start whacking groups starting with groups that only contain users. One handy way to do this is to NOT delete the group but just delete the members after copying the membership to a new group (which I handily call OLD_grouptogetdeleted). The base copy group membership script is on the technet scriptcenter. I haven't bothered converting it to powershell yet. It can be easily modified to remove the members of the source (or stick a note in saying DELETE ME in NOVEMBER (if you so desire). After that I wait about 6 months for the shouting to begin and if it doesn't - I delete the empty group (or you might schedule a task to scan the groups that match the current month in the description field, or delete the ones with NO description...

In a nutshell much like the doctor that pokes your broken nose, watches you yell, then asks if it hurts, sometimes you have to poke the users to get them to tell you if it hurts.