Group Policy User Rights Assignment Registry

I'm trying to get some software installed on my company laptop (Business Intelligence SSDT for Visual Studio). As a developer, I have administrator rights, and have never run into an issue installing software before. The software has been approved by my company.

SSDI needs to install Microsoft SQL Server Data Tools, which fails during setup due to "Rule 'Setup account privileges' failed." I've traced this issue back to a group policy setting for "Debug programs":

  • Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment

In the list of policies, the "Debug programs" security settings does not have "Administrators" listed. And although I am part of the administrators group, I am unable to add groups to this policy.

Is there some way I can "temporarily" disable or remove these group settings, install the software I need, then re-enable everything afterwards? Or better yet - add the administrator group to the policy?

I've seen several options, but I don't want to proceed with half-baked ideas that could affect my laptop's access to the company network.

For example, could I:

  1. Right-click into my Local Computer Policy > Properties, and select the option to "Disable Computer Configuration settings"?
  2. Edit the registry to remove group policy settings?
  3. Create a non-domain user (a true "local admin" user?) that has no GPO restrictions, disconnect from any network, and install the software from there?

Are there risks to the above options that I would not be able to reverse myself? Or are there other better options?

Side note: My first step troubleshooting this was to contact my system admin, who informed me that I should have "full control" over all my local policies, including the "Debug programs". According to him, there should be no permission / group policy restrictions for administrators.

His thought is that the issue is coming from some sort of permission (or as he put it, "sysadmin" access) to our SQL servers, and he would have to reach out to the server team and get back to me in a few days. I have permission to "explore" my own solutions in the mean time.


These are the nine types of Group Policy security features mentioned previously in this chapter. They are containers located in the Security Settings node of a Group Policy object. They include:

  • Account Policies

  • Local Policies

  • Event Log

  • Restricted Groups

  • Systems Services

  • Registry

  • File System

  • Public Key Policies

  • Internet Protocol Security Policies on Active Directory

Some of the policy areas apply only to the scope of a domain, that is, the policy settings are domain-wide. Account policies, for example, apply uniformly to all user accounts in the domain. You cannot define different account policies for different organizational units in the same domain.

Of the security policy areas, Account policies and Public Key policies have domain-wide scope. All other policy areas can be specified at level of the organizational unit.

Account Policies

Account policies are the first subcategory of Security Settings. The Account policies include the following:

Password Policy    You can modify password policy to meet your organization's security needs. For example, you can specify minimum password length and maximum password age You can also require complex passwords and prevent users from reusing passwords or simple variations of passwords.

Account Lockout Policy    You can force users to be locked out after a specified number of failed logon attempts. You can also specify the period of time that accounts are frozen.

Kerberos Authentication Policy    You can modify the default Kerberos settings for each domain. For example, you can set the maximum lifetime of a user ticket.

The policies you choose affect the level of help desk support required for users as well as the vulnerability of your network to security breaches and attacks. For example, specifying a restrictive account lockout policy increases the potential for denial of service attacks, and setting a restrictive password policy results in increased help desk calls from users who cannot log on to the network.

In addition, specifying restrictive password policy can actually reduce the security of the network. For example, if you require passwords longer than seven characters, most users have difficulty remembering them. They might write their passwords down and leave them where an intruder can easily find them.

Top Of Page

Local Computer Policies

The second subcategory of Security Settings is Local Computer policies. Local Computer policies include the following:

Audit Policy    Windows 2000 can record a range of security event types, from a system-wide event, such as a user logging on, to an attempt by a particular user to read a specific file. Both successful and unsuccessful attempts to perform an action can be recorded.

User Rights Assignment    You can control the rights assigned to user accounts and security groups for local computers. You can specify users and security groups who have rights to perform a variety of tasks affecting security. For example, you can control who can access computers from the network, who can log on locally, or who can shut down the system. You can specify who has rights to perform critical administrative tasks on the computer, such as backing up and restoring files and directories, taking ownership of files and objects, and forcing shutdown from a remote system.

Security Options    You can control a wide variety of security options for local computers. For example, you can specify policies that force users to log off when logon hours expire, disable CTRL+ALT+DEL for logon (to force smart card logon), and force computers to halt if unable to audit.

Top Of Page

Event Log Policies

You can use Event Log policies to control the settings of the application, system, and security event logs on local computers. For example, you can specify maximum log sizes, how long logged events are maintained, and log retention methods.

Top Of Page

Restricted Groups Policies

You can define Restricted groups policies to manage and enforce the membership of built-in or user-defined groups that have special rights and permissions. Restricted Groups policies contain a list of members of specific groups whose membership are defined centrally as part of the security policy. Enforcement of Restricted Groups automatically sets any computer local group membership to match the membership list settings defined in the policy. Changes to group membership by the local computer administrator are overwritten by the Restricted Groups policy defined in Active Directory.

Restricted Groups can be used to manage membership in the built-in groups. Built-in groups include local groups such as Administrators, Power Users, Print Operators, and Server Operators, as well as global groups such as Domain Administrators. You can add groups that you consider sensitive or privileged to the Restricted Groups list, along with their membership information. This allows you to enforce the membership of these groups by policy and not allow local variations on each computer.

Top Of Page

Systems Services Policies

System services offer a mechanism for potential exploitation by intruders, who can take over the service or use the service as an entry point to gain access to computers and network resources. For example, an intruder can try to exploit weaknesses in a running Web server to gain access to a computer's operating system or files. You can use Systems Services policies to:

  • Specify the startup mode for Windows 2000 services (manual or automatic) or to disable services.
    For example, you can configure system services to prevent unnecessary services from running. This provides maximum security for special servers such as domain controllers, DNS servers, proxy servers, remote access servers, and certification authority servers.

  • Specify rights and permissions granted to system services when they run.
    For example, you can configure system services to operate with minimum rights and permissions to limit the scope of potential damage caused by intruders who try to exploit the service.

  • Refine security auditing levels for system services.
    You can specify the type of events to be logged for both failed and successful events. For example, when auditing is enabled, you can refine auditing to monitor for inappropriate actions taken by running services.

Top Of Page

Registry Policies

You can use registry policies to configure security and control security auditing for registry keys and their subkeys. For example, to ensure that only administrators can change certain information in the registry, you can use registry policies to grant administrators full control over registry keys and their subkeys and to grant read-only permission to other users. You can also use registry policies to prevent certain users from viewing portions of the registry.

You can use registry policies to audit user activity in the registry of the computer when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.

Top Of Page

File System Policies

You can use File System policies to configure security for files and folders and control security auditing of files and folders. For example, to ensure that only administrators can modify system files and folders, you can use File System policies to grant administrators full control over system files and folders and to grant read-only permission to other users. You can also use File System policies to prevent certain users from viewing files and folders.

You can use File System policies to audit user activity affecting files and folders when auditing is enabled. You can specify which users and which user events are logged for both failed and successful events.

Top Of Page

Public Key Policies

This subdivision of security settings lets you add a new Encrypted Data Recovery Agent and set up Automatic Certificate Requests. You can also manage your lists of trusted Certification Authorities.

Top Of Page

IP Security Policies on Active Directory

The policies in this section tell the server how to respond to a request for IPSec communications. The server might require secure communication, permit secure communication, or communicate without using IPSec. The predefined policies are not intended for immediate use. They provide examples of behavior for testing purposes. Network security administrators need to carefully design and assign their own custom IPSec policy to computers.

Top Of Page


Leave a Reply

Your email address will not be published. Required fields are marked *