AD Cache — Service Account and Required Permissions
The AD Cache service (internally named RemoteAD; the Windows service is branded Thinfinity Remote Active Directory) connects to Active Directory under a service account to synchronize the directory into its cache, validate user credentials, and — when the deployment manages users and groups from Thinfinity Workspace — write changes back to the directory. This article describes where that account is configured and the Active Directory rights it requires.
only stores the account’s credentials. Granting the rights themselves is done in Active Directory, outside Thinfinity Workspace — delegate them with your AD administrator, following the least-privilege guidance below rather than using a broad administrative account.
The Service Account
The AD Cache performs all directory work under a single service account. Its credentials are entered in the Thinfinity Workspace Configuration Manager, on the Domains tab, under Domain credentials(Username/Password). If those fields are left blank, the service uses the Windows account that the service runs under instead.
This setting is available in the Configuration Manager only; there is no equivalent page in the Web Manager.
Do not confuse these with the Directory Services credentials. The Directory Services list (Configuration Manager, Authentication tab) also shows Username/Password fields when editing an entry — those belong to API Authentication, the credentials the Broker uses to call the AD Cache endpoint. The domain service account is configured on the Domains tab.
Multiple and Trusted Domains
When the installation synchronizes more than one domain, each trusted domain has its own credentials. On the same Domains tab, the Trusted domains list shows the trusts detected for the host’s domain; tick a domain to include it, and use Set Credentials… to enter a valid Username / Password for it (the dialog reads Credentials for <domain>). Grant the required access separately in each domain, using an account that is valid there.
The Trusted domains list is only shown when the host’s domain has trust relationships with other domains (as configured in Active Directory Domains and Trusts). Being joined to a domain is not enough: on a standalone domain with no trusts — the most common case — the group does not appear on the Domains tab at all.
Prerequisites
- The server hosting the service must be joined to an Active Directory domain. If it is not domain-joined, the service will not start. (The AD Cache tab is likewise only available on a domain-joined machine — see AD Cache Tab.)
- Directory connections are made over a secure (signed and encrypted) channel. Domain Controllers must accept LDAP signing and sealing, which is the default.
Required Active Directory Rights
The service account’s rights fall into two groups: the read rights every deployment needs to synchronize the directory and authenticate users, and the write rights needed only when users and groups are managed from Thinfinity Workspace. Grant only the rights that match the operations your installation performs.
Directory Synchronization
Synchronization keeps the cache current with the source domain. The service reads the directory in one of two modes, set by the SyncMethod setting. The modes have different privilege requirements, so choose the one that matches the rights you are willing to delegate.
| Sync mode | How the directory is read | Required right |
|---|---|---|
usn (default, recommended) |
Standard reads of changed users and groups, plus a read of the Deleted Objects container to detect removals. | Read on user and group objects, and Read on the Deleted Objects container. |
dirsync |
The directory-replication change-tracking control. | Replicating Directory Changes (DS-Replication-Get-Changes) on the domain. |
SyncMethod is not exposed in the user interface: it is set in the AD Cache service’s configuration file (Thinfinity.RemoteAD.ini, section [Domain Services], key SyncMethod). Any value other than usn or dirsync falls back to usn.
The attributes read during synchronization (both modes) include objectGUID, objectSid, objectClass, sAMAccountName, distinguishedName, isDeleted, member, memberOf, cn, name, userAccountControl, and displayName.
Once objects are cached, read-only operations — listing users and groups, listing domains, and resolving group memberships — are served from the cache and require no further live-directory rights.
In usn mode, reading the Deleted Objects container is restricted to administrators by default. If the service account runs usn mode without read access to that container, additions and changes still synchronize, but object deletions are not reflected in the cache. Grant Read on the Deleted Objects container, or use dirsync mode with its replication right.
Replicating Directory Changes is a high, domain-wide privilege, granted by default only to Domain Controllers and Domain Admins. Use usn mode unless a specific requirement calls for dirsync.
Authentication and Self-Service Password Change
These operations are performed with the end user’s own credentials, not the service account’s, so they need no delegated rights on the service account.
| Operation | How it is validated |
|---|---|
| Login | The user’s credentials are validated with a standard network logon. The account must be valid and enabled; guest accounts are rejected. |
| Self-service password change | The user supplies their current password and a new one, using the standard right every account has to change its own password. |
User and Group Management
The following rights apply only when users and groups are managed from Thinfinity Workspace — that is, through the Members section of the Web Manager (available to administrators with the Users permission when the AD Cache is active) or through the AD Cache API. Those operations write to Active Directory under the service account. If your deployment does not manage the directory from Workspace, the read rights above are sufficient — do not grant any of the following.
Grant these rights on the organizational unit that holds the managed objects, and only for the operations your installation actually performs.
User operations
| Operation | Required right | When required |
|---|---|---|
| Create user | Create User Objects on the target container, and Reset Password | Only if you create users from Workspace |
| Update user | Write on the touched properties; Reset Password if a new password is supplied; Move if the account is relocated | Only if you update users from Workspace |
| Delete user | Delete on the user object and Delete Child on its parent container | Only if you delete users from Workspace |
| Set password | Reset Password | Only if you reset passwords from Workspace |
User properties written during create and update: sAMAccountName, userPrincipalName, givenName, sn, mail, displayName, userAccountControl, and the password.
Group operations
| Operation | Required right | When required |
|---|---|---|
| Create group | Create Group Objects on the target container | Only if you create groups from Workspace |
| Update group | Write on the touched properties, and Write Members | Only if you update groups from Workspace |
| Delete group | Delete on the group object and Delete Child on its parent container | Only if you delete groups from Workspace |
| Add or remove members | Write Members on the target group | Only if you change group membership from Workspace |
Group properties written during create and update: sAMAccountName, displayName, groupType, and member. Setting membership requires the full Write Members right; the limited Add/Remove self as member right is not sufficient.
On the AD Cache Tab, Use this group as root scopes which part of the directory is synchronized and searched (a read-only restriction); it also acts as the default group when a user or group created from Workspace specifies no other. Add new users to these groups makes the service add every user created from Workspace to the listed groups — a real write of the groups’ member attribute, which requires Write Members on each of them. Neither option affects deployments that never create users or groups from Workspace.
Rights Summary
| Right | When required |
|---|---|
| Read on users and groups | All deployments (synchronization and all read operations) |
| Read on the Deleted Objects container | usn sync mode, to detect deletions |
| Replicating Directory Changes | dirsync sync mode |
| Create / Delete User Objects, Delete Child | Only if users are created or deleted from Workspace |
| Create / Delete Group Objects, Delete Child | Only if groups are created or deleted from Workspace |
| Write on user and group properties | Only if users or groups are updated from Workspace |
| Write Members | Only if group membership is changed from Workspace (including Add new users to these groups) |
| Reset Password | Only if users are created or passwords reset from Workspace |
| None (operation acts as the user) | Login, self-service password change |
Troubleshooting
| Symptom | Likely cause | Resolution |
|---|---|---|
| Service does not start | Server is not domain-joined | Join the host to the domain. |
| Login or password operations fail | The Domain Controller is not accepting a secure LDAP channel | Ensure LDAP signing and sealing are enabled on the Domain Controller. |
| Users from a trusted domain are not recognized | Missing or invalid credentials for that domain | Set valid credentials for the domain under Trusted domains on the Domains tab, using an account valid in that domain. |
Deletions never disappear from the cache (usn mode) |
The service account cannot read the Deleted Objects container | Grant Read on the container, or switch to dirsync with its replication right. |
See also
For how the AD Cache works and how it is deployed, see Understanding AD Cache (RemoteAD). The service account and trusted domains are entered on the Domains Tab; the cache scope and API access are configured on the AD Cache Tab.