LDAP Admin Groups with Least-Privilege ADOM Access
Fabrikam uses FortiManager 7.4.3 with two ADOMs: Prod and Lab. Administrators authenticate to an LDAP server. Two LDAP groups exist: CN=FMG-NOC,OU=Groups and CN=FMG-Policy,OU=Groups. The NOC group maps to admin profile NOC-RO, which should have read-only access to all ADOMs. The Policy group maps to Policy-RW, which has read-write access to Policy & Objects in Prod and Device Manager read-only. NOC users can log in but see an empty ADOM list. Policy users can open Prod, edit policies, and save, but the Install button is disabled. The LDAP bind succeeds, and group membership is correct. The FortiManager remote admin entries use a wildcard group pattern, and the LDAP server returns nested group membership only through an auxiliary attribute. The team wants least privilege, no local accounts, and install rights only for the Policy group in Prod.
1. Why do NOC users see an empty ADOM list even though their group matches NOC-RO?
Read the worked answer
NOC users authenticated and mapped to NOC-RO, so LDAP bind and group matching are working. The empty ADOM list points to the profile's ADOM privileges, not the LDAP group. A cloned profile can have All ADOMs selected at the top while the per-ADOM permission list is empty or set to None; FortiManager enforces the per-ADOM rights. Fix NOC-RO so that Prod and Lab are explicitly assigned with read-only permission, or use All ADOMs with read-only if that is truly the intent. Then have a NOC user log out and back in so the profile is re-evaluated. Also confirm the remote admin entry is bound to NOC-RO and not to a default profile. Least privilege is better served by explicit ADOM lists than by a broad All ADOMs grant.
2. Why is Install disabled for Policy-RW users, and how should the profile be changed without violating least privilege?
Read the worked answer
Editing and saving policies needs Policy & Objects read-write; installing needs Device Manager read-write as well, because install pushes configuration to devices. Policy-RW has Device Manager read-only, so the Install action is disabled. Grant Device Manager read-write to Policy-RW, but keep the profile scoped to Prod so the group cannot install in Lab. Confirm the install target devices are in Prod; an install to a device outside the admin's ADOMs will still be denied. If you want stricter separation, create a separate Policy-Install profile with Policy & Objects read-write and Device Manager read-write in Prod, and map only the senior policy group to it; keep ordinary policy editors at Device Manager read-only. Re-login after the profile change and test with a low-risk package.
3. How should the wildcard group pattern and nested LDAP membership be handled to preserve least privilege?
Read the worked answer
The wildcard pattern is the weak point. If CN=FMG-*,OU=Groups maps both groups to one remote admin entry or profile, the first match can give a user too much or too little access, and nested groups may not be returned by the LDAP search at all. FortiManager can only match groups that the LDAP response includes; if the server returns nested membership only through an auxiliary attribute, configure the LDAP query or filter to return that attribute or use a group filter that resolves nesting. Then create separate remote admin entries with exact group DNs: FMG-NOC to NOC-RO and FMG-Policy to Policy-RW. Test with one user from each group and verify the assigned profile and ADOM list in the GUI. Avoid using a wildcard for least-privilege mapping unless all matched groups are intended to share exactly the same rights.