Netwrix Auditor 
Netwrix Change Tracker 
Netwrix Data Classification 
Netwrix Password Policy Enforcer 
Netwrix Password Secure 
Netwrix Password Reset 
Netwrix PolicyPak 
Netwrix Privilege Secure 
Netwrix StealthAUDIT 
Netwrix StealthDEFEND 
Netwrix StealthINTERCEPT 
Netwrix Recovery for Active Directory 
Netwrix Usercube 
Netwrix GroupID 
Netwrix Strongpoint 
Active Directory Group Management Best Practices
Using Microsoft Active Directory groups is the best way to control access to resources and enforce a least-privilege model. It also enables you to more easily enumerate permissions to any resource, whether it’s a Windows file server or a SQL database.
Group Scopes
Which objects you can add to an AD group depends on that group’s scope.
- Local groups are truly local. They are created, defined on and available only to the specific computer they were created on. Don’t create new local groups on workstations; in most cases, the Users and Administrators groups are the only two local groups to manage.
- Domain local groups should be used to manage permissions to resources because this group can be applied everywhere in the domain. A domain local group can include members of any type in the domain and members from trusted domains. For example, suppose you need access management for a collection of folders on one or more servers that contain information for managers. The group you create for that purpose should be a domain local group (ex. “DL_Managers_Modify”).
- Universal groups in Active Directory are useful in multi-domain forests. They enable you to define roles or manage resources that span more than one domain. Each universal group is stored in the domain of where it was created, but its group membership is stored in the Global Catalog and replicated forest-wide. Don’t use universal groups if you have only one domain.
- Global groups are used primarily to define collections of domain objects (users, other global groups and computers) based on business roles, which means that they mostly serve as role groups. Role-based groups of users (such as “HR” or “Marketing”) and role-based groups of computers (such as a “Marketing Workstations”) are usually global groups.
Active Directory Nested Groups Best Practices.
As the table above illustrates, a group can be a member of another group; this process is called nesting. Nesting helps you better manage and administer your environment based on business roles, functions and management rules.
- User and computer accounts should be members of global groups that represent business roles, such as “Sales” or “HR”. Those global groups should be members of domain local groups that represent management rules — determining who has access to what, for example. These domain local groups are granted access to resources. In the case of a shared folder, access is granted by adding the domain local group to the folder’s access control list (ACL) with permissions that provide the appropriate level of access.
- In other words:
- Add user and computer accounts to a global group.
- Add the global group to a universal group.
- Add the universal group to a domain local group.
- Apply Active Directory security group permissions for the domain local group to a resource.
- The accounts in the original global group will have access to the resource based on the permissions applied to the domain local group.
Difference Between Security and Distribution Groups
Active Directory security groups and AD distribution groups are different things. For example, you can use security groups to assign permissions to shared resources and Active Directory distribution groups to create e-mail distribution lists in an Exchange environment. The technology is that when a user "logs on" to a computer, the machine creates the user's "access token". Access token contains all security group SIDs (security IDs) that the user is member of. SIDs of distribution groups are not included. To make it simple - you cannot assign permissions to distribution groups and even if you do so this would make no effect at all.
Group Management Tips
- Before starting group management tasks, configure Active Directory auditing capabilities in order to log group additions, deletions and membership modifications. This can be done using either native or third-party tools like Netwrix Auditor for Active Directory.
- Create a global group for each role or department (Sales, Marketing, Managers, Accountants, etc.).
- Implement standard naming conventions across your organization to make identifying critical information about a group much easier. Group names can include critical details about the group, such as the level of access, type of resource, level of security, group scope, mail capability, etc. for example, the group name “DL_Managers_Modify” means that for the selected folder, managers should have only modify permissions.
- Organize groups in an easy-to-understand way, such as by geography or managerial hierarchy. Use group descriptions to completely describe the purpose of the group.
- IT departments are often reluctant to give up AD group management responsibilities, but they're really the last people who should have them. Groups should be managed by the employees who own the content governed by the groups, not by IT staff members with limited visibility into the group's purpose. When the IT department refuses to give up control, it not only bogs down IT resources but also takes power away from the people who should own and manage their groups.
- Employees should be empowered to add themselves to appropriate groups without having to go through the IT department and be added manually. Choose a self-service group management software solution that has a membership workflow feature: Users request membership in the groups they need, and the group owners receive notifications and can either approve or deny the request with the click of a button.
- In most cases, group membership should be defined dynamically by information such as rules, AD attributes, and employee and contractor data in your HR information system or project databases. You can use these data sources to make dynamic groups, which are always up to date. For example, if an employee is removed from the HR system, then that user’s account will automatically be removed from the dynamic groups that base their membership on that system.
