Access can fail or become inconsistent because the appliance may still point to local accounts while the central directory expects exact user and group alignment. In practice, authentication may succeed for some users but authorisation can break, leaving admins with unclear permissions and support issues. Exact matching is essential when the directory becomes the authentication authority.
Why RADIUS conversion fails when usernames and groups do not line up
When FortiGate users are moved from local authentication to RADIUS, the device no longer treats the local account record as the source of truth for access decisions. If the RADIUS username or group claim does not match what the appliance expects, authentication and post-login authorisation can diverge. That creates a gap between “who logged in” and “what they are allowed to do.”
In practice, the break is often not a clean denial. Some users may still authenticate, but the mapped policy, group membership, or admin profile does not resolve the way the administrator intended. That is why conversions can look partially successful while producing inconsistent access outcomes.
What the appliance is trying to resolve during login
FortiGate needs more than a valid password exchange. It also needs a usable identity mapping so it can associate the session with the right group, policy, or administrative privilege set. With local users, that mapping is usually explicit and self-contained. With RADIUS-based users, the appliance depends on the external directory and the attribute mapping to deliver the same identity shape.
If the external directory uses a different username format, returns a different group value, or does not populate the expected attribute, FortiGate may authenticate the user but fail to place that user into the correct policy bucket. The result is an access control problem, not just an authentication problem.
- Authentication answers: “Is this user valid?”
- Authorisation answers: “What does this user get once valid?”
- Mapping answers: “How does the appliance translate the external identity into the local policy model?”
Why exact matching matters more after the migration
Local accounts can hide weak identity hygiene because the appliance already knows the account name, group, and administrative context. Once RADIUS becomes the authority, the lookup path depends on exact consistency between the directory, the FortiGate configuration, and any group filters or role mappings. A small mismatch can change the resulting privilege level or prevent the policy from binding at all.
This is especially important for administrative access. If the login succeeds but the admin profile does not map correctly, operators can lose expected permissions, fall into a default role, or be locked out of functions they assumed were available. The same pattern can also affect VPN or portal access where group membership drives the user experience and the enforcement outcome.
Risk and Threat Considerations
Identity conversion errors create more than inconvenience. They can produce inconsistent enforcement, unexpected privilege assignment, or failed access that pushes teams toward temporary exceptions and manual workarounds. In a live environment, that combination often increases support load while reducing confidence in the access model.
Failure mechanism: The appliance receives a valid RADIUS response but cannot translate the username or group into the intended local policy, so the session lands in the wrong role, loses expected privileges, or fails authorisation entirely.
Impact: Administrators can be over-restricted or under-restricted, troubleshooting becomes ambiguous, and the organisation may introduce ad hoc fixes that weaken the intended access model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | RADIUS-based access relies on external authentication and correct identity resolution. |
| AC-2 — Account Management | The issue is account-to-policy alignment during migration from local to central identity. | |
| AC-6 — Least Privilege | Broken mapping can grant the wrong privilege set or leave users over/under-authorised. | |
| Recommendation — Validate external identity mappings so authenticated users receive the intended access rights. Reconcile account and group mappings before decommissioning local access paths. Verify that mapped roles enforce the minimum access required after authentication. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question centers on identity resolution and access control after directory migration. |
| Recommendation — Align identity attributes and access rules so authentication and authorisation stay consistent. | ||
| OWASP ASVS | V8 — Authorization | The failure mode is authorisation breaking after successful authentication. |
| Recommendation — Test that authenticated users are consistently assigned the correct authorisation state. | ||
Practitioner Guidance
What to verify: Confirm the exact username format, returned group values, and any FortiGate group or admin-profile mapping before cutover. Test with at least one representative user from each access path, because a single successful login does not prove authorisation is working.
What to prioritise: Treat role resolution as the primary cutover risk, not just password validation. If authentication works but policy binding is unstable, pause the migration and fix the mapping before moving broader user populations.
Practitioner takeaway: The safe migration criterion is not “RADIUS accepts the user,” but “RADIUS resolves the user into the correct policy and privilege state every time.”
Related resources from NHI Mgmt Group
- What happens when DNS filtering is deployed without clear group-based policy mapping?
- What happens when Postgres users are created without role based access controls and auditing?
- What happens when users try to manipulate an image without restricting the edit to a local region?
- How can organisations test SAML mappings without disrupting real users?
