Authentication and Authorization
What this domain tests
Authentication and Authorization focuses on how FortiAuthenticator verifies credentials and passes authorization information to enforcement points. Expect RADIUS and LDAP details, FortiToken methods, certificate authentication, and group or attribute mapping.
Authentication methods
- Local users are stored on FortiAuthenticator. Remote users come from LDAP/AD or another RADIUS source. Certificate authentication uses a trusted CA chain, with CRL or OCSP checking.
- FortiToken methods include FortiToken Mobile push, time-based or event-based OTP, and SMS or email OTP. A token must be assigned to the user and activated before it can authenticate.
- RADIUS uses UDP 1812 for authentication and 1813 for accounting. Each network access server, such as a FortiGate, must be defined as a RADIUS client with its IP address and a shared secret.
- LDAP commonly uses 389 or 636. A bind DN and password are needed to search the directory; the user bind verifies the user password.
Authorization and group mapping
FortiAuthenticator does not enforce FortiGate firewall policy. It returns group information or vendor-specific attributes, and FortiGate matches that information to policies. For RADIUS, Fortinet VSAs can carry a group name. For LDAP, group membership can be mapped into a FortiAuthenticator user group. Admin authorization is separate: FortiAuthenticator admin profiles control access to FortiAuthenticator, while FortiGate admin profiles control access to FortiGate.
Worked example
A FortiGate administrator is configured to use RADIUS authentication to FortiAuthenticator with an OTP. The administrator enters the password and FortiToken code. FortiAuthenticator checks the user source, validates the token, and returns Accept with a group attribute. FortiGate then applies the matching admin profile. Reasoning: the password proves knowledge, the token proves possession, and the returned group determines authorization; a RADIUS Accept without the right group still will not grant the intended profile.
Traps that cost marks
- A RADIUS shared secret mismatch or an undefined client IP causes silent drops or rejects.
- A valid token assigned to the wrong user fails even when the code looks correct.
- OTP validation fails when FortiAuthenticator time is wrong, so NTP is part of authentication design.
- Expecting FortiAuthenticator to enforce firewall policy instead of returning group or attribute data.
- Using the wrong user group type, such as a local group when the user is remote, breaks policy matching.