FMC Domains and LDAP: Authenticated but Blind
Northwind runs a single FMC 7.2 managing 26 FTDs and has just cut over from local accounts to an LDAP realm (server 10.9.9.20, base DN ou=people,dc=northwind,dc=local). Devices and policies are organized in three domains: Global, Americas with 12 devices, and EMEA with 9 devices; five APAC devices currently sit inside Americas. Priya, an EMEA network engineer, was created in FMC with External Authentication selected and the Access Admin role assigned in the Global domain. She can log in with her LDAP password, but after login the device list is empty, the EMEA access control policies are not listed, and opening a device URL returns 'You do not have permission to view this page'. Her colleague Marcus, whose local account predates the migration and carries the Administrator role in Global, still sees every device in every domain. Priya's manager also wants the whole EMEA team granted write access 'by LDAP group', so that new starters are handled without per-person administration.
1. Why can Priya authenticate but see nothing, and what exactly do you change?
Read the worked answer
Authentication and authorization are separate here. LDAP proves who Priya is; FMC decides what she can see through role assignments that are scoped per domain. Her only assignment is Access Admin in Global, and the EMEA devices and policies live in the EMEA domain. A role in Global does not grant that role in the child domains, and a user who is not a member of a domain has that domain's objects filtered out of every list and page.
Fix:
- Edit the user record and add a role in the EMEA domain. Access Admin is read-only but includes the ability to view devices and policies; if she must create or modify objects, rules and policies, Network Admin in EMEA is the appropriate grant. Add Intrusion Admin in EMEA only if she tunes IPS policies.
- Leave Global assignments off unless she genuinely needs cross-domain visibility; this is what makes Marcus's account so powerful and so risky.
- Verify by logging in as Priya and confirming the device list shows exactly the nine EMEA devices and that an Americas device returns a permission error.
Also review Marcus's local Administrator account: it bypasses the domain model and should not survive the migration as a normal working account.
2. The manager asks you to map the EMEA LDAP group to FMC roles so new starters are provisioned automatically. What is your answer?
Read the worked answer
FMC does not consume LDAP group membership as an authorization input. LDAP authenticates the user; the role-and-domain mapping is an FMC-side object that you configure per user. There is no group-to-role binding for a plain LDAP realm, so the requested 'automatic' behaviour does not exist out of the box.
What you can offer:
- Each user still needs an FMC record created with External Authentication selected and the username matching the LDAP account, plus role assignments in each domain they work in. Without the FMC record, a valid LDAP user cannot be authorized.
- Automate the provisioning: create the users and assign roles with the FMC REST API from your joiner/mover/leaver workflow, keyed off LDAP group membership. That gives the manager the operational outcome without pretending FMC does group mapping.
- Set expectations on role granularity: there is no 'EMEA engineer' template that magically matches the team's needs; decide once whether the group gets Network Admin (change rights) or Access Admin (read-only) in EMEA, and document the exception process for the few people who need both.
Also flag the security trade-off: a single group-wide write role means any LDAP account added to that group can change production policy.
3. An EMEA administrator tries to reference a host object that already exists in the Americas domain and cannot select it. Why, and how should shared objects be designed?
Read the worked answer
Policy objects in FMC are domain-scoped. Objects created in Global, the root domain, are inherited and visible in every subdomain. Objects created in Americas are visible in Americas and its descendants only; EMEA is a sibling, so the object simply does not appear in the object picker, and there is no error message to explain the absence.
Design guidance:
- Anything used by two or more domains belongs in Global: DNS servers, shared RFC1918 groups, certificate authorities used for decryption, and external feeds. Objects used by one business unit stay in that unit's domain to keep the blast radius of an edit small.
- To fix this instance, recreate the host object in Global, update the EMEA rule to reference it, verify the EMEA policy deploys, then remove the Americas-only duplicate if nothing else references it.
- Watch the interaction with policy deployment: an object defined in an ancestor is still rendered into the device configuration, so changing it in Global can affect rules in domains you were not thinking about. Treat Global objects as production-wide changes.
- Review the domain column in the object table before troubleshooting missing objects; 'the object does not exist' is almost always 'the object exists in a domain you cannot see'.