About Realms and Identity Policies
A realm consists of one or more LDAP or Microsoft Active Directory servers that share the same directory credentials. You must configure a realm to perform user and user group queries, user control, or to configure an authoritative identity source. After configuring one or more realms, you can configure an identity policy.
An identity policy associates traffic on your network with an authoritative identity source and a realm. After configuring one or more identity policies, you can associate one with an access control policy and deploy the access control policy to a managed device.
About Realms
Realms are connections between the Firepower Management Center and the user accounts on the servers you monitor. They specify the connection settings and authentication filter settings for the server. Realms can:
-
Specify the users and user groups whose activity you want to monitor.
-
Query the user repository for user metadata on authoritative users, as well as some non-authoritative users: POP3 and IMAP users detected by traffic-based detection and users detected by traffic-based detection, a user agent, or ISE.
You can add multiple domain controllers as directories in a realm, but they must share the same basic realm information. The directories in a realm must be exclusively LDAP or exclusively Active Directory (AD) servers. After you enable a realm, your saved changes take effect next time the Firepower Management Center queries the server.
To perform user awareness, you must configure a realm for any of the supported server types. The system uses these connections to query the servers for data associated with POP3 and IMAP users, and to collect data about LDAP users discovered through traffic-based detection.
The system uses the email addresses in POP3 and IMAP logins to correlate with LDAP users on an Active Directory, or OpenLDAP. For example, if a managed device detects a POP3 login for a user with the same email address as an LDAP user, the system associates the LDAP user’s metadata with that user.
To perform user control, you can configure any of the following:
-
For captive portal, an LDAP realm.
A realm sequence is not supported for LDAP.
About User Download
You can configure a realm to establish a connection between the Firepower Management Center and an LDAP or AD server to retrieve user and user group metadata for certain detected users:
-
LDAP and AD users authenticated by captive portal or reported by a user agent or ISE. This metadata can be used for user awareness and user control.
-
POP3 and IMAP user logins detected by traffic-based detection, if those users have the same email address as an LDAP or AD user. This metadata can be used for user awareness.
You configure LDAP server or Active Directory domain controller connections as a directory in a realm. You must check Download users and user groups for access control to download a realm's user and user group data for user awareness and user control.
The Firepower Management Center obtains the following information and metadata about each user:
-
LDAP user name
-
First and last names
-
Email address
-
Department
-
Telephone number
About User Activity Data
User activity data is stored in the user activity database and user identity data is stored in the users database. The maximum number of users you can store and use in access control depends on your Firepower Management Center model. When choosing which users and groups to include, make sure the total number of users is less than your model limit. If your access control parameters are too broad, the Firepower Management Center obtains information on as many users as it can and reports the number of users it failed to retrieve in the Tasks tab page of the Message Center.
Note |
If you remove a user that has been detected by the system from your user repository, the Firepower Management Center does not remove that user from its users database; you must manually delete it. However, your LDAP changes are reflected in access control rules when the Firepower Management Center next updates its list of authoritative users. |
Realms and Trusted Domains
When you configure a realm in the Firepower Management Center, it is associated with an Active Directory or LDAP domain.
A grouping of Microsoft Active Directory (AD) domains that trust each other is commonly referred to as a forest. This trust relationship can enable domains to access each other's resources in different ways. For example, a user account defined in domain A can be marked as a member of a group defined in domain B.
The Firepower System and trusted domains
The Firepower System does not support trusted AD domains. This means that the Firepower System does not track which configured domains trust each other, and does not know which domains are parent or child domains of each other. The Firepower System also has not been tested to assure support for environments that use cross-domain trust, even when the trust relationship is exercised outside of the Firepower System.
Supported Servers for Realms
You can configure realms to connect to the following types of servers, providing they have TCP/IP access from the Firepower Management Center:
Server Type |
Supported for User Agent data retrieval? |
Supported for ISE data retrieval? |
Supported for captive portal data retrieval? |
Supported for RA VPN data retrieval? |
---|---|---|---|---|
Microsoft Active Directory on Windows Server 2008 and Windows Server 2012 |
Yes |
Yes |
Yes |
Yes |
OpenLDAP on Linux |
No |
No |
Yes |
Yes |
Note the following about your server group configurations:
-
To perform user control on user groups or on users in groups, you must configure user groups on the LDAP or Active Directory server.
-
Group names cannot start with S- because it is used internally by LDAP.
Neither group names or nor organizational unit names can contain special characters like asterisk (
*
), equals (=
), or backslash (\
); otherwise, users in those groups or organizational units are not downloaded and are not available for identity policies. - To configure an Active Directory realm that includes or
excludes users who are members of a sub-group on your server, note that
Microsoft recommends that Active Directory has no more than 5000 users per group
in Windows Server 2008 or 2012. For
more information, see Active Directory Maximum Limits—Scalability on MSDN.
If necessary, you can modify your Active Directory server configuration to increase this default limit and accommodate more users.
Supported Server Object Class and Attribute Names
The servers in your realms must use the attribute names listed in the following table for the Firepower Management Center to retrieve user metadata from the servers. If the attribute names are incorrect on your server, the Firepower Management Center cannot populate its database with the information in that attribute.
Metadata |
FMC Attribute |
LDAP ObjectClass |
Active Directory Attribute |
OpenLDAP Attribute |
---|---|---|---|---|
LDAP user name |
Username |
|
samaccountname |
cn uid |
first name |
First Name |
givenname |
givenname |
|
last name |
Last Name |
sn |
sn |
|
email address |
|
userprincipalname (if mail has no value) |
|
|
department |
Department |
department distinguishedname (if department has no value) |
ou |
|
telephone number |
Phone |
telephonenumber |
telephonenumber |
Note |
The LDAP ObjectClass for groups is group, groupOfNames, (group-of-names for Active Directory) or groupOfUniqueNames. |
For more information about ObjectClasses and attributes, see the following references:
Troubleshoot Realms and User Downloads
If you notice unexpected server connection behavior, consider tuning your realm configuration, device settings, or server settings. For other related troubleshooting information, see:
Symptom: Access control policy doesn't match group membership
This solution applies to an AD domain that is in a trust relationship with other AD domains. In the following discussion, external domain means a domain other than the one to which the user logs in.
If a user belongs to a group defined in a trusted external domain, Firepower doesn't track membership in the external domain. For example, consider the following scenario:
-
Domain controllers 1 and 2 trust each other
-
Group A is defined on domain controller 2
-
User mparvinder in controller 1 is a member of Group A
Even though user mparvinder is in Group A, the Firepower access control policy rules specifying membership Group A don't match.
Solution: Create a similar group in domain controller 1 that contains has all domain 1 accounts that belong to group A. Change the access control policy rule to match any member of Group A or Group B.
Symptom: Access control policy doesn't match child domain membership
If a user belongs to a domain that is child of parent domain, Firepower doesn't track the parent/child relationships between domains. For example, consider the following scenario:
-
Domain child.parent.com is child of domain parent.com
-
User mparvinder is defined in child.parent.com
Even though user mparvinder is in a child domain, the Firepower access control policy matching the parent.com don't match mparvinder in the child.parent.com domain.
Solution: Change the access control policy rule to match membership in either parent.com or child.parent.com.
Symptom: Realm or realm directory test fails
The Test button on the directory page sends an LDAP query to the hostname or IP address you entered. If it fails, check the following:
-
The Hostname you entered resolves to the IP address of an LDAP server or Active Directory domain controller.
-
The IP Address you entered is valid.
The Test button on the realm configuration page verifies the following:
-
DNS resolves the AD Primary Domain to an LDAP server or Active Directory domain controller’s IP address.
-
The AD Join Username and AD Join Password are correct.
AD Join Username must be fully qualified (for example, administrator@mydomain.com, not administrator).
-
The user has sufficient privileges to create a computer in the domain and join the Firepower Management Center to the domain as a Domain Computer.
Symptom: User timeouts are occurring at unexpected times
Symptom: Users are not included or excluded as specified in your realm configuration
If you configure an Active Directory realm that includes or excludes users who are members of a sub-group on your server, note that Microsoft Windows servers limit the number of users they report:
-
5000 users per group on Microsoft Windows Server 2008 or 2012
If necessary, you can modify your server configuration to increase this default limit and accommodate more users.
Symptom: Users are not downloaded
Possible causes follow:
-
If you have the realm Type configured incorrectly, users and groups cannot be downloaded because of a mismatch between the attribute the Firepower system expects and what the repository provides. For example, if you configure Type as LDAP for a Microsoft Active Directory realm, the Firepower system expects the
uid
attribute, which is set tonone
on Active Directory. (Active Directory repositories usesAMAccountName
for the user ID.)Solution: Set the realm Type field appropriately: AD for Microsoft Active Directory or LDAP for another supported LDAP repository.
-
Users in Active Directory groups that have special characters in the group or organizational unit name might not be available for identity policy rules. For example, if a group or organizational unit name contains the characters asterisk (
*
), equals (=
), or backslash (\
), users in those groups are not downloaded and can't be used for identity policies.Solution: Remove special characters from the group or organizational unit name.
Symptom: User data for previously-unseen ISE and User Agent users is not displaying in the web interface
After the system detects activity from an ISE or user agent user whose data is not yet in the database, the system retrieves information about them from the server. In some cases, the system requires additional time to successfully retrieve this information from Active Directory servers. Until the data retrieval succeeds, activity seen by the ISE or User Agent user is not displayed in the web interface.
Note that this may also prevent the system from handling the user's traffic using access control rules.
Symptom: User data in events is unexpected
If you notice user or user activity events contain unexpected IP addresses, check your realms. The system does not support configuring multiple realms with the same AD Primary Domain value.
About Identity Policies
Identity policies contain identity rules. Identity rules associate sets of traffic with a realm and an authentication method: passive authentication, active authentication, or no authentication.
With the exception noted in the following paragraphs, you must configure realms and authentication methods you plan to use before you can invoke them in your identity rules:
-
You configure realms outside of your identity policy, at Create a Realm.
. For more information, see -
You configure the user agent and ISE, passive authentication identity sources, at . For more information, see Configure the User Agent for User Control and Configure ISE for User Control.
-
You configure captive portal, the active authentication identity source, in the identity policy. For more information, see How to Configure the Captive Portal for User Control.
After you add multiple identity rules to a single identity policy, order the rules. The system matches traffic to rules in top-down order by ascending rule number. The first rule that traffic matches is the rule that handles the traffic.
After you configure one or more identity policies, you must associate one identity policy with your access control policy. When traffic on your network matches the conditions in your identity rule, the system associates the traffic with the specified realm and authenticates the users in the traffic using the specified identity source.
If you do not configure an identity policy, the system does not perform user authentication.
Exception to creating an identity policy
An identity policy is not required if all of the following are true:
-
You use the ISE/ISE-PIC identity source.
-
You do not use users or groups in access control policies.
-
You use Security Group Tags (SGT) in access control policies. For more information, see ISE SGT vs Custom SGT Rule Conditions.
Video YouTube video on creating an identity policy and rule.