Managing Authentication Objects
License:
Any
Authentication objects are server profiles for external authentication servers, containing connection settings and authentication filter settings for those servers. You can create, configure, and delete authentication objects on the Defense Center and use them to manage external authentication to LDAP or RADIUS servers. See the following sections for details:
LDAP Authentication
License:
Any
LDAP, or the Lightweight Directory Access Protocol, allows you to set up a directory on your network that organizes objects, such as user credentials, in a centralized location. Multiple applications can then access those credentials and the information used to describe them. If you ever need to change a user's credentials, you can change them in one place, rather than having to change them on each FireSIGHT System appliance.
See the following sections for more information:
Understanding LDAP Authentication
License:
Any
You can create LDAP authentication objects on a Defense Center, but not on other FireSIGHT System appliances. However, you can use the external authentication object on any appliance (except virtual devices or Cisco NGIPS for Blue Coat X-Series) by applying a system policy where the object is enabled to the appliance. When you apply the policy, the object is copied to the appliance.
Note Before enabling external authentication on Series 3 managed devices, remove any internally-authenticated shell users that have the same user name as externally-authenticated users included in your shell access filter.
Note that you can use LDAP naming standards for address specification and for filter and attribute syntax in your authentication object. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type
JoeSmith@security.example.com
rather than the equivalent user distinguished name of
cn=JoeSmith,ou=security, dc=example,dc=com
when using Microsoft Active Directory Server.
Note Currently, the FireSIGHT System supports LDAP external authentication on LDAP servers running Microsoft Active Directory on Windows Server 2008, Oracle Directory Server Enterprise Edition 7.0 on and Windows Server 2008, or OpenLDAP on Linux. However, the FireSIGHT System does not support external authentication for virtual devices or Cisco NGIPS for Blue Coat X-Series.
For more information, see the following sections:
Understanding Defaults
License:
Any
You can populate several fields using default values based on the server type you plan to connect to. Default values propagate the User Name Template, UI Access Attribute, Shell Access Attribute, Group Member Attribute, and Group Member URL Attribute fields when you select a server type and set defaults.
Understanding Base DNs
License:
Any
When the local appliance searches the LDAP server to retrieve user information on the authentication server, it needs a starting point for that search. You can specify the tree that the local appliance should search by providing a base distinguished name, or
base DN
.
Typically, the base DN has a basic structure indicating the company domain and operational unit. For example, the Security organization of the Example company might have a base DN of
ou=security,dc=example,dc=com
.
After you identify a primary server, you can automatically retrieve a list of available base DNs from it and select the appropriate base DN.
Understanding Base Filters
License:
Any
You can add a
base filter
(maximum 450 characters, including the enclosing parentheses) that sets a specific value for a specific attribute. The base filter focuses your search by only retrieving objects in the base DN that have the attribute value set in the filter. Enclose the base filter in parentheses. For example, to filter for only users with a common name starting with F, use the filter
(cn=F*)
.
To test your base filter more specifically by entering a test user name and password, see Testing User Authentication.
Understanding Impersonation Accounts
License:
Any
To allow the local appliance to access the user objects, you must supply user credentials for an impersonation account. The
impersonation account
is a user account with appropriate rights to browse the directory named by the base DN and retrieve the user objects you want to retrieve. Remember that the distinguished name for the user you specify must be unique to the tree for the server.
Understanding Your LDAP Connection
License:
Any
You can manage the encryption method for your LDAP connection. You can choose no encryption, Transport Layer Security (TLS), or Secure Sockets Layer (SSL) encryption.
Note that if you are using a certificate to authenticate when connecting via TLS or SSL, the name of the LDAP server in the certificate
must
match the name that you use in the Host Name/IP Address field. For example, if you enter
10.10.10.250
in the external authentication settings and
computer1.example.com
in the certificate, the connection fails. Changing the name of the server in the external authentication settings to
computer1.example.com
causes the connection to succeed.
Understanding User Name Templates
License:
Any
Selecting a user name template lets you indicate how user names entered on login should be formatted, by mapping the string conversion character (
%s
) to the value of the UI access attribute or shell access attribute for the user. The user name template is the format for the distinguished name used for authentication. When a user enters a user name into the login page, the name is substituted for the string conversion character and the resulting distinguished name is used to search for the user credentials.
For example, to set a user name template for the Security organization of the Example company, you might enter
%s@security.example.com
. If you want to use an object for CAC authentication and authorization, you
must
enter a value for the user name template that corresponds with your UI access attribute value. For more information, see Understanding LDAP Authentication With CAC.
Understanding Connection Timeouts
License:
Any
If you specify a backup authentication server, you can set a timeout for the connection attempt to the primary server. If the timeout period elapses without a response from the primary authentication server, the appliance then queries the backup server. For example, if the primary server has LDAP disabled, the appliance queries the backup server.
If LDAP is running on the port of the primary LDAP server and for some reason refuses to service the request (due to misconfiguration or other issues), however, the failover to the backup server does not occur.
Understanding Attributes to Manage Access
License:
Any
Different types of LDAP servers use different attributes to store user data. See the following sections for an explanation of UI and shell access attributes.
UI Access Attributes
If your LDAP server uses a UI access attribute of
uid
, the local appliance checks the
uid
attribute value for each object in the tree indicated by the base DN you set. If you do not set a specific UI access attribute, the local appliance checks the distinguished name for each user record on the LDAP server to see if it matches the user name. If one of the objects has a matching user name and password, the user login request is authenticated.
You can substitute a different LDAP attribute to make the local appliance match a user name with that attribute rather than the value of the distinguished name. Selecting a server type and setting defaults fills in a UI access attribute appropriate for that type of server. If one of the objects has a matching user name and, for non-CAC objects, a password as a value for the attribute you specify, the user login request is authenticated. You can use any attribute, if the value of the attribute is a valid user name for the FireSIGHT System web interface. Valid user names are unique, and can include underscores (
_
), periods (
.
), hyphens (
-
), and alphanumeric characters. If you want to use an object for CAC authentication and authorization, you
must
enter a value for the UI access attribute that corresponds with the user name template value. For more information, see Understanding LDAP Authentication With CAC.
Shell Access Attributes
If your LDAP server uses
uid
as your shell access attribute, the local appliance checks the user name entered on login against the attribute value of
uid
. You can also set a custom shell access attribute other than
uid
.
Note that selecting a server type and setting defaults prepopulates a shell access attribute typically appropriate for that type of server. You can use any attribute, if the value of the attribute is a valid user name for shell access. Valid user names are unique, and can include underscores (_), periods (.), hyphens (-), and alphanumeric characters.
Understanding Group Membership to Manage Access
License:
Any
If you prefer to base default access rights on a user’s membership in an LDAP group, you can specify distinguished names for existing groups on your LDAP server for each of the access roles used by your FireSIGHT System. When you do so, you can configure a default access setting for those users detected by LDAP that do not belong to any specified groups. When a user logs in, the FireSIGHT System dynamically checks the LDAP server and assigns access rights according to the user’s current group membership.
When a user authenticated by an LDAP server logs into a local FireSIGHT System appliance for the first time, the user receives the access rights for groups the user belongs to, or if groups are not configured, the default access setting you selected in the system policy.
You can then modify those settings, unless the settings are granted through group membership.
Understanding Shell Access
License:
Any
You can use the LDAP server to authenticate accounts for shell access on a managed device or Defense Center. Specify a search filter that retrieves entries for users to whom you want to grant shell access. Note that you can only configure shell access for the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.
With the exception of the admin account, shell access is controlled entirely though the shell access attribute you set. Shell users are configured as local users on the appliance. The filter you set here determines which set of users on the LDAP server can log into the shell.
Note that a home directory for each shell user is created on login, and when an LDAP shell access user account is disabled (by disabling the LDAP connection), the directory remains, but the user shell is set to
/bin/false
in
/etc/password
to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.
If all users qualified in the base DN are also qualified for shell access privileges, you can configure the shell access filter to search more efficiently by selecting
Same as Base Filter
. Normally, the LDAP query to retrieve users combines the base filter with the shell access filter. If you type the same shell access filter as the base filter, the same query runs twice, which is unnecessarily time-consuming.
Shell users can log in using user names with lowercase letters.Login authentication for the shell is case sensitive.
Caution On Series 3 Defense Centers, all shell users have
sudoers
privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the
Configuration level of command line access, which also grants
sudoers
privileges.
Understanding LDAP Authentication With CAC
License:
Any
If your organization uses Common Access Cards (CACs), you can configure LDAP authentication to authenticate users logging into the web interface and authorize access to specific functionality based on group membership or default access rights. With CAC authentication and authorization configured, users have the option to log in directly without providing a separate username and password for the appliance.
Note You must have a valid user certificate present in your browser (in this case, a certificate passed to your browser via your CAC) to enable user certificates as part of the CAC configuration process. After you configure CAC authentication and authorization, users on your network must maintain the CAC connection for the duration of their browsing session. If you remove or replace a CAC during a session, your web browser terminates the session and the system logs you out of the web interface.
For more information about configuring and managing CAC authentication and authorization, see the following sections:
Configuring CAC Authentication and Authorization
License:
Any
Supported Devices:
Any except virtual or X-Series
Supported Defense Centers:
Any except virtual or X-Series
Before users on your network can log in using their CAC credentials, a user with appropriate permissions must complete the multi-step configuration process for CAC authentication and authorization.
To configure and enable CAC authentication and authorization:
Access:
Admin/Network Admin
Step 1 Insert a CAC as directed by your organization.
Step 2 Direct your browser to
https://
hostname
/
, where
hostname
corresponds to the host name of your Defense Center.
Step 3 If prompted, enter the PIN associated with the CAC you inserted in step
1
.
Your PIN is accepted.
Step 4 If prompted, select the appropriate certificate from the drop-down list.
The browser accepts your selection and the Login page appears.
Step 5 In the
Username
and
Password
fields, log in as a user with Administrator privileges. User names are case sensitive.
Tip You cannot log in using your CAC credentials until you have fully configured CAC authentication and authorization.
The default start page appears.
Step 6 Navigate to
System > Local > User Management
and click the
External Authentication
tab. Create an LDAP authentication object exclusively for CAC authentication and authorization, following the procedures outlined in Preparing to Create an LDAP Authentication Object and Creating Advanced LDAP Authentication Objects. You must configure the following:
Tip Note that you cannot configure both CAC authentication and shell access in the same authentication object. If you also want to authorize users for shell access, create separate authentication objects and enable them separately in your system policy.
Step 7 Click
Save
.
The External Authentication page appears, with the new object listed.
Step 8 Navigate to
System > Local > System Policy
. Enable external authentication, then CAC authentication in your system policy, following the procedure outlined in Enabling External Authentication.
Caution Your changes do
not take effect until you apply the system policy to the Defense Center and its managed devices. See
Applying a System Policy for more information.
Step 9 Navigate to
System > Local > Configuration
and click
HTTPS Certificate
. Import a HTTPS server certificate, if necessary, following the procedure outlined in Uploading Server Certificates.
Note The same certificate authority (CA) must issue the HTTPS server certificate and the user certificates on the CACs you plan to use for authentication and authorization.
The Current HTTPS Certificate Page updates to reflect the new certificate.
Step 10 Under
HTTPS User Certificate Settings
, select
Enable User Certificates
. For more information, see Requiring User Certificates.
Step 11 Optionally, after a user logs in for the first time, navigate to
System > Local > User Management
to manually add or remove access rights for that user. If you do not modify the user’s rights, the user has only the rights granted by default. For more information, see Understanding User Privileges and Modifying User Privileges and Options.
For more information about changing a CAC user’s role after their initial login, see the following section, Managing CAC Authentication and Authorization.
Managing CAC Authentication and Authorization
After you configure and enable CAC authentication and authorization, users on your network can log into the web interface of an appliance using their CAC credentials. For more information, see Logging into the Appliance.
CAC-authenticated users are identified in the system by their electronic data interchange personal identifier (EDIPI) numbers. After users log in using their CAC credentials for the first time, you can manually add or remove access privileges for those users on the User Management page. If you did not preconfigure a user’s privileges using group-controlled access roles, the user has only the privileges granted by default in your system policy. For more information, see Understanding User Privileges, Understanding Group Membership to Manage Access, and Modifying User Privileges and Options.
Note that the system purges manually configured access privileges when it purges CAC-authenticated users from the User Management page after 24 hours of inactivity. The users are restored to the page after each subsequent login, but you must reconfigure any manual changes to their access privileges.
Preparing to Create an LDAP Authentication Object
License:
Any
Before you configure a connection to your LDAP server, you should collect the information that you need to create the LDAP authentication object. For more information on specific aspects of configuration, see Understanding LDAP Authentication.
You need the following for any authentication object:
-
the server name or IP address for the server where you plan to connect
-
the server type of the server where you plan to connect
-
the user name and password for a user account with sufficient privileges to browse the LDAP tree
-
if there is a firewall between the appliance and the LDAP server, an entry in the firewall to allow outgoing connections
-
if possible, the base distinguished name for the server directory where the user names reside
Note that you can use a third-party LDAP client to browse the LDAP tree and see base DN and attribute descriptions. You can also use that client to confirm that your selected user can browse the base DN you select. Ask your LDAP administrator to recommend an approved LDAP client for your LDAP server.
Depending on how you plan to customize your LDAP authentication object configuration, you might also need the information in the following table.
Table 61-1 Additional LDAP Configuration Information
|
|
connect over a port other than 389
|
the port number
|
connect via an encrypted connection
|
the certificate for the connection
|
filter the users who can access your appliance based on an attribute value
|
the attribute-value pair to filter by
|
use an attribute as a UI access attribute rather than checking the user distinguished name
|
the name of the attribute
|
use an attribute as a shell login attribute rather than checking the user distinguished name
|
the name of the attribute
|
filter the users who can access your appliance via the shell based on an attribute value
|
the attribute-value pair to filter by
|
associate groups with specific user roles
|
the distinguished name of each group, as well as the group member attribute if the groups are static groups or the group member URL attribute if the groups are dynamic groups
|
use CACs for authentication and authorization
|
your CAC, a server certificate signed by the same CA that issued your CAC, and the certificate chain for both certificates
|
Creating Basic LDAP Authentication Objects
License:
Any
You can set up an LDAP authentication object where you customize many of the values. However, if you just want to authenticate all the users in a particular directory, you can create a basic authentication object with the base DN for that directory. If you set defaults to those for your server type and supply authentication credentials for the account used to retrieve user data from the server, you can quickly create an authentication object. Follow the procedure below to do so.
Note If you prefer to consider and possibly customize each authentication setting when creating the authentication object (to configure CAC authentication and authorization, for example), use the procedure in Creating Advanced LDAP Authentication Objects to create the object. You should also use the advanced procedure if you plan to encrypt your connection to the server, set user timeouts, customize the user name template, or assign FireSIGHT System user roles based on LDAP group membership.
Before you configure a connection to your LDAP server, you should collect the information that you need to create the LDAP authentication object. For more information on specific aspects of configuration, see Understanding LDAP Authentication.
To create a basic authentication object, you need the following:
-
the server name or IP address for the server where you plan to connect
-
the server type of the server where you plan to connect
-
the user name and password for a user account with sufficient privileges to browse the LDAP tree; Cisco recommends that you use a domain admin user account for this purpose
Optionally, if you want to constrain your user search further, you can add a base filter to set a specific value for a specific attribute. The base filter focuses your search by only retrieving objects in the base DN that have the attribute value set in the filter. Enclose the base filter in parentheses. For example, to filter for only users with a common name starting with F, use the filter
(cn=F*)
. When you save the authentication object, the local appliance queries using the base filter to test it and indicates whether or not the filter appears to be correct.
To create an LDAP authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click
Create External Authentication Object
.
Step 4 Select
LDAP
from the
Authentication Method
drop-down list.
LDAP configuration options appear.
Step 5 Type a name and description for the authentication server in the
Name
and
Description
fields.
Step 6 Select your server type from the
Server Type
drop-down list, then click the
Set Defaults
button to configure default settings for that type. You have the following options:
-
If you are connecting to a Microsoft Active Directory Server, select
MS Active Directory
, then click
Set Defaults
.
-
If you are connecting to a Sun Java Systems Directory Server or Oracle Directory Server, select
Oracle Directory
, then click
Set Defaults
.
-
If you are connecting to an OpenLDAP server, select
OpenLDAP
, then click
Set Defaults
.
-
If you are connecting to a server other than those listed above and want to clear default settings, select
Other
, then click
Set Defaults
.
Step 7 Type the IP address or host name for the primary server where you want to obtain authentication data in the
Primary Server Host Name/IP Address
field.
Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.
Step 8 To fetch a list of all base DNs, click
Fetch DNs
and select the appropriate base DN from the drop-down list.
For example, to authenticate names in the Security organization at the Example company, select
ou=security,dc=example,dc=com
.
Step 9 Optionally, to set a filter that retrieves only specific objects within the directory you specified as the Base DN, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the
Base Filter
field (maximum 450 characters, including the enclosing parentheses).
For example, if the user objects in a tree have a physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of
NewYork
for that attribute, to retrieve only users in the New York office, type
(physicalDeliveryOfficeName=NewYork)
.
Step 10 In the
User Name
and
Password
fields, type the distinguished name and password for a user who has sufficient credentials to browse the LDAP server.
For example, if you are connecting to an OpenLDAP server where user objects have a
uid
attribute and the object for the administrator in the Security division at our example company has a
uid
value of
NetworkAdmin
, you might type
uid=NetworkAdmin,ou=security,dc=example,dc=com.
Caution If you are connecting to a Microsoft Active Directory Server, you cannot provide a server user name that ends with the
$
character.
Step 11 Retype the password in the
Confirm Password
field.
Step 12 Optionally, to retrieve users for shell access, type the attribute type you want to filter on in the
Shell Access Attribute
field.
For example, on a Microsoft Active Directory Server, use the
sAMAccountName
shell access attribute to retrieve shell access users by typing
sAMAccountName
in the
Shell Access Attribute
field.
Note IPv6 addresses are not supported for shell authentication.
Step 13 In the
User Name
and
Password
fields, type the
uid
value or shell access attribute value and password for the user whose credentials should be used to validate access to the LDAP server. Note, again, that server user names associated with a Microsoft Active Directory Server cannot end with the character
$
.
For example, to test to see if you can retrieve the
JSmith
user credentials at the Example company, type
JSmith.
Step 14 Click
Test
to test the connection.
A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. If the test succeeds, the test output appears at the bottom of the page, including a list of the users retrieved by the connection. If the number of users that appear in the test output is limited by the number of user records your LDAP server returns, the test output indicates this limitation.
Step 15 You have two options:
-
If the test succeeds, click
Save
.
The External Authentication page appears, with the new object listed.
To enable LDAP authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.
Tuning Your Basic LDAP Authentication Connection
License:
Any
If you create an LDAP authentication object and it either does not succeed in connecting to the server you select, or does not retrieve the list of users you want, you can tune the settings in the object.
If the connection fails when you test it, try the following suggestions to troubleshoot your configuration:
-
Use the messages displayed at the top of the screen and in the test output to determine which areas of the object are causing the issue.
-
Check that the user name and password you used for the object are valid:
-
Check that the user has the rights to browse to the directory indicated in your base distinguished name by connecting to the LDAP server using a third-party LDAP browser.
-
Check that the user name is unique to the directory information tree for the LDAP server.
-
Check that the user name contains only underscores, periods, hyphens, and alphanumeric characters.
-
If you see an LDAP bind error 49 in the test output, the user binding for the user failed. Try authenticating to the server through a third-party application to see if the binding fails through that connection as well.
-
Check that you have correctly identified the server:
-
Check that the server IP address or host name is correct.
-
Check that you have TCP/IP access from your local appliance to the authentication server where you want to connect.
-
Check that access to the server is not blocked by a firewall and that the port you have configured in the object is open.
-
If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used for the server.
-
Check that you have not used an IPv6 address for the server connection if you are authenticating shell access.
-
If you used server type defaults, check that you have the correct server type and click
Set Defaults
again to reset the default values.
For more information, see Identifying the LDAP Authentication Server.
-
If you typed in your base distinguished name, click
Fetch DNs
to retrieve all the available base distinguished names on the server, and select the name from the list.
-
If you are using any filters, access attributes, or advanced settings, check that each is valid and typed correctly.
-
If you are using any filters, access attributes, or advanced settings, try removing each setting and testing the object without it.
-
If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses and that you are using a valid comparison operator. For more information, see Understanding Base Filters and Understanding Shell Access.
-
To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve just that user.
-
If you are using an encrypted connection:
-
Check that the name of the LDAP server in the certificate matches the host name that you use to connect.
-
Check that you have not used an IPv6 address with an encrypted server connection.
-
If you are using a test user, make sure that the user name and password are typed correctly.
-
If you are using a test user, remove the user credentials and test the object.
-
Test the query you are using by connecting to the LDAP server via the command line on the appliance you want to connect from using this syntax:
ldapsearch -x -b 'base_distinguished_name'
-h LDAPserver_ip_address -p port -v -D
'user_distinguished_name' -W 'base_filter'
For example, if you are trying to connect to the security domain on
myrtle.example.com
using the
domainadmin@myrtle.example.com
user and a base filter of (
cn=*
), you could test the connection using this statement:
ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'
-h myrtle.example.com -p 389 -v -D
'domainadmin@myrtle.example.com' -W '(cn=*)'
If you can test your connection successfully but authentication does not work after you apply a system policy, check that authentication and the object you want to use are both enabled in the system policy that is applied to the appliance.
If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or change a base filter or shell access filter or use a more restrictive or less restrictive base DN. For more information, see the following topics:
Creating Advanced LDAP Authentication Objects
License:
Any
You can create LDAP authentication objects to provide user authentication services for an appliance.
When you create an authentication object, you define settings that let you connect to an authentication server. You also select the directory context and search criteria you want to use to retrieve user data from the server. Optionally, you can configure shell access authentication.
Make sure you have TCP/IP access from your local appliance to the authentication server where you want to connect.
Although you can use the default settings for your server type to quickly set up a basic LDAP configuration, you can also customize advanced settings to control whether the appliance makes an encrypted connection to the LDAP server, the timeout for the connection, and which attributes the server checks for user information.
For the LDAP-specific parameters, you can use LDAP naming standards and filter and attribute syntax. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type
JoeSmith@security.example.com
rather than the equivalent user distinguished name of
cn=JoeSmith,ou=security, dc=example,dc=com
when using Microsoft Active Directory Server.
Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user certificates. For more information, see Requiring User Certificates and Understanding LDAP Authentication With CAC.
To create an advanced authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click
Create External Authentication Object
.
The Create External Authentication Object page appears.
Step 4 Identify the authentication server where you want to retrieve user data for external authentication. For more information, see Identifying the LDAP Authentication Server.
Step 5 Configure authentication settings to build a search request that retrieves the users you want to authenticate. Specify a user name template to format the user names that users enter on login. For more information, see Configuring LDAP-Specific Parameters.
Step 6 Optionally, configure LDAP groups to use as the basis for default access role assignments. For more information, see Configuring Access Rights by Group.
Tip If you plan to use this object for CAC authentication and authorization, Cisco recommends configuring LDAP groups to manage access role assignments. For more information, see Managing CAC Authentication and Authorization.
Step 7 Optionally, configure authentication settings for shell access. For more information, see Configuring Shell Access.
Step 8 Test your configuration by entering the name and password for a user who can successfully authenticate. For more information, see Testing User Authentication.
Your changes are saved. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.
Identifying the LDAP Authentication Server
License:
Any
When you create an authentication object, you first specify the primary and backup server and server port where you want the managed device or Defense Center to connect for authentication.
To identify an LDAP authentication server:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click
Create External Authentication Object
.
The Create External Authentication Object page appears.
Step 4 Select
LDAP
from the
Authentication Method
drop-down list.
LDAP configuration options appear.
Step 5 Optionally, select the check box for
CAC
if you plan to use this authentication object for CAC authentication and authorization.
For an overview of configuring CAC authentication and authorization, see Understanding LDAP Authentication With CAC.
Step 6 Type a name and description for the authentication server in the
Name
and
Description
fields.
Step 7 Optionally, in the
Server Type
field, select the type of LDAP server you plan to connect to and click
Set Defaults
to populate the
User Name Template
,
UI Access Attribute
,
Shell Access Attribute
,
Group Member Attribute
, and
Group Member URL Attribute
fields with default values. You have the following options:
-
If you are connecting to a Microsoft Active Directory server, select
MS Active Directory
and click
Set Defaults
.
-
If you are connecting to a Sun Java Systems Directory Server or Oracle Directory Server, select
Oracle Directory
and click
Set Defaults
.
-
If you are connecting to an OpenLDAP server, select
OpenLDAP
and click
Set Defaults
.
-
If you are connecting to a LDAP server other than those listed above and want to clear default settings, select
Other
and click
Set Defaults
.
Step 8 Type the IP address or host name for the primary server where you want to obtain authentication data in the
Primary Server Host Name/IP Address
field.
Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.
Step 9 Optionally, modify the port used by the primary authentication server in the
Primary Server Port
field.
Step 10 Optionally, type the IP address or host name for the backup server where you want to obtain authentication data in the
Backup Server Host Name/IP Address
field.
Step 11 Optionally, modify the port used by the primary authentication server in the
Backup Server Port
field.
Continue with Configuring LDAP-Specific Parameters.
Configuring LDAP-Specific Parameters
License:
Any
The settings in the LDAP-specific parameters section determine the area of the LDAP directory where the appliance searches for user names, and control details of how the appliance connects to the LDAP server.
When configuring these settings, note that valid user names are unique, and can include underscores (_), periods (.), and hyphens (-), but otherwise only alphanumeric characters are supported.
In addition for most LDAP-specific settings, you can use LDAP naming standards and filter and attribute syntax. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type
JoeSmith@security.example.com
rather than the equivalent user distinguished name of
cn=JoeSmith,ou=security, dc=example,dc=com
when using Microsoft Active Directory Server.
The following table describes each of the LDAP-specific parameters.
Table 61-2 LDAP-Specific Parameters
|
|
|
Base DN
|
Supplies the base distinguished name of the directory where the appliance searches for user information on the LDAP server.
Typically, the base DN has a basic structure indicating the company domain and operational unit.
Note that after you identify a primary server, you can automatically retrieve a list of available base DNs from the server and select the appropriate base DN.
|
The Security organization of the Example company might have a base DN of
ou=security, dc=example,dc=com
|
Base Filter
|
Focuses your search by only retrieving objects in the base DN that have the specific attribute-value pair set in the filter. Note that you must enclose the base filter in parentheses.
To test your base filter more specifically by entering a test user name and password, see Testing User Authentication.
|
To filter for only users with a common name starting with F, use the filter
(cn=F*)
.
|
User Name/ Password
|
Allow the local appliance to access the user objects. Supply user credentials for a user with appropriate rights to the authentication objects you want to retrieve. The distinguished name for the user you specify must be unique to the directory information tree for the LDAP server. Note that server user names associated with a Microsoft Active Directory Server cannot end with the
$
character.
|
The user name for the
admin
user in the Security organization of the Example company might have a user name of
cn=admin,
ou=security,
dc=example,dc=com
|
Encryption
|
Determines whether and how the communications are encrypted. You can choose no encryption, Transport Layer Security (TLS), or Secure Sockets Layer (SSL) encryption. Note that if you are using a certificate to authenticate when connecting via TLS or SSL, the name of the LDAP server in the certificate
must
match the name that you use to connect.
If you change the encryption method after specifying the port, the port resets to the default value for the selected server type.
|
If you enter
10.10.10.250
in the external authentication settings and
computer1.
example.com
in the certificate, the connection fails, even if
computer1.
example.com
has an IP address of
10.10.10.250
. Changing the name of the server in the external authentication settings to
computer1.
example.com
causes the connection to succeed.
|
SSL Certificate Upload Path
|
Indicates the path on your local computer to the certificate to be used for encryption.
|
c:/server.crt
|
User Name Template
|
Indicates how user names entered on login should be formatted, by mapping the string conversion character (
%s
) to the value of the shell access attribute for the user. The user name template is the format for the distinguished name used for authentication. When a user enters a user name into the login page, the appliance substitutes the name for the string conversion character and uses the resulting distinguished name to search for the user credentials.
If you want to use this object for CAC authentication and authorization, you
must
enter a value that corresponds with your
UI Access Attribute
value. For more information, see Understanding LDAP Authentication With CAC.
|
%s@security.example.com
,
%s@mail.com
,
%s@mil
,
%s@smil.mil
,
|
Timeout
|
Sets a timeout for the connection attempt to the primary server, so the connection rolls over to the backup server. If the number of seconds indicated in this field (or the timeout on the LDAP server) elapses without a response from the primary authentication server, the appliance then queries the backup server.
However, if LDAP is running on the port of the primary LDAP server and for some reason refuses to service the request, the failover to the backup server does not occur.
|
If the primary server has LDAP disabled, the appliance queries the backup server.
|
UI Access Attribute
|
Tells the local appliance to match the value of a specific attribute rather than the value of the user distinguished name. You can use any attribute, if the value of the attribute is a valid user name for the FireSIGHT System web interface. If one of the objects has a matching user name and password, the user login request is authenticated.
Selecting a server type and setting defaults prepopulates the
UI Access Attribute
with a value typically appropriate for that type of server.
If you leave this field blank, the local appliance checks the user distinguished name value for each user record on the LDAP server to see if it matches the user name.
If you want to use this object for CAC authentication and authorization, you
must
enter a value that corresponds with your
User Name Template
value. For more information, see Understanding LDAP Authentication With CAC.
|
sAMAccountName,
userPrincipalName,
mail
|
Shell Access Attribute
|
If you want to check a specific attribute for shell access credentials, you must explicitly set this field to match the attribute. You can use any attribute if the value of the attribute is a valid user name for shell access.
If you leave this field blank, the user distinguished name is used for shell access authentication.
Note that selecting a server type and setting defaults prepopulates this field with an attribute typically appropriate for that type of server.
|
sAMAccountName
|
To configure the LDAP-specific parameters for a server:
Access:
Admin
Step 1 In the
LDAP-Specific Parameters
section of the Create External Authentication Object page, you have two options for setting the base DN:
-
To fetch a list of all available domains, click
Fetch DNs
and select the appropriate base domain name from the drop-down list.
-
Type the base distinguished name for the LDAP directory you want to access in the
Base DN
field.
For example, to authenticate names in the Security organization at the Example company, type or select
ou=security,dc=example,dc=com
.
Step 2 Optionally, to set a filter that retrieves only specific objects within the directory you specified as the Base DN, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the
Base Filter
field.
For example, if the user objects in a directory tree have a physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of
NewYork
for that attribute, to retrieve only users in the New York office, type
(physicalDeliveryOfficeName=NewYork)
.
Step 3 Type the distinguished name and password for the user whose credentials should be used to validate access to the LDAP directory in the
User Name
and
Password
fields.
For example, if you are connecting to an OpenLDAP server where user objects have a
uid
attribute and the object for the administrator in the Security division at our example company has a
uid
value of
NetworkAdmin
, you might type
uid=NetworkAdmin,ou=security,dc=example,dc=com.
Caution If you are connecting to a Microsoft Active Directory Server, you cannot provide a server user name that ends with the
$
character.
Step 4 Retype the password in the
Confirm Password
field.
Step 5 After you configure the basic LDAP-specific parameters, you have several options:
-
To access advanced options, click the arrow next to
Show Advanced Options
and continue with the next step.
-
If you want to configure user default roles based on LDAP group membership, continue with Configuring Access Rights by Group.
-
If you are not using LDAP groups for authentication, continue with Configuring Shell Access.
Step 6 Optionally, select one of the following encryption modes:
-
To connect using Secure Sockets Layer (SSL), select
SSL
.
-
To connect using Transport Layer Security (TLS), select
TLS
.
-
To connect without encryption, select
None
.
Note Note that if you change the encryption method after specifying a port, you reset the port to the default value for that method. For none or TLS, the port uses the default value of 389. If you select SSL encryption, the port uses the default of 636.
Step 7 If you selected TLS or SSL encryption and you want to use a certificate to authenticate, click
Browse
to browse to the location of a valid TLS or SSL certificate or, in the
SSL Certificate Upload Path
field, type the path to the certificate.
A message appears, indicating a successful certificate upload.
Note If you previously uploaded a certificate and want to replace it, upload the new certificate and reapply the system policy to your appliances to copy over the new certificate.
Step 8 Optionally, in the
User Name Template
field, type the string conversion character (
%s
) used to determine the user name from the value found in the
UI Access Attribute
.
For example, to authenticate all users who work in the Security organization of our example company by connecting to an OpenLDAP server where the shell access attribute is
uid
, you might type
uid=%s,ou=security,dc=example,dc=com
in the
User Name Template
field. For a Microsoft Active Directory server, you could type
%s@security.example.com.
If you want to use CAC credentials for authentication and authorization, you
must
enter a value in the
User Name Template
field. For more information, see Understanding LDAP Authentication With CAC.
Step 9 Optionally, in the
Timeout
field, type the number of seconds that should elapse before rolling over to the backup connection.
Step 10 Optionally, to retrieve users based on an attribute instead of the Base DN and Base Filter, you have two options:
-
Click
Fetch Attrs
to retrieve a list of available attributes and select the appropriate attribute.
-
Type the attribute in the
UI Access Attribute
field.
For example, on a Microsoft Active Directory Server, you may want to use the UI Access Attribute to retrieve users, because there may not be a
uid
attribute on Active Directory Server user objects. Instead, you can search the
userPrincipalName
attribute by typing
userPrincipalName
in the
UI Access Attribute
field.
If you want to use CAC credentials for authentication and authorization, you
must
enter a value in the
UI Access Attribute
field. For more information, see Understanding LDAP Authentication With CAC.
Step 11 Optionally, to retrieve users for shell access, type the attribute to filter by in the
Shell Access Attribute
field.
For example, on a Microsoft Active Directory Server, use the
sAMAccountName
shell access attribute to retrieve shell access users by typing
sAMAccountName
in the
Shell Access Attribute
field.
Note You cannot configure CAC authentication and authorization and shell access in the same authentication object. Selecting the CAC check box disables the shell access configuration options on the page. Instead, create separate authentication objects and enable them separately in your system policy. For more information, see Enabling External Authentication.
Step 12 For the next step, you have three choices:
Configuring Access Rights by Group
License:
Any
If you prefer to base default access rights on a user’s membership in an LDAP group, you can specify distinguished names for existing groups on your LDAP server for each of the access roles used by your FireSIGHT System. When you do so, you can configure a default access setting for those users detected by LDAP that do not belong to any specified groups. When a user logs in, the FireSIGHT System dynamically checks the LDAP server and assigns default access rights according to the user’s current group membership.
If you plan to use an object for CAC authentication and authorization, Cisco recommends configuring LDAP groups to manage access role assignments for CAC-authenticated users. For more information, see Managing CAC Authentication and Authorization.
Any group you reference must exist on the LDAP server. You can reference static LDAP groups or dynamic LDAP groups. Static LDAP groups are groups where membership is determined by group object attributes that point to specific users, and dynamic LDAP groups are groups where membership is determined by creating an LDAP search that retrieves group users based on user object attributes. Group access rights for a role only affect users who are members of the group.
The access rights granted when a user logs into the FireSIGHT System depend on the LDAP configuration:
-
If no group access rights are configured for your LDAP server, when a new user logs in, the FireSIGHT System authenticates the user against the LDAP server and then grants user rights based on the default minimum access role set in the system policy.
-
If you configure any group settings, new users belonging to specified groups inherit the minimum access setting for the groups where they are members.
-
If a new user does not belong to any specified groups, the user is assigned the default minimum access role specified in the Group Controlled Access Roles section of the authentication object.
-
If a user belongs to more than one configured group, the user receives the access role for the group with the highest access as a minimum access role.
You cannot use the FireSIGHT System user management page to remove the minimum access rights for users assigned an access role because of LDAP group membership. You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of
External - Locally Modified
.
Note If you use a dynamic group, the LDAP query is used exactly as it is configured on the LDAP server. For this reason, the FireSIGHT System limits the number of recursions of a search to four to prevent search syntax errors from causing infinite loops. If a user’s group membership is not established in those recursions, the default access role defined in the Group Controlled Access Roles section is granted to the user.
To configure default roles based on group membership:
Access:
Admin
Step 1 On the Create External Authentication Object page, click the down arrow next to
Group Controlled Access Roles
.
The section expands.
Step 2 Optionally, configure access defaults by group membership.
In the
DN
fields that correspond to FireSIGHT System user roles, type the distinguished name for the LDAP groups that contain users who should be assigned to those roles.
For example, you might type the following in the
Administrator
field to authenticate names in the information technology organization at the
Example
company:
cn=itgroup,ou=groups, dc=example,dc=com
For more information on user access roles, see Adding New User Accounts.
Step 3 From the
Default User Role
list, select the default minimum access role for users that do not belong to any of the specified groups.
Tip Press the Ctrl key while clicking role names to select multiple roles.
Step 4 If you used static groups, in the
Group Member Attribute
field, type the LDAP attribute that designates membership in a static group.
For example, if the
member
attribute is used to indicate membership in the static group you reference for default Security Analyst access, type
member
.
Step 5 If you used dynamic groups, in the
Group Member URL Attribute
field, type the LDAP attribute that contains the LDAP search string used to determine membership in a dynamic group.
For example, if the
memberURL
attribute contains the LDAP search that retrieves members for the dynamic group you specified for default Admin access, type
memberURL
.
Step 6 Continue with Configuring Shell Access.
Configuring Shell Access
License:
Any
You can also use the LDAP server to authenticate accounts for shell access on your managed device or Defense Center. Specify a search filter that retrieves entries for users you want to grant shell access.
You
cannot
configure CAC authentication and authorization and shell access in the same authentication object. Instead, create separate authentication objects and enable them separately in your system policy. The authentication object for shell access must be the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.
Note Cisco does not support external authentication for virtual devices or Cisco NGIPS for Blue Coat X-Series. In addition, IPv6 is not supported for shell access authentication.
With the exception of the admin account, shell access is controlled entirely though the shell access attribute you set. The shell access filter you set determines which set of users on the LDAP server can log into the shell.
Note that a home directory for each shell user is created on login, and when an LDAP shell access user account is disabled (by disabling the LDAP connection), the directory remains, but the user shell is set to
/bin/false
in
/etc/password
to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.
The
Same as Base Filter
check box allows you to search more efficiently if all users qualified in the base DN are also qualified for shell access privileges. Normally, the LDAP query to retrieve users combines the base filter with the shell access filter. If the shell access filter was the same as the base filter, the same query runs twice, which is unnecessarily time-consuming. You can use the
Same as Base Filter
option to run the query only once for both purposes.
Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.
Caution On Series 3 Defense Centers, all shell users have
sudoers
privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the
Configuration level of command line access, which also grants
sudoers
privileges.
To configure shell account authentication:
Access:
Admin
Step 1 Optionally, on the Create External Authentication Object page, set a shell access account filter. You have multiple options:
-
To retrieve administrative user entries based on attribute value, type the attribute name, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the
Shell Access Filter
field.
-
To use the same filter you specified when configuring authentication settings, select
Same as Base Filter
.
-
To prevent LDAP authentication of shell access, leave the field blank. If you choose not to specify a shell access filter, a warning displays when you save the authentication object to confirm that you meant to leave the filter blank.
For example, if all network administrators have a
manager
attribute which has an attribute value of
shell
, you can set a base filter of
(manager=shell)
.
Step 2 Continue with Testing User Authentication.
Testing User Authentication
License:
Any
After you configure LDAP server and authentication settings, you can specify user credentials for a user who should be able to authenticate to test those settings.
For the user name, you can enter the value for the
uid
attribute for the user you want to test with. If you are connecting to a Microsoft Active Directory Server and supplied a shell access attribute in place of
uid
, use the value for that attribute as the user name. You can also specify a fully qualified distinguished name for the user.
The test output lists valid and invalid user names. Valid user names are unique, and can include underscores (_), periods (.), and hyphens (-), but otherwise only alphanumeric characters are supported. Invalid user names are user names containing other non-alphanumeric characters, such as spaces.
Note that testing the connection to servers with more than 1000 users only returns 1000 users because of web interface page size limitations.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct. Test the server configuration without the additional test parameters first. If that succeeds supply a user name and password to test with the specific user.
To test user authentication:
Access:
Admin
Step 1 In the
User Name
and
Password
fields, type the
uid
value or shell access attribute value and password for the user whose credentials should be used to validate access to the LDAP server.
For example, to test to see if you can retrieve the
JSmith
user credentials at the Example company, type
JSmith.
Step 2 Click
Test
.
A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. You have two options:
-
If the test succeeds, the test output appears at the bottom of the page. Click
Save
. The External Authentication page appears, with the new object listed.
To enable LDAP authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.
LDAP Authentication Object Examples
License:
Any
The following sections provide an example of LDAP configuration using basic settings and an example using more advanced configuration options:
Example: Basic LDAP Configuration
License:
Any
The following figures illustrate a basic configuration of an LDAP login authentication object for a Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4. The connection uses port 389 for access.
This example shows a connection using a base distinguished name of
OU=security,DC=it,DC=example,DC=com
for the security organization in the information technology domain of the Example company.
However, because this server is a Microsoft Active Directory server, it uses the
sAMAccountName
attribute to store user names rather than the
uid
attribute. Selecting the MS Active Directory server type and clicking
Set Defaults
sets the UI Access Attribute to
sAMAccountName
. As a result, the FireSIGHT System checks the
sAMAccountName
attribute for each object for matching user names when a user attempts to log into the FireSIGHT System.
In addition, a Shell Access Attribute of
sAMAccountName
causes each
sAMAccountName
attribute to be checked for all objects in the directory for matches when a user logs into a shell account on the appliance.
Note that because no base filter is applied to this server, the FireSIGHT System checks attributes for all objects in the directory indicated by the base distinguished name. Connections to the server time out after the default time period (or the timeout period set on the LDAP server).
Example: Advanced LDAP Configuration
License:
Any
This example illustrates an advanced configuration of an LDAP login authentication object for a Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4. The connection uses port 636 for access.
This example shows a connection using a base distinguished name of
OU=security,DC=it,DC=example,DC=com
for the security organization in the information technology domain of the Example company. However, note that this server has a base filter of
(cn=*smith)
. The filter restricts the users retrieved from the server to those with a common name ending in
smith
.
The connection to the server is encrypted using SSL and a certificate named
certificate.pem
is used for the connection. In addition, connections to the server time out after 60 seconds because of the
Timeout
setting.
Because this server is a Microsoft Active Directory server, it uses the
sAMAccountName
attribute to store user names rather than the
uid
attribute. Note that the configuration includes a UI Access Attribute of
sAMAccountName
. As a result, the FireSIGHT System checks the
sAMAccountName
attribute for each object for matching user names when a user attempts to log into the FireSIGHT System.
In addition, a Shell Access Attribute of
sAMAccountName
causes each
sAMAccountName
attribute to be checked for all objects in the directory for matches when a user logs into a shell account on the appliance.
This example also has group settings in place. The Maintenance User role is automatically assigned to all members of the group with a
member
group attribute and the base domain name of
CN=SFmaintenance,DC=it,DC=example,DC=com
.
The shell access filter is set to be the same as the base filter, so the same users can access the appliance through the shell as through the web interface.
Editing LDAP Authentication Objects
License:
Any
You can edit an existing authentication object. Your changes do not take effect until you reapply the policy.
To edit an authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click the edit icon (
) next to the object you want to edit.
The Create External Authentication Object page appears.
Step 4 Modify the object settings as needed.
Step 5 Click
Test
.
A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. If the test succeeds, the test output appears at the bottom of the page.
If the test fails, see Tuning Your Basic LDAP Authentication Connection for suggestions for troubleshooting the connection. Note that the error message that appears indicates what caused the connection to fail.
Step 6 Click
Save
.
Your changes are saved and the External Authentication page appears. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.
RADIUS Authentication
The Remote Authentication Dial In User Service (RADIUS) is an authentication protocol used to authenticate, authorize, and account for user access to network resources. You can create an authentication object for any RADIUS server that conforms to RFC 2865.
See the following sections for more information:
Understanding RADIUS Authentication
License:
Any
When a user authenticated on a RADIUS server logs in for the first time, the user receives the roles specified for that user in the authentication object. If the user is not listed for any of the user roles, they receive the default access role you selected in the authentication object. If no default access role is selected in the authentication object, they receive the default access role from the system policy. You can modify a user’s roles, if needed, unless the settings are granted through the user lists in the authentication object. Note that when a user authenticated on a RADIUS server using attribute matching attempts to log in for the first time, the login is rejected as the user account is created. The user must log in a second time.
Note Before enabling external authentication on Series 3 managed devices, remove any internally-authenticated shell users that have the same user name as externally-authenticated users included in your shell access filter.
The FireSIGHT System implementation of RADIUS supports the use of SecurID® tokens. When you configure authentication by a server using SecurID, users authenticated against that server append the SecurID token to the end of their SecurID PIN and use that as their password when they log into a Cisco appliance. As long as SecurID is configured correctly to authenticate users outside the FireSIGHT System, those users can log into a FireSIGHT System appliance using their PIN plus the SecurID token without any additional configuration on the appliance.
Creating RADIUS Authentication Objects
License:
Any
When you create a RADIUS authentication object, you define settings that let you connect to an authentication server. You also grant user roles to specific and default users. If your RADIUS server returns custom attributes for any users you plan to authenticate, you must define those custom attributes. Optionally, you can also configure shell access authentication.
Note that to create an authentication object, you need TCP/IP access from your local appliance to the authentication server where you want to connect.
To create an authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click
Create External Authentication Object
.
The Create External Authentication Object page appears.
Step 4 Identify the primary and backup authentication servers where you want to retrieve user data for external authentication and set timeout and retry values. For more information, see Configuring RADIUS Connection Settings.
Step 5 Set the default user role. Optionally, specify the users or user attribute values for users that you want to receive specific FireSIGHT System access roles. For more information, see Configuring RADIUS User Roles.
Step 6 Optionally, configure administrative shell access. For more information, see Configuring Administrative Shell Access.
Step 7 If the profiles for any of the users to authenticate return custom RADIUS attributes, define those attributes. For more information, see Defining Custom RADIUS Attributes.
Step 8 Test your configuration by entering the name and password for a user who should successfully authenticate. For more information, see Testing User Authentication.
Your changes are saved. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.
Configuring RADIUS Connection Settings
License:
Any
When you create a RADIUS authentication object, you first specify the primary and backup server and server port where you want the local appliance (managed device or Defense Center) to connect for authentication.
Note For RADIUS to function correctly, you must open its authentication and accounting ports (by default, 1812 and 1813) on your firewall.
If you specify a backup authentication server, you can set a timeout for the connection attempt to the primary server. If the number of seconds indicated in the
Timeout
field (or the timeout on the LDAP server) elapses without a response from the primary authentication server, the appliance then re-queries the primary server.
After the appliance re-queries the primary authentication server the number of times indicated by the
Retries
field and the number of seconds indicated in the
Timeout
field again elapses without a response from the primary authentication server, the appliance then rolls over to the backup server.
If, for example, the primary server has RADIUS disabled, the appliance queries the backup server. If RADIUS is running on the port of the primary RADIUS server and for some reason refuses to service the request (due to misconfiguration or other issues), however, the failover to the backup server does not occur.
To identify a RADIUS authentication server:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click
Create External Authentication Object
.
The Create External Authentication Object page appears.
Step 4 Select
RADIUS
from the
Authentication Method
drop-down list.
RADIUS configuration options appear.
Step 5 Type a name and description for the authentication server in the
Name
and
Description
fields.
Step 6 Type the IP address or host name for the primary RADIUS server where you want to obtain authentication data in the
Primary Server Host Name/IP Address
field.
Note IPv6 addresses are not supported for shell authentication. To allow shell authentication when using an IPv6 address for your primary RADIUS server, set up an authentication object using an IPv4 address for the server and use that IPv4 object as the first authentication object in your system policy.
Step 7 Optionally, modify the port used by the primary RADIUS authentication server in the
Primary Server Port
field.
Note If your authentication port and accounting port numbers are not sequential, leave this field blank. The system then determines RADIUS port numbers from the radius
and radacct
data in your appliance’s /etc/services
file.
Step 8 Type the secret key for the primary RADIUS authentication server in the
RADIUS Secret Key
field.
Step 9 Type the IP address or host name for the backup RADIUS authentication server where you want to obtain authentication data in the
Backup Server Host Name/IP Address
field.
Step 10 Optionally, modify the port used by the backup RADIUS authentication server in the
Backup Server Port
field.
Note If your authentication port and accounting port numbers are not sequential, leave this field blank. The system then determines RADIUS port numbers from the radius
and radacct
data in your appliance’s /etc/services
file.
Step 11 Type the secret key for the backup RADIUS authentication server in the
RADIUS Secret Key
field.
Step 12 Type the number of seconds that should elapse before retrying the connection in the
Timeout
field.
Step 13 Type the number of times the primary server connection should be tried before rolling over to the backup connection in the
Retries
field.
Step 14 Continue with Configuring RADIUS User Roles.
Configuring RADIUS User Roles
License:
Any
You can specify the access roles for existing users on your RADIUS server by listing the user names for each of the access roles used by your FireSIGHT System. When you do so, you can also configure a default access setting for those users detected by RADIUS that are not specified for a particular role.
When a user logs in, the FireSIGHT System checks the RADIUS server and grants access rights depending on the RADIUS configuration:
-
If specific access rights are not configured for a user and a default access role is not selected, when a new user logs in, the FireSIGHT System authenticates the user against the RADIUS server and then grants user rights based on the default access role (or roles) set in the system policy.
-
If a new user is not specified on any lists and default access roles are selected in the
Default User Role
list of the authentication object, the user is assigned those access roles.
-
If you add a user to the list for one or more specific role, that user receives all assigned access roles.
You can also use attribute-value pairs, rather than user names, to identify users who should receive a particular user role. For example, if you know all users who should be Security Analysts have the value
Analyst
for their
User-Category
attribute, you can type
User-Category=Analyst
in the Security Analyst List field to grant that role to those users. Note that you need to define any custom attributes before you use them to set user role membership. For more information, see Defining Custom RADIUS Attributes.
You can assign a default user role (or roles) to be assigned to any users that are authenticated externally but not listed for a specific role. You can select multiple roles on the
Default User Role
list.
For more information on the user roles supported by the FireSIGHT System, see Configuring RADIUS User Roles.
You cannot remove the minimum access rights for users assigned an access role because of RADIUS user list membership through the FireSIGHT System user management page. You can, however, assign additional rights.
Caution If you want to change the minimum access setting for a user, you must not only move the user from one list to another in the RADIUS Specific Parameters section or change the user’s attribute on the RADIUS server, you must reapply the system policy, and you must remove the assigned user right on the user management page.
To base access on user lists:
Access:
Admin
Step 1 In the fields that correspond to FireSIGHT System user roles, type the name of each user or identifying attribute-value pair that should be assigned to those roles. Separate usernames and attribute-value pairs with commas.
For example, to grant the Administrator role to the users
jsmith
and
jdoe
, type
jsmith, jdoe
in the
Administrator
field.
As another example, to grant the Maintenance User role to all users with a
User-Category
value of
Maintenance
, type
User-Category=Maintenance
in the
Maintenance User
field.
For more information on user access roles, see Configuring User Roles.
Step 2 Select the default minimum access role for users that do not belong to any of the specified groups from the
Default User Role
list.
Tip Press the Ctrl key while clicking role names to select multiple roles.
Step 3 Continue with Configuring Administrative Shell Access.
Configuring Administrative Shell Access
License:
Any
You can also use the RADIUS server to authenticate accounts for shell access on your local appliance (managed device or Defense Center). Specify user names for users you want to grant shell access. Note that you can only configure shell access for the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.
Note IPv6 addresses are not supported for shell authentication. If you configure a primary RADIUS server with an IPv6 address and also configure administrative shell access, the shell access settings are ignored. To allow shell authentication when using an IPv6 address for your primary RADIUS server, set up another authentication object using an IPv4 address for the server and use that object as the first authentication object in your system policy.
With the exception of the admin account, the shell access list you set on the RADIUS authentication object entirely controls shell access on the appliance. Shell users are configured as local users on the appliance when the system policy is applied. Note that when a user authenticated on a RADIUS server using attribute matching attempts to log in for the first time, the login is rejected as the user account is created. The user must log in a second time.
Note that a home directory for each shell user is created on login, and when an RADIUS shell access user account is disabled (by disabling the RADIUS connection), the directory remains, but the user shell is set to
/bin/false
in
/etc/password
to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.
Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.
Caution On Series 3 Defense Centers, all shell users have
sudoers
privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the
Configuration level of command line access, which also grants
sudoers
privileges.
To configure shell account authentication:
Access:
Admin
Step 1 Type the user names, separated by commas, in the
Administrator Shell Access User List
field.
Note If you choose not to specify a shell access filter, a warning displays when you save the authentication object to confirm that you meant to leave the filter blank.
Step 2 Continue with Defining Custom RADIUS Attributes.
Defining Custom RADIUS Attributes
License:
Any
If your RADIUS server returns values for attributes not included in the
dictionary
file in
/etc/radiusclient/
and you plan to use those attributes to set user roles for users with those attributes, you need to define those attributes in the login authentication object.
You can locate the attributes returned for a user by looking at the user’s profile on your RADIUS server.
When you define an attribute, you provide the name of the attribute, which consists of alphanumeric characters. Note that words in an attribute name should be separated by dashes rather than spaces. You also provide the attribute ID, which should be an integer and should not conflict with any existing attribute IDs in the
etc/radiusclient/dictionary
file. You also specify the type of attribute: string, IP address, integer, or date.
As an example, if a RADIUS server is used on a network with a Cisco router, you might want to use the
Ascend-Assign-IP-Pool
attribute to grant a specific role to all users logging in from a specific IP address pool.
Ascend-Assign-IP-Pool
is an integer attribute that defines the address pool where the user is allowed to log in, with the integer indicating the number of the assigned IP address pool. To declare that custom attribute, you create a custom attribute with an attribute name of
Ascend-IP-Pool-Definition
, an attribute ID of
218
, and an attribute type of
integer
. You could then type
Ascend-Assign-IP-Pool=2
in the
Security Analyst (Read Only)
field to grant read-only security analyst rights to all users with an
Ascend-IP-Pool-Definition
attribute value of
2.
When you create a RADIUS authentication object, a new dictionary file for that object is created on the FireSIGHT System appliance in the
/var/sf/userauth
directory. Any custom attributes you add to the authentication object are added to the dictionary file.
To define a custom attribute:
Access:
Admin
Step 1 Click the arrow to expand the Define Custom RADIUS Attributes section.
The attribute fields appear.
Step 2 Type an attribute name consisting of alphanumeric characters and dashes, with no spaces, in the
Attribute Name
field.
Step 3 Type the attribute ID, in integer form, in the
Attribute ID
field.
Step 4 Select the type of attribute from the
Attribute Type
drop-down list.
Step 5 Click
Add
to add the custom attribute to the authentication object.
Tip You can remove a custom attribute from an authentication object by clicking Delete next to the attribute.
Step 6 Continue with Testing User Authentication.
Testing User Authentication
License:
Any
After you configure RADIUS connection, user role, and custom attribute settings, you can specify user credentials for a user who should be able to authenticate to test those settings.
For the user name, you can enter the user name for the user you want to test with.
Note that testing the connection to servers with more than 1000 users only returns 1000 users because of UI page size limitations.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct. To verify that the server configuration is correct, click Test without entering user information in the Additional Test Parameters field first. If that succeeds, supply a user name and password to test with the specific user.
To test user authentication:
Access:
Admin
Step 1 In the
User Name
and
Password
fields, type the user name and password for the user whose credentials should be used to validate access to the RADIUS server.
For example, to test to see if you can retrieve the
jsmith
user credentials at our example company, type
jsmith.
Step 2 Select
Show Details
and click
Test
.
A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected.
Step 3 If the test succeeds, click
Save
.
The External Authentication page appears, with the new object listed.
To enable RADIUS authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.
RADIUS Authentication Object Examples
License:
Any
This section provides examples of RADIUS server authentication objects to show how FireSIGHT System RADIUS authentication features can be used. See the following sections for more information:
Example: Authenticating a User Using RADIUS
License:
Any
The following figure illustrates a sample RADIUS login authentication object for a server running FreeRADIUS with an IP address of 10.10.10.98. Note that the connection uses port 1812 for access, and note that connections to the server time out after 30 seconds of disuse, then retry three times before attempting to connect to a backup authentication server.
This example illustrates important aspects of RADIUS user role configuration:
-
Users
ewharton
and
gsand
are granted administrative access to FireSIGHT System appliances where this authentication object is enabled.
-
The user
cbronte
is granted Maintenance User access to FireSIGHT System appliances where this authentication object is enabled.
-
The user
jausten
is granted Security Analyst access to FireSIGHT System appliances where this authentication object is enabled.
-
The user
ewharton
can log into the appliance using a shell account.
The following graphic depicts the role configuration for the example:
Example: Authenticating a User with Custom Attributes
License:
Any
You can use an attribute-value pair to identify users who should receive a particular user role. If the attribute you use is a custom attribute, you must define the custom attribute.
The following figure illustrates the role configuration and custom attribute definition in a sample RADIUS login authentication object for the same FreeRADIUS server as in the previous example.
In this example, however, the
MS-RAS-Version
custom attribute is returned for one or more of the users because a Microsoft remote access server is in use. Note the
MS-RAS-Version
custom attribute is a string. In this example, all users logging in to RADIUS through a Microsoft v. 5.00 remote access server should receive the Security Analyst (Read Only) role, so you type the attribute-value pair of
MS-RAS-Version=MSRASV5.00
in the
Security Analyst (Read Only)
field.
Editing RADIUS Authentication Objects
License:
Any
You can edit an existing authentication object. If the object is in use in a system policy, the settings in place at the time the policy was applied stay in effect until you reapply the policy.
To edit an authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click the edit icon (
) next to the object you want to edit.
The Create External Authentication Object page appears.
Step 4 Modify the object settings as needed.
Step 5 Click
Save
.
Your changes are saved and the External Authentication page reappears. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.
Deleting Authentication Objects
License:
Any
You can delete an authentication object if it is not currently enabled in a system policy.
To delete an authentication object:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
External Authentication
tab.
The External Authentication page appears.
Step 3 Click the delete icon (
) next to the object you want to delete.
The object is deleted and the External Authentication page appears.
Managing User Accounts
License:
Any
If you have Administrator access, you can use the web interface to view and manage user accounts on a Defense Center or a managed device, including adding, modifying, and deleting accounts. You can also create and modify custom user roles and configure user role escalation. User accounts without Administrator access are restricted from accessing management features. The navigation menu differs in appearance for each type of user.
See the following sections for more information about managing user accounts:
Viewing User Accounts
License:
Any
From the User Management page, you can view, edit, and delete existing accounts. You can view the type of authentication for a user from the
Authentication Method
column. The
Password Lifetime
column indicates the days remaining on each user’s password. The icons in the
Action
column allow you to edit users in more detail and set users active or inactive. Note that for externally authenticated users, if the authentication object for the server is disabled, the
Authentication Method
column displays
External (Disabled)
.
To access the User Management page:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears, showing each user, with options to activate, deactivate, edit, or delete the user account.
See the following sections for information about the actions you can perform on the User Management page:
Adding New User Accounts
License:
Any
Supported Devices:
feature dependent
When you set up a new user account, you can control which parts of the system the account can access. You can set password expiration and strength settings for the user account during creation. For a local account on a Series 3 device, you can also configure the level of command line access the user will have.
To add a new user:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click
Create User
.
The Create User page appears.
Step 3 In the
User Name
field, type a name for the new user.
New user names must contain alphanumeric or hyphen characters with no spaces, and must be no more than 32 characters. User names are case sensitive.
Step 4 If you want this user to authenticate to an external directory server on login, select
Use External Authentication Method
.
If you enable this option, the password management options disappear. Skip to step
8
to continue with configuring an access role for the user.
Note that for users to authenticate to an external directory server, you must use the Defense Center to create an authentication object for the server you want to use, then apply a system policy with authentication enabled. In addition, the external authentication server must be available in order for those users to log into FireSIGHT System appliances. For more information, see Managing Authentication Objects and Enabling External Authentication.
Step 5 In the
Password
and
Confirm Password
fields, type a password (up to 32 alphanumeric characters).
If you enable password strength checking, the password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character and one special character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.
Note If you enable STIG compliance on an appliance, see the FireSIGHT System STIG Release Notes for more information on password settings for shell access users.
Step 6 Configure the remaining user account login options.
For more information, see the
User Account Login Options
table.
Step 7 If you are creating a local user through the web interface of a Series 3 device, you can assign the level of
Command-Line Interface Access
for the user:
-
Select
None
to disable access to the command line for the user.
-
Select
Basic
to allow the user to log into the shell and to access a specific subset of commands.
-
Select
Configuration
to allow the user to log into the shell and use any command line option, including expert mode if that is allowed on the appliance.
For more information on command line access, see Managing Command Line Access.
Step 8 Select access roles to grant to the user.
Note For all physical managed devices, the Cisco-provided predefined user roles are limited to Administrator, Maintenance User, and Security Analyst.
For more information, see Configuring User Roles.
Step 9 Click
Save
.
The user is created and the User Management page appears again.
Tip Click the slider next to the name of an internally authenticated user on the User Management page to reactivate a deactivated user, or to disable an active user account without deleting it.
Managing Command Line Access
License:
Any
Supported Devices:
Series 3, virtual
On a Series 3 or virtual device, you can assign command line interface access to local device users.
Note that you can also assign command line access for users on a virtual device, but you use commands from the command line interface. For more information, see Command Line Reference.
The commands a user can run depend on the level of access you assign to the user. When you set
Command-Line Interface Access
to
None
, the user cannot log into the appliance on the command line. Any session the user starts will close when the user provides credentials. The access level defaults to
None
on user creation. When you set
Command-Line Interface Access
to
Basic
, a specific set of commands can be run by the user
Table 61-3 Basic Command Line Commands
configure password
|
interfaces
|
end
|
lcd
|
exit
|
link-state
|
help
|
log-ips-connection
|
history
|
managers
|
logout
|
memory
|
?
|
model
|
??
|
mpls-depth
|
access-control-config
|
NAT
|
alarms
|
network
|
arp-tables
|
network-modules
|
audit-log
|
ntp
|
bypass
|
perfstats
|
clustering
|
portstats
|
cpu
|
power-supply-status
|
database
|
process-tree
|
device-settings
|
processes
|
disk
|
routing-table
|
disk-manager
|
serial-number
|
dns
|
stacking
|
expert
|
summary
|
fan-status
|
time
|
fastpath-rules
|
traffic-statistics
|
gui
|
version
|
hostname
|
virtual-routers
|
hyperthreading
|
virtual-switches
|
inline-sets
|
|
When you set
Command-Line Interface Access
to
Configuration
, the user can access any of the command line options. Exercise caution in assigning this level of access to users.
Caution Shell access granted to externally authenticated users defaults to the
Configuration level of command line access, granting rights to all command line utilities. For more information on shell access for externally authenticated users, see
Understanding Shell Access and
Configuring Shell Access.
Managing Externally Authenticated User Accounts
License:
Any
When an externally authenticated user logs into an appliance that has external authentication enabled, the appliance grants the user the default access role you set by specifying group membership in the authentication object. If you did not configure access group settings, the appliance grants the default user role you set in the system policy. However, if you add users locally before they log into the appliance, the user privileges you configure on the User Management page override the default settings.
For more information on selecting a default user role, see Enabling External Authentication and Understanding User Privileges. Note that you can set both predefined and custom user roles as the default user role for externally authenticated users. For more information, see Configuring User Roles.
An internally authenticated user is converted to external authentication when all of the following conditions exist:
-
You enable LDAP (with or without CAC) or RADIUS authentication.
-
The same user name exists for the user on the LDAP or RADIUS server.
-
The user logs in using the password stored for that user on the LDAP or RADIUS server.
Note that you can only enable external authentication in a system policy on a Defense Center. You must use the Defense Center to apply the policy to managed devices if you want to use external authentication on them.
After an externally authenticated user logs in to an appliance for the first time, the appliance associates those credentials with a set of permissions by creating a local user record. For more information about user login, see Logging into the Appliance. After initial login, the permissions for that local user record can be modified unless they are granted through group or list membership, as follows:
-
If the default role for externally authenticated user accounts is set to a specific access role, users can log into the appliance using their external account credentials without any additional configuration by the system administrator.
-
If an account is externally authenticated and by default receives no access privileges, users can log in but cannot access any functionality. You (or your system administrator) can then change the permissions to grant the appropriate access to user functionality.
Tip The system does not create a local user account for shell access users. Shell access is controlled entirely through either the shell access filter or PAM login attribute set for an LDAP server, or the shell access list on a RADIUS server.
For more information on modifying user access, see Modifying User Privileges and Options. Note that you cannot manage passwords for externally authenticated users or deactivate externally authenticated users through the FireSIGHT System interface. For externally authenticated users, you cannot remove the minimum access rights through the FireSIGHT System user management page for users assigned an access role because of LDAP group or RADIUS list membership or attribute values. On the Edit User page for an externally authenticated user, rights granted because of settings on an external authentication server are marked with a status of
Externally Modified
.
You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of
External - Locally Modified
.
Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.
Caution On Series 3 Defense Centers, all shell users have
sudoers
privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the
Configuration level of command line access, which also grants
sudoers
privileges. For more information on setting up shell access, see
Understanding Shell Access and
Configuring Shell Access.
Managing User Login Settings
License:
Any
You can control how and when the password for each user account is changed, as well as when user accounts are disabled. If you configured a timeout for web interface login sessions, you can exempt users from this timeout. The following table describes some of the options you can use to regulate passwords and account access.
Note that for locally authenticated users on Series 3 managed devices, changing a user’s password for the web interface also changes that password for the command line interface.
If you enable the
Check Password Strength
option, the minimum password length is automatically set to 8 characters. If you also set a value for
Minimum Password Length
that exceeds 8 characters, the higher value applies.
Note After you enable Use External Authentication Method, login options no longer appear. Use the external authentication server to manage login settings.
Table 61-4 User Account Login Options
|
|
Use External Authentication Method
|
Select this check box if you want this user's credentials to be externally authenticated.
Note If you select this option for the user and the external authentication server is unavailable, that user can log into the web interface but cannot access any functionality.
|
Maximum Number of Failed Logins
|
Enter an integer, without spaces, that determines the maximum number of times each user can try to log in after a failed login attempt before the account is locked. The default setting is five tries; use 0 to allow an unlimited number of failed logins.
|
Minimum Password Length
|
Enter an integer, without spaces, that determines the minimum required length, in characters, of a user’s password. The default setting is
8
. A value of
0
indicates that no minimum length is required.
|
Days Until Password Expiration
|
Enter the number of days after which the user’s password expires. The default setting is
0
, which indicates that the password never expires.
|
Days Before Password Expiration Warning
|
Enter the number of warning days users have to change their password before their password actually expires. The default setting is 0 days.
Caution The number of warning days must be less than the number of days before the password expires.
|
Force Password Reset on Login
|
Select this option to force users to change their passwords the first time they log in.
|
Check Password Strength
|
Select this option to require strong passwords. A strong password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character and one special character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.
|
Exempt from Browser Session Timeout
|
Select this option if you do not want a user’s login sessions to terminate due to inactivity. Users with the Administrator role cannot be made exempt. For more information on session timeouts, see Configuring User Interface Settings.
|
Configuring User Roles
License:
Any
Each FireSIGHT System user has an associated user access role or roles. For example, an analyst needs access to event data to analyze the security of your network, but might not require access to administrative functions for the FireSIGHT System itself. Using user roles, you can, for example, grant Security Analyst access to analysts while reserving the Administrator role for the user or users managing the FireSIGHT System. The FireSIGHT System includes ten predefined user roles designed for a variety of administrators and analysts. You can also create custom user roles with specialized access privileges.
The menus and other options in the web interface that users can access depend on their roles. Predefined user roles have a set of predetermined access privileges, while custom user roles have granular access privileges that their creator determines.
You configure user roles on the User Roles page.
To access the User Roles page:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
User Roles
tab.
The User Roles page appears, showing all predefined and custom user roles, with options to activate, deactivate, edit, copy, delete, and export roles.
For more information on configuring the two types of user roles, see the following sections:
Managing Predefined User Roles
License:
Any
The FireSIGHT System includes ten predefined user roles that provide a range of access privilege sets to meet the needs of your organization. On the User Roles page, predefined user roles are labeled “Cisco Provided”. Note that managed devices have access to only three of the ten predefined user roles: Administrator, Maintenance User, and Security Analyst.
Although you cannot edit predefined user roles, you can use their access privilege sets as the basis for custom user roles. For information on creating and editing custom user roles, see Managing Custom User Roles. In addition, because you cannot edit predefined user roles, you cannot configure them to escalate to another user role. For more information, see Managing User Role Escalation.
The following table briefly describes the predefined roles available to you. For a list of the menus and options available to each role, see User Account Privileges.
Table 61-5 Predefined User Roles
|
|
Access Admin
|
Provides access to access control, SSL inspection, and file policy features. Note, however, that Access Admins cannot apply access control policies. Access Admins have access to access control, SSL inspection, and file-related options in the
Policies
menu.
|
Administrator
|
Provides access to analysis and reporting features, rule and policy configuration, system management, and all maintenance features. Administrators have access to all menu options; their sessions present a higher security risk if compromised, so you cannot make them exempt from login session timeouts.
Note that you should limit use of the Administrator role for security reasons.
This role is also available on managed devices.
|
Discovery Admin
|
Provides access to network discovery, correlation, and user activity features. Discovery Admins have access to relevant options in the
Policies
menu.
|
External Database User
|
Provides read-only access to the FireSIGHT System database using an application that supports JDBC SSL connections. Note that for the third-party application to authenticate to the FireSIGHT System appliance, you must enable database access in the system settings as described in Enabling Access to the Database. On the web interface, External Database Users have access only to online help-related options in the
Help
menu. Because this role’s function does not involve the web interface, access is provided only for ease of support and password changes.
|
Intrusion Admin
|
Provides access to all intrusion policy, intrusion rule, and network analysis policy features. Intrusion Admins have access to intrusion-related options in the
Policies
menu. Note that Intrusion Admins cannot apply intrusion or network analysis policies as part of access control policies.
|
Maintenance User
|
Provides access to monitoring and maintenance features. Maintenance Users have access to maintenance-related options in the
Health
and
System
menus.
This role is also available on managed devices.
|
Network Admin
|
Provides access to access control, SSL inspection, and device configuration features. Network Admins have access to access control, SSL inspection, and device-related options in the
Policies
and
Devices
menus.
|
Security Analyst
|
Provides access to security event analysis features, including event views, reports, hosts, host attributes, services, vulnerabilities, client applications, and read-only access to health events. Security Analysts have access to analysis-related options in the
Overview
,
Analysis
,
Health
, and
System
menus.
This role is also available on managed devices.
|
Security Analyst (Read Only)
|
Provides read-only access to security event analysis features, including event views, reports, hosts, host attributes, services, vulnerabilities, client applications, and health events. Security Analysts have access to analysis-related options in the
Overview
,
Analysis
,
Health
, and
System
menus.
|
Security Approver
|
Provides limited access to access control, intrusion, file, SSL, and network discovery policies. Security Approvers can view these policies and apply network discovery, intrusion, and access control policies, but cannot make policy changes. They have access to applicable policy-related options in the
Policies
menu.
|
Along with assigning an event analyst role to a user, you can restrict that user’s deletion rights to only allow deletion of report profiles, searches, bookmarks, custom tables, and custom workflows created by that user. For more information, see Adding New User Accounts.
Note that externally authenticated users, if assigned no other roles, have minimum access rights based on the settings in LDAP or RADIUS authentication objects and in the system policy. You can assign additional rights to these users, but to remove or change minimum access rights, you must perform the following tasks:
-
Move the user from one list to another in the authentication object or change the user's attribute value or group membership on the external authentication server.
-
Reapply the system policy.
-
Use the User Management page to remove the access from that user account.
You cannot delete predefined user roles, but you can deactivate them. Deactivating a role removes that role and all associated permissions from any user who is assigned that role.
Caution If a deactivated role is the only role assigned to a given user, that user can log in and access the User Preferences menu, but is otherwise unable to access the FireSIGHT System.
To activate or deactivate a user role:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
User Roles
tab.
The User Roles page appears.
Step 3 Click the slider next to the user role you want to activate or deactivate.
Note If you deactivate, then reactivate, a role with Lights-Out Management while a user with that role is logged in, or restore a user or user role from a backup during that user’s login session, that user must log back into the web interface to regain access to IPMItool commands. For more information, see Using Lights-Out Management.
Managing Custom User Roles
License:
Any
In addition to the predefined user roles, you can also create custom user roles with specialized access privileges. Custom user roles can have any set of menu-based and system permissions, and may be completely original or based on a predefined user role. Like predefined user roles, custom roles can serve as the default role for externally authenticated users. Unlike predefined roles, you can modify and delete custom roles.
Selectable permissions are hierarchical, and are based on the FireSIGHT System menu layout. Permissions are expandable if they have sub-pages or if they have more fine-grained permissions available beyond simple page access. In that case, the parent permission grants page view access and the children granular access to related features of that page. For example, the Correlation Events permission grants access to the Correlation Events page, while the Modify Correlation Events check box allows the user to edit and delete the information available on that page. Permissions that contain the word “Manage” grant the ability to edit and delete information that other users create.
Tip For pages or features not included in the menu structure, privileges are granted by parent or related pages. For example, the Modify Intrusion Policy privilege also allows you to modify network analysis policies.
You can apply restricted searches to a custom user role. These constrain the data a user may see in the event viewer. You can configure a restricted search by first creating a private saved search and selecting it from the “Restricted Search” drop-down menu under the appropriate menu-based permission. For more information, see Performing a Search.
When you configure a custom user role on a Defense Center, all menu-based permissions are available for you to grant. When you configure a custom user role on a managed device, only some permissions are available — those relevant to device functions. For more information on the menu-based permissions you can configure and their relationship with predefined user roles, see:
The selectable options under System Permissions allow you to create a user role that can make queries to the external database or escalate to the permissions of a target user role. For more information, see Enabling Access to the Database and Managing User Role Escalation.
Optionally, instead of creating a new custom user role, you can export a custom user role from another appliance, then import it onto your appliance. You can then edit the imported role to suit your needs before you apply it. For more information, see Exporting Configurations and Importing Configurations.
To create a custom user role:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
User Roles
tab.
The User Roles page appears.
Step 3 Click
Create User Role
.
The User Role Editor page appears.
Step 4 In the
Name
field, type a name for the new user role.
You can use alphanumeric or hyphen characters, without spaces. Role names must be no more than 75 characters. User role names are case sensitive.
Step 5 Optionally, add a description for the new role in the
Description
field.
Role descriptions must be no more than 255 characters.
Step 6 Select permissions for the new role.
When you select an unselected permission, all of its children are selected, and the multi-value permissions choose the first value. If you clear a high-level permission, all of its children are cleared also. Selected permissions without all children selected appear in italic text.
Note that choosing to copy a predefined user role to use as the base for your custom role preselects the permissions associated with that predefined role. For more information on copying predefined user roles, see Creating a Custom Copy of a Predefined User Role.
The current escalation target role is listed beside the role escalation check box. If you select this check box, you can then choose to authenticate escalations either with the assigned user’s password or with the password of another specified user role. For more information, see Managing User Role Escalation.
Step 7 Click
Save
.
The custom user role is created and the User Roles page appears again.
Creating a Custom Copy of a Predefined User Role
License:
Any
You can copy an existing role to use as the basis for a new custom role. This preselects the existing role’s permissions in the User Role Editor so you can model one role on another.
To create a custom copy of a predefined user role:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
User Roles
tab.
The User Roles page appears.
Step 3 Click the copy icon (
) next to the user role you want to copy.
The User Role Editor page appears with the copied role’s permissions preselected.
Note that you can copy both custom and predefined user roles in this way.
Deleting a Custom User Role
License:
Any
Unlike predefined user roles, you can delete custom roles that are no longer necessary. If you want to disable a custom role without removing it entirely, you can deactivate it instead; for more information, refer to the procedure in Managing Predefined User Roles. Note that you cannot delete your own user role or a role that is set as a default user role in the system policy. For more information, see Enabling External Authentication.
To delete a custom user role:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the
User Roles
tab.
The User Roles page appears.
Step 3 Click the delete icon (
) next to the custom role you want to delete.
The custom role is deleted.
If a deleted role is the only role assigned to a given user, that user can log in and access the User Preferences menu, but is otherwise unable to access the FireSIGHT System.
Modifying User Privileges and Options
License:
Any
After adding user accounts to the system, you can modify access privileges, account options, or passwords at any time. Note that password management options do not apply to users who authenticate to an external directory server. You manage those settings on the external server. However, you must configure access rights for all accounts, including those that are externally authenticated.
For externally authenticated users, you cannot remove the minimum access rights through the FireSIGHT System user management page for users assigned an access role because of LDAP group or RADIUS list membership or attribute values. You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of
External - Locally Modified
.
Note that if you change the authentication for a user from externally authenticated to internally authenticated, you must supply a new password for the user.
To modify user account privileges:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Click the edit icon (
) next to the user you want to modify.
The Edit User page appears.
Step 3 Modify the account or accounts as needed:
Understanding Restricted User Access Properties
License:
Any
You can restrict the data that a user role can view in the event viewer by applying a restricted search to that role. You can specify this information when creating or editing the role assigned to a user. To create a custom role with restricted access, you must choose the tables you want to restrict from the Menu Based Permissions list, then select private saved searches from the Restrictive Search drop-down lists. For more information, see Managing Custom User Roles.
Modifying User Passwords
License:
Any
You can modify user passwords from the User Management page for internally authenticated users. Note that you must manage externally authenticated user passwords on the LDAP or RADIUS server.
Note If you enable STIG compliance or Lights-Out Management (LOM) on an appliance, different password restrictions apply. For more information on password settings for shell access users on systems with STIG compliance enabled, see the FireSIGHT System STIG Release Notes. For more information on password settings for the system password for LOM users, see Enabling Lights-Out Management User Access.
To change a user’s password:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Next to the user name, click the edit icon (
).
The Edit User page appears.
Step 3 In the
Password
field, type the new password (up to 32 alphanumeric characters).
Step 4 In the
Confirm Password
field, retype the new password.
If password strength checking is enabled for the user account, the password must have at least eight alphanumeric characters of mixed case, with at least one number and one special character. It cannot be a word that appears in a dictionary or contain consecutive repeating characters.
Step 5 Make any other changes you want to make to the user configuration:
Step 6 Click
Save
.
The password is changed and any other changes saved.
Deleting User Accounts
License:
Any
You can delete user accounts from the system at any time, with the exception of the admin account, which cannot be deleted.
To delete a user account:
Access:
Admin
Step 1 Select
System > Local > User Management
.
The User Management page appears.
Step 2 Next to the user whose account you want to delete, click the delete icon (
). The account is deleted.
User Account Privileges
License:
Any
The following sections provide a list of the configurable user permissions in the FireSIGHT System and the user roles that can access them. The permissions listed here follow the order of the Menu Based Permissions list that appears when you create a custom user role. Not all permissions are available on managed devices; permissions available only on the Defense Center are marked accordingly. For more information, see Managing Custom User Roles.
Note that because the DC500 Defense Center and Series 2 devices support restricted features sets, not all permissions are applicable to these appliances. See the
Supported Access Control Capabilities by Device Model
table for a summary of Series 2 appliance features.
For more information on the access notations used in the tables that follow and throughout this documentation, see Access Conventions. The following sections refer to the user role privileges associated with each main menu in the web-based interface:
Overview Menu
License:
Any
The following table lists, in order, the user role privileges required to access each option in the Overview menu and whether the user role has access to the sub-permissions within. The Security Approver, Discovery Admin, Intrusion Admin, Access Admin, Network Admin, and External Database User roles have no permissions in the Overview menu.
Table 61-6 Overview Menu
|
|
|
|
|
Dashboards
|
yes
|
yes
|
yes
|
yes
|
Manage Dashboards
|
yes
|
no
|
no
|
no
|
Appliance Information Widget
|
yes
|
yes
|
yes
|
yes
|
Appliance Status Widget
(
Defense Center
only)
|
yes
|
yes
|
yes
|
yes
|
Correlation Events Widget
|
yes
|
no
|
yes
|
yes
|
Current Interface Status Widget
|
yes
|
yes
|
yes
|
yes
|
Current Sessions Widget
|
yes
|
no
|
no
|
no
|
Custom Analysis Widget
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Disk Usage Widget
|
yes
|
yes
|
yes
|
yes
|
Interface Traffic Widget
|
yes
|
yes
|
yes
|
yes
|
Intrusion Events Widget
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Network Correlation Widget
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Product Licensing Widget
(
Defense Center
only)
|
yes
|
yes
|
no
|
no
|
Product Updates Widget
|
yes
|
yes
|
no
|
no
|
RSS Feed Widget
|
yes
|
yes
|
yes
|
yes
|
System Load Widget
|
yes
|
yes
|
yes
|
yes
|
System Time Widget
|
yes
|
yes
|
yes
|
yes
|
White List Events Widget
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Reporting
(
Defense Center
only
)
|
yes
|
no
|
yes
|
yes
|
Manage Report Templates
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Summary
|
yes
|
no
|
yes
|
yes
|
Intrusion Event Statistics
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Intrusion Event Performance
|
yes
|
no
|
no
|
no
|
Intrusion Event Graphs
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Discovery Statistics
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Discovery Performance
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
Connection Summary
(
Defense Center
only)
|
yes
|
no
|
yes
|
yes
|
Analysis Menu
License:
Any
The following table lists, in order, the user role privileges required to access each option in the Analysis menu and whether the user role has access to the sub-permissions within. Permissions that appear multiple times under different headings will be listed on the table only where they first appear, except to indicate submenu headings. The Security Approver, Intrusion Admin, Access Admin, Network Admin, and External Database User roles have no permissions in the Analysis menu. The Analysis menu is only available on the Defense Center.
Table 61-7 Analysis Menu
|
|
|
|
|
|
Application Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
Geolocation Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
User Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
URL Category Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
URL Reputation Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
SSL Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
Intrusion Event Statistics by Application
|
yes
|
no
|
no
|
yes
|
yes
|
Intrusion Event Statistics by User
|
yes
|
no
|
no
|
yes
|
yes
|
Security Intelligence Category Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
File Storage Statistics by Disposition
|
yes
|
no
|
no
|
yes
|
yes
|
File Storage Statistics by Type
|
yes
|
no
|
no
|
yes
|
yes
|
Dynamic File Analysis Statistics
|
yes
|
no
|
no
|
yes
|
yes
|
Context Explorer
|
yes
|
no
|
no
|
yes
|
yes
|
Connection Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Connection Events
|
yes
|
no
|
no
|
yes
|
no
|
Connection Summary Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Connection Summary Events
|
yes
|
no
|
no
|
yes
|
no
|
Security Intelligence Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Security Intelligence Events
|
yes
|
no
|
no
|
yes
|
no
|
Intrusion
|
yes
|
no
|
no
|
yes
|
yes
|
Intrusion Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Intrusion Events
|
yes
|
no
|
no
|
yes
|
no
|
View Local Rules
|
yes
|
no
|
no
|
yes
|
yes
|
Reviewed Events
|
yes
|
no
|
no
|
yes
|
yes
|
Clipboard
|
yes
|
no
|
no
|
yes
|
yes
|
Incidents
|
yes
|
no
|
no
|
yes
|
yes
|
Files
|
yes
|
no
|
no
|
yes
|
yes
|
Malware Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Malware Events
|
yes
|
no
|
no
|
yes
|
no
|
File Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify File Events
|
yes
|
no
|
no
|
yes
|
no
|
Captured Files
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Captured Files
|
yes
|
no
|
no
|
yes
|
no
|
File Trajectory
|
yes
|
no
|
no
|
yes
|
yes
|
File Download
|
yes
|
no
|
no
|
yes
|
yes
|
Dynamic File Analysis
|
yes
|
no
|
no
|
yes
|
no
|
Hosts
|
yes
|
no
|
no
|
yes
|
yes
|
Network Map
|
yes
|
no
|
no
|
yes
|
yes
|
Hosts
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Hosts
|
yes
|
no
|
no
|
yes
|
no
|
Indications of Compromise
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Indications of Compromise
|
yes
|
no
|
no
|
yes
|
no
|
Servers
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Servers
|
yes
|
no
|
no
|
yes
|
no
|
Vulnerabilities
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Vulnerabilities
|
yes
|
no
|
no
|
yes
|
no
|
Host Attributes
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Host Attributes
|
yes
|
no
|
no
|
yes
|
no
|
Applications
|
yes
|
no
|
no
|
yes
|
yes
|
Application Details
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Application Details
|
yes
|
no
|
no
|
yes
|
no
|
Host Attribute Management
|
yes
|
no
|
no
|
no
|
no
|
Discovery Events
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Discovery Events
|
yes
|
no
|
no
|
yes
|
no
|
Users
|
yes
|
yes
|
no
|
yes
|
yes
|
User Activity
|
yes
|
yes
|
no
|
yes
|
yes
|
Modify User Activity Events
|
yes
|
yes
|
no
|
yes
|
no
|
Users
|
yes
|
yes
|
no
|
yes
|
yes
|
Modify Users
|
yes
|
yes
|
no
|
yes
|
no
|
Vulnerabilities
|
yes
|
no
|
no
|
yes
|
yes
|
Third-party Vulnerabilities
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Third-party Vulnerabilities
|
yes
|
no
|
no
|
yes
|
no
|
Correlation
|
yes
|
yes
|
no
|
yes
|
yes
|
Correlation Events
|
yes
|
yes
|
no
|
yes
|
yes
|
Modify Correlation Events
|
yes
|
yes
|
no
|
yes
|
no
|
White List Events
|
yes
|
yes
|
no
|
yes
|
yes
|
Modify White List Events
|
yes
|
yes
|
no
|
yes
|
no
|
White List Violations
|
yes
|
yes
|
no
|
yes
|
yes
|
Remediation Status
|
yes
|
yes
|
no
|
no
|
no
|
Modify Remediation Status
|
yes
|
yes
|
no
|
no
|
no
|
Custom
|
yes
|
no
|
no
|
yes
|
yes
|
Custom Workflows
|
yes
|
no
|
no
|
yes
|
yes
|
Manage Custom Workflows
|
yes
|
no
|
no
|
yes
|
yes
|
Custom Tables
|
yes
|
no
|
no
|
yes
|
yes
|
Manage Custom Tables
|
yes
|
no
|
no
|
yes
|
yes
|
Search
|
yes
|
no
|
yes
|
yes
|
yes
|
Manage Search
|
yes
|
no
|
no
|
no
|
no
|
Bookmarks
|
yes
|
no
|
no
|
yes
|
yes
|
Manage Bookmarks
|
yes
|
no
|
no
|
yes
|
yes
|
Policies Menu
License:
Any
The following table lists, in order, the user role privileges required to access each option in the Policies menu and whether the user roles has access to the sub-permissions within. The External Database User, Maintenance User, Security Analyst, and Security Analyst (Read Only) roles have no permissions in the Policies menu. The Policies menu is only available on the Defense Center.
Note that the Intrusion Policy and Modify Intrusion Policy privileges also allow you to create and modify network analysis policies.
Table 61-8 Policies Menu
|
|
|
|
|
|
|
Access Control
|
yes
|
yes
|
no
|
no
|
yes
|
yes
|
Access Control List
|
yes
|
yes
|
no
|
no
|
yes
|
yes
|
Modify Access Control Policy
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Modify Administrator Rules
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Modify Root Rules
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Apply Intrusion Policies
|
no
|
yes
|
no
|
no
|
no
|
yes
|
Apply Access Control Policies
|
no
|
yes
|
no
|
no
|
no
|
yes
|
Intrusion
|
yes
|
yes
|
no
|
yes
|
no
|
yes
|
Intrusion Policy
|
no
|
yes
|
no
|
yes
|
no
|
yes
|
Rule Editor
|
no
|
yes
|
no
|
yes
|
no
|
no
|
Email
|
no
|
yes
|
no
|
yes
|
no
|
no
|
Modify Intrusion Policy
|
no
|
yes
|
no
|
yes
|
no
|
no
|
File Policy
|
yes
|
yes
|
no
|
no
|
no
|
no
|
Modify File Policy
|
yes
|
yes
|
no
|
no
|
no
|
no
|
Network Discovery
|
no
|
yes
|
yes
|
no
|
no
|
yes
|
Custom Fingerprinting
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Custom Topology
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Modify Network Discovery
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Apply Network Discovery
|
no
|
yes
|
no
|
no
|
no
|
yes
|
SSL
|
yes
|
yes
|
no
|
no
|
yes
|
yes
|
Modify SSL Policy
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Modify Administrator Rules
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Modify Root Rules
|
yes
|
yes
|
no
|
no
|
yes
|
no
|
Apply SSL Policy
|
no
|
yes
|
no
|
no
|
no
|
yes
|
Application Detectors
|
no
|
yes
|
yes
|
no
|
no
|
no
|
User 3rd Party Mappings
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Custom Product Mappings
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Users
|
no
|
yes
|
no
|
no
|
no
|
no
|
Correlation
|
no
|
yes
|
no
|
no
|
no
|
no
|
Policy Management
|
no
|
yes
|
no
|
no
|
no
|
no
|
Rule Management
|
no
|
yes
|
no
|
no
|
no
|
no
|
White List
|
no
|
yes
|
no
|
no
|
no
|
no
|
Traffic Profiles
|
no
|
yes
|
no
|
no
|
no
|
no
|
Actions
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Alerts
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Impact Flag Alerts
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Discovery Event Alerts
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Scanners
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Scan Results
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Modify Scan Results
|
no
|
yes
|
yes
|
no
|
no
|
no
|
Groups
|
no
|
yes
|
no
|
no
|
no
|
no
|
Modules
|
no
|
yes
|
no
|
no
|
no
|
no
|
Instances
|
no
|
yes
|
no
|
no
|
no
|
no
|
Devices Menu
License:
Any
The
Devices
menu table lists, in order, the user role privileges required to access each option in the Devices menu and the sub-permissions within. An X indicates that the user role has access. The Access Admin, Discovery Admin, External Database User, Intrusion Admin, Maintenance User, Security Approver, Security Analyst, and Security Analyst (Read Only) have no permissions in the Devices menu. The Devices menu is only available on the Defense Center.
Table 61-9 Devices Menu
|
|
|
Device Management
|
yes
|
yes
|
Modify Devices
|
yes
|
yes
|
Apply Device Changes
|
yes
|
yes
|
NAT
|
yes
|
yes
|
NAT List
|
yes
|
yes
|
Modify NAT Policy
|
yes
|
yes
|
Apply NAT Rules
|
yes
|
no
|
VPN
|
yes
|
yes
|
Modify VPN
|
yes
|
yes
|
Apply VPN Changes
|
yes
|
yes
|
Object Manager
License:
Any
The Object Manager permission is available to the Access Admin, Administrator, and Network Admin user roles. The Object Manager permission is only available on the Defense Center.
FireAMP
License:
Any
The FireAMP permission is available only to the Administrator user role. This permission is only available on the Defense Center.
Health Menu
License:
Any
The following table lists, in order, the user role privileges required to access each option in the Health menu and whether the user role has access to the sub-permissions within. The Access Admin, Discovery Admin, Intrusion Admin, External Database User, Network Admin, and Security Approver roles have no permissions in the Health menu. The Health menu is only available on the Defense Center.
Table 61-10 Health Menu
|
|
|
|
|
Health Policy
|
yes
|
yes
|
no
|
no
|
Modify Health Policy
|
yes
|
yes
|
no
|
no
|
Apply Health Policy
|
yes
|
yes
|
no
|
no
|
Health Events
|
yes
|
yes
|
yes
|
yes
|
Modify Health Events
|
yes
|
yes
|
no
|
no
|
System Menu
License:
Any
The following table lists, in order, the user role privileges required to access each option in the System menu and whether the user role has access to the sub-permissions within. The Access Admin, Discovery Admin, Intrusion Admin, External Database User, and Security Analyst (Read Only) roles have no permissions in the System Menu.
Table 61-11 System Menu
|
|
|
|
|
|
Local
|
yes
|
no
|
no
|
no
|
no
|
Configuration
|
yes
|
no
|
no
|
no
|
no
|
Registration
|
yes
|
no
|
no
|
no
|
no
|
High Availability
(DC1000, DC1500, DC2000, DC3000, DC3500, DC4000 only)
|
yes
|
no
|
no
|
no
|
no
|
eStreamer
|
yes
|
no
|
no
|
no
|
no
|
Host Input Client
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
User Management
|
yes
|
no
|
no
|
no
|
no
|
Users
|
yes
|
no
|
no
|
no
|
no
|
User Roles
|
yes
|
no
|
no
|
no
|
no
|
Login Authentication
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
System Policy
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
Apply System Policy
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
Modify System Policy
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
Updates
|
yes
|
no
|
no
|
no
|
no
|
Rule Updates
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
Rule Update Import Log
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
no
|
Licenses
|
yes
|
no
|
no
|
no
|
no
|
Monitoring
|
yes
|
yes
|
yes
|
yes
|
yes
|
Audit
|
yes
|
no
|
no
|
no
|
no
|
Modify Audit Log
|
yes
|
no
|
no
|
no
|
no
|
Syslog
|
yes
|
yes
|
no
|
no
|
no
|
Task Status
|
yes
|
yes
|
yes
|
yes
|
yes
|
View Other Users’ Tasks
|
yes
|
no
|
no
|
no
|
no
|
Statistics
|
yes
|
yes
|
no
|
no
|
no
|
Tools
|
yes
|
yes
|
no
|
no
|
yes
|
Backup Management
|
yes
|
yes
|
no
|
no
|
no
|
Restore Backup
|
yes
|
yes
|
no
|
no
|
no
|
Scheduling
|
yes
|
yes
|
no
|
no
|
no
|
Delete Other Users’ Scheduled Tasks
|
yes
|
no
|
no
|
no
|
no
|
Import/Export
|
yes
|
no
|
no
|
no
|
no
|
Discovery Data Purge
(
Defense Center
only)
|
yes
|
no
|
no
|
no
|
yes
|
Whois
|
yes
|
yes
|
no
|
no
|
yes
|
Help Menu
License:
Any
The Help menu and its permissions are accessible to all user roles. You cannot restrict Help menu options.