This topic discusses common terminology for user identity and user control.

User awareness

Identifying users on your network using identity sources (such as or TS Agent). User awareness enables you to identify users from both authoritative (such as Active Directory) and non-authoritative (application-based) sources. To use Active Directory as an identity source, you must configure a realm and directory. For more information, see About User Identity Sources.

User control

Configuring an identity policy that you associate with an access control policy. (The identity policy is then referred to as an access control subpolicy.) The identity policy specifies the identity source and, optionally, users and groups belonging to that source.

By associating the identity policy with an access control policy, you determine whether to monitor, trust, block, or allow users or user activity in traffic on your network. For more information, see Access Control Policies.

Authoritative identity sources

A trusted server validated the user login (for example, Active Directory). You can use the data obtained from authoritative logins to perform user awareness and user control. Authoritative user logins are obtained from passive and active authentications:

• Passive authentications occur when a user authenticates through an external repository. ISE/ISE-PIC, the TS Agent, Microsoft Active Directory, and Microsoft Azure Active Directory are passive authentication user repositories supported by the system.

  Passive authentications occur when a user authenticates with Cisco ISE.

• Active authentications occur when a user authenticates through preconfigured managed devices. Captive portal is another name for active authentication. Active authentication generally uses the same user repositories as passive authentication (the exceptions being ISE/ISE-PIC, and TS Agent, which are passive only).

Non-authoritative identity sources

An unknown or untrusted server validated the user login. Traffic-based detection is the only non-authoritative identity source supported by the system. You can use the data obtained from non-authoritative logins to perform user awareness.

The following table provides a brief overview of the user identity sources supported by the system. Each identity source provides a store of users for user awareness. These users can then be controlled with identity and access control policies.

Consider the following when selecting identity sources to deploy:

• You must use traffic-based detection for non-LDAP user logins.

• You must use traffic-based detection or captive portal to record failed login or authentication activity. A failed login or authentication attempt does not add a new user to the list of users in the database.

• The captive portal identity source requires a managed device with a routed interface. You cannot use an inline (also referred to as tap mode) interface with captive portal.

Data from those identity sources is stored in the CDO's users database and the user activity database. You can configure CDO-server user downloads to automatically and regularly download new user data to your databases.

After you configure identity rules using the desired identity source, you must associate each rule with an access control policy and deploy the policy to managed devices for the policy to have any effect. For more information about access control policies and deployment, see Associating Other Policies with Access Control.

For general information about user identity, see About User Identity.

When the system detects user data from a user login, from any identity source, the user from the login is checked against the list of users in the CDO user database. If the login user matches an existing user, the data from the login is assigned to the user. Logins that do not match existing users cause a new user to be created, unless the login is in SMTP traffic. Non-matching logins in SMTP traffic are discarded.

The group to which the user belongs is associated with the user as soon as the user is seen by the CDO.

Sample identity deployments

The sample deployments discussed in this section are based on the system shown in the following figure.

In the preceding figure, CDO and one managed device are deployed to AWS and the other devices are located on premises. These devices can be either physical or virtual; they just need to be able to communicate with each other.

The two on-premises managed devices are intended to be used as a proxy sequence. You must add those devices to CDO as well.

A proxy sequence is one or more managed devices that can be used to communicate with an LDAP, Active Directory, or ISE/ISE-PIC server. It is necessary only if CDO cannot communicate with your Active Directory or ISE/ISE-PIC server. (For example, CDO might be in a public cloud but Active Directory or ISE/ISE-PIC might be in a private cloud.)

LDAP or Active Directory are needed only for TS Agent and captive portal, as the following paragraphs explain.

For more information about setting up a system like this, see How to Set Up an Identity Policy.

ISE/ISE-PIC identity source

When you deploy the ISE/ISE-PIC identity source, CDO contacts the proxy sequence if CDO cannot contact the ISE/ISE-PIC server directly. Users, groups, and subscriptions are sent from the ISE/ISE-PIC server to the managed device in AWS.

You can optionally have an LDAP server in an ISE/ISE-PIC deployment but because it's optional, it isn't shown in the following figure.

For more information about ISE/ISE-PIC, see The ISE/ISE-PIC Identity Source.

TS Agent identity source

The Terminal Services (TS) Agent software runs on a Microsoft Server and sends CDO user information based on the port range the users log in to the server with. TS Agent gets user identity information from LDAP or Active Directory and sends it to CDO.

For more information about the TS Agent identity source, see The Terminal Services (TS) Agent Identity Source.

Captive portal

Captive portal is the only identity source that supports LDAP in addition to Active Directory. The captive portal identity source is triggered when a user tries to access network resources using the managed device in AWS, using either an IP address or host name. Captive portal gets user information from LDAP or Active Directory using the proxy sequence and sends user information to CDO.

