detection is the only non-authoritative identity source supported by the
Firepower System. When configured, managed devices detect LDAP, AIM, POP3,
IMAP, Oracle, SIP (VoIP), FTP, HTTP, MDNS, and SMTP logins on the networks you
specify. The data gained from traffic-based detection can be used only for user
awareness. Unlike authoritative identity sources, you configure traffic-based
detection in your network discovery policy as described in
Configuring Traffic-Based User Detection.
Note the following
detection also records failed login attempts. A failed login attempt does not
add a new user to the list of users in the database. The user activity type for
detected failed login activity detected by traffic-based detection is
Traffic-based detection interprets only Kerberos logins for LDAP
connections as LDAP authentications. Managed devices cannot detect encrypted
LDAP authentications using protocols such as SSL or TLS.
detection detects AIM logins using the OSCAR protocol only. They cannot detect
AIM logins using TOC2.
detection cannot restrict SMTP logging. This is because users are not added to
the database based on SMTP logins; although the system detects SMTP logins, the
logins are not recorded unless there is already a user with a matching email
address in the database.
The system cannot distinguish between failed and successful HTTP
logins. To see HTTP user information, you must enable
Capture Failed Login Attempts in the traffic-based
Enabling or disabling non-authoritative, traffic-based user detection over the HTTP, FTP, or MDNS protocols, using the network discovery policy restarts the Snort process when you deploy configuration changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior for more information.
When a device detects a login using traffic-based detection, it
sends the following information to the
to be logged as user activity:
the user name identified in the login
the time of the login
the IP address involved in the login, which can be the IP
address of the user’s host (for LDAP, POP3, IMAP, and AIM logins), the server
(for HTTP, MDNS, FTP, SMTP and Oracle logins), or the session originator (for
the user’s email address (for POP3, IMAP, and SMTP logins)
the name of the device that detected the login
If the user was previously detected, the
updates that user’s login history. Note that the
can use the email addresses in POP3 and IMAP logins to correlate with LDAP
users. This means that, for example, if the
detects a new IMAP login, and the email address in the IMAP login matches that
for an existing LDAP user, the IMAP login does not create a new user; rather,
it updates the LDAP user’s history.
If the user was previously undetected, the
adds the user to the users database. Unique AIM, SIP, and Oracle logins always
create new user records, because there is no data in those login events that
can correlate with other login types.
not log user activity or user identities in the following
if you configured the network discovery policy to ignore that
if a managed device detects an SMTP login, but the users
database does not contain a previously detected LDAP, POP3, or IMAP user with a
matching email address
The user data is added to the users table.
You can restrict the protocols where user activity is discovered
to reduce the total number of detected users so you can focus on users likely
to provide the most complete user information. Limiting protocol detection
helps minimize user name clutter and preserve storage space on your
following when selecting traffic-based detection protocols:
user names through protocols such as AIM, POP3, and IMAP may introduce user
names not relevant to your organization due to network access from contractors,
visitors, and other guests.
AIM, Oracle, and SIP logins may create extraneous user records.
This occurs because these login types are not associated with any of the user
metadata that the system obtains from an LDAP server, nor are they associated
with any of the information contained in the other types of login that your
managed devices detect. Therefore, the
cannot correlate these users with other types of users.