A. Domain local groups can be defined in and managed from AD. Local groups are defined in the security databases of standalone machines and domain member workstations and servers. Local groups are only meaningful on the local computer for setting permissions on local resources—domain local groups can be used to set permissions on resources domain-wide. Domain local groups cannot be used for setting permissions on resources that are not part of the domain where the domain local group is defined. For that purpose you should use global or universal groups.

I don't recommend using local groups in Windows domain environments. When you use local groups you lose the benefits of using a Windows domain: central control and accountability.

Local groups can't be controlled through AD and don't show up in a user account’s group membership list in the AD Users and Computers (ADUC) snap-in. Also, local group membership changes are logged to a local machine’s security event log, and not to the domain controller’s event log.

Domain local groups can be centrally administered from the ADUC MMC snap-in and changes to domain local groups are logged to the Domain Controllers’ event log. If you want give local resource server administrators control over domain local group memberships, you can delegate them this administrative capability from the ADUC.

As a general best practice for managing access control settings in a Windows domain environment, I recommend you use global groups to group users, use domain local groups to set the permissions on resources, and finally put global groups into domain local groups to apply authorization settings.