Share via

AGPM Least Privilege Scenario

  • Article

Mike here again. A customer recently asked how they should configure their Advanced Group Policy Management (AGPM) server using the least amount of privileges. AGPM Program Manager, Michael Kleef, posted a quick task list on his TechNet blog(https://blogs.technet.com/mkleef/archive/2008/11/18/locking-down-agpm-fit-for-least-privilege.aspx) , but I thought I'd take the opportunity to go into more detail and provided some additional suggestions.

AGPM adds role-based administration, change control, workflow, and granular delegation to Group Policy Management. These features allow you to use AGPM to delegate Group Policy creation, review and deployment to non-administrative users. You can read more information about AGPM by downloading the Advance Group Policy Management Overview whitepaper (https://go.microsoft.com/fwlink/?LinkId=106067).

Least privilege requirements

AGPM least privilege configurations can vary slightly. The variance largely depends on how little of privileges you want to provide to the AGPM Server (actually the service account running the AGPM Service). Regardless, you need to achieve the following four requirements for the AGPM Service to work properly:

  • The AGPM Service account requires full access to the AGPM archive folder
  • The AGPM Service account requires full access to the local computer's temp folder
    (%systemroot%\temp)
  • Full access to GPOs created prior to using AGPM
  • The AGPM Service account must be a member of the Group Policy Creator Owners and Backup Operators Group

The AGPM Service account

There are two options when choosing the AGPM Service account: Local System or an actual domain user account used to run the service. Least privilege scenarios cannot use the Local System account. The AGPM service can only use the Local System account when the service is running on a domain controller. Yes, the AGPM service can run on a domain controller; however, it's highly advisable not to install it on a domain controllers. Domain controllers have a specific purpose in the infrastructure just as Exchange or SQL servers-- domain controllers authenticate users. The last thing you'll want to do is restore a domain controller because your AGPM Server had a problem. I typically suggest naming the service account something intuitive-- like AGPMService.

Archive folder

The AGPM Service requires Full Control of the archive folder. The archive folder is where the AGPM Server keeps a manifest and backups of controlled GPOs. The default archive for AGPM version 3.0 is %ProgramData%\Microsoft\AGPM

Temp folder

The AGPM Service uses GPMC application programming interfaces (APIs) to accomplish many GPO operations. Many of these APIs use the computer's temp folder for temporary storage. You must grant the AGPM Service account Full Control to the computer's temp folder, which is %systemroot%\temp.

Full Access to existing GPOs

AGPM ensures that it has proper ownership and permissions to all controlled GPOs. However, GPOs created before implementing AGPM will not provided adequate permissions to the AGPM Service. For this reason, you'll want give the AGPM Service Full Control to all GPOs that exists prior to implementing AGPM.

Group memberships

The AGPM Service requires membership in two groups: Group Policy Creator Owners and Backup Operators.

Group Policy Creator Owners

By Default, Windows only allows Domain Administrators and Group Policy Creator Owners to create Group Policy objects. The least privilege configuration requires you to make the AGPM Service account a member of Group Policy Creator Owners. Membership in the Group Policy Creator Owners group allows the AGPM service to create Group Policy objects , makes the AGPM Service the owner of the new Group Policy object, and gives it the permissions required to manage the Group Policy object.

Backup Operators

Some of the operations that occur in AGPM mimic the functionality found in backup software. For example, the AGPM service may need to change the owner of a Group Policy object. Granting ownership to a security principal different from yourself is a privileged operations. Including the AGPM service account in the Backup Operators group provides it with the privilege to grant ownership. Backup Operators is a well-known security identifier found on each Windows Server. The AGPM Service attempts to change ownership on Group Policy objects, which are stored on the domain controller. The ownership change operation occurs at the domain controller, so you need to make sure the AGPM Service account is in the Backup Operators group on the domain controllers. Membership to the Backup Operators account on the AGPM Server is not required.

Troubleshooting

You can run across some configuration issue when attempting to configure the AGPM Server in a least privilege scenario. The following are the most common errors seen during an AGPM least privilege scenario.

[GPMC Error] Could not take ownership of the production GPO. Value does not fall within the expected range

image

Figure 1- Value does not fall within the expected range error

This error is discoverable when attempting to delete a controlled Group Policy object. The error occurs when choosing Delete GPO from archive only or Delete GPO from archive and production.

Solution

The AGPM Service is configured for least privileges and is not a member of Backup Operators on the domain controller. The AGPM service is attempting to grant ownership to a security principal in which it is not allowed. Add the AGPM service account to Backup Operators on the domain controller. Restarting the AGPM service is not a requirement.

[Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML.

image

Figure 2- GpReport.xml error

This error is discoverable when attempting to create a new controlled Group Policy object. There are two major causes of this error

Solution 1:

The AGPM service does not have permissions to the computer's temp folder. Ensure the AGPM service has Full Control to the %systemroot%\temp folder of the computer running the AGPM Server service.

Solution 2:

First, check solution 1. Permissions on the computer's temp folder is root cause of the problem and you'll want to fix that first. If you are still receiving the error after following solution 1 (or temporarily making the AGPM service account a local admin of the computer running the AGPM Server service and restart the service), then the root cause of the problem occurred when you attempted to create your first controlled Group Policy object. The template created during the first controlled GPO creation failed (most likely with the this warning [GPMC Warning] A Report for this GPO could not be created. The backup will not contain any report of the settings Details: 0x80131509).

image

Figure 3- AGPM Templates view

Therefore, all subsequent controlled GPOs created from the template fail with [Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML. You need to Delete and Destroy all templates created before you followed solution 1 (permissions on the temp folder). Templates created before following solution 1 contain invalid XML.

image

Figure 4- Destroying template from AGPM Recycle Bin

After deleting and destroying invalid templates (specifically the <Empty GPO> template), then create a new controlled Group Policy object. You'll be prompted to create a new template. Agree to the create the new template. The operation takes longer than expected; however, it should return successful.

That's all the time we have for this episode of AskDS: AGPM Least Privilege Scenario. Tune in next time to read Ned Pyle's latest saga about DFSR :)

- Mike Stephens

Comments

  • Anonymous
    December 17, 2008
    PingBack from http://www.ditii.com/2008/12/17/agpm-least-privilege-scenario/

  • Anonymous
    December 17, 2008
    The comment has been removed

  • Anonymous
    January 28, 2009
    We (actually I) have been struggling with the "Full access to existing GPOs" element in AGPM 2.5 but I cracked it today! :-) When I was trying to approve the deployment of both new GPOs and those taken from Uncontrolled to Controlled, I was getting the error "could not take ownership of Group Policy Object.  Access is Denied". The logs showed it alright, but were gobblydegook to me. I thought about the "take ownership" and amended the Domain Controller policy (because that's where the existing policies actually are) and did a GPUpdate on the DCS, restarted the service for good measure are now that's fixed. Access is denied is because as you say, the AGPMService needs FullControl to existing policies.  How do I do that? I thought for a few days.  Under C:Program FilesGPMC is the Scripts folder. cscript "C:Program FilesGPMCScriptsGrantPermissionOnAllGPOs.wsf" "mydomainagpmservice" /Permission:FullEdit /Replace Hope that this helps someone else... time for a coffee

  • Anonymous
    March 15, 2009
    hello Scoobysnax You are a MAN!! Thanks for your guide!!

  • Anonymous
    December 08, 2009
    how do i trun off acces to all users out side of APGM

  • Anonymous
    March 17, 2010
    Good article, I moved our AGPM Server to run from an MSA. and I got stuck with similar GP issues. I fixed the permissions via PS. import-module GroupPolicy Set-GPPermissions -All -TargetName "...." -TargetType Group -PermissionLevel GpoEditDeleteModifySecurity After that our AGPM was ok again.

  • Anonymous
    June 23, 2014
    It’s been a while since I posted anything here, but I’m back and I have a few things to share

  • Anonymous
    September 01, 2015
    We get this error due to Sync and permissions issue on the GPO.

    1) Find out the AGPM Server (not the client)

    2) Login to AGPM server, and find out to which DC, the AGPM is authenticating to (use the command echo %logonserver%)

    3) Login to the DC where AGPM is authenticating

    4) Access ADSIEDIT.msc and SYSVOL from that DC

    5) Take the ownership of GPO and GPT.

    a) on ADSI access the GPO using corresponding GUID, right click --> properties -->Security --> Advance --> change the ownership to your account or your group. This gives permission on the GUID.

    b) on SYSVOL right click on the GUID folder (corresponding GPO's folder) -->properties -->Security --> advanced --> take the ownership --> and full control to your account or group.

    6 ) Access GPMC, right click on domain --> select change the domain controller --> and connect to the DC to which AGPM is authenticating.

    Now access the GPO from GPMC , access delegation tab, advanced --advanced --> here we should see the owner account which was mentioned in ADSI and SYSVOL. If we can see the correct account then it indicated that the Sync is completed.

    7) If we see same owner on ADSI, SYSVOL and on GPO, it indicates that SYNC is completed and then we can move the uncontrolled GPO to AGPM control.