Read and Write Permission of Services Account Monitoring AD

Hello.

Granting the specific read and write permissions your vendor is requesting for Active Directory instances is typically done through the Delegation of Control Wizard at the domain or Organizational Unit level.

You should right-click your domain root in Active Directory Users and Computers, choose Delegate Control, and select your service account to assign a custom task that specifies the "Read" and "Write" property permissions on the target objects. You should also ensure the account has the necessary WMI permissions by opening wmimgmt.msc, right-clicking WMI Control to select Properties, and granting "Enable Account" and "Remote Enable" under the Security tab for the Root\CIMV2 namespace. It is common for these tools to also require read access to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Performance registry key to pull real-time database metrics.

If you find my answer useful, please mark it as the "Accepted Answer" so other members can find the solution easily. Your help in supporting the community is much appreciated!
Best regards,
Scott Nguyen

In Active Directory and Windows, “read/write” access is not set on groups themselves, but as permissions (ACEs) on specific securable objects (for example, AD objects, services, files, registry keys, event logs). Adding the service account to built‑in groups like Event Log Readers only grants the predefined rights of those groups; it does not give generic “read/write” to AD or to all services.

To meet a vendor requirement such as “service account needs read/write access to monitor AD instances and services,” the exact permissions depend on what the monitoring product actually touches. Typical patterns from the documentation are:

1. Grant specific AD permissions on required objects
   If the monitoring tool must read or modify particular AD objects (for example, user or group attributes), grant only the needed permissions on those objects or their parent containers/OUs:
   • Open Active Directory Users and Computers.
   • Enable Advanced Features (View → Advanced Features) if needed.
   • Right‑click the target container/OU or object → Properties → Security → Advanced.
   • Add the monitoring service account as a principal and grant the required permissions (for example, Read all properties, Read permissions, and specific Write permissions on attributes), similar to how management accounts are granted rights in the AdminSDHolder and user‑object examples.
   • Use the Applies to field to scope the permissions (for example, This object only or Descendant User objects), as shown in the management‑account and password‑writeback examples.
   The same mechanism is used in:
   • The AdminSDHolder example, where Dsacls is used to grant RPWP (read/write property) on the member attribute to a management account.
   • The password writeback examples, where an AD DS connector account is granted Read/write all properties on descendant User, Group, Contact, etc., objects from the domain root or Builtin container.
2. Use dsacls for precise AD ACL changes (if vendor specifies attributes)
   If the vendor specifies particular attributes or containers, use dsacls from an elevated command prompt on a DC:

      dsacls "<DN of target object or container>" /G <serviceAccountUPN>:RPWP;<attributeName>
   

   For example, the AdminSDHolder pattern:

      Dsacls "CN=AdminSDHolder,CN=System,DC=TailSpinToys,DC=msft" /G ******@tailspintoys.msft:RPWP;member
   

   This grants read property/write property on the member attribute for that account. Adjust the DN, account, and attribute(s) to match the monitoring requirement.
3. Avoid over‑privileging (no Domain Admin / LocalSystem on DCs)
   Running the monitoring service as LocalSystem on a domain controller gives unrestricted access to AD DS and is explicitly discouraged because bugs or attacks against the service can damage the entire forest. The guidance is to:
   • Avoid running services as LocalSystem on DCs.
   • Avoid adding computer accounts (which LocalSystem uses) to powerful groups.
   • Instead, run the service under a dedicated, least‑privilege domain account and grant only the specific permissions needed via ACLs.
4. Check whether the vendor really needs “write”
   Many monitoring tools only need read access (for example, read AD objects, read event logs, query services). “Write” might be required only for specific features (for example, password reset, remediation). If the vendor documentation is ambiguous, clarify exactly which objects and attributes require write access and grant only those.

In practice, the next step is to map the vendor’s documented requirements (which AD objects, which attributes, which Windows resources) to explicit ACL entries using the Security tab / Advanced Security Settings or dsacls, rather than trying to find a generic “read/write” switch for the service account.

References:

• Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory
• Appendix B: Active Directory privileged accounts and groups reference guide
• Troubleshoot password writeback access rights and permissions
• Using the LocalSystem Account as a Service Logon Account
• Active Directory domain join permissions