Administration: support reference¶
Internal. The customer-facing explanation is in the screen reference.
Access problems account for most administration tickets, and they present as product faults rather than as permissions — which is the first thing to rule out.
A missing control is a permission, not a defect¶
The product hides what a role cannot use rather than disabling it. A caller saying "the button isn't there" is describing their role in almost every case.
Ask them to read out the row menu they can see and compare it with the role. Do not investigate a missing action as a rendering fault until the role is ruled out.
Roles, levels and groups are three different things¶
| Concept | Decides |
|---|---|
| Role | Which permissions the account holds |
| User Level | Seniority in approval chains — three independent tiers, not a ladder |
| User Group | Which collection of users someone belongs to |
A user can hold a different level in each of the three tiers; that is how an organisation models someone senior in one domain and junior in another. Expecting a single rank explains several "the approval went to the wrong person" tickets.
Auditor is a flag, not a role¶
An account not flagged as User/Auditor cannot be assigned to an audit, however its role is configured. "Why can't I select this person" is nearly always this.
Directory-backed accounts¶
An account created against Active Directory requires a Directory, because the same username can exist in more than one. The wrong choice produces an account that looks correct in the list and fails at sign-in with an invalid-credentials message — indistinguishable from a wrong password.
Correcting it is an edit rather than a re-create.
Ownership is visibility¶
Asset ownership is edited from the user, not from each asset. When someone leaves, their ownership must move or nobody receives notifications for those assets — the assets do not become unowned in a way anything reports.
Download all users with assets is the access-review export: every user with everything they can reach. Nothing else in the product produces it, and it is what an auditor asks for.
IP restriction¶
Sign-in can be limited to an address range per user. Remarks is where the justification goes — "site VPN egress", "vendor jump host". An entry without one cannot be reviewed later, because an address alone says nothing about why it was permitted.
A user who can sign in from the office and not from home is usually here rather than in their credentials.
Bulk updates¶
CSV upload applies changes in bulk and produces a log file with the per-row outcome. A bulk update that "partly worked" is answered by that log rather than by comparing lists by hand.
Audit properties are mapped per asset type and audit type¶
A property meaningful for a web DAST audit need not exist on a network VA. Mandatory blocks audit creation until filled — which is the usual reason an audit that used to save now will not, after someone added a required property.
Master status tables¶
The RLCM status masters are administered here, and their flags are enforced at save time: comment required, auditor required, evidence required, closed type, and is exception.
Two of these change reporting rather than behaviour:
- Closed Type decides whether something stops counting as open.
- Is Exception separates an agreed exception from a resolution.
A deployment whose counts do not match the documentation has usually edited these, and they are configuration rather than a fixed rule.
What to collect before escalating¶
- The username and their roles, quoted from the Users screen rather than described.
- The user's three levels, for approval-routing questions.
- Whether the account is directory-backed, and against which directory.
- For missing controls: what the caller can see, listed.
- For bulk updates: the log file from the queue, not a summary of it.