In order to function as expected, Senergy requires significant rights and privileges granted to its proxy account (through the Senergy Proxy Rights Group.) Generally this requires that administrators grant the Proxy Rights Group membership in the "Administrators" group in each domain, as well as other rights and privileges on individual servers as detailed in our documentation. However, not all organizations permit this configuration.
Below is a summary of the effective access minimums that the Proxy Rights group must have for Senergy to function properly in a “fine-grained” security deployment where the Proxy Rights group does not have membership in the BUILT-IN\Administrators group for each domain that Senergy manages.
- Read access to the RootDSE on every DC in each domain where a Senergy component runs or otherwise manages objects and/or storage, as well as on every DC in the forest root domain.
- Read access to the Schema partition
- Read access to the Configuration partition
- ADSI/LDAP access to all DCs in the forest root domain.
- This is required to enumerate trust relationships when discovering the tree root domains for all AD trees in the forest, as well as for enumerating forest trust relationships.
- Access to all GC [Global Catalog] servers in each domain where a Senergy component runs in or otherwise manages objects and/or storage.
- Read access to all object classes & attributes [a.k.a properties] for the entire domain, or for just the containers & their subordinates that contain objects of interest if a scope has been defined in Senergy.
- On each server where the Event Monitor component is running, the proxy rights group must be granted the “Synchronize Directory Service Data” LSA privilege [a.k.a “SeSyncAgentPrivilege”].
- On each “DC=<domain-name>” domain object that the Event Monitor is configured to monitor for changes, the permissions on the “DC=<domain-name>” object in AD must grant the proxy rights group an extended-right named “Replicating Directory Changes” [a.k.a “DS-Replication-Get-Changes”].
- Read access to all object classes and attributes [a.k.a properties] in the Deleted Objects container.
- Changing the permissions of the Deleted Objects container in each domain is tricky, and not all of the AD administration tools can do this. LDP can be used to open up access to the container for an administrator, and then XCACLS or PowerShell should be able to make the necessary changes to the permissions.
- Note that this needs to be done in each domain where users and storage are managed.
- For all user objects that Senergy manages, Senergy needs write access to the following attributes:
- If the product’s schema extensions have been added to AD to enable Aux Storage and Group Collaborative storage, then write access is required to the “objectClass” attribute on all user & group objects that Senergy manages, as well as read & write access to all attributes of the auxiliary classes that Senergy dynamically attaches to instances of user & group objects.
Note that other rights and privileges may be required depending on individual environmental details and configuration choices. This list should be considered a minimum rather than a comprehensive list suitable to every organization.
Once Senergy is running in this type of configuration, it cannot perform any storage management activities for shares that are hosted by DCs. The same goes for directly accessing the name space root share contents for any DFS name spaces that are hosted by DCs. (Correctly-configured DFS namespaces hosted on domain controllers are fine, however.)
All other local group membership & LSA privilege/rights requirements remain the same for member servers on which Senergy components are running or are managing by proxy over the network, including NAS devices and their various custom configurations.