Inshipia Security Gateway

Troubleshooting Web Access

The pages a browser gets from ISG when a web console cannot be opened or a request is not let through, quoted verbatim (the English text; the Hungarian one follows the browser's language), grouped by when they appear. Each refusal is also an audit line with its reason code — the line, not the page, says why. Search for the text on your screen.

Before the application opens

"You do not have access to this application through ISG."

  1. The user is in none of the application's allow_groups, is on a reserved name, or — for an identity: credential application — no credentials entry matches the user's groups. The audit line is APP_ACCESS_DENIED with reason not_in_group, reserved_username or no_credential. Check the user's groups in the directory and the application's lists; there is no default account.
  1. The one-time hand-off code expired (it is valid for 60 seconds), was used already, or was redeemed in a different browser than the one that started the sign-in (reason handoff_invalid or handoff_unbound). Opening the application again from My applications starts a new hand-off. If it keeps happening, check that the browser keeps cookies for the application's host name between the redirects.

"An administrator locked this access (your account or the application)."

  1. A lock is in place for the user or the application (reason locked); isg lock list shows it, with its reason and end. Lifting it is isg lock rm.

"The ISG license does not allow new Web Access sessions. Ask your administrator."

  1. The license in force does not allow a new Web Access session for this user; open sessions are not affected. isg license shows what is in force.

"Approval required" / "Waiting for approval" / "The request was denied"

The application asks for a four-eyes approval (require_approval). The user picks a duration and sends the request; an approver decides on the web UI's approvals page. "Waiting" refreshes by itself; a pending request expires after approval_timeout_seconds. "Denied by …" quotes the approver's reason. With approval_mode: self the page is "Justification required" instead: the justification has to meet approval_reason_min_len and approval_reason_pattern.

"No application of this name is configured on this gateway."

404 on the web UI's hand-off: the application in the link does not exist on this broker — usually an apps.yaml that differs between the brokers, or a dynamic application that was deleted. A host name the listener does not know at all gets a bare 421.

"The directory is currently unavailable. Try again later."

  1. The directory could not be asked for the user's groups; Web Access does not let a request through on a guess. The ldap_bind row of isg system check names the cause.

While the application is open

"This operation is denied by an ISG rule: …"

  1. A deny rule of http_rules matched the request (APP_REQUEST_DENIED, with the rule); the application never saw it and the session stays. The text after the colon is the rule's own reason; the audit line names the rule.

"This request is not among the application's allowed requests (allow-list mode)."

  1. The application is in http_app_modes mode allow, and no allow rule matched (rule http_mode:allow). Run the application in allow_audit for a while: the APP_REQUEST_WOULD_DENY lines list what the allow rules miss.

"This operation needs a fresh verification. Open this address in the browser, verify, then repeat the operation: …"

403 for a request that is not a page load (a form post, an API call), with the address also in the X-ISG-Step-Up header: a step_up rule wants the second factor again. Open the address, confirm the code, then repeat the operation. A page load goes to the confirmation page by itself.

"An administrator closed this Web Access session. Open the application again; …"

  1. The session was closed from the web UI or with isg sessions close. Opening the application again starts a new session; an application with approval needs a new request.

"The application's session had expired; ISG signed in again. Send the request again."

409, for a kind: form account. The console's own session had ended; ISG signed in again, repeated a GET or HEAD by itself, but does not repeat a modifying request behind the user's back. Sending it again works. If this appears at regular intervals (every 10 minutes on Grafana), the console was not signing out but rotating its token: add the string its 401 body carries to logged_out.unless_body_contains (see preparing a web console).

"ISG could not sign in to the application with the brokered account. Tell your administrator; the reason is in the broker's log."

502, for a kind: form account. The recipe's sign-in did not succeed; APP_UPSTREAM_LOGIN_FAILED names why: status (the last step's status is not in success.status), success_cookie (the named cookie was not set), success_redirect, extract (a token rule found nothing — the login page changed), timeout, transport (the upstream is not reachable from the broker), secret (the OpenBao entry lacks username or password). Signing in by hand with the same account on the console's own page tells a wrong password from a wrong recipe.

"Temporarily unavailable"

503, with one of these texts — in every case the request was not let through, because Web Access fails closed:

The console shows its own error

The page is the console's, not ISG's (it has the console's look). The request reached the console with the identity ISG added: check what the console thinks of that identity — the account's rights for identity: credential, the role_map for identity: jwt. The session's transcript (web UI, Sessions) shows each request's status as the console answered it.

isg system check rows

Web Access listener

not listening on … — the listener did not start (the port is taken, or the certificate does not load). not covered: … — a host (or the dynamic apps domain's wildcard) is missing from the certificate's SANs. rejected at … — a certificate reload was refused and the previous certificate is still served.

Web Access credentials

N of M account(s) unreadable: <app>/<account>: … — those accounts' secrets cannot be read; a request through them would get the "credential cannot be read" page. not measured: apps.yaml does not load points at the apps.yaml row.