AD Replication Check
When GrantFlow activates a role or checks out an account in Active Directory, the agent writes the change to one domain controller: the host configured on the connector. Windows, however, checks a logon against whichever domain controller it picks, and enabling an account or adding a group member is not urgent replication in AD. Without a check, a session could open right after activation and show "Your account has been disabled", because the domain controller that checked the logon had not received the change yet.
GrantFlow now confirms the change on the domain controllers that can check the logon before it reports the access as applied. A session waits for that confirmation, and if a domain controller cannot confirm the change, the session stops and tells the user which one and why.
Requirements at a glance
AD agents on version 0.4.0 or later (0.4.1 is current), and Skip TLS verification turned off on the AD connector. Recommended: the Replication Synchronization right for the connector's service account.
How it works
After the agent has written an activation's changes, GrantFlow runs one replication check per AD connector. The check:
- Works out which domain controllers can check the logon (see Which domain controllers are checked).
- Asks each of them to pull exactly the changed objects from the domain controller that took the write: the user for an enabled account, the group for a new membership. This step runs only when the service account holds the Replication Synchronization right.
- Reads the change back from each domain controller, including the one that took the write. Only a read that shows the change counts as confirmed. Without the right, GrantFlow skips step 2 and keeps reading until normal replication delivers the change.
The check never waits on a fixed timer, and it ends after at most 90 seconds. The activation is reported as active once the check has finished, whatever it found: the change is in place, and a domain controller that has not confirmed it yet will still receive it through normal replication.
How long it takes
In our lab, with the right granted, both domain controllers of a site confirmed the change in about 0.1 seconds. Without the right, the same site confirmed by normal replication in about 15 seconds.
Which domain controllers are checked
GrantFlow checks the writable domain controllers of the connector's domain. Read-only domain controllers are skipped, because they forward the logon to a writable one.
| Situation | Domain controllers checked |
|---|---|
| A session to a target that is a domain controller | That domain controller |
| A session to a member server | Every writable domain controller in the target's AD site |
| A session to a member server whose site cannot be determined | Every writable domain controller in the site of the domain controller that took the write; the session then stops with a site warning |
| An activation without a session | Every writable domain controller in the site of the domain controller that took the write |
GrantFlow finds a member server's site the way Windows does: by matching the server's IP address against the subnets defined in Active Directory Sites and Services. In a forest with a single site, every target belongs to that site. In a forest with several sites, define a subnet for every network that holds session targets. Otherwise GrantFlow cannot tell which domain controllers the target will use.
Targets in other sites
Without change notification on the site link, AD replicates between sites on the site link's schedule, by default every 180 minutes. For a target in another site, the change can only be confirmed within 90 seconds if the service account can force replication, or if change notification is enabled on that site link. See Instant Replication for the site link option.
What users see
When a user opens a session from Sessions, the preparing steps include Applying access and waiting for AD replication. The session connects as soon as every checked domain controller has confirmed the change.
If the check does not confirm the change everywhere, the session stops before connecting and shows one of these warnings:
| Warning | Meaning |
|---|---|
| Access is applied, but not every domain controller has it yet | At least one domain controller did not confirm the change. Each one is named with its reason, for example unreachable from the agent or didn't show the change within 90 s. |
| Access is applied, but whether every domain controller has it could not be checked | The check could not run, for example because the connector doesn't verify TLS, or the agent was too busy. |
| Access is applied, but it could not be confirmed for this target's site | GrantFlow could not determine which domain controllers the target uses. |
Every warning offers Connect anyway. The access is applied, so connecting is safe. The worst case is that Windows shows the "disabled" screen until replication reaches the domain controller it picked.
For an account checkout with a role, both the checkout and the role activation are checked. The session stops once, after the last step, and names every unconfirmed domain controller from both.
What admins see
Every check appears as an AD Replication Check job in the activation's group on the Connector Jobs page, next to the write jobs of the same activation. You can filter for it with the job type filter. A check completes whenever it ran, even if a domain controller did not confirm the change. A failed check means it could not finish, for example because no agent answered within three minutes; the activation still becomes active.
Set up the replication check
Update your AD agents
The replication check runs on the agent that writes for the connector. That agent must run version 0.4.0 or later; 0.4.1 is the current release. GrantFlow assigns the check automatically to every AD agent on a supported version, so you do not need to change the agent's capabilities.
While no agent on a supported version is connected for a connector, activations on that connector behave as before: the session opens without waiting, and nothing is confirmed. See Updating the Agent.
Verify TLS on the connector
The replication check connects to every domain controller it checks with the connector's service account. GrantFlow does this only over a verified TLS connection, so:
- Turn off Skip TLS verification on the AD connector.
- Make sure every writable domain controller presents a certificate for its host name that the agent host trusts. A certificate from your enterprise CA is enough on domain-joined hosts.
On a connector with Skip TLS verification turned on, sessions stop with the warning "Access is applied, but whether every domain controller has it could not be checked". After you run the connector test, the connector card also says: "The connector doesn't verify TLS, so sessions can't confirm AD replication. Turn on certificate verification."
Grant Replication Synchronization (recommended)
With the Replication Synchronization right on the domain, the agent can ask each domain controller to pull the changed objects immediately. Without it, the check waits for normal replication, which is slower within a site and usually too slow across sites.
Grant the right to the connector's service account on the domain's root, for example:
dsacls "DC=contoso,DC=com" /G "CONTOSO\svc_grantflow:CA;Replication Synchronization"Run the command as a Domain Admin on a domain controller or on a host with the AD DS management tools. The right on the domain's root is enough; the configuration partition needs nothing. For details, see Service Account Permissions.
Copy the command from the connector card
After you run the connector test, the AD connector card shows a warning when the service account lacks the right, together with the exact dsacls command for your domain and service account and a copy button.
Make every domain controller reachable
The agent must reach every domain controller it checks over LDAP, on the connector's port. That includes the agent running on a domain controller: it still connects to the other domain controllers over the network. See Network Requirements.
Check your setup with the connector test
Run Test on the AD connector card after you change any of the settings above. Besides the connection itself, the test now reports:
- whether the service account can force replication, with the
dsaclscommand when it cannot; - whether the connector skips TLS verification;
- for each site, which writable domain controllers the testing agent cannot reach, for example "Sessions to targets in site Vienna can't be confirmed from agent …".
The warnings stay on the connector card until the next test. If several agents serve the connector, the reachability result reflects only the agent that ran the test.
Limitations
- Active Directory only. Entra ID role assignments are not checked.
- New activations only. When the role is already active before the session starts, the session opens as before, without a check.
- Grants only. Removals and disables at the end of an activation are not checked.
- A fixed 90-second limit. It is not configurable per connector.
Troubleshooting
A domain controller is "unreachable from the agent"
The agent could not open an LDAP connection to that domain controller. Check firewalls between the agent host and the domain controller on the connector's port, and check DNS resolution of the domain controller's host name from the agent host. Run the connector test to see every domain controller the agent cannot reach.
A domain controller "didn't show the change within 90 s"
The domain controller was reachable but had not received the change when the check ended. Grant Replication Synchronization so the agent can force replication. For a target in another site, also consider change notification on the site link.
Every session stops with "could not be checked"
Check that Skip TLS verification is off on the connector, and that an agent on version 0.4.0 or later is online for the connector.
Sessions stop with "could not be confirmed for this target's site"
The forest has more than one site, and the target's IP address matches no subnet in Active Directory Sites and Services. Add a subnet for the target's network and assign it to the right site. When a role spans several AD domains, the hint for the target's domain is also dropped if GrantFlow cannot tell which connector the target belongs to.