For more information about the captive portal identity source, see The Captive Portal Identity Source.

The user activity database on the Secure Firewall Management Center contains records of user activity on your network detected or reported by all of your configured identity sources. The system logs events in the following circumstances:

• When it detects individual logins or logoffs.

• When it detects a new user.

• When a system administrator manually delete a user.

• When the system detects a user that is not in the database, but cannot add the user because you have reached your user limit.

• When you resolve an indication of compromise associated with a user, or enable or disable indication of compromise rules for a user.

Note

If the TS Agent monitors the same users as another passive authentication identity source (such as the ISE/ISE-PIC), the management center prioritizes the TS Agent data. If the TS Agent and another passive source report identical activity from the same IP address, only the TS Agent data is logged to the management center.

You can view user activity detected by the system using the Secure Firewall Management Center. (Analysis > Users > User Activity.)

The users database on the Secure Firewall Management Center contains a record for each user detected or reported by all of your configured identity sources. You can use data obtained from an authoritative source for user control.

See About User Identity Sources for more information about the supported non-authoritative and authoritative identity sources.

The total number of users the Secure Firewall Management Center can store depends on the Secure Firewall Management Center model. After the user limit is reached, the system prioritizes previously-undetected user data based on its identity source, as follows:

• If the new user is from a non-authoritative identity source, the system does not add the user to the database. To allow new users to be added, you must delete users manually or with a database purge.

• If the new user is from an authoritative identity source, the system deletes the non-authoritative user who has remained inactive for the longest period and adds the new user to the database.

If an identity source is configured to exclude specific user names, user activity data for those user names are not reported to the Secure Firewall Management Center. These excluded user names remain in the database, but are not associated with IP addresses.

If you have management center high availability configured and the primary fails, no logins reported by a captive portal, ISE/ISE-PIC, TS Agent, or Remote Access VPN device can be identified during failover downtime, even if the users were previously seen and downloaded to the management center. The unidentified users are logged as Unknown users on the management center. After the downtime, the Unknown users are reidentified and processed according to the rules in your identity policy.

Note

If the TS Agent monitors the same users as another passive authentication identity source (ISE/ISE-PIC), the management center prioritizes the TS Agent data. If the TS Agent and another passive source report identical activity from the same IP address, only the TS Agent data is logged to the management center.

When the system detects a new user session, the user session data remains in the users database until one of the following occurs:

• A user on the management center manually deletes the user session.

• An identity source reports the logoff of that user session.

• A realm ends the user session as specified by the realm's User Session Timeout: Authenticated Users, User Session Timeout: Failed Authentication Users, or User Session Timeout: Guest Users setting.

The Cloud-delivered Firewall Management Center adds a host to the network map when it detects activity associated with an IP address in your monitored network (as defined in your network discovery policy).

Cloud-delivered Firewall Management Center can store a maximum of 600,0000 hosts in its host database but we recommend the following.

You cannot view contextual data for hosts not in the network map. However, you can perform access control. For example, you can perform application control on traffic to and from a host not in the network map, even though you cannot use a compliance allow list to monitor the host's network compliance.

Note	The system counts MAC-only hosts separately from hosts identified by both IP addresses and MAC addresses. All IP addresses associated with a host are counted together as one host.

A user is added to the Cloud-delivered Firewall Management Center user database when:

• The user is downloaded from a realm.

• A captive portal or RA-VPN user logs in.

• A user is detected from any identity source (for example, TS Agent).

A Cloud-delivered Firewall Management Center can store a maximum of 600,0000 users in its host database but we recommend the following.

Only authoritative users are available for user control with access control policies.

The Cloud-delivered Firewall Management Center can store 600,000 sessions in its user database.

When the system detects a new, previously-undetected user after the limit has been reached, it prioritizes user data based on their identity source:

• If the new user is from a non-authoritative source, the system does not add the non-authoritative user to the database. To allow new users to be added, you must delete users manually or purge the database.

• If the new user is from an authoritative identity source, the system deletes the non-authoritative user who has remained inactive for the longest period of and adds the new authoritative user to the database.

  If there are only authoritative users, the system deletes the authoritative user who has remained inactive for the longest period of time and adds the new user to the database.

Troubleshooting information can be found in Troubleshoot User Control.

Tip

Note that if you are using traffic-based detection, you can restrict user logging by protocol to help minimize username clutter and preserve space in the database. For example, you could prevent the system from adding users discovered in AIM, POP3, and IMAP traffic because you know it is traffic from specific contractors or visitors you do not want to monitor.