Blocked Grants
Knocknoc can refuse a grant when the connection doesn't meet the rules set for a Knoc. The grant is then recorded as blocked, and the user is told that their access was refused. If an administrator trusts the connection, they can override the block and grant access anyway. The override needs a comment, and the comment is recorded in the audit log.
When a grant is blocked
Most blocks come from the Trust Engine. Each Knoc has a trust policy, which is a named set of restrictions: country, known networks, malicious addresses and so on. You manage policies under Admin > Trust Engine > Policies. Each restriction has a response of Off, Observe, Challenge or Block. When a restriction set to Block matches the address the user is connecting from, the grant is refused. When several restrictions match, the strictest response wins.
A grant can be blocked for any of these reasons:
| Block reason | What it means |
|---|---|
| Blocked by a trust policy | A restriction in the Knoc's trust policy matched the connection and is set to Block. For example, the user connected from outside the approved countries or known networks, or from an address that threat intelligence reports as malicious. |
| Blocked while the attached trust policy could not be read | Knocknoc could not read the Knoc's policy, so it could not decide the connection. Open the policy under Admin > Trust Engine > Policies, check its restrictions and select Save. |
| Address outside the Knoc's allowed source addresses | Legacy only. The Knoc has no trust policy, and the user's address is not on its Enable Knoc for users connecting from list. |
| Address reported as malicious | Legacy only. The Knoc has no trust policy, it has Block if GreyNoise identifies as malicious turned on, and GreyNoise reports the user's address as malicious. |
A restriction set to Challenge does not block the grant. It holds the grant back until the user confirms who they are: the Knoc's tile shows Verification needed with a Verify button, and confirming delivers the access. A held grant is not in the grant history and cannot be overridden, because only the user can clear it. You can see it on the user's sign-in session under Trust policy, and under Admin > Trust Engine > Activity, where it reads Challenged until the user verifies.
A block is different from a grant error. An error means the agent could not apply the grant to the device, which is usually temporary or a problem on the device. A block means a policy deliberately refused the connection.
What the user sees
The Knoc's tile in the user portal tells the user why they have no access, without naming the policy, the restriction or the provider:
| Tile | When |
|---|---|
| Connection not permitted | A trust policy refused the connection. |
| Verification needed | A trust policy wants the user to confirm who they are. The tile shows a Verify button. |
| Checking your connection | Knocknoc is still waiting to hear from a threat intelligence provider. Access appears on its own within a few seconds. |
| Source IP not permitted | Legacy. The address is not on the Knoc's allowed source addresses. |
| Blocked by threat intelligence | Legacy. GreyNoise flagged the address as malicious. |
Every refusal tells the user to contact their administrator if they think it's a mistake.
What the administrator sees
Blocked grants appear in red in the Knoc's grant history, along with the reason for the block. If the block came from a trust policy, you can expand the row to see the finding that refused it: which policy decided, which restrictions matched and what each one was set to at the time.
The same findings are listed under Admin > Trust Engine > Activity, where you can filter by outcome, policy, user, address or Knoc. They also appear on the user's sign-in session, under Admin > Identities > Sessions > the session > Trust policy. On the session's Access this session tab, blocked rows expand onto the same finding.
Legacy blocks don't record a finding, so their rows show the reason but don't expand.
Overriding a blocked grant
Note: You must be an Admin to override a blocked grant.
- Log in to your Admin console:
https://<your-server>/admin - Open the Knoc where the grant was blocked.
- In the grant history, find the blocked grant.
- Click Grant Anyway.
- The Override blocked grant? dialog shows which policy refused the grant and what matched. Enter a comment explaining why the override is justified. You can't confirm until you've written one.
- Confirm.
Knocknoc then applies the grant as a normal grant. It follows the Knoc's usual grant duration and expiry, and it stays in place for the life of that grant. The override only covers that one grant. It doesn't change the Knoc's trust policy, and it doesn't allow the address for future sign-ins. If you want a connection like this to be allowed next time, change the policy instead (for example, add the network under Known networks).
How an overridden grant is shown
- The original blocked grant stays in the history, badged (overridden), so you can see that the block was deliberately bypassed.
- A new grant marked Admin Override carries the access from then on.
- The admin's name and the override comment are shown next to the grant.
Audit implications
Every override creates its own audit-log entry, Admin overrode blocked grant. The entry records:
- the administrator who performed the override
- the required comment (the justification)
- the user and the IP address that access was granted for
- the requesting IP that the override was performed from
- the Knoc involved
- the user agent
- the time of the override
These entries appear in the audit log under the Admin grants category, alongside manual grants, so you can filter for them directly. Both the original block and the audited override are kept, so the history shows the block, who overrode it, when and why.
Note: An override deliberately bypasses a trust decision. Only use it when you trust the connection. The required comment keeps the decision accountable in the audit trail.