SSEC SSG 2021.1 PDF

F I R E E Y E T E C H N I C A L
D O C U M E N T A T I O N
SYSTEM SECURITY
SYSTEM SECURITY GUIDE
RELEASE 2021.1
SYSTEM SECURITY / 2021

FireEye and the FireEye logo are registered trademarks of FireEye, Inc. in the United
States and other countries. All other trademarks are the property of their respective
owners.
FireEye assumes no responsibility for any inaccuracies in this document. FireEye
reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.
Copyright © 2021 FireEye, Inc. All rights reserved.

System Security Guide
Software Release 2021.1
Revision 3
FireEye Contact Information:

Website: www.fireeye.com
Technical Support: https://csportal.fireeye.com
Phone (US):
1.408.321.6300
1.877.FIREEYE
Contents
PART I: Overview 17
CHAPTER 1: AAA Concepts 19
PART II: Authentication 21
CHAPTER 2: Authentication Methods 23

Authentication Order 24
Defining the Authentication Order Using the CLI 24
Example: Configuring Authentication 25
Enabling or Disabling the Log Out Message Setting Using the CLI 26
CHAPTER 3: Local Authentication 29

User Accounts and System Accounts 29
User Account Roles 29
Analyst User Account Roles Specific to Endpoint Security Appliances 31
System Account Roles 31
Managing User Accounts 32
Information Needed to Manage User Accounts 33
Viewing the List of Accounts Using the Appliance Web UI 33
Viewing the List of Accounts Using the Appliance CLI 34
Creating a User Account Using the Appliance Web UI 35
Creating a User Account Using the Appliance CLI 36
Deleting User Accounts Using the Appliance Web UI 37
Deleting User Accounts Using the Appliance CLI 38
Unlocking User Accounts Using the Appliance CLI 39
© 2021 FireEye 3
Contents
Managing Account Status 40

Setting Account Status Using the Web UI 40
Setting Account Status Using the CLI 42
Managing Your Own Account 42
Changing Your Own Account Password Using the Web UI 43
Changing Your Own Account Password Using the CLI 44
Showing Your Own Account Information Using the CLI 46
Generating an SSH Client Identity for Yourself Using the CLI 46
Changing the Status of Your Own Local User Account Using the CLI 47
Configuring Password Policies 48
Managing Password Change Policies 48
Managing User Password Validation Policies 55
Managing Admin Password Validation Policies 60
Example: Configuring Password Validation Policies 62
CHAPTER 4: Remote Authentication 65

Configuring RADIUS Authentication Using the CLI 66
Configuring TACACS+ Authentication 69
LDAP Server Configuration 71
Configuring an LDAP Server 72
Defining LDAP Search Filters 72
Example: Configuring an LDAP Server 73
Configuring an Active Directory Server Using the CLI 74
Local Overrides of Remote User Mappings 75
About Overriding Remote User Mappings 75
Locally Overriding Remote User Mappings Using the CLI 76
Mapping Remote Users to Default Local Users Using the CLI 77
CHAPTER 5: Common Access Card (CAC) for Certificate Authentication 79

About CAC for Certificate Authentication 79
Task List for Configuring the Appliance to Use CAC for Certificate
Authentication 80
4 © 2021 FireEye
Contents
Configuring a CA Certificate Bundle 81

Adding a CA Certificate to a Bundle Using the CLI 82
Deleting a CA Certificate From a Bundle Using the CLI 84
Downloading a CA Certificate Bundle Using the CLI 85
Enabling or Disabling the Policy Settings of the Web UI for Certificate Authentication 86
Enabling or Disabling the Policy Settings of the Web UI for Certificate
Authentication Using the CLI 87
Configuring Certificate Revocation for Certificates 88
Enabling or Disabling OCSP Using the CLI 89
Enabling or Disabling the OCSP Override Responder Using the CLI 91
Adding or Removing the OCSP URL Using the CLI 92
Enabling or Disabling a Certificate with Missing Basic Constraints Using the CLI93
Deleting a CRL File Using the CLI 94
Downloading a Local CRL File Using the CLI 95
Configuring the User Attributes for Certificate Authentication 96
Configuring the User Attributes for Certificate Authentication Using the CLI 98
Configuring LDAP for Authorization 99
Enabling or Disabling the LDAP Server for Certificate Authorization Using the
CLI 101
Configuring an LDAP Attribute to Match a Certificate Authorization Field
Using the CLI 102
Removing an LDAP Attribute for Certificate Authorization Using the CLI 103
Configuring the Certificate Fields to Match the LDAP Field for Authorization
Using the CLI 103
Defining LDAP Search Filters for Certificate Authorization Using the CLI 105
Removing LDAP Search Filters for Certificate Authorization Using the CLI 105
Enabling or Disabling the LDAP Override for Certificate Authorization Using
the CLI 106
Configuring Local User Mappings for Authorization 107
Allowing or Preventing Authorization Rule Matches for Certificate
Authentication Using the CLI 108
Configuring Authorization Rules to Match the Certificate Fields Using the CLI 110
Logging in to the Web UI for Certificate Authentication 112
© 2021 FireEye 5
Contents
Verifying Certificate Authentication Status Using the Web UI 113
CHAPTER 6: Secure Shell (SSH) Authentication 115

About SSH Authentication 115
User Authentication 116
Example for a Central Management Administrator 117
Example for a Managed Email Security — Server Edition Appliance Admin 117
Creating a Public Key Using the CLI 117
Pushing a Public Key Using the Central Management CLI 119
Configuring User Authentication Using the Central Management Web UI 120
Configuring User Authentication Using the CLI 122
Host-Key Authentication 124
About Host-Key Authentication 125
Obtaining a Host Key Using the Web UI 126
Obtaining a Managed Appliance Host Key Using the CLI 128
Obtaining the Central Management Appliance Host Key Using the CLI 130
Importing a Host Key into the Global Host-Keys Database Using the Central
Management Web UI 131
Importing a Host Key into the Central Management Global Host-Keys Database
Using the CLI 133
Importing a Host Key into the Managed Appliance Global Host-Keys Database
Using the CLI 134
Enabling and Disabling Strict and Global Host-Key Checking Using the CLI 136
Global Host-Key Authentication on a Central Management Appliance in a
NAT Deployment 139
Global Host-Key Authentication on a Managed Appliance in a NAT
Deployment 140
CHAPTER 7: Single Sign-On Authentication 143

SSO Authentication Overview 143
About Helix Mode and Single Sign-On Mode 145
Helix Mode 145
Single Sign-On Mode 145
6 © 2021 FireEye
Contents
When SSO Authentication Is Disabled 146

Logging In When SSO Is Disabled 146
Logging Out When SSO Is Disabled 147
When SSO Authentication Is Required 148
Logging In When SSO Is Required 148
Logging Out When SSO Is Required 149
When SSO Authentication Is Allowed 152
Logging In When SSO Is Allowed 152
Logging Out When SSO Is Allowed 153
Viewing Helix Mode and SSO Authentication Mode Using the CLI 155
Enabling SSO Authentication Using the CLI 157
CHAPTER 8: Configuring SAML Authentication and Authorization on

FireEye Appliances 159
About Security Assertion Markup Language (SAML) 159
Configuring SAML Authentication 160
Enabling or Disabling SAML Authentication Using the CLI 160
Redirecting to the IdP Login Page 161
Uploading the SAML IdP Metadata on to the SP 163
Downloading the SAML Service Provider Metadata 164
Configuring SAML Authorization 166
Mapping User Roles Using Custom SAML Attributes 166
Defining SAML Authorization Rules 168
PART III: Authorization 171
CHAPTER 9: Assigning Roles for Local User Accounts 173

Assigning Roles Using the Web UI 173
Assigning Roles Using the CLI 174
CHAPTER 10: Configuring Access Groups for Alerts 175

Task List for Configuring Access Groups for Alerts 176
© 2021 FireEye 7
Contents
Creating Access Groups for Alerts 176

Creating Access Groups for Alerts Using the CLI 176
Defining Rules 177
Rule Usage Guidelines 178
Command Options 179
Defining Access Group Rules 183
Defining Authorization Rules 185
Enabling and Disabling Access Groups for Alerts 186
Enabling Access Groups for Alerts Using the CLI 186
Disabling Access Groups for Alerts Using the CLI 187
Modifying and Deleting Rules 188
Modifying and Deleting Access Groups 192
Viewing Access Groups, Rules, and Users 193
Viewing Access Group Rules and Groups Using the CLI 194
Viewing Authorization Rules Using the CLI 195
Viewing Access Group Users Using the CLI 195
Example: Configuring an Access Groups for Alerts 197
CHAPTER 10: Configuring Access Groups for YARA Rules 198

Enabling and Disabling Access Groups for YARA Rules 198
Enabling Access Groups for YARA Rules Using the CLI 199
Disabling Access Groups for Alerts Using the CLI 199
Creating Access Groups for YARA Rules 200
Creating Access Groups for YARA Rules Using the CLI 200
Defining Access Group Rules for YARA Settings 201
Defining Access Group Rules for YARA Settings Using the CLI 202
Adding a User to the YARA Rules Access Group 203
Adding a User to the YARA Rules Access Group Using the CLI 203
8 © 2021 FireEye
Contents
PART IV: Accounting 205
CHAPTER 11: Accounting 207

Managing Audit Logs Using the CLI 209
PART V: Certificates 211
CHAPTER 12: Certificate Management 213

The VX Series Appliance 213
System Self-Signed Server Certificate 214
HTTPS and MTA Server Certificates 214
Web Server CA Certificate Chains 214
Certificate Authority (CA) Client Certificates 214
CHAPTER 13: Managing HTTPS and MTA Certificates 215

Viewing Certificates 217
Viewing Certificates Using the Web UI 218
Viewing Certificates Using the CLI 220
Regenerating the System Self-Signed Certificate 225
Managing HTTPS Certificates Using the Web UI 227
Importing an HTTPS Certificate 228
Exporting an HTTPS Certificate 229
Managing Named Certificates Using the CLI 229
Managing MTA Certificates Using the Web UI 235
Importing an MTA Certificate 235
Creating a Self-Signed MTA Certificate 236
Using a Certificate Signing Request (CSR) to Obtain an MTA Certificate 237
Restoring the System Self-Signed Certificate as the MTA Certificate 238
Exporting an MTA Certificate 238
Downloading Certificates 239
Downloading a Certificate Using the CLI 239
Activating Named Certificates 240
© 2021 FireEye 9
Contents
Activating Named Certificates Using the Web UI 240

Activating Named Certificates Using the CLI 241
CHAPTER 14: Managing CA Certificates 245

Obtaining a CA Certificate from a Trusted Public Certificate Authority (CA) 245
Adding Supplemental CA Certificates 247
Adding Supplemental CA Certificates Using the Web UI 248
Adding Supplemental CA Certificates Using the CLI 249
Configuring a SharePoint CA Certificate Chain 252
Configuring a SharePoint CA Certificate Chain Using the Web UI 252
Configuring a SharePoint CA Certificate Chain Using the CLI 253
Configuring a Web Server CA Certificate Chain 256
Configuring a Web Server CA Certificate Chain Using the Web UI 257
Configuring a Web Server CA Certificate Chain Using the CLI 258
Activating a Web Server CA Certificate Chain Using the CLI 261
Manually Verifying Certificates 262
Manually Verifying Certificates Using the CLI 263
CHAPTER 15: Improving Certificate Security 267

Specifying the Minimum Key Size Using the CLI 267
Requiring Secure Hashes Using the CLI 268
Reviewing the Minimum Transport Layer Security (TLS) Version Requirement 268
Reviewing the Minimum Transport Layer Security (TLS) Version Requirement
Using the CLI 269
Reviewing the Minimum Transport Layer Security (TLS) Version Requirement
In the Logs 270
Specifying the Minimum Transport Layer Security (TLS) Version Requirement 271
CHAPTER 16: Defining Default Certificate Attributes 273

Common Attributes of X.509 Certificates 273
Defining Default Certificate Attributes Using the CLI 276
10 © 2021 FireEye
Contents
CHAPTER 17: Renaming a Certificate 277

Renaming a Certificate Using the CLI 277
PART VI: FireEye IAM 279
CHAPTER 18: FireEye IAM Overview 281

OAuth 2.0 and OIDC 281
The IAM Organization 282
OIDC Clients 282
The Default IAM Organization Administrator 283
FireEye IAM Concepts and Terminology 284
Roles 284
Entitlements 284
User Accounts 285
User Groups 285
FireEye IAM Web UI Access 285
Terms of Service 285
Logging In to the FireEye IAM Web UI 286
Logging Out of the FireEye IAM Web UI 289
FireEye IAM Initial Configuration Task List 290
CHAPTER 19: Managing Your Own FireEye IAM User Account 293
About Managing Your Own User Account 294
Account Enrollment 294
IAM Username and Password 294
Phone Number 295
Backup Codes for 2FA 295
Enrolling Your New FireEye IAM User Account 295
Setting User Information and Preferences for Your IAM Account 299
Viewing Your IAM Login Activity 304
Changing the Password for Your IAM User Account 305
About Two-Factor Authentication 306
© 2021 FireEye 11
Contents
Two-Factor Authentication 306

Optional Google Authenticator Mobile App 307
Setting Up a Smartphone as a Two-Factor Authentication Device 307
Resetting Two-Factor Authentication on Your Smartphone 309
Generating Two-Factor Authentication Codes in Advance 310
CHAPTER 20: FireEye IAM Organization 313

Security in a FireEye IAM Organization 313
Allowed Email Domains 313
Single-Factor Authentication 313
Two-Factor Authentication 313
User Password Policy 314
Web UI Session Timeout 314
Role-Based Access Controls 314
FireEye IAM Organization Settings 315
Configuring the FireEye IAM Organization 318
CHAPTER 21: FireEye IAM Roles 321

About Roles 321
Global Roles 321
Custom Roles 322
Fallback Roles 322
About Entitlements 322
Viewing the List of Roles 323
Viewing the Entitlements Assigned to a Role 325
Creating a Custom Role 326
Editing a Custom Role 329
Deleting Custom Roles 331
CHAPTER 22: FireEye IAM User Accounts 333

About User Accounts 333
User Account Creation 333
12 © 2021 FireEye
Contents
Permissions Granted by Directly Assigned Roles 334

Permissions Granted by Membership in a User Group 334
The Potential Impact of Deleting a User Account 334
About External User Accounts 334
Permissions Assigned in This Organization 335
Limitations for Managing an External User Account 335
Viewing the Lists of User Accounts 336
Viewing the Roles Assigned to a User Account 338
Creating a User Account 340
The Invite User View 341
Adding an External User Account 343
Editing a User Account 347
Resetting the Password for a Local User Account 352
Re-Enrolling a Local User Account 353
Deleting User Accounts 355
Disabling and Enabling User Accounts 357
CHAPTER 23: FireEye IAM User Groups 359

About Internal User Groups 359
User Group Access Privileges 359
One System-Defined User Group 360
About External User Groups 360
External User Group Names Displayed in the Organization Settings Page 361
External User Group Names Listed in the User Groups Page 361
Two System-Defined External User Groups 361
Viewing the Lists of Internal and External User Groups 362
Viewing the Roles and Users Assigned to an Internal User Group 364
Creating an Internal User Group 367
Editing an Internal User Group 371
Deleting Internal User Groups 373
© 2021 FireEye 13
Contents
CHAPTER 24: FireEye IAM API Keys 375

Viewing All API Keys for the Organization 375
Viewing, Copying, or Downloading an API Key You Created 376
Creating an API Key 379
Editing an API Key You Created 382
Revoking an API Key You Created 384
PART VII: Appendices 387
APPENDIX A: Capabilities of FireEye Appliance Local Roles 389

Capabilities of Local Roles 390
Capability Categories 390
Capability Descriptions 393
Access Messages 396
Capabilities of Local Roles on Endpoint Security Appliances 397
Endpoint Security Appliance Capabilities and Authorized Local Roles 397
Admin Role 404
Analyst Role 404
Senior Analyst Role 404
API Admin Role 405
API Analyst Role 405
Auditor Role 405
fe_services User 406
Investigator Role 406
Monitor Role 406
Operator Role 407
Access Messages 407
APPENDIX B: FireEye IAM Entitlements 409

Entitlements for the FireEye IAM Web UI Roles 411
IAM Admin Role 412
IAM User Role 416
14 © 2021 FireEye
Contents
FireEye Super Admin Role 419

SCIM Admin Role 424
Entitlements for Helix Roles 426
All FireEye Helix Entitlements 427
FaaS Analyst Role 437
TAP Analyst Role 438
TAP Analyst Limited Role 445
TAP Cloud Collector Role 452
TAP Content Limited Role 454
TAP Federated Analyst Role 455
TAP Federated Analyst Limited Role 463
TAP Federated Organization Administrator Role 473
TAP Organization Administrator Role 483
Entitlements for FireEye Threat Intelligence Roles 491
Threat Intelligence—Included Role 491
Entitlements for the FireEye Appliance Roles 494
About IAM Global Roles for FireEye Appliances 495
Central Management Appliance Roles 496
Email Security — Server Edition Appliance Roles 498
Network Security Appliance Roles 500
Endpoint Security Appliance Roles 502
Fallback Roles for FireEye Appliances 504
FireEye Appliance Org Admin Role 507
Technical Support 511

Documentation 511
© 2021 FireEye 15
Contents
16 © 2021 FireEye
Release 2021.1
PART I: Overview
l AAA Concepts on page 19
© 2021 FireEye 17
System Security Guide PART I: Overview
18 © 2021 FireEye
CHAPTER 1: AAA Concepts
AAA (authentication, authorization, and accounting) is a security framework that validates
user identities, enforces access to resources, and audits user activities and usage.
l Authentication validates users before they are allowed to access the system. Each user
has a unique identity and associated credentials. The authentication process
compares the login credentials the user provides with the user credentials stored in
a database. If the credentials match, the user is granted access to the system;
otherwise, the authentication fails and the user is denied access.
l Authorization provides access control. You configure authorization by assigning
users roles, which offer a specific set of capabilities on the appliance. You can also
configure access groups on a Central Management appliance, which controls which
alerts users with the analyst and monitor roles can view and manage.
l Accounting tracks user activities and resource usage.
© 2021 FireEye 19
System Security Guide CHAPTER 1: AAA Concepts
20 © 2021 FireEye
Release 2021.1
PART II: Authentication
l Enabling or Disabling the Log Out Message Setting Using the CLI on page 26
l Authentication Methods on page 23
l Local Authentication on page 29
l Remote Authentication on page 65
l Common Access Card (CAC) for Certificate Authentication on page 79
l Secure Shell (SSH) Authentication on page 115
l Single Sign-On Authentication on page 143
© 2021 FireEye 21
System Security Guide PART II: Authentication
22 © 2021 FireEye
CHAPTER 2: Authentication
Methods
Depending on your environment, FireEye includes multiple authentication methods for
you to use:
l Local—Users are authenticated against the local username database. This is

described in User Accounts and System Accounts on page 29.
l RADIUS—Users are authenticated against a remote RADIUS security server. System
configuration is described in Configuring RADIUS Authentication Using the CLI on
page 66.
l TACACS+—Users are authenticated against a remote TACACS+ security server.
System configuration is described in Configuring TACACS+ Authentication on
page 69.
l LDAP—Users are authenticated against a remote LDAP server. This is described in
LDAP Server Configuration on page 71.
l Active Directory — Users are authenticated against a remote Active Directory
server. System configuration is described in Configuring an Active Directory Server
Using the CLI on page 74.
l SAML — Users are authenticated against a remote Identity Provider (IdP) server.
For more information, see Configuring SAML Authentication on page 160.
l Common Access Card (CAC) — Users are authenticated against a CAC server. For
more information, see About CAC for Certificate Authentication on page 79.
l Single Sign-On Using FireEye IAM — Users are authenticated against the FireEye
IAM database. This provides a single sign-on method across all FireEye products.
For more information, see Single Sign-On Authentication on page 143.
IMPORTANT! The FireEye software uses the remote authentication methods as

a client and does not become an authentication server itself.
© 2021 FireEye 23
System Security Guide CHAPTER 2: Authentication Methods
Authentication Order
An authentication methods list defines the order in which authentication should be
attempted, and provides backup methods in the event that a method fails to authenticate a
user. The local method must be included in the list, preferably first to reduce the risk of
local account access issues.
If a method denies a user or is not reachable, the next method in the list is tried. If there are
multiple servers within a method (assuming the method is contacting authentication
servers), and a server timeout is encountered, then the next server in the list is tried.
If the current server being contacted issues an authentication reject, no other servers for
that method are tried and the next method in the list is attempted. If no method validates a
user, the user is denied access to the appliance.
You can configure the system to track authentication attempts, limit authentication based
on previous failures, and so on.
Defining the Authentication Order Using the CLI

If you have multiple authentication tools that can be used for authentication, you can
determine the order in which each tool is used to authenticate users against the appliance.
For example, if you have an external LDAP server authenticating users, you can set the
order to authenticate users first with LDAP, and then locally on the appliance itself.
The order of the tools used is based on the sequence of tools added to the aaa
authentication login default command.
Prerequisites
l Admin access
To define the authentication order:
1. Go to CLI configuration mode:
hostname > enable
hostname # configure terminal
2. To specify the authentication tool order, use the following command:

aaa authentication login default <first> <second>. . .
For example, if you want to set the authentication order to first authenticate against
an LDAP server, second authenticate against a RADIUS server, and finally locally
on the appliance, enter the following:
hostname # (config) aaa authentication login default ldap radius local
24 © 2021 FireEye
Release 2021.1 Example: Configuring Authentication
Example: Configuring Authentication
This procedure describes how to use CLI commands to configure authentication for an
appliance.
Prerequisites
l Admin access
To configure the authentication:
hostname > enable
2. Authenticate first from the local user/password settings, then from RADIUS if that
does not work, then from LDAP if RADIUS does not work, and finally from
TACACS+ if LDAP does not work:
hostname (config) # aaa authentication login default local radius ldap
tacacs+
3. For users who do not exist in the local user/password settings, if there is no Local-
User attribute returned by the RADIUS, LDAP, or TACACS+ server at login time, the
login will have the same capabilities as the Monitor user. Otherwise, it will have the
capabilities of the username given by the attribute.
hostname (config) # aaa authorization map default-user monitor
hostname (config) # aaa authorization map order remote-first
4. Configure the IP address and secret of the RADIUS server:

hostname (config) # radius-server host 10.1.0.58 key myradius123
5. Configure the IP address and secret of the TACACS+ server:

hostname (config) # tacacs-server host 10.1.0.58 key mytac123
6. Configure the fully-qualified hostname of the LDAP server. The hostname (not the IP
address) is needed for the optional TLS certificate validation to work.
hostname (config) # ldap host orange.purple.com
7. Configure the IP address of the LDAP server, as a fallback mechanism:

hostname (config) # ldap host 10.1.0.58
8. Configure the base of the user tree for LDAP:

hostname (config) # ldap base-dn ou=users,dc=orange,dc=com
9. Configure the LDAP user schema name for LDAP:

hostname (config) # ldap login-attribute uid
© 2021 FireEye 25
10. Configure the base of the group tree for LDAP:

hostname (config) # ldap group-dn
cn=authgroup1,ou=groups,dc=orange,dc=com
11. Configure the LDAP group schema name for membership:

hostname (config) # ldap group-attribute member
12. Save your changes:

hostname (config) # write memory
Enabling or Disabling the Log Out

Message Setting Using the CLI
Use the commands in this section to enable or disable the display of the log out message
on the appliance. When you enable the log out message setting, a message is displayed to
indicate that you have successfully logged out of the appliance and the session has ended.
When you disable the log out message setting, a message will not be displayed on the
appliance. The log out message setting is disabled by default.
Prerequisites
l Admin access to enable or disable the display of the log out message setting.
l Monitor or Analyst access to verify whether the log out message setting is enabled
or disabled.
To enable the log out message setting:
1. Go to CLI configuration mode.
hostname > enable
2. Enable the display of the log out message when your session is closed.
hostname (config) # aaa authentication logout user-message enable
3. Save your changes.

4. Verify the status of the log out message setting.

hostname (config) # show aaa
User session termination log-out message enabled: yes
.....
26 © 2021 FireEye
Release 2021.1 Enabling or Disabling the Log Out Message Setting Using the CLI
To disable the log out message setting:
hostname > enable
2. Disable the display of the log out message when your session is closed.
hostname (config) # no aaa authentication logout user-message enable

4. Verify the status of the log out message setting.

hostname (config) # show aaa
User session termination log-out message enabled: no
© 2021 FireEye 27
28 © 2021 FireEye
System Security Guide User Accounts and System Accounts
CHAPTER 3: Local Authentication

Local authentication is covered in the following topics:
l User Accounts and System Accounts below

l Managing User Accounts on page 32
l Managing Your Own Account on page 42
l Configuring Password Policies on page 48
User Accounts and System Accounts

You can view the list of local accounts on an appliance Web UI or the CLI. For each
account, the list shows the account name, role, account status, and account login data. The
list is divided into two types of accounts: user accounts and system accounts.
This section describes user account roles and system account roles.
User Account Roles

User account roles give system administrators finer control over what users can do and see
on the appliance. Each user account is associated with a single role, which is a collection
of capabilities that allow the user to perform certain operations. A default user account is
provided for each of the following user roles, depending on your appliance type.
NOTE: For more information about managing user accounts, see Assigning Roles
for Local User Accounts on page 173, Capabilities of Local Roles on page 390, and
Capabilities of Local Roles on Endpoint Security Appliances on page 397.
admin
This role enables a user to perform all appliance product functions and have full
access to all Web UI views, all CLI commands, and the API. The primary function of
this role is to configure and control the system.
© 2021 FireEye 29
System Security Guide CHAPTER 3: Local Authentication
analyst
This role enables a system analyst to focus on detecting malware and taking
appropriate action, including setting up alerts and reports.
For more information about analyst roles on Endpoint Security appliances, see Analyst
User Account Roles Specific to Endpoint Security Appliances on the facing page.
api_admin
This role is a Web service API role, and it grants API access to Endpoint Security
appliance features only. Users assigned the api_admin role can perform all of the
functions of an api_analyst, but in addition they can maintain API custom policy
channels and can contain hosts.
api_analyst
This role is a Web service API role, and it grants only API access to the appliance
features.
api_monitor
This role is a Web service API role, and it grants only API access to existing reports on
the appliance. Unlike the api_analyst, an api_monitor cannot generate reports or
perform other actions.
auditor
This role enables a user to view System Logs and Audit Logs only. The only other
roles that grant access to these logs are the Admin and Monitor roles.
fe_services
This role is a FireEye Managed Defense account used to maintain the connection to the
Managed Defense backend. Users assigned this role have API and CLI access to
Endpoint Security appliance features and can run CLI commands, but they cannot log
into the Web UI.
monitor
This role grants read-only access to the appliance setting screens, the Health Check
page, and the Appliance Update page. A monitor cannot request data or take actions
on the system. Monitors do not have access to appliance product features or the API
and can only run CLI show commands. On some systems, they also have access to
some malware analysis functions.
operator
This role grants a subset of the capabilities associated with the admin role. Operators
have read-only access to Web UI dashboards, can run CLI show commands only, and
have no access to the API. Operators can adjust some, but not all, appliance settings
and can perform log management and appliance updates.
On the Endpoint Security appliance, Operators can also perform agent upgrades.
30 © 2021 FireEye
Release 2021.1 User Accounts and System Accounts
reject
A user with a reject user account is automatically locked out and is denied access of
any kind to the appliance.
Analyst User Account Roles Specific to Endpoint Security

Appliances
On the Endpoint Security appliance, these roles represent three tiers of analysts, focusing
on the detection of malware and responding appropriately.
analyst
On an Endpoint Security appliance, this role enables users to perform most Endpoint
Security appliance functions, except approving containment requests and stopping
containment. They have no access to agent or appliance settings. They have read-only
access to the maintenance of host sets, and they cannot maintain data acquisition
scripts. They have no access to the API and can only run CLI show commands.
analyst_sr
On an Endpoint Security appliance, this role grants users the same capabilities as the
analyst role, but they can perform most other Endpoint Security appliance functions,
except approving containment requests and stopping containment. They have no
access to agent or appliance settings. They have read-only access to the maintenance of
host sets, but can fully maintain data acquisition scripts. They have no access to the
API and can only run CLI show commands.
investigator
On an Endpoint Security appliance, this role enables users to perform the same
functions as the analyst and analyst_sr roles, but they can also approve containment
requests and stop containment of host endpoints. Investigators have no access to the
API and can only run CLI show commands.
System Account Roles

System accounts are “reserved accounts” that permit remote login for the purpose of
specific FireEye system-internal communication. Local password login to these accounts is
disabled by default. The user cannot log in to the appliance locally using a password, but
can log in using an SSH authorized key.
NOTE: You cannot create or modify system accounts. The appliance Web UI and
CLI display system account status information so that you can verify that these
accounts are not used to log in to the appliance. System accounts can be locked
out so they cannot be used to log in to the appliance.
© 2021 FireEye 31
On appliances other than the Central Management appliance, a default system account
corresponds to each of the following system-defined roles:
ccd_node
This role enables remote login to Virtual Execution compute nodes in an on-premises
MVX cluster. Use of this role is limited to internal communication between standard
compute nodes and compute nodes that have been designated as broker nodes. This
type of communication uses the cluster communication process (CCD) and the
TLS/SSH protocol.
ccd_sensor
This role enables remote login to a Virtual Execution compute node in an on-premises
MVX cluster. Use of this role is limited to internal communication between standard
compute nodes and Network Security sensors. This type of communication uses the
cluster communication process (CCD) and the GCL protocol that is based on TLS/SSH.
cmcrendv
This role enables remote login to initiate a persistent connection from an appliance to a
Central Management appliance. Use of this role is limited to communication from a
rendezvous client and the GCL protocol that is based on SSH.
hasync
This role enables remote login used to initiate a persistent connection between two
Network Security nodes in an HA deployment. Use of this role is limited to the HA
appliance reboot monitoring daemon (hamon) on the Network Security appliance and
the GCL protocol that is based on SSH.
Managing User Accounts

The following sections cover information about managing user accounts.
l Information Needed to Manage User Accounts on the facing page

l Viewing the List of Accounts Using the Appliance Web UI on the facing page
l Viewing the List of Accounts Using the Appliance CLI on page 34
l Creating a User Account Using the Appliance Web UI on page 35
l Creating a User Account Using the Appliance CLI on page 36
l Deleting User Accounts Using the Appliance Web UI on page 37
l Deleting User Accounts Using the Appliance CLI on page 38
l Unlocking User Accounts Using the Appliance CLI on page 39
32 © 2021 FireEye
Release 2021.1 Managing User Accounts
Information Needed to Manage User Accounts

You need the following information to manage user accounts:
User name—The user name identifies each user accessing the appliance or appliances.
Each user name must be unique to the network. By default, the user name has the
following characteristics:
l Must be 1 to 16 characters in length

l Is case-sensitive
l May only use letters, numbers, and underscores
Role—Each user is given a role, and this role determines the abilities of the user. For
example, only users with an admin role can add and remove users to the system by
default. For more information on roles, see Assigning Roles for Local User Accounts on
page 173.
Password—The password is the secret information, known only to the user, that is used to
authenticate the user on the system. By default, passwords must be 8 to 32 characters in
length. You can configure rules for stricter password security. For details, see Managing
User Password Validation Policies on page 55 and Managing Password Change Policies
on page 48. Users have the ability to change their own passwords. For more information,
see Managing Your Own Account on page 42.
Account Status—The account status specifies whether the user is currently authorized to
log in to the system and for how long. For more information on Account Status, see
Managing Account Status on page 40.
Viewing the List of Accounts Using the Appliance Web UI

Follow these steps to view user accounts and system accounts using the appliance Web UI.
NOTE: For a managed appliance, you can perform this procedure on the Central
Management appliance as well as the local appliance. The procedure remains the
same. However, you will need to take the additional step to locate the appliance on
the Central Management Web UI. For instructions on locating an appliance on the
Central Management Web UI, see the Central Management Administration Guide.
Prerequisites
l Admin access
© 2021 FireEye 33
To view the list of accounts:
1. Log in to the appliance Web UI.
2. Choose Settings > User Accounts.
Viewing the List of Accounts Using the Appliance CLI

Follow these steps to view user accounts and system accounts using the appliance CLI.
the Central Management CLI. For instructions on locating an appliance on the
Central Management CLI, see the FireEye Central Management Administration Guide.
Prerequisites
l Admin access
To view the list of accounts:
1. Go to CLI enable mode:
hostname > enable
34 © 2021 FireEye
2. Use the show usernames command to see the list of user accounts and system
accounts.
hostname > show usernames
User Accounts
-------------
USERNAME FULL NAME ROLE ACCOUNT STATUS
admin System Administrator admin Password set
analyst System Analyst analyst Password set
api_analyst API Analyst api_analyst Password set
api_monitor API Monitor api_monitor Password set
auditor System Auditor auditor Password set
fe_services FireEye Services User fe_services Password set
monitor System Monitor monitor Password set
operator System Operator operator Password set
reject Reject User Account locked out
System Accounts
---------------
USERNAME FULL NAME ROLE ACCOUNT STATUS
ccd_node ccd_node user ccd_node Local password login disabled
ccd_sensor ccd_sensor user ccd_sensor Local password login disabled
cmcrendv CMC Rendezvous User cmcrendv Password set
hasync HA synchronization user hasync Password set
Remote access for admin user: enabled
Creating a User Account Using the Appliance Web UI

Follow these steps to add a user account on an appliance using the Web UI.
Prerequisites
l Admin access
To add a user account:

2. Click the Settings tab.
Note: If the Settings tabs are not visible, select Appliance Settings from the
Admin menu, or click the Appliance Settings tab at the top of the page.
3. Click User Accounts on the sidebar.

4. Enter the User Name
5. Select a role from the Role list.
© 2021 FireEye 35
6. Enter a case-sensitive user password in the Create Password and Confirm

Password boxes.
IMPORTANT! The "Password set" account status is set automatically

for new users when creating a user account with the Web UI.
7. (Optional) For Monitor users only, specify a subnet, subnet mask, and VLAN for the
user.
Once the user account is created, the user configuration is displayed in the user account
list.
Creating a User Account Using the Appliance CLI

On a local system, you have the ability to add user accounts using the device's CLI. The
instructions below will provide the steps necessary to add a user account locally.
Prerequisites
l Admin access
To add a new user account:
hostname > enable
2. Add the user name with the username command.

The following example creates the user account nx-3_operator:
hostname (config) # username nx-3_operator
3. Assign a role to the user account with the username <username> role sub-
command.
The following example assigns a role to the user account nx-3_operator:
hostname (config) # username nx-3_operator role operator
36 © 2021 FireEye
4. Assign a password to the user account with the username <username> role
<role> password sub-command.
The following example assigns the password mArT!n1_@ to the user account nx-3:
hostname (config) # username nx-3_operator password mArT!n1_@
NOTE: The command does not ask you to confirm the password.
5. (Optional) For monitor accounts only, configure a subnet and VLAN ID for the
specified user account. Use the username <username> subnet and
username <usename> vlan sub-commands:
username <username> subnet <networkPrefix>
username <username> vlan <vlanNumber>
The following example configures the subnet and a VLAN ID for the user account
nx-3_operator:
hostname (config) # username nx-3_operator subnet 24
hostname (config) # username nx-3_operator vlan 22
6. View your changes:

hostname (config) # show usernames

To see the list of user accounts, enter the show usernames command. See Viewing the List
of Accounts Using the Appliance CLI on page 34.
Deleting User Accounts Using the Appliance Web UI

Follow these steps to delete a user account on an appliance using the Web UI.
Prerequisites
l Admin access
To delete a user account:

2. Choose Settings > User Accounts.
© 2021 FireEye 37
3. In the User Accounts table, select the user account to delete.

4. Click Remove Selected Users.
The selected user account will be removed and the account will no longer show on the All
Users table.
Deleting User Accounts Using the Appliance CLI

On a local system, you have the ability to delete user accounts using the device's CLI. The
instructions below will provide the steps necessary to delete the user account.
Prerequisites
l Admin access
To delete an existing account:
hostname > enable
2. To delete a specified user, use the following command:

no username <userName>
The following example deletes the user account for nx-3_operator:

hostname (config) # no username nx-3_operator

38 © 2021 FireEye
Unlocking User Accounts Using the Appliance CLI

By default, authentication failures are tracked, and users are locked out after five failed log
in attempts. Use the CLI commands in this topic to view the authentication history and
unlock the user accounts.
Prerequisites
l Admin access
To unlock a single user account:
hostname > enable
2. Determine the user who is locked out using the show aaa authentication
attempts command:
hostname (config) # show aaa authentication attempts
3. To unlock the account, use the following command:

aaa authentication attempts reset user <username>

To unlock all user accounts:
hostname > enable
2. Determine the user who is locked out using the show aaa authentication
attempts command:
hostname (config) # show aaa authentication attempts
3. Unlock all user accounts by using the aaa authentication attempts reset all
command:
hostname (config) # aaa authentication attempts reset all

© 2021 FireEye 39
Managing Account Status

Each user has an account status that determines whether and how the user can log in to
the FireEye appliance locally. The account statuses are described in the following table.
Account Status Description
Account locked out The user cannot log in at all. This could be due to the account
status being configured this way explicitly, or due to too many
unsuccessful login attempts.
Local login disabled The user cannot log in to an appliance locally, using either a

password or an SSH authorized key. A user with this account
status can still authenticate remotely and be mapped to this user
account.
Local password The user cannot log in to the appliance locally using a password,
login disabled but can log in using an SSH authorized key.
Password set The user can log in to the appliance locally using a username and
password.
The provided Operator, Analyst, and Auditor system accounts have the "local login
disabled" status set by default, so they cannot log in until an administrator changes their
account status by setting passwords for them. The provided Monitor account defaults to
the "account locked out" status for security.
Setting Account Status Using the Web UI

Use the User Account Settings page to set the account status for a user. For a description of
each account status, see Managing Account Status above.
NOTE: The VX Series appliance has a CLI, but it does not have a Web UI. The
recommended method for this configuration on a VX Series appliance is through
the managing Central Management appliance Web UI.
40 © 2021 FireEye
Release 2021.1 Managing Account Status
NOTE: This example is from a Network Security appliance, but the Account
Status setting is representative of other appliances as well.
Prerequisites
l Admin access
To set an account status:
1. Click the Settings tab on all products other than the Endpoint Security appliance.
Select Appliance Settings from the Admin menu on the Endpoint Security
appliance.

3. Click the user name in the User column.
© 2021 FireEye 41
4. In the Update User section, select an account status from the Account Status list.
5. Click Update User.
Setting Account Status Using the CLI

Use the CLI commands in this topic to set the account status for a user.
For a managed appliance, you can perform this procedure on the Central Management
appliance as well as the local appliance. The procedure remains the same. However, you
will need to take the additional step to locate the appliance on the Central Management
CLI. For instructions on locating an appliance on the Central Management CLI, see the
FireEye Central Management Administration Guide.
Prerequisites
l Admin access
To set an account status :
hostname > enable
2. Change the password for the specified user. Use the following command:
username <username> password
3. Disable the means to log in to this account. Use the following command:
username <username> disable

For command usage and parameters, see the CLI Reference.
Managing Your Own Account

Users in all roles can manage their own accounts in the following ways:
l Change their passwords:

l Install secure shell (SSH) authorized keys that permit them to log in from remote
hosts using an SSH identity.
l Create and manage SSH identities that permit them to log in to another host on
which the corresponding authorized key was installed.
42 © 2021 FireEye
Release 2021.1 Managing Your Own Account
l Remove SSH known host entries so they can log in to remote hosts whose host keys
have changed.
l Restrict the ways they can log in locally.
l View their account information, including when their password will expire and
whether they authenticate using a password or an SSH authorized key.
You can use the Web UI (if your appliance has one) to change your password. You can use
the CLI to change your password and perform the other account management functions
available to you.
Changing Your Own Account Password Using the Web UI

To change your own password, use the My Account Setting page.
Users with the Admin role do not have access to this page. Users with the Admin role
manage their own accounts using the User Account Settings page instead.
NOTE: This procedure does not apply to VX Series appliances, which do not

have a Web UI.
To change your own non-Admin password:
1. Go to the Settings > My Account page or, for an HX Series appliance, the Admin
> Appliance Settings > My Account page.
2. Enter your current password in the Current Password box (if present).
3. Enter your new password in the New Password box.
4. Enter your new password again in the Confirm Password box.
© 2021 FireEye 43
Changing Your Own Account Password Using the CLI

Use the CLI commands in this topic to change the password on your own account.
If you are required to enter your current password when you change your password, you can do
this in two different ways:
l You can specify your password interactively by entering the command and then
entering your current password after the CLI prompts you.
l You can specify your password inline by including it as a command option.
If you enter an invalid current password, you must wait three seconds before trying again.
You can set a password with an encrypted string by specifying the hashed string in the
command.
CAUTION! If your role is Monitor, Analyst, or Auditor, you can change your
own account password, but you cannot save the changes. This is because your
role does not permit committing system changes. Your password changes could
be lost if an administrator reboots without saving changes or reverts to the last
saved configuration.
Only Administrators and Operators are allowed to save system changes.
Prerequisites
l Any role
To change the password on your own account:
1. Log in to the CLI as yourself.

hostname > enable
3. Change your password.

Use this command to set a cleartext password:
username <username> password <password>
For example:
hostname (config) # username tsmith password 12345!@#$%AbCdE
If you are required to enter your current password when you change your password:
l To enter your current password interactively, enter your current password

when prompted.
For example:
44 © 2021 FireEye
hostname (config) #username <username> password <password>
Current password:678910!@#$%FgHiJ
l To enter your current password inline, use the following command:

username <username> password <password> curr-
password <currentPassword>
For example:
username tsmith password 12345!@#$%AbCdE curr-password
678910!@#$%FgHiJ
Use the following command to set your password with an encrypted string:
username <username> password 7<encrypted-password>
For example:
hostname (config) # username tsmith password 7
$6$iWtdrQBA$eaJzOvEERGSgYezdnvZ4cU0vMhbBziMtRPfUe7INU8qD9xo0WUCfaF/LqkJ
4agxo1kJj2kXYuWUGY00qeslJ5.
4. (Operator role only) Save your changes:

Example
In this example, Marie changes her password and then displays her account information
two ways.
hostname (config) # username marieb password 12345!@#$%AbCdE
hostname (config) # show usernames user marieb
Local username: marieb
Full name:
Account status: Password set
Role: operator
VLAN: not set

Subnet: not set
Password last set: 2017/01/09 21:28:13

Password age: 20 days 12 hr 17 min 50 sec
Password expires: in 69 days 23 hr 58 min 20 sec
Must change password: no
hostname (config) # show whoami

Username: marieb
Local username: marieb
Full name:
Account status: Password set
Role: operator
VLAN: not set

Subnet: not set
Password last set: 2017/01/09 21:28:13

Password age: 20 days 12 hr 17 min 55 sec
Password expires: in 69 days 23 hr 58 min 15 sec
Must change password: no
© 2021 FireEye 45
Login time: 2017/01/09 21:27:54.002

Auth method: local (password)
Remote address: 10.10.0.0
Line: pts/1
Session ID: 25614
Showing Your Own Account Information Using the CLI

Use the CLI commands in this topic to show information about your own account.
Prerequisites
l Any role
To show information about your own account:

hostname > enable
3. To display your own account information, enter one of the following commands:
l show usernames user <username>
l show whoami
Generating an SSH Client Identity for Yourself Using the

CLI
Use the CLI commands in this topic to generate a new identify that allows you to open a
Secure Shell (SSH) session on another device from this appliance.
Prerequisites
l Any role
To generate a new SSH client identity for yourself on this appliance:

hostname > enable
46 © 2021 FireEye
3. Generate a new identify that allows you to open a Secure Shell (SSH) session on
another device from this appliance. Use the following command:
ssh client user <username> ...
See the CLI Reference for command usage and parameters.
4. View your own SSH client identities:
hostname (config) # show ssh client

Changing the Status of Your Own Local User Account

Using the CLI
Use the CLI commands in this topic to changing your own local user account status.
CAUTION! Although you can change your own user account with a Monitor,
Analyst, or Auditor role, you cannot save the changes to memory. Your changes
could be lost if an administrator reboots without saving changes or reverts to the
last saved configuration.
Prerequisites
l Any role
To change your own local account status:

hostname > enable
3. To change your local account status:
l Specify that you cannot log in to the appliance locally using a password, but
can do so using an SSH authorized key. Use the following command:
username <username> disable login
NOTE: If your role is Monitor, Analyst, or Auditor, the CLI session

will end immediately after you run this command.
l Specify that you cannot log in to the appliance locally, but can log in
remotely. Use the following command:
username <username> disable local-login
© 2021 FireEye 47

Configuring Password Policies

The following sections describe how to configure password policies.
Managing Password Change Policies

You can specify when and the frequency in which users must change their passwords.
You can require users who authenticate locally to change their passwords in the following
circumstances:
l After new users log in the first time

l After a specific period of time elapses
l At the next login attempt, for a specific user or all users
The password change features described in this section are disabled by default.
NOTE: The Web UI display and commands do not apply to VX Series

appliances, which do not have Web-based interfaces.
The new password must be different from the current password, even if no password reuse
restrictions are configured. After users change their passwords, they must log out and then
log in again to access the functionality their role allows.
You can also configure when the system should start warning users that their passwords
will expire. The warnings are displayed after the user logs in.
l In the Web UI (except for VX Series appliances), the warning appears in the
Dashboard:
l In the CLI, the warning appears below a "Password change notice" banner:
If the password is not changed before it expires, the account will not be locked.
In the Web UI, users will be taken directly to the My Account Settings page where a
message is displayed as shown:
48 © 2021 FireEye
Release 2021.1 Configuring Password Policies
Until the user changes the password and then logs out and then logs back in, the Web UI
limits user privileges to changing the passwords.
In the CLI, a message is displayed as shown:
Users will be unable to do anything except change their passwords and run a small
number of basic commands that do not impact the system or show sensitive information
(such as show whoami, show cli, and cli session).
You can disable the maximum password age policy for specific users. Passwords of these
users who have this policy disabled will not expire.
IMPORTANT! These policies apply only to users who authenticate locally.

They are not enforced if a user authenticates remotely and is then mapped to a
local user account that requires a password change, or if a user authenticates
using an SSH authorized key.
CAUTION! The connection between the Central Management appliance and

its managed appliances requires remote user credentials for the appliance (if the
Central Management appliance initiated the connection) or the Central
Management appliance (if the appliance initiated the connection). If the
password expires, the connection between the Central Management appliance
and the managed appliance will be lost until the password is changed and the
connection is reset. To work around this scenario, you can use an
SSH authorized key for authentication. For details, see the System
Administration Guide.
Configuring Password Change Frequency Using the CLI

You can specify how often users must change their passwords using the aaa
authentication password local require-change max-password-age all command.
appliance as well as the local appliance. Use cmc execute appliance <applianceName>
© 2021 FireEye 49
command "aaa authentication password local require-change max-password-

age all <days>" and specify the managed appliance’s hostname in the Central
Management appliance. See the FireEye Central Management Administration Guide for details.
Prerequisites
l Admin access
To configure the password change frequency:
hostname > enable
2. Specify the number of days before a password must be changed. Use the following
command:
aaa authentication password local require-change max-password-age all
<days>
where <days> is a values from 1 through 999.
3. Verify your change:
hostname (config) # show aaa authentication password

Disabling the Password Age Policy Using the CLI

You can disable password expiry for specific users. By default, the maximum password
age policy applies to all users. Use the no version of the aaa authentication password
local require-change max-password-age command and specify the username to disable
the policy for that user.
appliance as well as the local appliance. Use cmc execute appliance <applianceName>
command "no aaa authentication password local require-change max-password-
age user <username> enable" and specify the managed appliance’s hostname in the
Central Management appliance. See the FireEye Central Management Administration Guide for
details.
Prerequisites
l Admin access
50 © 2021 FireEye
To disable the maximum password age policy:
hostname > enable
2. Disable the max password age policy for a user:

no aaa authentication password local require-change max-password-
age user <username> enable
where <username> is the name of the user.
Forcing a Password Change On First Log In Using the CLI

You can require users to change their password on their first log in to the system.
NOTE: This setting affects only users who are created after this change was
made. It does not affect users who were created prior to setting this condition,
even if those users have not logged in yet.
Prerequisites
l Admin access
To require new users to change their passwords after their first login:
hostname > enable
2. Enable the requirement:

hostname (config) # aaa authentication password local require-change
new-account


© 2021 FireEye 51
Forcing a Password Change On Next Log In Using the CLI

There may be times when you need to force users to change their password immediately.
You can specify whether to force everyone or a specific user to change his or her password
on next log in.
Prerequisites
l Admin access
To force a password change on the next login for all users:
hostname > enable
2. Specify the change password on next log in for all users.

hostname (config) # aaa authentication password local require-change
force all

hostname (config) # show usernames password-status

To force a password change on the next login for one user:
hostname > enable
2. To specify the change password on next log in for the user, use the following
command:
aaa authentication password local require-change force user <username>
3. To verify your change, use the following command:

show usernames username <username>

52 © 2021 FireEye
Requiring the Current Password for Password Changes Using

the CLI
You can require users other than the Admin role to enter their current passwords when
they change their passwords. This requirement has the following additional impact:
l The My Account Settings page in the Web UI includes a Current Password field.
l Local login commands such as username <userName> password <password>
prompt for the current password if the user does not supply it as a command
parameter.
CAUTION! Custom scripts that use the CLI to configure user accounts may
need to be updated if the current password is required. For example, a script
that sets the password for a user needs to be modified to accommodate the
prompt for the current password.
Use the commands in this section to require users to enter their current password as well
as their new password when they change passwords.
To require current passwords:
hostname > enable
2. Enable the current password feature:

hostname (config) # aaa authentication password local change require-
current non-admin
3. Verify that it is enabled:


NOTE: To disable the feature, use the no aaa authentication password local
change require-current command.
© 2021 FireEye 53
Providing Advanced Notice of a Required Password Change on

the CLI
You can provide advanced warning that a user's password will expire (from 2 through
999 days), allowing the user time to change the password before he or she is locked out of
the system.
Prerequisites
l Admin access
To configure the advance notice about a pending password change:
hostname > enable
2. To specify the number of days of advance notice, use the following command:
aaa authentication password local require-change advance-warning
<days>
where <days> is a values from 1 through 999.
NOTE: When you specify 1, the unit of measurement is minutes, not days.

This allows you to test your configuration without waiting a full day to see
the results.


NOTE: To remove a configuration, append no to the command. For

example, to remove the requirement for all users to change their passwords
the next time they log in, use the no aaa authentication password
local require-change force all command.
54 © 2021 FireEye
Managing User Password Validation Policies

Password validation policies are used to test user submitted passwords and ensure that
these passwords meet specified minimum standards.
You must use the CLI to configure password policies:
l Limitations of User Password Validation Policies below

l Configuring Local Password Strength Rules Using the CLI below
l Preventing a Password from Matching the Username Using the CLI on page 57
l Configuring Password Reuse Policy Using the CLI on page 58
l Requiring the Current Password for Password Changes Using the CLI on page 59
Limitations of User Password Validation Policies

The following limitations are in effect when configuring passwords:
l Local password validation rules are not applied to passwords managed by remote
authentication tools such as Active Directory, LDAP or a RADIUS server.
l Password validation rules are enforced only when the user sets a plain text string as
the password. They are not applied to passwords that are configured as a hashed
value. For full enforcement, you can prevent administrators from configuring
passwords as hashed values, described in Prohibiting Hashed Passwords Using the
CLI on page 61.
l Password validation rules are enforced only when a password is first added to the
system. They are not applied to passwords that already exist.
Configuring Local Password Strength Rules Using the CLI

To configure the minimum user account password strength requirements for this appliance
or sensor, use the aaa authentication password local commands in CLI configuration
mode. To restore the default settings for any password strength rule, type no in the CLI
command line, followed by the configuration command.
For example, the following command removes the configured restriction on the number of
characters than can be repeated consecutively in a password:
no aaa authentication password local max-chars-repeats
© 2021 FireEye 55
The following command removes configured requirement for the minimum number of
upper-case characters in a password:
no aaa authentication password local character-type upper-case minimum
NOTE: The password validation features described in this procedure are disabled

by default.
Password Strength Commands

The following commands are available to configure user password strength. For more
information on individual commands, see the CLI Guide.
l Minimum Number of Characters

aaa authentication password local length minimum <number>
l Maximum Number of Characters

aaa authentication password local length maximum <number>
l Maximum Number of Repeat Characters

aaa authentication password local max-char-repeats <number>
l Minimum Number of Lower-Case Characters

aaa authentication password local character-type lower-case minimum
<number>
l Minimum Number of Upper-Case Characters

aaa authentication password local character-type upper-case minimum
<number>
l Minimum Number of Numeric Characters

aaa authentication password local character-type numeral minimum
<number>
l Minimum Number of Special Characters

aaa authentication password local character-type special minimum
<number>
l Minimum Number of New Passwords Before Repeating a Password

aaa authentication password local history compare <number>
Prerequisites
l Admin access
To configure password strength rules:
hostname > enable
2. Enter the password strength command.

The table above lists the available commands. For full information about each
command, see the CLI Command Reference.
56 © 2021 FireEye
3. Verify your changes:


Preventing a Password from Matching the Username Using the

CLI
By default, users can select a password that is the same as their username. For stricter
password security, you can prevent this by using a form of the aaa authentication
password command. To remove the restriction on matching password to username, use the
"no" form of the command.
Prerequisites
l Admin access
To prevent a matching username and password:
hostname > enable
2. Prevent users from using their username as a password:

hostname (config) # aaa authentication password local no-userid


Example
See Example: Configuring Password Validation Policies on page 62.
© 2021 FireEye 57
Configuring Password Reuse Policy Using the CLI

You can configure the number of password changes required before users can reuse a
password. When this feature is enabled, the system maintains a history of the configured
number of passwords. For example, if you specify the number 5, users must change their
passwords five times before they can reuse their first password. If the configured number is
changed to a lower number, the oldest excess passwords are removed from the history.
The password history is cleared in the following cases:
l An administrator disables the feature.

l An administrator clears the history.
A password can be reused immediately after the password history is cleared or the feature
is disabled. In both cases, information about the current password, such as the date and
time it was set, is retained.
This procedure describes how to configure the number of times users must change a
password before using it again, and to clear the password history for a specific user or all
users.
Prerequisites
l Admin access
To configure the number of passwords:
hostname > enable
2. Specify the number of previous passwords to maintain. Use the following

command:
aaa authentication password local history compare <number>
where<number>is the number of times a password must be changed before an earlier

password can be reused. Valid values are 1–50.

58 © 2021 FireEye
NOTE: To disable the feature, use either of the following commands:

l
no aaa authentication password local history compare
l
aaa authentication password local history compare 0
To clear the password history:
hostname > enable
2. Clear the history for a specific user. Use the following command:
aaa authentication password local history clear user <userName>
3. Clear the history for all users:

hostname (config) # aaa authentication password local history clear all

Example
See Example: Configuring Password Validation Policies on page 62.
Requiring the Current Password for Password Changes Using

the CLI
You can require users other than the Admin role to enter their current passwords when
they change their passwords. This requirement has the following additional impact:
l The My Account Settings page in the Web UI includes a Current Password field.
l Local login commands such as username <userName> password <password>
prompt for the current password if the user does not supply it as a command
parameter.
CAUTION! Custom scripts that use the CLI to configure user accounts may
need to be updated if the current password is required. For example, a script
that sets the password for a user needs to be modified to accommodate the
prompt for the current password.
Use the commands in this section to require users to enter their current password as well
as their new password when they change passwords.
© 2021 FireEye 59
To require current passwords:
hostname > enable
2. Enable the current password feature:

hostname (config) # aaa authentication password local change require-
current non-admin
3. Verify that it is enabled:


NOTE: To disable the feature, use the no aaa authentication password local
change require-current command.
Managing Admin Password Validation Policies

Administrators have the following features that are not available to other users:
l Use of hashed passwords by default

l Access to log in to the appliance using the LCD screen
You can limit the use of hashed passwords by administrators, and you can specify LCD
password validation requirements.
You must use the appliance CLI to configure password policies:
l Limitations of Admin Password Validation Policies below

l Prohibiting Hashed Passwords Using the CLI on the facing page
l Configuring the LCD Password Minimum Length Using the CLI on the facing page
Limitations of Admin Password Validation Policies

The following limitations are in effect when configuring passwords:
l Local password validation rules are not applied to passwords managed by remote
authentication tools such as Active Directory, LDAP or a RADIUS server.
l Password validation rules are enforced only when a password is first added to the
system. They are not applied to passwords that already exist.
60 © 2021 FireEye
Prohibiting Hashed Passwords Using the CLI

By default, admins can use hashed passwords. When hashed, passwords are not validated
using standard user validation policies. You can disable the use of hashed passwords,
ensuring that the passwords must conform to standard user validation policies.
This procedure shows how you can prevent administrators from using the
username <userName> password 7 <hashValue> command to set passwords as hashed
values. Passwords in plain text are subject to the other password validation rules
described in Managing User Password Validation Policies on page 55.
IMPORTANT! The output of the show configuration command contains

commands to restore system user accounts. These commands include hashed
passwords, which are needed because plain-text passwords are unavailable. If
you prohibit hashed passwords, this restoration cannot be done, and those
commands will be commented out in the output.
Prerequisites
l Admin access
To prohibit or allow hashed passwords:
hostname > enable
2. If you want to prohibit hashed passwords:

hostname (config) # no aaa authentication password local change allow-
encrypted
3. If you want to stop prohibiting hashed passwords:

hostname (config) # aaa authentication password local change allow-
encrypted


Configuring the LCD Password Minimum Length Using the CLI

To configure the minimum password length for this appliance or sensor, use the
aaa authentication password lcd length minimum command in CLI.
NOTE: The minimum password length is set to 0 (no min length) by default.
© 2021 FireEye 61
If you want to set the minimum length of the LCD password, use the command
hostname (config) # aaa authentication password lcd length minimum <number>
where number is 0 by default.
Prerequisites
l Admin access
To configure password strength rules:
hostname > enable
2. Specify the minimum password length. Use the following command:

aaa authentication password lcd length minimum <number>


Example: Configuring Password Validation Policies

This example specifies that a password must include at least one uppercase character, two
numerals, and one special character; that a character cannot be repeated consecutively; and
that the password must be changed five times before it can be used again. It also specifies
that the password must be different from the username, that non-admin users must enter
their current passwords to change their passwords, that admin users cannot use hashed
passwords when they create new users, and that the LCD password must be at least eight
characters.
The following commands are entered at CLI configuration mode:

aaa authentication password local character-type upper-case minimum 1
aaa authentication password local character-type numeral minimum 2
aaa authentication password local character-type special minimum 1
aaa authentication password local character max-char-repeats 1
aaa authentication password local history compare 5
aaa authentication password local no-userid
aaa authentication password local change require-current non-admin
no aaa authentication password local change allow-encrypted
aaa authentication password lcd length minimum 10
show aaa authentication password
Local password requirements:
Minimum length: 8
Maximum length: 32
Maximum character repeats: 1
Minimum lower case characters: 0
62 © 2021 FireEye
Minimum upper case characters: 1

Minimum special characters: 1
Minimum numeric characters: 2
Recent passwords to check against: 5
Allowed to match userid: no
Require current password on change: yes

(non-admin users only)
Allow set of encrypted password: no

(admin users only)
Require password change on local accounts:
Require password change for new account: no

Maximum password age before change required: none
Warn user before password expires: 7 days ahead
LCD password requirements:
Minimum length: 10
© 2021 FireEye 63
64 © 2021 FireEye
CHAPTER 4: Remote
Authentication
For security, the provided Monitor user account is locked out by default. This account must
be enabled before remote users can be mapped to it. For more information, see Managing
Account Status on page 40.
NOTE: A user with a reject user account is automatically locked out and is not
associated with a role by default.
For details about configuring method-specific attribute strings, see:
l Configuring RADIUS Authentication Using the CLI on the next page

l Configuring TACACS+ Authentication on page 69
l LDAP Server Configuration on page 71
l Configuring an Active Directory Server Using the CLI on page 74
l Local Overrides of Remote User Mappings on page 75
Prerequisites
l Admin access to the appliance.
l If a remote authentication server is configured with an IPv6 address: In the Configure
IPv6 section of the Network Settings page of the appliance Web UI, the Global IPv6
and Management Interface IPv6 checkboxes are selected. (They are selected by
default.)
© 2021 FireEye 65
System Security Guide CHAPTER 4: Remote Authentication
Configuring RADIUS Authentication

Using the CLI
This section describes how to configure a RADIUS server to return Local-User attributes,
and to enable an appliance to authenticate with a RADIUS server.
Configuring a RADIUS Server

Your RADIUS server configuration should follow standard RADIUS protocol. The
examples in this section are provided for illustration only.
To configure a RADIUS server:
1. Configure a secret key on the authentication server. The same key must be
configured on both the server and the appliance.
2. Create a dictionary to reference the following mapping data:
VENDOR FireEye 25597
BEGIN-VENDOR FireEye
ATTRIBUTE FireEye-Local-User 1 string
END-VENDOR FireEye
where Local-User is the mapping attribute with an index of 1 that matches the
FireEye code.
3. Store the dictionary, typically in the /user/share/radius/dictionary directory.

4. Use the authentication types shown in the following example to create user
authentications against the RADIUS server login credentials, and authentication
against “on-the-fly” passwords:
<username> Auth-Type := System
FireEye-Local-User = “admin”
r-admin Auth-Type := Local, User-Password == “test123”
FireEye-Local-User = “admin”
r-monitor Auth-Type := Local, User-Password == “test123”
FireEye-Local-User = “monitor”
Both r-admin and r-monitor are authenticated against “on-the-fly” passwords.

Local-User is the string defined in the dictionary and used by the authentication
server to map to the local user. In the example above, both <username> and r-
admin are Admin users on the FireEye appliance, while r-monitor is mapped to
the appliance’s Monitor role.
6. Restart the RADIUS server after authentication mappings are modified. For example,
enter service radiusd restart.
66 © 2021 FireEye
Release 2021.1 Configuring RADIUS Authentication Using the CLI
Auth-Type := System causes the RADIUS server to use the password file on
the server for user passwords. Passwords for users with the Admin or Monitor
role must be specified on an individual basis.
Enabling an Appliance to Authenticate with a

RADIUS Server
Use the commands in this section to enable an appliance to authenticate with a RADIUS
server.
You can configure multiple RADIUS servers on an appliance. The appliance

will contact the servers in the order in which they were configured. If the first
server in the list is unreachable, the appliance will contact the next server, and
so on.
You can configure some RADIUS settings globally, so the settings apply to all
new RADIUS servers configured on an appliance and become the new default
settings. For example, you could use the radius-server timeout <seconds>
command to configure the timeout value for all RADIUS servers.
To enable RADIUS authentication:
1. Define the server host and server key attributes:

hostname <config> # radius-server host <ip address> key <key string>
where ip address is the IPv4 or IPv6 address of the RADIUS server and key
string is the secret key configured on the RADIUS server.
Link-local and site-local IPv6 addresses are not supported.
2. By default, the appliance retransmits a request that previously timed out after three
seconds. To change the number of seconds:
hostname (config) # radius-server host <ip address> timeout <seconds>
where seconds can be 1–60.

3. By default, the appliance attempts to contact the RADIUS server one time before the
request fails. To change the number of attempts:
hostname (config) # radius-server host <ip address> retransmit <number>
where number can be 0–5.

4. By default, the port number for RADIUS authentication is 1812. To change the port
number, or to define an additional port for another RADIUS service:
hostname (config) # radius-server host <ip address> auth-port <port
number>
© 2021 FireEye 67
5. Add RADIUS authentication to the authentication method list in the desired order.
For example:
hostname (config) # aaa authentication login default local radius

hostname (config) # show radius
A RADIUS server is administratively enabled by default. Use the radius-server

host <ip address> enable command if you need to re-enable it, or if you want
to add a new RADIUS server that is initially disabled.
See the CLI Command Reference for a complete list of RADIUS server commands
and parameters.
Examples
The following example configures a RADIUS server and changes the timeout and
retransmit values.
hostname (config) # radius-server host 192.168.1.1 key 12345678
hostname (config) # radius-server host 192.168.1.1 timeout 5
hostname (config) # radius-server host 192.168.1.1 retransmit 2
RADIUS Settings:
Authentication and Authorization are enabled in AAA configuration.
RADIUS DEFAULTS:
Key: ********
Timeout: 3
Retransmit: 1
RADIUS servers:
192.168.1.1:1812
Enabled: yes
Key: *********
Timeout: 5
Retransmit: 2
The following example configures three RADIUS servers on the appliance, and then
defines global settings for the timeout and retransmit values.
hostname (config) # radius-server host fdd3:c75:345::8a4 key 34567890
hostname (config) # radius-server timeout 5
hostname (config) # radius-server retransmit 1
RADIUS Settings:
RADIUS defaults:
Key: ********
Timeout: 5
Retransmit: 1
RADIUS servers:
68 © 2021 FireEye
Release 2021.1 Configuring TACACS+ Authentication
192.168.1.2:1812
Enabled: yes
Key: ********
Timeout: 5 (default)
Retransmit: 1 (default)
fdd3:c75:345::8a4:1812
Enabled: yes
Key: ********
192.168.3.4:1812
Enabled: yes
Key: ********
Configuring TACACS+ Authentication

This topic describes how to configure a TACACS+ server to return Local-User attributes,
and to enable an appliance to authenticate with a TACACS+ server.
Configuring a TACACS+ Server

Use the commands in this section to configure a TACACS+ server.
Your TACACS+ server configuration should follow standard TACACS+ protocol.

The examples in this topic are provided for illustration only.
To configure a TACACS+ server:
1. Define users on the authentication server.

2. In the tac_plus.conf file on the authentication server, configure a secret key. The
same key must be configured on both the server and the appliance.
3. Store the file, typically in the /usr/local/etc/ directory.
4. Create user authentications against the TACACS+ server login credentials:
user=t-admin {
pap = cleartext “test123”
service = fireeye-exec {
"local-user-name-fireeye” = “admin”
}
}
user=t-monitor {
pap = cleartext “test123”
service = fireeye-exec {
“local-user-name-fireeye” = “monitor”
}
}
where local-user-name-fireeye is the mapping attribute that matches the

FireEye code, and fireeye-exec matches the service definition. The t-admin user
© 2021 FireEye 69
maps to the appliance admin role, and the t-monitor user maps to the appliance
monitor role.
5. After configuring authentication mappings, put the following line in the

/etc/rc.local file to start the authentication mapping on reboot:
/usr/local/bin/tac_plug -g -C /usr/local/etc/tac_plus.conf
Enabling an Appliance to Authenticate with a TACACS+

Server
Use the commands in this section to enable an appliance to authenticate with a TACACS+
server.
You can configure multiple TACACS+ servers on an appliance. The appliance

will contact the servers in the order in which they were configured. If the first
server in the list is unreachable, the appliance will contact the next server, and
so on.
You can configure some TACACS+ settings globally, so the settings apply to all
TACACS+ servers configured on an appliance and become the new default
settings. For example, you could use the tacacs-server timeout <seconds>
command to configure the timeout value for all TACACS+ servers.
To enable TACACS+ authentication:
1. Define the server host and server key attributes:

hostname <config> # tacacs-server host <ip address> key <key string>
where ip address is the IPv4 address of the TACACS+ server and key string is
the secret key configured on the TACACS+ server.
2. By default, the appliance retransmits a request that previously timed out after three
seconds. To change the number of seconds:
hostname (config) # tacacs-server host <ip address> timeout <seconds>
where seconds can be 1–60.

3. By default, the appliance attempts to contact the TACACS+ server one time before
the request fails. To change the number of attempts:
hostname (config) # tacacs-server host <ip address> retransmit <number>
where number can be 0–5.

4. By default, the port number for TACACS+ authentication is 49. To change the port
number:
hostname (config) # tacacs-server host <ip address> auth-port <port
number>
70 © 2021 FireEye
Release 2021.1 LDAP Server Configuration
5. By default, PAP is the TACACS+ authentication type. To change the authentication

type:
hostname (config) # tacacs-server host <ip address> auth-type <type>
where type is ascii or pap.

6. Add TACACS+ authentication to the authentication method list in the desired order.
For example:
hostname (config) # aaa authentication login default local tacacs+

hostname (config) # show tacacs
A TACACS+ server is administratively enabled by default. Use the tacacs-

server host <ip address> enable command if you need to re-enable it.
See the CLI Command Reference for a complete list of TACACS+ server commands
and parameters.
Example
The following example configures a TACACS+ server and changes the timeout and
retransmit values.
hostname (config) # radius-server host 192.168.2.1 timeout 5
hostname (config) # radius-server host 102.168.2.1 retransmit 2
hostname (config) # aaa authentication login default local tacacs+
hostname (config) # show tacacs
TACACS+ Settings:
Accounting is disabled in AAA configuration.
TACACS+ DEFAULTS:
Key: ********
Timeout: 3
Retransmit: 1
TACACS+ servers:
192.168.2.1:49
Enabled: yes
Auth Type: pap
Key: *********
Timeout: 5
Retransmit: 2
LDAP Server Configuration

This section describes how to configure LDAP servers to authenticate users. It contains the
following topics:
© 2021 FireEye 71
l Configuring an LDAP Server below

l Defining LDAP Search Filters below
l Example: Configuring an LDAP Server on the facing page
Configuring an LDAP Server
For LDAP configuration, localUserNameFireEye is the attribute name for mapping to the
Admin or Monitor role.
NOTE: This topic describes how to configure the LDAP server, not the FireEye
appliance. Your configuration should follow standard LDAP protocol; the
examples in this topic are provided for illustration only.
To configure an LDAP server:
1. Add local user attributes:

a. Define a schema at /etc/openldap/schema/fireeye.schema.
b. Refer to the schema in your sldap.conf file on the LDAP server.
c. On the authentication server, add the localUserNameFireEye attribute to the
schema so that it can be defined and referenced in the user definition.
2. Define users.
3. On the appliance, define the server host, base-dn, and login-attribute.
4. Run the service ldap start CLI command after configuring authentication
mappings.
Defining LDAP Search Filters

An administrator can define an LDAP search filter in the local configuration that controls
which users can log in using LDAP. For example, the filter could prevent users who are
not part of a certain LDAP group from logging in. A negative response from the filter takes
precedence over a remote authentication server that permits the user to log in.
Prerequisites
l Admin access
To specify or remove an LDAP search filter:
hostname > enable
72 © 2021 FireEye
Release 2021.1 LDAP Server Configuration
2. To configure the LDAP search filter, use the following command:

ldap search-filter <filterString>
IMPORTANT! If the <filterString> contains spaces, enclose the

string with double quotation marks.
The following example defines a filter that allows "operator" role users in the Acme
IT network group to log in using LDAP.
hostname (config) # ldap search-filter "(|
(memberOf=cn=Operators2,ou=Network Group,dc=acmeit,dc=com)"
3. Remove a search filter:

hostname (config) # no ldap search-filter

Example: Configuring an LDAP Server

The following example shows how to add the FireEye attribute to the schema file:
attributetype ( FEattributeType:1
NAME ‘localUserNameFireEye’
DESC ‘local username to map this user to the appliance’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32}
SINGLE-VALUE )
The following example shows how to define users:

# 1-admin
dn: cn=ldap-admin,ou=users,dc=fireeye,dc=com
objectclass: top
objectclass: FireEyeEmployee
cn: ldap-admin
sn: ldap-admin
uid: 1-admin
localUserNameFireEye: admin
userPassword: gaNoLdT7LYczjvD1F3oSUQCMvRy7gwk2
# 1-monitor
dn: cn=ldap-monitor,ou=users,dc=fireeye,dc=com
objectclass: top
objectclass: FireEyeEmployee
cn: ldap-monitor
sn: ldap-monitor
uid: 1-monitor
localUserNameFireEye: monitor
userPassword: gaNoLdT7LYczjvD1F3oSUQCMvRy7gwk2
NOTE: In this example, the password "test123" is encrypted as

gaNoLdT7LYczjvD1F3oSUQCMvRy7gwk2 .
© 2021 FireEye 73
The following example shows how to define attributes on the FireEye appliance:
ldap host hostname
ldap base-dn cn=ldap-monitor,ou=users,dc=fireeye,dc=com ldap login-attribute
uid
Configuring an Active Directory Server

Using the CLI
Because Active Directory (AD) supports the LDAP protocol, FireEye appliances can also
authenticate through an AD server.
The binding user or bind-dn as seen in the FireEye configuration is a read-only user that is
used to query the directory structure starting from the base-dn. The
localUserNameFireEye attribute is an addition that needs to be made above other
attributes used by default on Active Directory. Adding the localUserNameFireEye as an
attribute to the AD schema is not without risks. Refer to the following resource for more
information:
https://technet.microsoft.com/en-us/library/2008.05.schema.aspx?pr=blog
IMPORTANT! The localUserNameFireEye attribute requires a non-

administrator “binding user” for searching and browsing AD server records.
Prerequisites
l Admin access
To configure Active Directory authentication:
hostname > enable
2. Configure the host to send LDAP authentication requests. Use the following
command:
ldap host <adServerHostnameIpaddress>
3. Configure the LDAP user search base. Use the following command:
ldap base-dn <ldapBaseDN>
4. Set the Distinguished Name used to bind to the server. Use the following command:
ldap bind-dn <searchUserDN>
74 © 2021 FireEye
Release 2021.1 Local Overrides of Remote User Mappings
5. Configure the credentials used to bind to the server. Use the following command:
ldap bind-password <searchUserPassword>
6. Configure which attribute holds the login name. Use the following command:
ldap login-attribute sAMAccountName
sAMAccountName is a fixed value that replaces the<uid>attribute defined for LDAP

authentication.
Local Overrides of Remote User

Mappings
When remote users are authenticated by a remote server, they are logged in to the
appliance as a local user and are granted the same access privileges as that user. For any
remote authentication method, the mapping of a remote user to a local user is configured
in a method-specific attribute string that is returned by the remote server after a user is
authenticated.
You can use the aaa authorization rules rule command to configure rules in the local
configuration to override this mapping when specified conditions are met. This is
described in the following topics:
l About Overriding Remote User Mappings below

l Locally Overriding Remote User Mappings Using the CLI on the next page
If the user is authenticated by the remote server but the remote server does not return the
attribute string, the remote user is logged in as the default local user. This is specified by
the aaa authorization map default-user CLI command, as described in the following
topic:
l Mapping Remote Users to Default Local Users Using the CLI on page 77.
About Overriding Remote User Mappings

When a remote user logs into the appliance, a remote authentication server typically
determines which local user account on the appliance the remote user should use.
It uses one of the following methods to do this:
l Mapping to a local user account according to rules set by the aaa authorization
map order CLI command. The mapping can come from the local configuration or
© 2021 FireEye 75
from an attribute in the remote authentication server's response.

l Directly from an attribute in the remote authentication server's response.
An administrator can use the aaa authorization rules rule CLI command to
configure rules in the local configuration that override this mapping when the specified
conditions are met. Rule criteria include the following:
l Authentication type
l Remote user name
l Local user name (before the override)
l LDAP group
l LDAP search filter
The first rule that evaluates as "true" will override the initial mapping, and the remaining
rules will not be considered. If a rule includes multiple criteria, every criterion must be met
before the rule itself can evaluate as true. For example, if a rule specifies that the remote
username must be "alice" and that the LDAP group cannot be "group_a" , the rule will
evaluate as true if the user is Alice, but only if she is in a group other than Group A.
For more information, see Locally Overriding Remote User Mappings Using the CLI below.
Locally Overriding Remote User Mappings Using the CLI

Use the CLI commands in this topic to override remote user mappings.
Prerequisites
l Admin access
To configure local override rules:
hostname > enable
2. Displays all authorization rules, including whether they are enabled:

hostname (config) # show aaa authorization rules
3. Enable all authorization rules:

hostname (config) # aaa authorization rules enable
4. Disable all authorization rules:

hostname (config) # no aaa authorization rules enable
5. To delete the specified rule, use the following command:

no aaa authorization rules rule <ruleNumber>
76 © 2021 FireEye
Release 2021.1 Local Overrides of Remote User Mappings
6. To create a new rule or to modify an existing rule, use the following command:
aaa authorization rules rule <wordPair>
where <wordPair> is one of the following:

l append tail creates a new rule after the highest-numbered existing rule or at
position 1 if there are no rules.
l insert <ruleNumber> creates a new rule at the specified number. If another
rule is already at that position, it is shifted up by one, along with the other
existing rules above it.
l set <ruleNumber> creates a new rule at the specified number. If another rule
is at that position, it is replaced.
l modify <ruleNumber> creates or modifies the rule at the specified number. If
another rule is at that position, its values are preserved, except when they are
overwritten by new values specified in this command.
Mapping Remote Users to Default Local Users Using the

CLI
If a remote authentication method does not return a local user attribute string after a
remote user is authenticated, the remote user will be mapped to a default local user
account.
Prerequisites
l Admin access
To specify the default local user account:
hostname > enable
2. To specify the default local user account, use the following command:
aaa authorization map default-user <username>
Any non-mapped users will default to the specified local user account.
© 2021 FireEye 77
78 © 2021 FireEye
System Security Guide About CAC for Certificate Authentication
CHAPTER 5: Common Access

Card (CAC) for Certificate
Authentication
This section covers the following information:
l About CAC for Certificate Authentication below

l Configuring a CA Certificate Bundle on page 81
l Enabling or Disabling the Policy Settings of the Web UI for Certificate Authentication
on page 86
l Configuring Certificate Revocation for Certificates on page 88
l Configuring the User Attributes for Certificate Authentication on page 96
l Configuring LDAP for Authorization on page 99
l Configuring Local User Mappings for Authorization on page 107
l Logging in to the Web UI for Certificate Authentication on page 112
l Verifying Certificate Authentication Status Using the Web UI on page 113
NOTE: These procedures do not apply to VX Series appliances.
About CAC for Certificate Authentication

A Common Access Card (CAC) or a Personal Identity Verification (PIV) is a smart card
that is used by many government employees for all user authentications. Both CAC and
PIV use the X.509 standard for a Public Key Infrastructure (PKI) as an authentication
mechanism to manage certificates.
© 2021 FireEye 79
System Security Guide CHAPTER 5: Common Access Card (CAC) for Certificate Authentication
The keys and the certificates are stored on the CAC card. CAC satisfies a two-factor
authentication (2FA) because you must place a physical card in a CAC reader and know a
Personal Identification Number (PIN). The CAC card stores the public certificates and the
corresponding private keys that belong to the user.
The certificate is automatically uploaded from the CAC card to the browser, and the user
selects an installed certificate to log in. The user is prompted to enter the PIN of the CAC
card. If the PIN is validated, the card unlocks a private key that is used to set up a TLS
connection with the appliance. The certificate identifies the user and it is used to set up a
TLS connection. If the certificate is verified and signed by a trusted Certificate Authority
(CA) and has not been revoked, the user is authenticated and can log in to the Web UI. The
private key never leaves the CAC card.
The following are the two security elements to allow the user to gain access to the Web UI:
l Authentication—Verifies the certificate date, obtains the revocation status of the

X.509 certificate through the Online Certificate Status Protocol (OCSP) or the
Certificate Revocation List (CRL), and verifies the CA certificate chain.
l Authorization—Maps the X.509 certificate fields to match an entry in the Active
Directory (AD) or to match locally configured rules to permit or deny access to the
Web UI.
IMPORTANT! X.509-based authentication is mutually exclusive with

OIDC-based authentication. If FireEye IAM or single sign-on (SSO)
authentication are configured, do not enable CAC or PIV authentication. FireEye
IAM uses the OpenID Connect (OIDC) identity layer on top of the OAuth 2.0
protocol to manage sessions between end users and their resources, and SSO
authentication requires FireEye IAM. See FireEye IAM Overview on page 281
and SSO Authentication Overview on page 143.
Task List for Configuring the Appliance to Use CAC for

Certificate Authentication
Complete the steps for configuring the appliance to use CAC for authentication in the
following order:
1. Log in to the CLI.

2. (Optional) Configure the LDAP settings. Use this step only if you intend to configure
the LDAP server to authorize users. For details about how to configure an LDAP
server, see LDAP Server Configuration on page 71.
3. Download a CA certificate bundle or add an imported certificate to an existing
bundle from a specified URL. For details about how to download a CA certificate
bundle, see Downloading a CA Certificate Bundle Using the CLI on page 85.
80 © 2021 FireEye
Release 2021.1 Configuring a CA Certificate Bundle
4. Enable policy settings of the Web UI for certificate authentication. For details about
how to enable policy settings of the Web UI, see Enabling or Disabling the Policy
Settings of the Web UI for Certificate Authentication on page 86.
5. Configure user attributes for certificate authentication. For details about how to
configure the user attributes for certificate authentication, see Configuring the User
Attributes for Certificate Authentication on page 96.
6. (Optional) Enable and configure OCSP so that the appliance can validate certificate
revocation. For details about how to enable and configure OCSP for certificate
validation, see Enabling or Disabling OCSP Using the CLI on page 89
7. (Optional) Download a local Certificate Revocation List (CRL) file from a specified
remote location so that the appliance can validate certificate revocation. For details
about how to download a local CRL file for certificate validation, see Downloading
a Local CRL File Using the CLI on page 95.
8. Configure LDAP mappings for authorization if you selected to configure an LDAP
server to authorize users. For details about how to configure LDAP mappings for
authorization, see Configuring LDAP for Authorization on page 99.
9. Configure local user mappings for authorization. For details about how to configure
local user mappings for authorization, see Configuring Local User Mappings for
Authorization on page 107.
On Central Management and Network Security appliances the user can log in to the Web
UI for certificate authentication by entering the user name and password provided by the
administrator, using a certificate, or both. For details about how to log in to the Web UI, see
Logging in to the Web UI for Certificate Authentication on page 112.
Configuring a CA Certificate Bundle

You can configure Certificate Authority (CA) certificate bundles that are used to validate
client certificates by using the appliance CLI.
l Adding a CA Certificate to a Bundle Using the CLI on the next page

l Deleting a CA Certificate From a Bundle Using the CLI on page 84
l Downloading a CA Certificate Bundle Using the CLI on page 85
The appliance supports single PEM-encoded certificates. A set of intermediate and root CA
certificates are used to validate the certificates from the CAC card and they are presented to
the appliance. You can download a certificate bundle from a remote URL, import all the
certificates to the appliance, and add the certificates to the specified bundle list.
The following important attributes are provided in the certificate:
© 2021 FireEye 81
l Subject
l Public Key
l Serial Number
l Valid to (expiration date)
l Key Usage
l Subject Alternative Name
For details about how to define the certificate attributes, see Defining Default Certificate
Attributes on page 273.
Prerequisites
l (Optional) LDAP servers have been configured to authorize users. For details about
how to configure an LDAP server, see LDAP Server Configuration on page 71.
Adding a CA Certificate to a Bundle Using the CLI

Use the CLI commands in this section to add a CA certificate to a bundle.
NOTE: The certificate name must already exist in the system.
NOTE: The certificate bundle must be named client-cert-auth.
To add a CA certificate to a bundle:

hostname > enable
2. Add a certificate that already has been configured to the bundle.

hostname (config) # crypto certificate bundle <bundle_name> cert-name
<certificate_name>
where <bundle_name> is the name of the certificate bundle. The bundle must be
named client-cert-auth.
<certificate_name> is the name of the certificate that already has been configured.
3. Verify the list of all the certificates that have been added to the bundle.
hostname (config) # show crypto certificate bundle client-cert-auth
Certificate bundle 'client-cert-auth':
Certificate with name 'client-cert-auth-0235cfce'
82 © 2021 FireEye
Certificate Type: RSA

Private Key: not present
Serial Number: 0xd1de64fae48a6876
SHA-1 Fingerprint:
64171a6cab5b92ae6006f851c37ed84202198690
Validity:
Starts: 2016/10/07 13:11:23
Expires: 2026/10/05 13:11:23
Subject:
Common Name: vps1_root_ca_1
Country: US
State or Province: CA
Locality: Milpitas
Organization: FireEye
Organizational Unit: CAou
Issuer:
Country: US
Locality: Milpitas
Certificate with name 'client-cert-auth-d7217279'
Serial Number: 0x1001
SHA-1 Fingerprint:
6d3565c309038644b32ece8a732b2bbfdbc52460
Validity:
Starts: 2016/10/10 10:46:12
Expires: 2026/10/08 10:46:12
Subject:
Common Name: vps1_ca_3
Country: US
Locality: Milpitas
© 2021 FireEye 83
Issuer:
Country: US
Locality: Milpitas

Deleting a CA Certificate From a Bundle Using the CLI

Use the CLI commands in this section to delete a CA certificate from a bundle.
To delete a CA certificate from a bundle:

hostname > enable
2. Depending on whether you want to keep the certificates in the database, choose one
of the following options:
l To delete the certificates from a bundle and delete them directly from the
database:
hostname (config) # no crypto certificate bundle <bundle_name>
cert-name <certificate_name>
where <bundle_name> is the name of the certificate bundle. The bundle must
be named client-cert-auth.
<certificate_name> is the name of the certificate that already has been
configured.
l To delete the certificates from a bundle but keep them in the database:
hostname (config) # no crypto certificate bundle <bundle_name>
cert-name <certificate_name> keep-member-certs
where <bundle_name> is the name of the certificate bundle. The bundle must
be named client-cert-auth.
<certificate_name> is the name of the certificate that already has been
configured.
3. Verify that the specified certificate is deleted from the bundle named client-cert-
auth.
hostname (config) # show crypto certificate bundle client-cert-auth
84 © 2021 FireEye

Downloading a CA Certificate Bundle Using the CLI

Use the CLI commands in this section to download a CA certificate bundle, and add an
imported certificate to an existing bundle from a specified URL. The bundle must be a
single concatenated PEM file. Each certificate is imported in to the bundle configuration.
The imported certificates are listed in the specified bundle.
By default, if the name of the bundle already exists, it will be replaced with an imported
certificate.
NOTE: The certificate bundle must be named client-cert-auth.
To download a CA certificate bundle:

hostname > enable
2. Specify the name for the certificate bundle and download it.
hostname (config) # crypto certificate bundle <bundle_name> fetch url
<url>
where:
l <bundle_name> is the name of the certificate bundle. The bundle must be
client-cert-auth.
l <url> is the direct path to the certificate file. The <url> is specified with
remote server Administrator credentials (<username> and <password>), the
remote server( <hostname>), the path and filename in which to save the
certificate bundle (<path/filename>) in the following format:
scp://<username>[:<password>]@<hostname>/<path/filename>
NOTE: If you do not specify the remote host administrator

password in the crypto certificate bundle fetch url
command (where the password would be visible as clear text), the
CLI prompts for the password and obfuscates the keyboard input as
you type it.
If the certificates were successfully imported, the command output is as follows:

Successfully imported 2 of 2 certificate(s).
3. (Optional) Add a new certificate to an existing certificate bundle. The existing

certificates will be retained in the database.
© 2021 FireEye 85
hostname (config) # crypto certificate bundle <certificate_name> fetch

url <url> append
4. Verify the list of all the certificate bundle names. The comment is added
automatically when you import a certificate bundle.
hostname (config) # show crypto certificate bundle
Bundle name Comment
=======================================================================
client-cert-auth Imported from
http://builds.eng.fireeye.com/~john.doe/vps1-cacerts.pem
5. (Optional) View the Privacy Enhanced Email (PEM) encrypted ASCII string of the
certificate bundle.
hostname (config) # show crypto certificate bundle client-cert-auth pem
-----BEGIN CERTIFICATE-----
MIIFRzCCBC+gAwIBAgIJANHeZPrkimh2MA0GCSqGSIb3DQEBCwUAMGcxCzAJBgNV
BAYTAlVTMQswCQYDVQQIDAJDQTERMA8GA1UEBwwITWlscGl0YXMxEDAOBgNVBAoM
B0ZpcmVFeWUxDTALBgNVBAsMBENBb3UxFzAVBgNVBAMMDnZwczFfcm9vdF9jYV8x
.....
-----END CERTIFICATE-----

Enabling or Disabling the Policy Settings

of the Web UI for Certificate
Authentication
The administrator can enable the policy settings of the Web UI for certificate authentication
to allow the user to choose one of the following options:
l Log in to the Web UI using the user name and password provided by their
administrator or using a certificate when a client X.509 certificate is optional for user
authentication. For details, see Logging in to the Web UI for Certificate
Authentication on page 112.
l Log in to the Web UI using a certificate when a client X.509 certificate is mandatory
for user authentication. For details, see Logging in to the Web UI for Certificate
When certificate authentication is not mandatory, you can configure the appliance not to
accept a client X.509 certificate.
86 © 2021 FireEye
Release 2021.1 Enabling or Disabling the Policy Settings of the Web UI for Certificate Authentication
NOTE: You cannot use other authentication methods that are already configured
to log in to the Web UI.
NOTE: You can enable or disable the policy settings of the Web UI for certificate
authentication only using the CLI. Policy settings are disabled by default.
Prerequisites
l A Certificate Authority (CA) certificate bundle has been downloaded, and an
imported certificate has been added to an existing bundle from a specified URL. For
details about how to download CA certificate bundle, see Downloading a CA
Certificate Bundle Using the CLI on page 85.
Enabling or Disabling the Policy Settings of the Web UI

for Certificate Authentication Using the CLI
IMPORTANT! X.509-based authentication is mutually exclusive with
OIDC-based authentication. If FireEye IAM or single sign-on (SSO)
authentication are configured, do not enable CAC or PIV authentication. FireEye
IAM uses the OpenID Connect (OIDC) identity layer on top of the OAuth 2.0
protocol to manage sessions between end users and their resources, and SSO
authentication requires FireEye IAM. See FireEye IAM Overview on page 281
and SSO Authentication Overview on page 143.
Use the CLI commands in this section to enable or disable the policy settings of the Web UI
to authenticate users using a X.509 certificate.
NOTE: Use the no aaa authentication certificate web policy command to

reset the policy not to accept a certificate for user authentication.
To enable the policy settings of the Web UI for certificate authentication:

hostname > enable
© 2021 FireEye 87
2. Enable users to log in to Web UI for certificate authentication.

l To accept an optional X.509 certificate:
hostname (config) # aaa authentication certificate web policy
allowed
NOTE: Users log in to the Web UI either using the user name and
password provided by their administrator or using an optional X.509
certificate.
l To use only a client X.509 certificate:

hostname (config) # aaa authentication certificate web policy
required
3. Verify the status of the policy settings of the Web UI.

hostname (config) # show aaa authentication certificate
Certificate based authentication settings:
Web Policy : required
.....

To disable the policy settings of the Web UI to not accept a certificate:

hostname > enable
2. Disable the policy settings of the Web UI to not accept a client X.509 certificate.
hostname (config) # aaa authentication certificate web policy disabled
3. Verify the status for the policy settings of the Web UI.
Web Policy : disabled
.....

Configuring Certificate Revocation for

Certificates
You can configure certificate revocation for X.509 certificates by using the appliance CLI:
88 © 2021 FireEye
Release 2021.1 Configuring Certificate Revocation for Certificates
l Enabling or Disabling OCSP Using the CLI below

l Enabling or Disabling the OCSP Override Responder Using the CLI on page 91
l Adding or Removing the OCSP URL Using the CLI on page 92
l Enabling or Disabling a Certificate with Missing Basic Constraints Using the CLI on
page 93
l Deleting a CRL File Using the CLI on page 94
l Downloading a Local CRL File Using the CLI on page 95
Both the Online Certificate Status Protocol (OCSP) and the Certificate Revocation List (CRL)
protocol are used to validate whether an X.509 certificate has been revoked. OCSP is used
as an alternative to the CRL.
OCSP servers are also referred as OCSP responders. OCSP allows the appliance to check if
a certificate has been revoked without downloading and searching the entire list. If an
OCSP URL is found in the certificate, the OCSP responder is queried to determine the
status of the certificate revocation. If an OCSP URL is not found in the certificate or the
appliance cannot communicate with the OCSP responder from the certificate, a configured
default URL is used.
A CRL contains a list of certificates that have been revoked or can no longer be trusted.
When a TLS connection is set up with the appliance, part of the authentication process is
to validate that the certificate is not listed in the CRL. Each entry in the list corresponds to
the certificate number and the date of the revoked certificate.
Prerequisites
l Policy settings of the Web UI have been enabled for certificate authentication. For
details about how to enable policy settings of the Web UI, see Enabling or Disabling
the Policy Settings of the Web UI for Certificate Authentication on page 86.
Enabling or Disabling OCSP Using the CLI

Use the CLI commands in this section to enable or disable the Online Certificate Status
Protocol (OCSP) so that the appliance can verify the status of the certificate revocation.
© 2021 FireEye 89
When OCSP is enabled and the appliance cannot reach the OCSP server, the user is denied
access to the Web UI.
NOTE: OCSP is enabled by default.
To enable OCSP:

hostname > enable
2. Enable OCSP for certificate authentication.

hostname (config) # aaa authentication certificate ocsp enable
3. Verify the status of OCSP.

Certificate field for username : x509-cert-subject-cn
CA certificate bundle : client-cert-auth
OCSP enabled : yes
...

To disable OCSP:

hostname > enable
2. Disable OCSP for certificate authentication.

hostname (config) # no aaa authentication certificate ocsp enable
3. Verify the status of OCSP.

OCSP enabled : no
...
90 © 2021 FireEye

Enabling or Disabling the OCSP Override Responder

Using the CLI
Use the CLI commands in this section to enable or disable the OCSP override responder so
that the default OCSP responder is used when the certificate is being validated even if the
certificate references an OCSP responder.
NOTE: The OCSP override responder setting is disabled by default.
To enable the OCSP override responder:

hostname > enable
2. Enable the override of the OCSP responder from the certificate that is being
validated and instead use the default OCSP responder.
hostname (config) # aaa authentication certificate ocsp override-
responder
3. Verify the status of the OCSP responder.

OCSP enabled : no
Default OCSP URL : http://10.3.13.219:80
OCSP override responder : yes
...

To disable the OCSP override responder:

hostname > enable
2. Disable the override of the OCSP responder from the certificate that is being
validated.
© 2021 FireEye 91
hostname (config) # no aaa authentication certificate ocsp override-

responder
3. Verify the status of the OCSP responder.

OCSP enabled : no
OCSP override responder : no
...
Adding or Removing the OCSP URL Using the CLI

Use the CLI commands in this section to add or remove the default OCSP URL so that the
appliance can validate certificate revocation.
To add the default OCSP URL:

hostname > enable
2. Specify the default OCSP URL so that certificate revocation can be validated.
hostname (config) # aaa authentication certificate ocsp default URL
<URL>
where <URL> is the default URL that is configured on the appliance. This URL is
based on the configuration of the OCSP override responder.
3. Verify the configuration of the OCSP URL.
OCSP enabled : no
...

92 © 2021 FireEye
To remove the default OCSP URL:

hostname > enable
2. Remove the default OCSP URL.

hostname (config) # no aaa authentication certificate ocsp default URL
3. Verify the configuration of the OCSP URL.

OCSP enabled : no
Default OCSP URL : Not Configured
...

Enabling or Disabling a Certificate with Missing Basic

Constraints Using the CLI
Use the CLI commands in this section to enable or disable the appliance to allow the user
to log in to the Web UI even when the basic constraints extension is not included in the
X.509 certificate. The basic constraints extension is used to identify that the certificate is
issued for a Certificate Authority (CA). By default, the appliance verifies if the basic
constraints extension is included in the X.509 certificate, and the login fails if the extension
is not found. When the aaa authentication certificate validation allow-missing-
basic-constraints command is disabled, users cannot log in to the Web UI if the basic
constraints extension is not included in the X.509 certificate.
To enable the appliance to allow a certificate with a missing basic constraints extension:

hostname > enable
2. Enable the appliance to allow the user to log in to the Web UI even when the basic
hostname (config) # aaa authentication certificate validation allow-
missing-basic-constraints
3. Verify the status of the basic constraints extension.
© 2021 FireEye 93

...
Basic constraints must present : no
...

To prohibit certificates with a missing basic constraints extension:

hostname > enable
2. Disable the option to allow the user to log in to the Web UI when the basic
hostname (config) # no aaa authentication certificate validation allow-
missing-basic-constraints
3. Verify the status of the basic constraints extension.

...
Basic constraints must present : yes
...

Deleting a CRL File Using the CLI

Use the CLI commands in this section to delete a specified Certificate Revocation List
(CRL) file from the appliance.
To delete a local CRL file:

hostname > enable
2. Verify the name of the configured CRL file.

...
94 © 2021 FireEye
CRL Filename : john-doe.crl.pem
3. Delete a specified CRL file from the appliance.

hostname (config) # aaa authentication certificate crl delete filename
<name_of_file>
4. Verify the status of the CRL file.

hostname (config) # show aaa authentication certificate crl
No CRL file is configured.

Downloading a Local CRL File Using the CLI

Use the CLI commands in this section to download a local Certificate Revocation List
(CRL) file from a specified remote location so that the appliance can validate certificate
revocation. Only one CRL file can be present on the system. When you download a new
CRL file, the existing CRL file will be automatically deleted.
To download a local CRL file:

hostname > enable
2. Verify the name of the configured CRL file.

...
CRL Filename : john-doe.crl.pem
3. Download a local CRL file from a specified URL to the appliance.

hostname (config) # aaa authentication certificate crl fetch url <URL>
where <URL> is the direct path to the certificate file. The <url> is specified with
remote server Administrator credentials (<username> and <password>), the remote
server (<hostname>), the path and filename in which to save the certificate bundle
(<path/filename> )in the following format:
scp://<username>[:<password>]@<hostname>/<path/filename>
NOTE: If you do not specify the remote host administrator password in the
aaa authentication certificate crl fetch url command (where the
password would be visible as clear text), the CLI prompts for the password
and obfuscates the keyboard input as you type it.
4. (Optional) Specify a filename to save the CRL file that you downloaded.
© 2021 FireEye 95
hostname (config) # aaa authentication certificate crl fetch url <URL>

filename <name_of_file>
NOTE: If you do not specify a filename, the CRL file will be saved to the
appliance locally and the remote filename will be used.
5. Verify the content of the CRL file.

hostname (config) # show aaa authentication certificate crl
Filename : john-doe.crl.pem
File Timestamp : 2016/10/11 23:56:04
File MD5Sum : 285d9b706f5636f575c3d2d2e2fc9fb3
File Content :
-----BEGIN X509 CRL-----
MIIB5zCB0AIBATANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzELMAkGA1UE
CAwCQ0ExETAPBgNVBAcMCE1pbHBpdGFzMRAwDgYDVQQKDAdGaXJlRXllMQ0wCwYD
VQQLDARDQW91MRIwEAYDVQQDDAl2cHMxX2NhXzMXDTE2MTAxMDE4MDIyNFoXDTE2
MTEwOTE4MDIyNFowKjATAgIgARcNMTYxMDA3MjAzNzQ2WjATAgIgAhcNMTYxMDEw
MTc1NTI1WqAOMAwwCgYDVR0UBAMCAQIwDQYJKoZIhvcNAQELBQADggEBAJcE2qxg
QqA9Y2791InwFcJ2xZi3raEXRldZcB6nh421yvRYWsRAsSr6d6JyPJC0mYfWBkOz
avsBwoFXygInwF1fDfR4oLM+kQchFE5n9ukwhuK6aGd2sAM+BAIiPyVVFw5UdhQ/
7cewJ/5sOTW3cO0uA70DEJmKK25mHfR89jSuFjQArj6QvgkWRMYugpqnounX3ujA
RBEPhCiTaHpyCxJj6LrBMCvAaSQNg1udAF3I68MHjh5SrVD7fjDruI43pTOeVzFn
0wqDc/YyN+meVlhznsB0IcVqon10zPkIBCxS3k9ditHUaL7Nb5LYxkl65reo6JjG
LFadKDokYyzZBBY=
-----END X509 CRL-----

Configuring the User Attributes for

Certificate Authentication
An administrator uses the information from the X.509 certificate to identify the user and
assign user roles that allow the user to perform certain operations on the appliance. The
following table describes the user attributes for the X.509 certificates that are used for
certificate authentication.
96 © 2021 FireEye
Release 2021.1 Configuring the User Attributes for Certificate Authentication
Attribu
Description
te
x509- Name of the entry for the subject field in the certificate. The subject is the
cert- Distinguished Name (DN) and is the X.509 structure. Each entry has a unique
subject identifier.
The following example shows the DN format for CAC:
C=US, O=Test Government, OU=Test Department, OU=Test Agency,
CN=Test Cardholder
x509- Common Name (CN) entry from the DN attribute that is associated in a
cert- certificate. For example, CN=Test Cardholder.
subject-
cn
x509- The email address in the Subject Alternative Name (SAN) field of the
cert- certificate. You are allowed to have multiple subfields for SAN.
san-
email
x509- The user name of the email address without the domain name in the
cert- certificate.
san-
email-
userna
me
x509- User Principal Name (UPN) attribute that is encoded in the Other Name field
cert- of the SAN field in the certificate.
san-
upn
x509- Username of the UPN attribute in the certificate.

cert-
san-
upn-
userna
me
NOTE: You can configure the user attributes for certificate authentication only
using the CLI.
© 2021 FireEye 97
Prerequisites
l Policy settings of the Web UI for certificate authentication have been enabled. For
details about how to enable policy settings of the Web UI, see Enabling or Disabling
the Policy Settings of the Web UI for Certificate Authentication on page 86.
Configuring the User Attributes for Certificate

Authentication Using the CLI
Use the CLI commands in this section to configure the user attributes for certificate
authentication.
NOTE: Use the no aaa authentication certificate username command to

reset the certificate field for the username to use the default x509-cert-san-upn
attribute.
To configure the user attributes for certificate authentication:

hostname > enable
2. Specify the name of the entry for the subject field in the certificate.
hostname (config) # aaa authentication certificate username x509-cert-
subject
3. Specify an entry for the Common Name (CN) from the DN attribute that is
associated in a certificate.
subject-cn
4. Specify an email address in the Subject Alternative Name (SAN) field of the
certificate. You are allowed to have multiple subfields for SAN.
san-email
5. Specify the user name of the email address without the domain name in the
certificate.
98 © 2021 FireEye
Release 2021.1 Configuring LDAP for Authorization

san-email-username
6. Specify the User Principal Name (UPN) that is encoded in the "Other Name" field of
the SAN field in the certificate.
san-upn
7. Specify the user name of the UPN attribute without the domain name in the
certificate.
san-upn-username
8. Verify the configuration of the certificate-based authentication settings.

OCSP enabled : no
Basic constraints must present : no
No CRL file is configured.

Configuring LDAP for Authorization

If you configured an LDAP server to authenticate users, you can configure LDAP
mappings for authorization by using the appliance CLI:
l Enabling or Disabling the LDAP Server for Certificate Authorization Using the CLI
on page 101
l Configuring an LDAP Attribute to Match a Certificate Authorization Field Using the
CLI on page 102
l Removing an LDAP Attribute for Certificate Authorization Using the CLI on
page 103
l Configuring the Certificate Fields to Match the LDAP Field for Authorization Using
the CLI on page 103
© 2021 FireEye 99
l Defining LDAP Search Filters for Certificate Authorization Using the CLI on
page 105
l Removing LDAP Search Filters for Certificate Authorization Using the CLI on
page 105
l Enabling or Disabling the LDAP Override for Certificate Authorization Using the
CLI on page 106
When the appliance needs to determine the identity of the user, the Subject Alternative
Name (SAN) extension with the User Principal Name (UPN) extension in the certificate can
be used as an identifier when matching the certificate to an entry in the Active Directory
(AD), which is supported by the LDAP protocol.
When the certificate is validated, the AD server uses the Principal Name field (Principal
Name=user@fully.qualified.domain.name) in the SAN with the UPN of the certificate to
search for the user in the Active Directory. The server permits or denies access to the Web
UI based on the matched fields.
The user schema name and login name for the LDAP attribute are used to match the
configured certificate authorization field. An administrator can configure the LDAP record
to map the login name. An administrator can define an LDAP search filter in the
configuration that controls which users can log in using a certificate and then can be
authorized using LDAP.
Prerequisites
l LDAP servers have been configured to authorize users. For details about how to
configure an LDAP server, see LDAP Server Configuration on page 71.
l Policy settings of the Web UI for certificate-based authentication have been enabled.
For details about how to enable policy settings of the Web UI, see Enabling or
Disabling the Policy Settings of the Web UI for Certificate Authentication on page 86.
l User attributes for certificate authentication have been configured. For details about
how to configure the user attributes for certificate authentication, see Configuring the
User Attributes for Certificate Authentication on page 96.
100 © 2021 FireEye

l Online Certificate Status Protocol (OCSP) has been enabled and configured so that
the appliance can validate certificate revocation. For details about how to enable
and configure OCSP for certificate revocation, see Enabling or Disabling OCSP Using
the CLI on page 89 and Adding or Removing the OCSP URL Using the CLI on
page 92.
Enabling or Disabling the LDAP Server for Certificate

Authorization Using the CLI
Use the CLI commands in this section to enable or disable the LDAP server that is used to
authorize users that are already authenticated using the X.509 certificate.
To enable the LDAP server for certificate authorization:

hostname > enable
2. Enable the LDAP server to map a remote user to a local user account for certificate-
based authentication.
hostname (config) # aaa authorization certificate map-ldap enable
3. Verify the status of the LDAP server.

hostname (config) # show aaa authorization certificate
Certificate based authorization settings:
LDAP enabled : yes
.....

To disable the LDAP server for authorization:

hostname > enable
2. Disable the LDAP server that is used for authorization.

hostname (config) # no aaa authorization certificate map-ldap enable
3. Verify the status of the LDAP server.

LDAP enabled : no
.....
© 2021 FireEye 101


Configuring an LDAP Attribute to Match a Certificate

Authorization Field Using the CLI
Use the CLI commands in this section to configure an LDAP attribute to match the
certificate authorization field that was specified with the aaa authorization
certificate map-ldap match-cert-field command.
NOTE: Use the no aaa authorization certificate map-ldap match-ldap-

attribute command to reset the attribute of the LDAP account to use the default
sAMAccountName attribute.
To configure an LDAP attribute to match a certificate authorization field:

hostname > enable
2. Specify the LDAP user schema name for LDAP to match the configured certificate
authorization field.
hostname (config) # aaa authorization certificate map-ldap match-ldap-
attribute uid
3. Specify which attribute holds the login name to match the configured certificate
attribute sAMAccountName
NOTE: The sAMAccountName attribute is the default.
4. Specify which attribute holds an email address to match the configured certificate
attribute mail
5. Verify the setting of the LDAP attribute.

LDAP enabled : yes
LDAP Match Attribute : uid
...
102 © 2021 FireEye


Removing an LDAP Attribute for Certificate

Use the CLI commands in this section to remove an LDAP search filter for certificate
authorization.
To remove an LDAP search filter for certificate authorization:

hostname > enable
2. Remove the LDAP search filter.

hostname (config) # no aaa authorization certificate map-ldap search-
filter
3. Verify the status of the LDAP search filter.

LDAP enabled : yes
Certificate field to match : x509-cert-subject
LDAP Search Filter : Not Configured
#160; Username override : no

Configuring the Certificate Fields to Match the LDAP

Field for Authorization Using the CLI
Use the CLI commands in this section to configure the certificate fields to match the LDAP
field for authorization. For details about user attributes for the X.509 certificates, see
Configuring the User Attributes for Certificate Authentication on page 96.
NOTE: Use the no aaa authentication certificate map-ldap match-cert-

field command to reset the certificate field for the LDAP field to use the default
x509-cert-san-upn attribute.
© 2021 FireEye 103

To configure the certificate fields to match the LDAP field for authorization:

hostname > enable
2. Specify the name of the subject field in the certificate to match the LDAP field. The
subject is the Distinguished Name (DN) and is the X.509 structure. Each entry has a
unique identifier.
hostname (config) # aaa authorization certificate map-ldap match-cert-
field x509-cert-subject
3. Specify an entry for the Common Name (CN) from the DN attribute that is
associated in a certificate to match the LDAP field.
field x509-cert-subject-cn
4. Specify an email address in the Subject Alternative Name (SAN) field of the
certificate to match against the LDAP field. You are allowed to have multiple
subfields for the SAN.
field x509-cert-san-email
5. Specify the user name of the email address without the domain name in the
certificate to match against the LDAP field.
field x509-cert-san-email-username
6. Specify the User Principal Name (UPN) that is encoded in the Other Name field of
the Subject Alternative Name to match against the LDAP field.
field x509-cert-san-upn
7. Specify the user name of the UPN field without the domain name in the certificate to
match against the LDAP field.
field x509-cert-san-upn-username
8. Verify the setting of the certificate field to match the LDAP field.
LDAP enabled : yes
Certificate field to match : x509-cert-san-email-username
LDAP Search Filter : Not configured
Username override : no
104 © 2021 FireEye


Defining LDAP Search Filters for Certificate

Use the CLI commands in this section to define an LDAP search filter for certificate
authorization.
To define an LDAP search filter for certificate authorization:

hostname > enable
2. Specify the LDAP search filter for certificate authorization.

hostname (config) # aaa authorization certificate map-ldap search-
filter <filter_string>
NOTE: If the text of the <filter_string> parameter contains spaces,

enclose the string with double quotation marks.
The following example shows how to define an LDAP filter:

hostname (config) # aaa authorization certificate map-ldap search-
filter "(!(cn=Test Cardholder))"
3. Verify the setting of the LDAP search filter.

LDAP enabled : yes
LDAP Search Filter : (!(cn=Test Cardholder))

Removing LDAP Search Filters for Certificate

Use the CLI commands in this section to remove an LDAP search filter for certificate
authorization.
© 2021 FireEye 105

To remove an LDAP search filter for certificate authorization:

hostname > enable
2. Remove the LDAP search filter.

hostname (config) # no aaa authorization certificate map-ldap search-
filter
3. Verify the status of the LDAP search filter.

LDAP enabled : yes
LDAP Search Filter : Not Configured

Enabling or Disabling the LDAP Override for Certificate

Use the CLI commands in this section to enable or disable the LDAP override of the
username setting that was specified with the aaa authentication certificate
username command.
NOTE: By default, the username setting in the aaa authentication

certificate username command is used.
If the login is mapped to the LDAP account, an administrator can use the ldap login-
attribute command to override the username setting, and instead use the username from
the LDAP attribute.
To enable the LDAP override for certificate authorization:

hostname > enable
106 © 2021 FireEye

Release 2021.1 Configuring Local User Mappings for Authorization
2. Enable the LDAP override of the username setting that was specified with the aaa
authentication certificate username command, and instead use the username
from the LDAP attribute.
hostname (config) # aaa authorization certificate map-ldap username-
override
3. Verify the status of the LDAP override.

...
Username override : yes

To disable the LDAP override for certificate-based authorization:

hostname > enable
2. Disable the LDAP override of the username setting that was specified with the aaa
authentication certificate username command.
hostname (config) # no aaa authorization certificate map-ldap username-
override
3. Verify the status of the LDAP override.

...

Configuring Local User Mappings for

Authorization
You can configure local user mappings for authorization by using the appliance CLI:
l Allowing or Preventing Authorization Rule Matches for Certificate Authentication

Using the CLI on the next page
l Configuring Authorization Rules to Match the Certificate Fields Using the CLI on
page 110
© 2021 FireEye 107

Prerequisites
l Policy settings of the Web UI for certificate-based authentication have been enabled.
For details about how to enable policy settings of the Web UI, see Enabling or
Disabling the Policy Settings of the Web UI for Certificate Authentication on page 86.
l User attributes for certificate authentication have been configured. For details about
how to configure the user attributes for certificate authentication, see Configuring the
User Attributes for Certificate Authentication on page 96.
l Online Certificate Status Protocol (OCSP) has been enabled and configured so that
the appliance can validate certificate revocation. For details about how to enable
and configure OCSP for certificate revocation, see Enabling or Disabling OCSP Using
the CLI on page 89 and Adding or Removing the OCSP URL Using the CLI on
page 92.
l Enable all authorization rules. Use the aaa authorization rules enable
command.
Allowing or Preventing Authorization Rule Matches for

Certificate Authentication Using the CLI
Use the CLI commands in this section to allow or prevent specific authorization rule
matches for users who were authenticated using an X.509 certificate as the only criterion
for an authentication method.
To allow authorization rule matches based on the certificate authentication method:

hostname > enable
108 © 2021 FireEye

2. Match all authorization rules for users who were authenticated using an X.509
certificate.
hostname (config) # aaa authorization rules rule append tail match-
auth-method x509-cert map-local-user <role>
where <role> is the assigned role that allows the user to perform certain
operations.
3. Verify the status of the new authorization rules that are matched using the X.509
certificate authentication method.
------------------------------------------------
# AAA Authorization Rules : Enabled
------------------------------------------------
# Rule Statements
------------------------------------------------
# 1 Match Auth Methods : x509-cert
-->Action Map Local User : monitor
# 2 Match x509 Cert Subject : C=US, ST=CA,
L=Milpitas, O=FireEye, OU=Engineering, CN=Test Cardholder

To prevent authorization rule matches based on the certificate authentication method:

hostname > enable
2. Prevent a new authorization rule from being matched for users who were
authenticated using an X.509 certificate.
hostname (config) # aaa authorization rules rule append tail match-not-
auth-method x509-cert map-local-user <role>
where <role> is the assigned role that allows the user to perform certain
operations.
3. Verify the status of the new authorization rules that are matched using the X.509
certificate authentication method.
------------------------------------------------
------------------------------------------------
# Rule Statements
------------------------------------------------
# 1 Match Auth Methods : x509-cert
© 2021 FireEye 109

Match x509 Cert Subject CN : Test Cardholder

.
.
.
# 10 Not-Match Auth Methods : x509-cert

Configuring Authorization Rules to Match the Certificate

Fields Using the CLI
Use the CLI commands in this section to configure a specific authorization rule to match
against the fields in the X.509 certificate. The administrator must configure one separate
rule for each authorized user. For details about how to configure rules in a local
configuration and about user roles, see Local Authentication on page 29.
NOTE: Only one subject is allowed per authorization rule.
To configure authorization rules to match the certificate fields:

hostname > enable
2. Specify an authorization rule to match against the name of the subject field in the
X.509 certificate. The subject is the Distinguished Name (DN) and is the X.509
structure. Each entry has a unique identifier.
x509-cert-subject "<string>" map-local-user <role>
where <string> is extracted from the subject field of the certificate and is matched
against the string that is in the rule. For example, C=US, ST=CA, L=Milpitas,
O=FireEye, OU=Engineering, CN=Test Cardholder.
<role> is the assigned role that allows the user to perform certain operations.
3. Specify an authorization rule to match against an entry for the Common Name (CN)
from the DN attribute of an X.509 certificate.
x509-cert-subject-cn "<string>" map-local-user <role>
110 © 2021 FireEye

where <string> is extracted from the subject field of the certificate and is matched
against the string that is in the rule. For example, CN=Test Cardholder.
4. Specify an authorization rule to match against an email address in the Subject

Alternative Name (SAN) field of an X.509 certificate. You are allowed to have
multiple subfields for the SAN.
x509-cert-san-email "<string>" map-local-user <role>
where <string> is extracted from the Subject Alternative Name field of the
certificate and is matched against the string that is in the rule. For example,
email:test.cardholder@fireeye.com.
5. Specify an authorization rule to match against the username of an email address

without the domain name of an X.509 certificate.
x509-cert-san-email-username "<string>" map-local-user <role>
where <string> is extracted from the Subject Alternative Name field without the
domain name of the X.509 certificate and is matched against the string that is in the
rule. For example, test.cardholder.
6. Specify an authorization rule to match against the User Principal Name (UPN) that
is encoded in the "Other Name" field of an X.509 certificate.
x509-cert-san-upn "<string>" map-local-user <role>
where <string> is extracted from the Subject Alternative Name field for the "Other
Name" value of the X.509 certificate and is matched against the string that is in the
rule. For example, Principal Name:test.cardholder@fireeye.com.
7. Specify an authorization rule to match against the username of the UPN field of an
X.509 certificate.
x509-cert-san-upn-username <string> map-local-user <role>
where <string> is extracted from the certificate and is matched against the string
that is in the rule. For example, test.cardholder.
8. Verify the settings of all the matched authorization rules.

------------------------------------------------
© 2021 FireEye 111


------------------------------------------------
# Rule Statements
------------------------------------------------
# 1 Match x509 Cert Subject : C=US, ST=CA, L=Milpitas,
O=FireEye, OU=Engineering, CN=Test Cardholder
# 2 Match x509 Cert Subject CN : Test Cardholder
# 3 Match x509 Cert SAN email :
test.cardholder@fireeye.com
# 4 Match x509 Cert SAN email username : test.cardholder
# 5 Match x509 Cert SAN UPN :
test.cardholder@fireeye.com
# 6 Match x509 Cert SAN UPN username : test.cardholder

Logging in to the Web UI for Certificate

Authentication
You can log in to the Web UI for certificate authentication by entering your user name and
password provided by the administrator, using a certificate, or both. You can also log in to
the Web UI for SSO authentication. For details about SSO authentication, see Single Sign-
On Authentication on page 143.
To log in to the Web UI when a certificate is mandatory for user authentication:
1. Go to https://<appliance> in the browser, where <appliance> is the IP address

or hostname of the appliance. For example, if the configured IP address of the
appliance is 10.1.0.1, enter https://10.1.0.1.
2. On the login page, click Sign In Using Certificates.
112 © 2021 FireEye

Release 2021.1 Verifying Certificate Authentication Status Using the Web UI
To log in to the Web UI when a certificate is optional for user authentication:
1. Go to https://<appliance> in the browser, where <appliance> is the IP address

or hostname of the appliance. For example, if the configured IP address of the
appliance is 10.1.0.1, enter https://10.1.0.1.
2. On the login page, choose one of the following options:
l Enter the user name and password your administrator provided.
l Click Sign In Using Certificates.
Verifying Certificate Authentication

Status Using the Web UI
Use the control at the top right corner of the Web UI page to view the user authentication
status that the appliance extracted from the configured certificate fields. The Auth Method
field is set to the x509-cert value.
© 2021 FireEye 113

To verify certificate authentication status:
1. Log in to the Web UI.

2. Click your username at the top right of the page.
3. Verify that the following certificate fields are displayed and configured correctly:
l Cert Subject
l Cert Email
l Cert UPN
l Expiration Date
To close your session, click Logout.
The log out message will not be displayed if it is disabled. Use the aaa
authentication logout user-message enable command to display the
log out message. For details about how to enable the log out message
setting, see Enabling or Disabling the Log Out Message Setting Using the
CLI on page 26.
114 © 2021 FireEye

System Security Guide About SSH Authentication
CHAPTER 6: Secure Shell (SSH)

Authentication
l About SSH Authentication below

l User Authentication on the next page
o Creating a Public Key Using the CLI
o Configuring User Authentication Using the CLI
l Host-Key Authentication on page 124
o Obtaining a Host Key Using the Web UI
o Obtaining a Managed Appliance Host Key Using the CLI
o Obtaining the Central Management Appliance Host Key Using the CLI on
page 130
o Importing a Host Key into the Central Management Global Host-Keys
Database Using the CLI
o Importing a Host Key into the Managed Appliance Global Host-Keys
Database Using the CLI on page 134
o Enabling and Disabling Strict and Global Host-Key Checking Using the CLI
on page 136
About SSH Authentication

The Secure Shell (SSH) protocol is used for secure communication between the Central
Management appliance and the appliances it manages. When the Central Management
appliance initiates the connection, it logs in as a remote "admin" user on the managed
appliance. When the managed appliance initiates the connection, it logs in as a remote
"admin" user on the Central Management appliance. SSH user authentication verifies the
identity of the remote user attempting the connection.
© 2021 FireEye 115

System Security Guide CHAPTER 6: Secure Shell (SSH) Authentication
SSH host authentication verifies the identity of the Central Management appliance to the
managed appliance and verifies the identity of the managed appliance to the Central
Management appliance.
The topics in this section describe how to configure SSH authentication
Server-initiated connection
With this type of connection, the Central Management administrator adds an
appliance directly from the Central Management Web UI or CLI. For information about
a client-initiated connection (where a managed appliance administrator sends a
request for management to the Central Management appliance, and a Central
Management administrator accepts or rejects the request), see the System Administration
Guide or Administration Guide for the managed appliance.
Client-initiated connection
With this type of connection, a managed appliance administrator sends a request for
management to the Central Management appliance, and a Central Management
administrator accepts or rejects the request). For information about a server-initiated
connection (where the Central Management administrator adds an appliance directly
from the Central Management Web UI or CLI, see the Central
Management Administration Guide.
User Authentication
The remote user can authenticate using either a password or a public key. After the
connection is established, it is controlled by the configured password or the public key.
Password Authentication
With password authentication, a password is configured for the remote user. This is the
initial authentication type for an appliance that is added to the Central Management
appliance using the Web UI.
Public Key Authentication
Public key authentication uses a pair of keys—a public key and a private key. With public
key authentication, an SSH-DSA2 or SSH-RSA2 identity is configured for the remote user
and is pushed to the appliance.
Benefits of public key authentication include:
l The private key remains on the managed appliance and cannot be computed from
the public key. This is an advantage over password authentication, where the
116 © 2021 FireEye

Release 2021.1 User Authentication
password could be cracked.
l If you use password authentication, password change policies can break the
connection between the Central Management platform and the managed appliance.
Example for a Central Management Administrator

Suppose users on a managed Email Security — Server Edition appliance must change their
passwords every 90 days. As a Central Management administrator, you might be unaware
of this policy. After the password for the remote user changes, the connection to the Email
Security — Server Edition appliance will be broken until you change the password on the
Central Management appliance.
Example for a Managed Email Security — Server Edition

Appliance Admin
Suppose users on the Central Management appliance must change their passwords every
90 days. As the administrator of the managed appliance, you might be unaware of this
policy. After the password for the remote user changes, the connection to the Central
Management appliance will be broken until you change the password on the managed
appliance.
Best Practice: Because password change policies apply only to password

authentication, FireEye recommends using public key authentication for this
connection.
For details, see the following topics:
l Creating a Public Key Using the CLI below

l Configuring User Authentication Using the Central Management Web UI on
page 120
l Configuring User Authentication Using the CLI on page 122
Creating a Public Key Using the CLI

Use the commands in this section to create a new public key for SSH user authentication.
You can use this key instead of the password to authenticate the remote user.
NOTE: (Central Management only) If no SSH-DSA2 or SSH-RSA2 public keys

exist, you can use the Web UI to create an "admin" SSH-DSA2 key and an
"admin" SSH-RSA2 key. For details, see Importing a Host Key into the Global
Host-Keys Database Using the Central Management Web UI on page 131.
© 2021 FireEye 117

To create a public key:
hostname > enable
2. Create the public key:

hostname (config) # cmc auth <keyType> identity <identityName> generate
where <keyType> can be ssh-dsa2 or ssh-rsa2 and <identityName> is a user-

friendly name.
hostname (config) # show cmc auth identities

5. (Central Management only) Push the key to the managed appliance as described in
Pushing a Public Key Using the Central Management CLI on the facing page.
To remove a public key:
hostname > enable
2. Remove the public key:

hostname (config) # no cmc auth <keyType> identity <identityName>

hostname (config) # show cmc auth identities

Example
The following example creates an SSH-DSA2 identity named "admin4" on the NX-04
appliance.
NX-04 (config) # cmc auth ssh-dsa2 identity admin4
NX-04 (config) # show cmc auth identities
DSA2 identity admin4:
Public Key:
ssh-dss AAA3NzaC1kc3MAAACBAJl3PisWNnz/gYLvL4JC7xFMoq3HE89rai7trnJmpxjylArYhf
MzaGndFA4qGRZMFzhiz9Jhi/+W1ufIrXLGzakC0lAAAAFQCuMCsMwMGN9zT5w2JCiDt7D6orNwAA
.
.
.
NOTE: This example is from an Network Security appliance, but it is

representative of other appliances as well.
118 © 2021 FireEye

Pushing a Public Key Using the Central Management CLI

Use the commands in this section to push the public key of an SSH-DSA2 or SSH-RSA2
identity to the managed appliance. When a remote Central Management user and this
identity are used to authenticate against the appliance, the connection is established only if
the appliance already has this key.
NOTE: You can also use the Central Management Web UI to push the key. For
details, see Importing a Host Key into the Global Host-Keys Database Using the
Central Management Web UI on page 131.
To push a public key:
1. Log in to the Central Management CLI.

cm-hostname > enable
cm-hostname # configure terminal
3. Push the key to the appliance:

cm-hostname (config) # cmc appliance <applianceID> auth <keyType>
identity <identityName> push [username <username> password <password>]
where the username and password options allow the remote user to log in to the
appliance to push the public key before the appliance is connected.
a. Log in to the managed appliance CLI.
b. Go to CLI enable mode:
appl-hostname > enable
c. Verify that the key is present:

appl-hostname # show ssh client
Examples
Pushing an SSH-DSA2 Public Key

The following example displays the public key string of the Central Management SSH-
DSA2 identity named "admin4," and then pushes it to the Email Security — Server Edition
appliance. It then displays the SSH authorized keys on the Email Security — Server Edition
appliance to verify that the key was pushed.
CM-08 (config) # cmc auth ssh-dsa2 identity admin4
CM-08 (config) # show cmc auth identities
DSA2 identity admin4:
Public Key:
© 2021 FireEye 119

.
.
CM-08 (config) # cmc appliance EX-03 auth ssh-dsa2 identity admin4 push
Push of identity for user admin onto EX-03 succeeded.
EX-03 # show ssh client
.
.
SSH authorized keys:
User admin:
Key 1:
.
.
.
Pushing an SSH-RSA2 Public Key and Establishing a Connection

The following example logs the remote user into the Email Security — Server Edition
appliance to push the Central Management SSH-RSA2 identity named "admin6" to the
Email Security — Server Edition appliance. It then establishes the connection between the
Central Management platform and the Email Security — Server Edition appliance.
CM-02 (config) # cmc appliance EX-05 address 172.17.74.54
CM-02 (config) # cmc appliance EX-05 auth ssh-rsa2 identity admin6 push
username admin password admin
CM-02 (config) # cmc appliance EX-05 authtype ssh-rsa2
CM-02 (config) # cmc appliance EX-05 auth ssh-rsa2 identity admin6
CM-02 (config) # show cmc appliances EX-05
Appliance EX-05:
Connection status:
Connected: yes (server-initiated)
.
.
.
Authentication:
Authentication type: ssh-rsa2
password username: admin
password password: ********
ssh-dsa2 username: admin
ssh-dsa2 identity:
ssh-rsa2 username: admin
ssh-rsa2 identity: admin6
Configuring User Authentication Using the Central

Management Web UI
Use the Sensor Management page to configure authentication parameters for the remote
user the Central Management appliance uses to log in to an appliance to establish the
connection. This is an existing "admin" user on the managed appliance.
When you add an appliance using the Web UI, you must configure a username and
password, so the Central Management appliance initially uses password authentication.
120 © 2021 FireEye

After the appliance is connected, you can select an SSH-DSA2 or SSH-RSA2 key, which
changes the authentication type accordingly.
IMPORTANT! After you configure SSH-DSA2 or SSH-RSA2 authentication, the

only way to return to password authentication using the Web UI is to delete the
appliance and then add it again.
To configure SSH-DSA2 or SSH-RSA2 authentication:
1. In the Action column for the appliance, click Use CMS Public Key to Connect. The
Password field is replaced by the CMS Public Key field.
2. Click the Select a Key drop-down list.
3. To configure SSH-DSA2 authentication, do one of the following:
l Select an existing key.
l Select No dsa keys. Create One, and then select the dsa-admin key that is
created.
4. To configure SSH-RSA2 authentication, do one of the following:
l Select an existing key.
l Select No rsa keys. Create one, and then select the rsa-admin key that is
created.
5. Click Update Sensor.
NOTE: The connection will be interrupted briefly. Error messages and
indicators will be displayed, but they will clear as soon as the connection
is reestablished.
6. Verify that the key is displayed in the Public Key Used column for the appliance.
© 2021 FireEye 121

Configuring User Authentication Using the CLI

This procedure describes how use CLI commands to configure remote user authentication
for an existing "admin" user account.
On a Central Management appliance, the account is used for logging in to a managed

appliance to establish an SSH connection. On a managed appliance, the account is used to
log in to the Central Management appliance to announce itself.
NOTE: See the ssh and cmc commands in the CLI Reference for advanced
authentication options.
To configure password authentication:
hostname > enable
2. Specify the "password" authentication type.

On a Central Management appliance:
cmc appliance <identityID> authtype password
On a managed appliance:
cmc client server auth authtype password
3. Specify the remote user account.

On a Central Management appliance, the account is used to log in to a
managed appliance.
cmc appliance <applianceID> auth password username <username>
On a managed appliance, the account is used to log in to the Central

Management appliance:
cmc client server auth password username <username>
4. Specify the password used to authenticate the remote user.

cmc appliance <applianceID> auth password password <password>
cmc client server auth password password <password>

To configure SSH-DSA2 authentication:
hostname > enable
122 © 2021 FireEye

2. Specify the SSH-DSA2 authentication type.

cmc appliance <applicationID> authtype ssh-dsa2
On a managed appliance, use the following command instead:

cmc client server auth authtype ssh-dsa2
3. Specify the remote user account.

On a Central Management appliance, the account is used to log in to a
managed appliance:
cmc appliance <applianceID> auth ssh-dsa2 username <username>
On a managed appliance, the account is used to log in to the Central

Management appliance:
cmc client server auth ssh-dsa2 username <username>
4. Specify the existing named identity used to authenticate the remote user.
cmc appliance <applianceID> auth ssh-dsa2 identity <identityName>
cmc client server auth ssh-dsa2 identity <identityName>

To configure SSH-RSA2 authentication:
hostname > enable
2. Use the following command to specify the SSH-RSA2 authentication type:

cmc appliance <applianceID> authtype ssh-rsa2

cmc client server auth authtype ssh-rsa2
3. On a Central Management appliance, use the following command to specify the

name of the remote user to log in to the managed appliance:
cmc appliance <applianceID> auth ssh-rsa2 username <username>
On a managed appliance, use the following command to specify the name of the
remote user to log in to the Central Management appliance:
cmc client server auth ssh-rsa2 username <username>
© 2021 FireEye 123

4. Use the following command to specify the existing named identity used to
authenticate the remote user:
cmc appliance <applianceID> auth ssh-rsa2 identity <identityName>

cmc client server auth ssh-rsa2 identity <identityName>

Example
The following example configures a Central Management appliance with SSH-RSA2
authentication parameters used to log in to the NX-04 managed appliance:
hostname (config) # cmc appliance NX-04 auth authtype ssh-rsa2
hostname (config) # cmc appliance NX-04 auth ssh-rsa2 username cmcadmin2
hostname (config) # cmc appliance NX-04 auth ssh-rsa2 identity admin2
The following example configures a managed appliance with SSH-DSA2 authentication

parameters used to log in to the Central Management appliance:
hostname (config) # cmc client server auth authtype ssh-dsa2
hostname (config) # cmc client server auth ssh-dsa2 username cmcadmin3
hostname (config) # cmc client server auth ssh-dsa2 identity admin3
Host-Key Authentication
l About Host-Key Authentication on the facing page

l Obtaining a Host Key Using the Web UI on page 126
l Obtaining the Central Management Appliance Host Key Using the CLI on page 130
l Obtaining a Managed Appliance Host Key Using the CLI on page 128
l Importing a Host Key into the Global Host-Keys Database Using the Central
Management Web UI on page 131
l Importing a Host Key into the Central Management Global Host-Keys Database
Using the CLI on page 133
l Importing a Host Key into the Managed Appliance Global Host-Keys Database
Using the CLI on page 134
l Enabling and Disabling Strict and Global Host-Key Checking Using the CLI on
page 136
124 © 2021 FireEye

Release 2021.1 Host-Key Authentication
l Global Host-Key Authentication on a Central Management Appliance in a NAT

Deployment on page 139
l Global Host-Key Authentication on a Managed Appliance in a NAT Deployment on
page 140
About Host-Key Authentication

Host-key authentication can be used to prevent man-in-the middle attacks, in which
another server poses as the managed appliance or the Central Management appliance and
intercepts the traffic between them.
The connection between a Central Management appliance and a managed appliance can
be server-initiated or client-initiated.
Host-key authentication using a server-initiated connection

When the Central Management appliance and the managed appliance connect the first
time using a server-initiated connection, a key exchange takes place. The managed
appliance sends a copy of its host key to the Central Management appliance, where it
is compared to the keys in the Central Management host-keys database.
If strict host-key checking is enabled, the connection can be established only if the key
that is sent matches an entry in the local host-keys database for the Central
Management remote user. If global host-key checking is enabled, the connection can be
established only if the key that is sent matches an entry in the Central Management
global host-keys database.
Host-key authentication using a client-initiated connection

When the managed appliance and the Central Management appliance connect the first
time using a client-initiated connection, a key exchange takes place. The Central
Management appliance sends a copy of its host key to the appliance, where it is
compared to the keys in the appliance's host-keys database.
If strict host-key checking is enabled, the connection can be established only if the key
that is sent matches an entry in the local host-keys database for the managed
appliance remote user. If global host-key checking is enabled, the connection can be
established only if the key that is sent matches an entry in the managed appliance
global host-keys database.
You can enforce strict host-key checking, global host-key checking, or both. In compliance
mode, both strict and global host-key checking is enforced. For details, see the FIPS 140-2
and Common Criteria Addendum.
In the case of primary and secondary Central Management platforms in a Central
Management High-Availability (HA) deployment, the two Central Management platforms
exchange keys, and the connection is established if the keys match. For details, see the
Central Management High Availibility Guide.
© 2021 FireEye 125

IMPORTANT: Host keys are stored in the configuration database, so they are

included in the backup file.
Prerequisites
l Admin access to configure authentication and create keys.
l Central Management appliances only:

o Monitor, Operator, or Admin access to obtain managed appliance host keys.
o The private key remains on the Central Management appliance and cannot
be computed from the public key.
l Managed appliances only:

o Monitor, Operator, or Admin access to obtain Central Management appliance
host keys.
o The private key remains on the managed appliance and cannot be computed
from the public key.
Obtaining a Host Key Using the Web UI

You can use the Web UI to obtain a host key on a Central Management appliance or on a
managed appliance running Release 7.6.0 or later. For a managed appliance running an
earlier release, or for a VX Series appliance, see Obtaining the Central Management
Appliance Host Key Using the CLI on page 130 and Obtaining a Managed Appliance Host
Key Using the CLI on page 128.
IMPORTANT! In a Network Address Translation (NAT) deployment, the host-

key string might need to be modified. For details about configuring global host-
key authentication in a NAT deployment, see the Administration Guide or System
Administration Guide for your appliance.
To use the Web UI to obtain the host key of a supported appliance, use the Certificate
Management page:
l On a Central Management appliance, the host key is the key that you will import
into the global host-keys database of the managed appliance:
126 © 2021 FireEye

l On a managed appliance, the host key is the key that you will import into the global
host-keys database of the Central Management appliance:
Prerequisites
l Admin access to configure authentication and create keys.
l Central Management appliances only:

o Monitor, Operator, or Admin access to obtain managed appliance host keys.
o The private key remains on the Central Management appliance and cannot
be computed from the public key.
l Managed appliances only:

o Monitor, Operator, or Admin access to obtain Central Management appliance
host keys.
o The private key remains on the managed appliance and cannot be computed
from the public key.
To obtain a host key:

2. Go to the Settings > Certificates/Keys page.
3. In the Keys section of the page, find the string that identifies the host key.
l On a Central Management appliance:

Appliance Public Key
l On a managed appliance:
Appliance Public Key (Use this key for managed appliance connections)
4. Copy the string starting with the IP address.
© 2021 FireEye 127

5. Do one of the following:

l (Central Management only) Paste the key into the Central Management Web
UI, as described in Importing a Host Key into the Global Host-Keys Database
Using the Central Management Web UI on page 131.
l Paste the key into the CLI, as described in Importing a Host Key into the
Central Management Global Host-Keys Database Using the CLI on page 133
or Importing a Host Key into the Managed Appliance Global Host-Keys
Database Using the CLI on page 134.
l Paste the key into a text file and save it for later.
Obtaining a Managed Appliance Host Key Using the CLI

This procedure describes how to use a Central Management appliance command obtain
the host key of the managed appliance. This is the key that you will import into the global
host-keys database of the Central Management appliance.
IMPORTANT! You must obtain the RSA v2 key.
IMPORTANT! The host-key string may need to be modified in Network

Address Translation (NAT) deployments. For details, see Global Host-Key
Authentication on a Central Management Appliance in a NAT Deployment on
page 139 or Global Host-Key Authentication on a Managed Appliance in a
NAT Deployment on page 140.
To obtain the host key:

2. View the keys:
l If the appliance is running Release 7.6.0 or later:
hostname > show ssh server host-keys interface ether1
l If the appliance is running an earlier release:

hostname > show ssh server host-keys
3. Locate the RSA v2 host key entry.
128 © 2021 FireEye

4. Do one of the following, depending on whether you will add the key using the
Central Management appliance Web UI or CLI:
l Web UI: Copy the key string, starting with the IP address and ending with
the last character. Omit the double quotation marks at the beginning and end
of the host key entry.
l CLI: Copy the key string as described above, but include the double
quotation marks.
l Paste the key into the Central Management Web UI, as described in Importing
a Host Key into the Global Host-Keys Database Using the Central
Management Web UI on page 131.
l Paste the key into the Central Management CLI, as described in Importing a
Host Key into the Central Management Global Host-Keys Database Using the
CLI on page 133 or Importing a Host Key into the Managed Appliance
Global Host-Keys Database Using the CLI on page 134.
Example
This example displays the host keys for a managed appliance. The RSA v2 key is
highlighted for illustration.
Acme-05 > show ssh server host-keys interface ether1
SSH server configuration:
SSH server enabled: yes
.
.
.
Interface listen enabled: yes
Listen Interfaces:
Interface: ether1
Host Key Finger Prints and Key Lengths:

RSA v1 host key: 33:20:5f:af:65:33:e8:62:26:3c:25:d0:1f:2d:8a:54 (2048)
RSA v2 host key: 54:fa:10:2a:f4:c2:cf:3a:46:b1:a4:ed:72:78:b8:22 (2048)
DSA v2 host key: 99:59:a8:a1:d8:3e:df:2e:74:fc:6a:be:be:d2:62:32 (1024)
Host Keys:
RSA v1 host key: "172.17.74.40 2048 65537 2767892723557105143394492343612763
94200729942394341979526174787907308831935615818924165744283828800766510523178479
02037474895252247975570054315595358600142845914848782710493540937857691486699538
04205200729560274476403668156602030333253822356382587237819555941646603447324517
63747513796533041848893042157553987170029619742182277730552872281173097286794724
22744200184844597327452806661880313000836518022137675657765205670872217927843062
15703217249958957713631587970078908302914798758861955796169110420493384623007632
35665546051494669314340340626018765311569680255688151929860734984461083957535425
72032093143856912019598"
RSA v2 host key : "172.17.74.40 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzd5JwK
BjHLe/jxkF0JzWcXOTw9l0bz2SctkQrihkqg/zXqrmxAfgbzYulDSIxOKZTh2VBnKsy0qRWrCps64Itl
h6iRlr7Jxa+jAtTAGsygD0GsSKy13wfsJDhMfWk/nrEqicQ4BJN4M/8AzP+0ATQ2QeZ3nGRRzAiyqkn4
K8cRLJ1E80SnLrwElvw805LZWqNLSQwz6tF+8L1vrmr1kzutl082NBV548AU0wptE6Z2f2oxUobcax+e
qS6QMp5nnbPTDLJTbHChsVVrchTCwfGdNnjkawdDC6IhLk0BdncChpTS9E+ZF/F67YwpuIpgraWcoXuZ
xZDTwHDYPZfNtk5"
DSA v2 host key: "172.17.74.40 ssh-dss AAAAB3NzaC1kc3MAAACBAMY7tSZt46Qrv/hqL
1tazYjXNzkyLTWp54DjfkxzE//+qjE0AUr9hTU3ZmHYChzUVTEKj7syaxd+4Y+8IZ94eRVcnrH/jrqtE
© 2021 FireEye 129

aJ64SvoUqGkbKKezUbCVfSrzGgTV/A0dUzLYMLbOEMrTMcXki+DnaUSd80PCWLvq0Mcg0IpXAAAAFQDI
tRIv/iH3AAy23h3cnWzp3dpOXQAAAIAS0AONTi0O8A+f1HNOm3PzS02ZQ9ittHxA1ISs7yE6dcbj9JrW
Vf1w2lJTEZAJPQz/c9NysGVJusll6Aj1aqQ6EKuhKlPcpY0PyCVKT3TGgY93i648umYZSs9+HzoLY1/a
TnnkBGDQ8mFbjhyw3UdeiFjamVVr+4o8QwMbDXAfXAAAAIEAjBMXsp4gK5yvsAgBqcZeZm3vW4zYUpZZ
374A3ANXENWTh2yyQd8Ig1gB0YKDBhSHD6sZpPg88WSDxK3IAdifYGx+FAhowiuWcI+kA0UeiAb9/C+A
653zii1Nc85/fsIwl3GIjmp/xO23b+9YmHY8V5CsT+mmSIYQutCIzUVWbcYvEc="
Obtaining the Central Management Appliance Host Key

Using the CLI
This procedure describes how to use a managed appliance CLI command to obtain the
host key of the Central Management appliance. This is the key that you will import into
the global host-keys database of the managed appliance.
IMPORTANT! You must obtain the RSA v2 key.
IMPORTANT! The host-key string may need to be modified in Network

Address Translation (NAT) deployments. For details, see Global Host-Key
page 139 or Global Host-Key Authentication on a Managed Appliance in a
To obtain the host key:
1. Log in to the managed appliance CLI.

2. View the keys:
hostname > show ssh server host-keys interface ether1
3. Locate the RSA v2 host key entry.

4. Copy the key string, including the double quotation marks.
l Paste the key into the managed appliance CLI, as described in Importing a
Host Key into the Managed Appliance Global Host-Keys Database Using the
CLI on page 134.
Example
This example displays the Central Management host keys. The RSA v2 key is highlighted
for illustration.
CM-08 > show ssh server host-keys interface ether1
SSH server configuration:
SSH server enabled: yes
.
.
130 © 2021 FireEye

.
Interface listen enabled: yes
Listen Interfaces:
Interface: ether1
Host Key Finger Prints and Key Lengths:

RSA v1 host key: 37:20:5f:af:65:33:e8:62:26:3c:25:d0:1f:2d:8a:54 (2048)
RSA v2 host key: c7:64:12:8a:71:a6:da:14:3c:05:37:aa:7a:2e:2a:8c (2048)
DSA v2 host key: 85:59:a8:a1:d8:3e:df:2e:74:fc:6a:be:be:d2:62:32 (1024)
Host Keys:
RSA v1 host key: "10.11.121.13 2048 65537 2767892723557105143394492343612763
94200729942394341979526174787907308831935615818924165744283828800766510523178479
02037474895252247975570054315595358600142845914848782710493540937857691486699538
04205200729560274476403668156602030333253822356382587237819555941646603447324517
63747513796533041848893042157553987170029619742182277730552872281173097286794724
22744200184844597327452806661880313000836518022137675657765205670872217927843062
15703217249958957713631587970078908302914798758861955796169110420493384623007632
35665546051494669314340340626018765311569680255688151929860734984461083957535425
72032093143856912019598"
RSA v2 host key : "10.11.121.13 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZZJLE/

ftkUddyNW6KdqEQXjS0PjbtzTn3OB51Qg0fdeQHrJgFHM2/4C9WtDkwuX5jd7gdWnSWYwrXDv657thly
RPIt4Wxjf0bpOolPKAe6shgYq35NxalYDt7Pa/oym51SN/x9dGaaTFOHvvdAf0Gu5E7nv3YjLjmSgdpS
p7auHnYsyJ5O+xlYocXtoBq6jOueyxm8qm76IWL007JIJ7ZLgMI8FjZ5gp48r+Hnjrdio2rhKKUP/6B0
jpHRxsd8yPxMgJpyz2Dwv9ZIJha67f6sgWYdt4yxfBc9yr7yG3iVWVJcLE+83aY24X7DBUXFnG3AeciD
pEqAit2dPF586hJ"
DSA v2 host key: "10.11.121.13 ssh-dss AAAAB3NzaC1kc3MAAACBAMY7tSZt46Qrv/hqL

1tazYjXNzkyLTWp54DjfkxzE//+qjE0AUr9hTU3ZmHYChzUVTEKj7syaxd+4Y+8IZ94eRVcnrH/jrqtE
aJ64SvoUqGkbKKezUbCVfSrzGgTV/A0dUzLYMLbOEMrTMcXki+DnaUSd80PCWLvq0Mcg0IpXAAAAFQDI
tRIv/iH3AAy23h3cnWzp3dpOXQAAAIAS0AONTi0O8A+f1HNOm3PzS02ZQ9ittHxA1ISs7yE6dcbj9JrW
Vf1w2lJTEZAJPQz/c9NysGVJusll6Aj1aqQ6EKuhKlPcpY0PyCVKT3TGgY93i648umYZSs9+HzoLY1/a
TnnkBGDQ8mFbjhyw3UdeiFjamVVr+4o8QwMbDXAfXAAAAIEAjBMXsp4gK5yvsAgBqcZeZm3vW4zYUpZZ
374A3ANXENWTh2yyQd8Ig1gB0YKDBhSHD6sZpPg88WSDxK3IAdifYGx+FAhowiuWcI+kA0UeiAb9/C+A
653zii1Nc85/fsIwl3GIjmp/xO23b+9YmHY8V5CsT+mmSIYQutCIzUVWbcYvEc="
Importing a Host Key into the Global Host-Keys Database

Using the Central Management Web UI
Use the Sensor Management page to import the host keys of managed appliances into the
Central Management global host-key database. You can do the following:
l Import the key for a specific appliance as part of the connection settings. You can
edit the settings of an existing managed appliance, or import the key while you are
configuring the initial connection with an appliance.
l Import keys from other appliances, even those appliances that are not currently
being managed by the Central Management appliance.
© 2021 FireEye 131

CAUTION! If compliance mode is not enabled, global host-key authentication

is optional. If you choose to use global host-key authentication, you must
explicitly enable it in addition to importing the global host key. For details, see
Enabling and Disabling Strict and Global Host-Key Checking Using the CLI on
page 136.
IMPORTANT: Before you perform this procedure, you must obtain the host key
from the managed appliance. For appliances running Release 7.6.0 or later, you
can obtain this key from the appliance Web UI or CLI. For appliances running
an earlier release, you must obtain this key from the CLI. For details, see
Obtaining a Host Key Using the Web UI on page 126 or Obtaining the Central
Management Appliance Host Key Using the CLI on page 130 or Obtaining a
Managed Appliance Host Key Using the CLI on page 128.
To import a host key from a specific managed appliance:
1. Click the Appliances tab. The Sensors tab should be selected.

2. If the appliance is already being managed, click Edit in the appliance row.
3. Paste the key into the Sensor Host Key field.
IMPORTANT! The key must start with the appliance IP address and it
must not be enclosed in double quotation marks. If the key starts with
the hostname, replace the hostname with the IP address.
4. Click Update Sensor. The key is added to the global host-keys database and
displayed in the Sensor Host Keys section.
To import a host key for other appliances:
1. Click the Appliances tab. The Sensors tab should be selected.

2. Click Add Sensor Host Key.
3. Paste the key into the Host Key field in the Sensor Host Keys section.
4. Click Add Key.
To remove a host key:
l Click Remove in the row for the key in the Sensor Host Keys section.
CAUTION! If you delete a host key that is in use, the connection between the
Central Management appliance and the managed appliance is broken.
132 © 2021 FireEye

Importing a Host Key into the Central Management

Global Host-Keys Database Using the CLI
Use the commands in this section to import the host key from an appliance into the
Central Management appliance global host-keys database. This procedure is required for
global host-key authentication, in which the connection will be allowed only if the host key
the appliance sends is already in this database.
CAUTION! If you choose to use global host-key authentication, you must

explicitly enable the feature in addition to importing the host key. For details,
see Enabling and Disabling Strict and Global Host-Key Checking Using the CLI
on page 136.
IMPORTANT! Before you perform this procedure, you must obtain the host key
from the managed appliance. You can obtain this key from the appliance Web
UI or CLI. For details, see Obtaining a Host Key Using the Web UI on page 126,
Obtaining a Managed Appliance Host Key Using the CLI on page 128, or
Obtaining the Central Management Appliance Host Key Using the CLI on
page 130.
IMPORTANT! The host-key string may need to be modified in a Network

Address Translation (NAT) deployment. For details, see Global Host-Key
page 139 and Global Host-Key Authentication on a Managed Appliance in a
NOTE: See the ssh commands in the CLI Reference for advanced authentication
options.
To import a host key:

hostname > enable
3. Import the key into the global host-keys database:

hostname (config) # ssh client global known-host "<keyString>"
IMPORTANT! The key must start with the managed appliance IP address,

and it must be enclosed in double quotation marks. If the key starts with
the hostname, replace the hostname with the IP address.

© 2021 FireEye 133


1. Log in to the Central Management appliance CLI.

hostname > enable
3. Remove the key:

hostname (config) # no ssh client global known-host "<keyString>"


Example
This example imports the host key from a managed appliance into the Central
Management platform global host-key database.
hostname (config) # ssh client global known-host "172.17.74.54 ssh-rsa AAAAB3
NAfgbzYulDSIxOKZTh2VBnKsy0qRWrCps64Itlh6iRlr7JxazaC1yc2EAAAADAQABAAABAQCzd5Jw
Ktk5BjHLe/jxkF0JzWcXOTw9l0bz2SctkQrihkqg/zXqrmxtE6Z2f2oxUobcax+eqS6QMp5nnbPTD
LJTbHCNnjkawdDC6IhLk0BdncChpTS9E+ZF/F67YwpuIpgraWrchTCwfG+jAtTAGsygD0VVrchTCc
ncChpTS9E+ZF/F67YwpuIpgraWcoXuZxZKy13wfsJDhMfWk/nrEqicQ4BJN4M/8AzP+fd9sda3li"
SSH client Strict Hostkey Checking: ask
Minimum protocol version: 2
Cipher list: compatible
Minimum key length: 1024 bits
SSH Global Known Hosts:

Entry 1:
Host: 172.17.74.54
Finger Print: 54:fa:10:2a:f4:c2:cf:3a:46:b1:a4:ed:72:78:b8:22
Key Length (bits): 2048
...
Importing a Host Key into the Managed Appliance Global

Host-Keys Database Using the CLI
Use the commands in this section to import the host key from a Central Management
appliance into the managed appliance global host-keys database. This procedure is
134 © 2021 FireEye

required for global host-key authentication, in which the connection will be allowed only if
the host key the Central Management appliance sends is already in this database.
CAUTION! If you choose to use global host-key authentication, you must

explicitly enable the feature in addition to importing the host key. For details,
see Enabling and Disabling Strict and Global Host-Key Checking Using the CLI
on the next page.
IMPORTANT! Before you perform this procedure, you must obtain the host key
from the Central Management appliance. You can obtain this key from the
Central Management appliance Web UI or CLI. For details, see Obtaining a
Host Key Using the Web UI on page 126, Obtaining a Managed Appliance Host
Key Using the CLI on page 128, or Obtaining the Central Management
Appliance Host Key Using the CLI on page 130.
IMPORTANT! The host-key string may need to be modified in a Network

Address Translation (NAT) deployment. For details, see Global Host-Key
page 139 and Global Host-Key Authentication on a Managed Appliance in a
NOTE: See the ssh commands in the CLI Reference for advanced authentication
options.
To import a host key:

hostname > enable
3. Import the key into the global host-keys database:

hostname (config) # ssh client global known-host "<keyString>"
IMPORTANT! The key must start with the Central Management

appliance IP address, and it must be enclosed in double quotation
marks. If the key starts with the hostname, replace the hostname with the
IP address.

hostname (config) # show ssh server host-keys

© 2021 FireEye 135


hostname > enable
3. Remove the key:

hostname (config) # no ssh client global known-host "<keyString>"


Example
This example imports the host key from a Central Management appliance into the
managed appliance global host-key database.
hostname (config) # ssh client global known-host "10.11.121.13 ssh-rsa AAAAB3
NzaC1yc2EAAAADAQABAAABAQDZZJLE/ftkUddyNW6KdqEQXjS0PjbtzTn3OB51Qg0fdeQHrJgFHM2
/4C9WtDkwuX5jd7gdWnSWYwrXDv657thlyRPIt4Wxjf0bpOolPKAe6shgYq35NxalYDt7Pa/oym51
SN/x9dGaaTFOHvvdAf0Gu5E7nv3YjLjmSgdpSp7auHnYsyJ5O+xlYocXtoBq6jOueyxm8qm76IWL0
07JIJ7ZLgMI8FjZ5gp48r+Hnjrdio2rhKKUP/6B0jpHRxsd8yPxMgJpyz2Dwv9ZIJha67f6sgWYdt
4yxfBc9yr7yG3iVWVJcLE+83aY24X7DBUXFnG3AeciDpEqAit2dPF586hJ"
SSH client Strict Hostkey Checking: ask
SSH Global Known Hosts:

Entry 1:
Host: 10.11.121.13
Finger Print: c7:64:12:8a:71:a6:da:14:3c:05:37:aa:7a:2e:2a:8c
Key Length (bits): 2048
...
Enabling and Disabling Strict and Global Host-Key

Checking Using the CLI
The procedures in this topic describe how to use CLI commands to enable host-key
checking. You can enable strict host-key checking, global host-key checking, or both.
136 © 2021 FireEye

Strict host-key checking

If you enable strict host-key checking on a Central Management appliance, the
connection will be allowed only if the local host-keys database for the Central
Management appliance remote user already has an entry that matches the key the
managed appliance sends.
If you enable strict host-key checking on a managed appliance, the connection will be
allowed only if the local host-keys database for the managed appliance remote user
already has an entry that matches the key the Central Management appliance sends.
Global host-key checking

If you enable global host-key checking on a Central Management appliance, the
connection will be allowed only if the managed appliance global host-keys database
already has an entry that matches the key the Central Management appliance sends.
If you enable global host-key checking on a managed appliance, the connection will be
allowed only if the Central Management appliance global host-keys database already
has an entry that matches the key the managed appliance sends.
Enabling Strict Host-Key Checking

You can use these commands on a Central Management appliance or on a managed
appliance.
To enable strict host-key checking:
1. Log in to the appliance CLI.

hostname > enable
3. Enable strict host-key checking:

hostname (config) # cmc auth ssh host-key strict

hostname (config) # show cmc auth ssh

© 2021 FireEye 137

Enabling Global Host-Key Checking

appliance.
CAUTION! When you enable global host-key authentication, any established

connections will be broken until you explicitly add the host key to the global host-
keys database.
To enable global host-key checking:

hostname > enable
3. Enable global host-key checking:

hostname (config) # cmc auth ssh host-key global-only
Any established connections are broken


6. To add the host-key to the global database, follow the instructions at Importing a
Host Key into the Central Management Global Host-Keys Database Using the CLI
on page 133 or, for a Central Management appliance, Importing a Host Key into the
Global Host-Keys Database Using the Central Management Web UI on page 131.
Disabling Strict or Global Host-Key Checking

appliance.
To disable strict or global host-key authentication:

hostname > enable
3. Perform the following steps as needed.

l To disable strict host-key checking:
hostname (config) # no cmc auth ssh host-key strict
138 © 2021 FireEye

l To disable global host-key checking:

hostname (config) # no cmc auth ssh host-key global


Example
This example enforces both strict and global host-key checking on a Central Management
appliance or a managed appliance.
hostname (config) # cmc auth ssh host-key strict
hostname (config) # cmc auth ssh host-key global-only
CMC SSH configuration:

Strict host key checking enabled: yes
Global only known hosts enabled: yes
Global Host-Key Authentication on a Central

Management Appliance in a NAT Deployment
When global host-key authentication is enforced on the Central Management appliance,
you must obtain the public host key from managed appliance and import it into the
Central Management appliance global host-keys database. This is described in Secure Shell
(SSH) Authentication on page 115.
The managed appliance host-key string includes its IP address. If the managed appliance
is in an internal network behind a NAT gateway, the IP address in the key string you
obtain from the managed appliance Web UI or CLI must be replaced with the virtual
IP address that is mapped to the managed appliance on the NAT gateway.
Example
In this example, the Email Security — Server Edition appliance is behind the NAT
gateway. Its IP address is 2.2.2.5, and its virtual IP address is 3.3.3.5.
© 2021 FireEye 139

The host-key string you obtain from the appliance Web UI or CLI starts with "2.2.2.5". For
example:
2.2.2.5 ssh-rsa BEWDS4d65dj/T29+6a38loABAAABAQDZZJLE/ftkUddyNW6KdqEQXjS0Pjb
tzTn3OB51Qg0fdeQHrJgFHM2/4C9WtDkwuX5jd7gdWnSWYwrXDv657thlyRPIt4Wxjf0bpOolPKAe
...
Before you import the host-key into the Central Management appliance global host-keys
database, you must replace "2.2.2.5" with "3.3.3.5." For example:
3.3.3.5 ssh-rsa BEWDS4d65dj/T29+6a38loABAAABAQDZZJLE/ftkUddyNW6KdqEQXjS0Pjb
tzTn3OB51Qg0fdeQHrJgFHM2/4C9WtDkwuX5jd7gdWnSWYwrXDv657thlyRPIt4Wxjf0bpOolPKAe
...
Global Host-Key Authentication on a Managed Appliance

in a NAT Deployment
When global host-key authentication is enforced on a managed appliance, you must obtain
the public host-key from the Central Management appliance and import it into the
managed appliance global host-keys database. This is described in Secure Shell (SSH)
The Central Management appliance host-key string includes its IP address. If the Central
Management appliance in an internal network behind a NAT gateway, the IP address in
the key string you obtain from the Central Management appliance Web UI or CLI must be
replaced with the virtual IP address that is mapped to the Central Management appliance
on the NAT gateway.
Example
In this example, the Central Management appliance is behind the NAT gateway. Its
IP address is 1.1.1.5, and its virtual IP address is 3.3.3.5.
NOTE: This example is from an Email Security — Server Edition appliance, but it

is representative of other managed appliances as well.
140 © 2021 FireEye

The host-key string you obtain from the Central Management appliance Web UI or CLI
starts with "1.1.1.5". For example:
1.1.1.5 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzd5JwKBjHLe/jxkF0JzWcXOTw9l0
bz2SctkQrihkqg/zXqrmxAfgbzYulDSIxOKZTh2VBnKsy0qRWrCps64Itlh6iRlr7Jxa+jAtTAGsy
...
Before you import the host-key into the Email Security — Server Edition appliance global
host-keys database, you must replace "1.1.1.5" with "3.3.3.5." For example:
3.3.3.5 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzd5JwKBjHLe/jxkF0JzWcXOTw9l0
bz2SctkQrihkqg/zXqrmxAfgbzYulDSIxOKZTh2VBnKsy0qRWrCps64Itlh6iRlr7Jxa+jAtTAGsy
...
© 2021 FireEye 141

142 © 2021 FireEye

System Security Guide SSO Authentication Overview
CHAPTER 7: Single Sign-On

Authentication
l SSO Authentication Overview below

l About Helix Mode and Single Sign-On Mode on page 145
l When SSO Authentication Is Disabled on page 146
l When SSO Authentication Is Required on page 148
l When SSO Authentication Is Allowed on page 152
l Viewing Helix Mode and SSO Authentication Mode Using the CLI on page 155
l Enabling SSO Authentication Using the CLI on page 157
SSO Authentication Overview

FireEye Helix is a unified detection and response platform that aggregates and prioritizes
security alerts generated from the smart nodes and endpoint agents in your network.
Security operations are managed from a single console for alert management, search,
analysis, rules, analytics, investigations, and reporting.
© 2021 FireEye 143

System Security Guide CHAPTER 7: Single Sign-On Authentication
FireEye Identity and Access Management (IAM) provides user provisioning through role-
based access control policies. Using the default IAM organization administrator account,
you log in to the FireEye Cloud Web UI to configure security policies, other FireEye IAM
users, and user access controls.
FireEye IAM enables Helix to support single sign-on (SSO). Users authenticate against
FireEye IAM when they log in to a Helix appliance with their FireEye IAM account
credentials. The appliance verifies the user’s identity and obtains information from the
user’s ID token, access token, or session token. The user can navigate among components
without logging in to each appliance locally.
144 © 2021 FireEye

Release 2021.1 About Helix Mode and Single Sign-On Mode
IMPORTANT! OIDC-based authentication and X.509-based authentication are

mutually exclusive. FireEye IAM uses OIDC-based authentication. If you use
FireEye IAM, do not enable the use of Common Access Cards (CAC) or Personal
Identity Verification (PIV) smart cards. Both CAC and PIV use the X.509
standard for a Public Key Infrastructure (PKI) as an authentication mechanism
to manage certificates. See FireEye IAM Overview on page 281 and Common
Access Card (CAC) for Certificate Authentication on page 79.
About Helix Mode and Single Sign-On

Mode
Web UI login options on an appliance depend on how Helix mode and SSO mode are set.
Helix Mode
In a Helix deployment, a FireEye appliance can be in one of three Helix modes:
l cloud―The appliance is in the FireEye private cloud.

l on-premises―The appliance is in your network.
l on-premises with-sso―The appliance is in your network.
l disabled―The appliance is not operating in the Helix environment.
Helix mode is disabled by default, and it is enabled when it is set to cloud or on-premises.
For details, see the Helix Integration Guide.
Single Sign-On Mode

In a Helix deployment, a FireEye appliance can be in one of three SSO authentication
modes:
l required―Users sign in once at a FireEye Cloud Account login page with FireEye
IAM credentials. Users can pivot to any Helix component without logging in again
until the SSO session expires. See When SSO Authentication Is Required on
page 148.
l disabled―Users log in at the standard appliance Web UI login page with local
credentials for that appliance. See When SSO Authentication Is Disabled on the next
page.
l allowed―Users can sign in either locally or at the FireEye Cloud Account login
page. See When SSO Authentication Is Allowed on page 152.
© 2021 FireEye 145

Single sign-on authentication is disabled by default, and it is enabled when it is set SSO
authentication mode to required or allowed.
IMPORTANT: The Mandiant Managed Defense (MD) integration uses local

authentication. Authentication fails and MD service delivery can be interrupted if
you require SSO authentication.
When SSO Authentication Is Disabled

If SSO authentication is disabled when you make a Helix appliance Web UI page request
(through an application or by entering the appliance URL in the browser address bar), you
must log in to the appliance locally.
Logging In When SSO Is Disabled

If SSO authentication is disabled, and if no session to the requested Helix appliance exists
when you make a Web request for a Web UI page on that appliance, the Web UI login page
for the appliance appears. You sign in locally with your credentials for that specific
appliance.
This login sequence applies to each individual Helix appliance in the organization. This is
the default setting.
146 © 2021 FireEye

Release 2021.1 When SSO Authentication Is Disabled
Logging Out When SSO Is Disabled

If SSO authentication is disabled, you log out of an individual appliance, and no SSO
session is involved.
Information displayed in the dialog box describes the authentication method:
Dialog Box
Description
Field
Auth Method Local means that the user logged in locally to the appliance using their
appliance-specific credentials.
Username The user logged in with this appliance-specific user rname.
After you click Logout, your local session is closed.
© 2021 FireEye 147

authentication logout user-message enable command to display the log out
message. For details about how to enable the log out message setting, see
Enabling or Disabling the Log Out Message Setting Using the CLI on page 26.
When SSO Authentication Is Required

If SSO authentication is required when you make a Helix appliance Web UI page request
must sign in to FireEye Helix with your FireEye IAM account credentials.
Logging In When SSO Is Required

If SSO authentication is required, and if no SSO session exists when you make a Web
request for a Web UI page on the appliance, use the login page to log in to the appliance:
When you click Sign In Using Single Sign-On, the FireEye Cloud Account login page
appears. Enter your FireEye IAM account credentials.
After you authenticate against FireEye IAM, the Alerts page of the requested appliance
appears. You can access other Helix components in your network without logging in
locally to individual appliances, as long as your SSO session has not expired.
148 © 2021 FireEye

Release 2021.1 When SSO Authentication Is Required
Logging Out When SSO Is Required

If SSO authentication is required, the logout dialog box allows you to log out of the local
session only, or to log out of both the local and SSO sessions.
Information about the authentication methods is displayed in the logout dialog box:
Dialog Box Field Description
Username The user's FireEye IAM account username.
Local Username The user's appliance-specific local username.
Role The role assigned to the user's IAM account
Auth Method The value oidc means that the user logged in with
SSO authentication using FireEye IAM credentials.
Also log me out of Single Sign-On The user has the option to log out of both the local
session and the SSO session.
© 2021 FireEye 149

Logging Out From a Local Session Only

When SSO is required and you also have a local session to an appliance, you can log out
from the local session while continuing to work in other areas of the Helix Web UI. The
SSO session remains open until you log out of SSO or the SSO session token expires.
After you log out from the local session, the following page appears:
To log out from a local session to an appliance while your SSO session remains active:
1. At the appliance, select the logout command.

The SSO local logout dialog box (shown at Logging Out When SSO Is Required on
the previous page) appears.
2. Make sure the Also log me out of Single Sign-On checkbox is clear.
3. Click Logout.
The appliance logout page shown above appears.
4. Click Appliance Console.
The Central Management appliance Dashboard appears.
150 © 2021 FireEye

Release 2021.1 When SSO Authentication Is Required
If You Log Out From Both the Local and SSO Sessions

When SSO is required you can log out of your SSO Web UI session and any local sessions
to individual appliances. After you log out, the following page appears:
To log out from your SSO session and any local sessions to individual appliances:
1. At the appliance, select the logout command.

The SSO local logout dialog box (shown at Logging Out When SSO Is Required on
page 149) appears.
2. Select Also log me out of Single Sign-On.
3. Click Logout.
The appliance logout page shown above appears.
4. Click one of the following options:
l Helix Console—The Helix console login page appears.

l Appliance Console—The Central Management appliance login appears.
© 2021 FireEye 151

When SSO Authentication Is Allowed

If SSO authentication is allowed when you make a Helix appliance Web UI page request
can choose between local login and single sign-on authentication. You can also log in to
the Web UI for certificate authentication. For details about certificate authentication, see
Common Access Card (CAC) for Certificate Authentication on page 79.
Logging In When SSO Is Allowed

If no session to the requested Helix appliance exists when you make a Web request for a
Web UI page on that appliance, the login page offers two ways to log in to the appliance:
The login page also offers three ways to log in to the appliance if both a certificate and SSO
are optional for user authentication:
Logging In to the Appliance

If you use the standard login, you enter your local credentials for the appliance, and
the Web UI session is valid only for this appliance. To view the Web UI pages on other
Helix appliances, you must log in locally at the Web UI of each appliance.
152 © 2021 FireEye

Release 2021.1 When SSO Authentication Is Allowed
Logging In Using SSO

If you click Sign In Using Single Sign-On, the FireEye Cloud Account login page
appears, and you enter your FireEye IAM account credentials. The Alerts page of the
requested appliance appears. To view Web UI pages of other Helix appliances, you do
not need to log in again, as long as the SSO session has not expired.
Logging Out When SSO Is Allowed

If SSO is allowed, the logout sequence depends on whether you logged in locally used SSO
authentication.
© 2021 FireEye 153

If You Logged In Locally

If you logged in locally, you log out using the local logout dialog box.
If You Logged In With Single Sign-On Authentication

If you logged in with SSO authentication, you log out using the single sign-on logout
dialog box.
After you click Logout, your session is closed and the dual login page appears again.
154 © 2021 FireEye

Release 2021.1 Viewing Helix Mode and SSO Authentication Mode Using the CLI
authentication logout user-message enable command to display the log out
message. For details about how to enable the log out message setting, see
Enabling or Disabling the Log Out Message Setting Using the CLI on page 26.
Viewing Helix Mode and SSO

Authentication Mode Using the CLI
Helix mode can be viewed by an appliance Admin user logged in to the CLI of any Helix
appliance in the IAM organization.
Prerequisites
l Admin access to a Helix appliance CLI.
To view Helix mode and SSO authentication mode:
1. Log in to a Helix appliance CLI.

2. Go to enable mode.
hostname > enter
3. To display Helix configuration settings, including SSO authentiation mode, use the
show helix command.
l In this example, the appliance is not operating as a Helix appliance. Helix

mode and SSO authentication are disabled, which are the default settings:
hostname # show helix
© 2021 FireEye 155

Helix Configurations:
Enabled : no
Mode : cloud
Single Sign-On : disabled
Console URL : http:///google.com
Alert Sync Enabled : yes
Alert Sync From : 0 days old
Alert Sync Max Count : 10000
l In this example, the appliance is not operating as a Helix appliance, Helix is

enabled for cloud operation, and SSO authentication is disabled.
Enabled : yes
Mode : cloud
Single Sign-On : disabled
l In this example, the appliance is operating as a Helix appliance. Helix mode

is enabled for on-premises operation, and SSO authentication is required:
Enabled : yes
Mode : on-premises
Single Sign-On : required
4. Display SSO authentication mode.
In this example, SSO authentication for the Web UI is disabled, which is the default
setting.
hostname # show aaa authentication oidc
OIDC based authentication settings:
Web Policy : disabled
ID-token field for username : oidc-preferred-username
156 © 2021 FireEye

Release 2021.1 Enabling SSO Authentication Using the CLI
Enabling SSO Authentication Using the

CLI
SSO authentication can be configured by an appliance Admin user logged in to the CLI of
a Helix appliance in the IAM organization.

to manage certificates. See FireEye IAM Overview on page 281 and Common
Access Card (CAC) for Certificate Authentication on page 79.
If SSO authentication is disabled, it automatically changes to required if Helix mode is

changed to on-premises with the single sign-on option.
Prerequisites
l Your FireEye IAM organization and user accounts are configured. See FireEye IAM
Overview on page 281
l Admin access to a Helix appliance CLI.
To enable SSO authentication:
1. Log in to a Helix appliance CLI.

2. Go to configuration mode.
hostname > enable
© 2021 FireEye 157

3. Enable SSO authentication. Do one of the following:
To enable SSO authentication on a managed on-premises appliance:
a. Enable Helix mode.

hostname (config) # helix mode on-premises
b. Enable SSO authentication.

l To require SSO authentication, use the following command:
hostname (config) # aaa authentication oidc web policy
required
l To make SSO authentication optional, use the following command:

hostname (config) # aaa authentication oidc web policy
allowed
To require SSO authentication on a standalone on-premises appliance:
l Use the following CLI configuration command to put the appliance in Helix
mode and set SSO authentication mode to required:
hostname (config) # helix mode on-premises with-sso
For all other cases:
a. Enable Helix mode.

l For a cloud-managed appliance, use the following command:
hostname (config) # helix mode cloud
l For an on-premises appliance, use the following command:

hostname (config) # helix mode on-premises
b. Set SSO authentication to required.

hostname (config) # aaa authentication oidc web policy required
4. Verify your changes. Use the following commands, as described in Viewing Helix
Mode and SSO Authentication Mode Using the CLI on page 155.
l hostname (config) # show helix
l hostname (config) # show aaa authentication oidc
(the Enabled field of the show helix command output displays yes),
5. (Optional) After the appliance is running in Helix mode, you can use the following
command to administratively disable SSO authentication without causing the
appliance to exit Helix mode:
hostname (config) # aaa authentication oidc web policy disabled

158 © 2021 FireEye

Release 2021.1 About Security Assertion Markup Language (SAML)
CHAPTER 8: Configuring SAML

Authentication and Authorization
on FireEye Appliances
l About Security Assertion Markup Language (SAML) below

l Configuring SAML Authentication on the next page
l Configuring SAML Authorization on page 166
About Security Assertion Markup

Language (SAML)
Security Assertion Markup Language (SAML) extends the Single Sign-On (SSO) standard to
authenticate and authorize users.
SAML is an XML and Web based open standard protocol for federated authentication and
authorization processes between separate identity providers and service providers. SAML
shares or "federates" user identities within a network.
SAML configuration involves these roles:
l Users—a human user that requests a service from the service provider. Also known
as a principal.
l Identity provider (IdP)—the entity that does authentication assertions with a single
sign-on (SSO). The IdP is a third-party service that creates, manages, and verifies the
authenticity of the user within a federation or distributed network. Examples of an
IdP are Okta and Microsoft Active Directory Federation Services (ADFS).
l Service provider (SP)—the entity that uses the IdP to authenticate the identity of the
user so that it can authorize access to its services. The FireEye appliance operates as
the SAML SP.
Your SAML IdP solution depends on your security and network requirements.
Refer to your IdP server installation and configuration documentation to
integrate with FireEye appliances.
© 2021 FireEye 159

System Security Guide CHAPTER 8: Configuring SAML Authentication and Authorization on FireEye Appliances
SAML passes credentials about users, logins, and attributes between the IdP and SP. The
credentials are in the form of assertions. An assertion is an XML metadata file that the IdP
posts to a location that the SP retrieves. The metadata contains the user's identify or profile.
With SAML, the user only needs to log in once using single sign-on (SSO) on the FireEye
appliance. The user log in generates an SP authentication SAML request that is redirected
to the IdP via the Web UI. When the request is received, the IdP generates and returns a
SAML authentication response that contains the stored user attributes back to the SP.
For SAML authentication and authorization to work:
l An Assertion Consumer Service URL (ACS Endpoint) must be configured on the IdP
l An IdP login URL must be configured on the FireEye appliance operating as an SP.
This information is the metadata that is configured on the IdP and SP. See Configuring
SAML Authorization on page 166.
Configuring SAML Authentication

The administrator does the following to configure SAML authentication and authorization
on the FireEye appliance operating as a SAML service provider.
l Enabling or Disabling SAML Authentication Using the CLI below

l Redirecting to the IdP Login Page on the facing page
l Uploading the SAML IdP Metadata on to the SP on page 163
l Downloading the SAML Service Provider Metadata on page 164
l Mapping User Roles Using Custom SAML Attributes on page 166
l Defining SAML Authorization Rules on page 168
Prerequisites
l Admin access to the FireEye appliance (SP).
l Admin access to the SAML IdP service.
l Communication between the SAML IdP service and the FireEye appliance.
l If using access groups, access group rules must be configured for SAML.
l If using AAA authorization rules, they must be configured for SAML.
Enabling or Disabling SAML Authentication Using the CLI

Enable SAML authentication using the CLI and then perform configuration tasks from the
Setting > Authentication tab on the FireEye appliance Web UI.
160 © 2021 FireEye

Release 2021.1 Configuring SAML Authentication
The authentication Web UI tab displays only after SAML is enabled.
SAML authentication is mutually exclusive with OIDC-based authentication.
Prerequisites
To enable SAML using the CLI:

hostname # enable
3. Allow users to log in to the Web UI for SAML authentication.

hostname (config) # aaa authentication saml web policy allowed

hostname (config) # show aaa authentication saml

To disable the policy setting of the Web UI for SAML:
1. Log in to the Email Security — Server Edition CLI.

hostname # enable
3. Disallow users to log in to the Web UI for SAML authentication.

hostname (config) # no aaa authentication saml web policy


Redirecting to the IdP Login Page

As an administrator, you can automatically redirect users to the SAML IdP login page.
When this feature is enabled, users are redirected from the FireEye appliance's login page
© 2021 FireEye 161

to the IdP login page without clicking the Sign in using SAML link.
See Redirecting to the IdP Login Page Using the CLI below to enable or disable the feature.
Redirecting to the IdP Login Page Using the CLI

Enable redirecting to the IdP login page or restore default SAML behavior using the CLI.
Prerequisites
To enable redirecting to the IdP login page using the CLI:

hostname # enable
3. Allow users to directly log in from the IdP page.

hostname (config) # aaa authentication saml web policy required-force


To disable the redirecting policy:
1. Log in to the Email Security — Server Edition CLI.

hostname # enable
3. Disable the existing policy and restore it to the default SAML behavior.
hostname (config) # no aaa authentication saml web policy


162 © 2021 FireEye

Uploading the SAML IdP Metadata on to the SP

The SAML IdP and FireEye appliance (SP) must be registered with each other's metadata
for SAML authentication requests and authorization responses to occur.
To register the IdP for SAML authentication, you must upload the SAML IdP metadata that
contains the endpoint on the IdP where SAML requests are posted. The metadata is also
referred to as the IdP login URL.
You can upload the IdP metadata directly on to a standalone or from the Central
Management appliance for a managed appliance using the Web UI or CLI.
Prerequisites
l Admin access to the FireEye appliance operating as SAML SP.
l Admin access to the SAML IdP server.
l SAML Web policy setting is enabled by using the CLI.
l SAML IdP metadata file.
To upload the IdP metadata using the Web UI:
1. Log in to the appliance Web UI as an admin user.

2. Go to the Settings > Authentication > SAML IdP Configuration tab.
3. Click Choose File. This is the metadata file obtained from your SAML IdP server.
© 2021 FireEye 163

4. Click Upload to import the file onto the appliance.
To upload the IdP metadata using the CLI:
1. Log in to the appliance CLI as an admin user.

hostname # enable
3. Specify the IdP metadata file to upload to the appliance.

4. If the IdP uses a a self-signed certificate, turn off the verification of SSL server
certificates.
hostname # no aaa authentication saml ssl cert-verify
5. Upload the IdP metadata file.

hostname # aaa authentication saml idp fetch meta-data-url <meta-data-
pathname>
Examples:
aaa authentication saml idp fetch meta-data-url
https://172.16.142.99/IDPMetadata.xml
To use SCP to copy the IdP metadata file:

aaa authentication saml idp fetch meta-data-url scp://username
[:password]@hostname/path/filename
Downloading the SAML Service Provider Metadata

The SAML IdP and Service Provider must be registered with each other's metadata for
SAML authentication requests and authorization responses to occur.
164 © 2021 FireEye

Download the service provider metadata and upload it to your IdP server. The metadata
file includes the single sign-on (SSO) Assertion Consumer Service URL (ACS Endpoint)
and the entity ID. The metadata is used by the IdP server to learn where the SP SAML
requests are posted. The metadata is also referred to as the SP login URL.
You can download the SP metadata directly from a standalone appliance or from the
Central Management appliance for a managed appliance using the Web UI or CLI.
Prerequisites
l Admin access to the FireEye appliance operating as a SAML SP.
l Admin access to the SAML IdP server.
l SAML Web policy setting is enabled by using the CLI.
To download the appliance metadata using the Web UI:

2. Go to the Settings > Authentication > SAML Service Provider Configuration tab.
3. Click Download to retrieve the entity ID and consumer service URL
4. Click OK to save the SP metadata onto your desktop.
To download the appliance (SP) metadata using the CLI:
1. Log in to the appliance CLI as an admin user.

hostname # enable
© 2021 FireEye 165

3. Download the appliance XML metadata by specifying your admin login, password,
and path to the metadata.
hostname # aaa authentication saml download meta-data <meta-data-
pathname>
For example,
aaa authentication saml download meta-data
scp://<username>:<password>@x.x.x.x/var/www/html/saml-server-xml/
Configuring SAML Authorization

l Mapping User Roles Using Custom SAML Attributes below

l Defining SAML Authorization Rules on page 168
Prerequisites
l Admin access to the Identity Provider
Mapping User Roles Using Custom SAML Attributes

You define custom SAML attributes with a specific user role and access level for SAML
users.
Custom attributes for authorization required by FireEyeappliances SPs should be
configured on the SAML IdP server. Refer to your IdP server documentation.
The following vendor specific custom attributes are supported for all FireEye appliances
configured as a SAML SP:
l appliance.role.cms—Central Management
l appliance.role.wmps—Network Security
l appliance.role.emps—Email Security — Server Edition
l appliance.role.fmps—File Protect
l appliance.role.mas—Malware Analysis
l appliance.role.hx—Endpoint Security
l appliance.role.default—used for any designated FireEye appliance configured as an
SP.
166 © 2021 FireEye

Release 2021.1 Configuring SAML Authorization
When a user logs into a FireEye appliance through an SAML IdP server authorization, the
user must be first mapped to one of the following user roles:
l admin
l analyst
l auditor
l monitor
l operator
The FireEye appliance expects these attributes as a key-value pair.
User Role Mapping Examples
Guidelines
l The "appliance.role.<product type>" attribute takes precedence over the
"appliance.role.default" attribute.
l The "appliance.role.default" attribute can be configured on the IdP server or the
backend LDAP database where you define the user attributes.
l The user privileges are restricted to the product specified in the attribute name and
value configuration.
l The user privileges are asigned for each product specified in the
"appliance.role.<product type>" attribute.
Example 1—Assigning a default role to a user on all appliances

Configure the "appliance.role.default” attribute to user “enterpriseadmin1” to grant admin
privileges on all appliances.
Assigned Product
User Name IdP Configuration
Role Type
enterpriseadmin1 admin All Attribute Name Value
appliance.role.default admin
l In this example, the user "enterpriseadmin1" is assigned the admin role on the
Central Management, File Protect, and Network Security SP appliances.
Example 2—Assigning a specific user role on a specific appliance

Configure the "appliance.role. <product type>" attribute for a specific user.
© 2021 FireEye 167

Assigned Product
User Name IdP Configuration
Role Type
cmsadmin1 monitor cms Attribute Name Value
appliance.role.cms monitor
l In this example, the user "cmsadmin1" is assigned the monitor role on the Central
Management appliance SP.
Defining SAML Authorization Rules

SAML authorization is done by the FireEye service provider (SP). The appliance grants
access to the authenticated user after the IdP passes user authentication.
Custom attributes for authorization required by FireEye appliances should be configured
on the IdP SAML server, but an alternate solution when the IdP does not support custom
attribute definitions is to define authorization rules on the SP. Authorization rules take
precedence over custom attributes that are defined on the IdP server.
You can configure SAML users for IdP to SP authorization by mapping them to local user
accounts and granting them local role access privileges. Local users roles are passed as
attributes under the Attribute Section of the XML assertion from the SAML IdP server.
To configure SAML authorization rules on the SP, use the following command options
with the aaa authorization rules rule append tail comment command.
l match-saml-nameid Match Attribute element from SAML Assertion
l match-saml-attribute Match NameID element from SAML Assertion
Example 1—Defining a rule to map a user name to a local user role

This example authorizes the admin user to log in to the SP in CMS monitor role.
hostname (config) # aaa authorization rules rule append tail comment "mapping
monitor user to admin" map-local-user admin match-saml-nameid "cmsmonitor"
Example 2—Defining a rule to map an IdP attribute to a local user role

This example authorizes the user with the cmsadmin@exqa.com email address to log in to
the SP in local monitor role.
hostname (config) # aaa authorization rules rule append tail map-local-user
monitor match-saml-attribute "Email-Address:cmsadmin@exqa.com"
To map the login user to a local user, use the match-saml-attribute value with
the key-value pair to define the statement.
hostname # show aaa authorization rules
168 © 2021 FireEye

Release 2021.1 Configuring SAML Authorization
--------------------------------------------------------------
# AAA Auhorization Rules : Enabled
--------------------------------------------------------------
# Rule Statements
--------------------------------------------------------------
# 1
Match saml namid : cmsmonitor
-->Action Map Local User : admin
Comment : mapping monitor user to admin
# 2
Match saml attribute : Email-Address:cmsadmin@exqa.com
Example 3—Defining a rule to map users to a default role

This example maps all IdP authenticated users to log in to the SP in the default monitor
role.
hostname (config) # aaa authorization roles default monitor
hostname # show aaa authorization roles
ROLE DESCRIPTION
admin System administorator: unrestricted privileges
operator System operator: limited administrative privileges
monitor System monitor: limited read-only privileges
analyst Analyst: malware analysis
auditor Auditor: viewing of audit logs
api_analyst Analyst limited to Web Services API
api_monitor Monitor limited to Web Services API
fe_services FireEye Services
Example 4—Defining a rule to restrict access SAML groups to alerts on the

Central Management Appliance
This example defines a rule to restrict an access group to alerts that the Central
Management appliance receives from a managed SP appliance.
hostname (config) # aaa authorization access-groups rules rule append tail
match-saml-nameid <access group name> match-saml-attribute <attribute>
For detailed information, see Configuring Access Groups for Alerts on page 175
© 2021 FireEye 169

170 © 2021 FireEye

Release 2021.1
PART III: Authorization
l Assigning Roles for Local User Accounts on page 173

l Configuring Access Groups for Alerts on page 175
© 2021 FireEye 171

System Security Guide PART III: Authorization
172 © 2021 FireEye

System Security Guide Assigning Roles Using the Web UI
CHAPTER 9: Assigning Roles for

Local User Accounts
For every role, there is a corresponding system account by the same name that has the role.
System accounts cannot be deleted or modified, with the exception of being locked out so
they cannot be used to log in.
By default, each new user is granted the monitor role. An administrator can change the
role or give a user no role; a user with no role cannot log in to the appliance. If a role is
changed while the affected user is logged in, the user will be forcibly logged out. When the
user logs in again, the capabilities provided by the new role are available to the user.
Users in all roles can change their passwords and perform other account management
functions. For details, see Managing Your Own Account on page 42.
For details about the capabilities associated with each role, see Capabilities of Local Roles
on page 390
Assigning Roles Using the Web UI

Use the User Account Settings page to change an existing user’s role. (If you are creating a
new user, follow the instructions in Creating a User Account Using the Appliance Web UI
on page 35.)
IMPORTANT! If you change a role while the user is logged in, the user will be
forcibly logged out. When the user logs in again, the capabilities associated
with the new role are available to the user.
© 2021 FireEye 173

System Security Guide CHAPTER 9: Assigning Roles for Local User Accounts
Prerequisites
l Admin access
To assign a role to a user:
1. Click the Settings tab on all appliances except the Endpoint Security server. On the
Endpoint Security appliance, select Appliance Settings from the Admin menu.

3. Click the appropriate link in the User column in the table at the bottom of the page.
4. Select the new role in the Role list. For detailed information about the functionality
each role provides, see Assigning Roles for Local User Accounts on the previous
page.
Assigning Roles Using the CLI

Use the CLI commands in this topic to change an existing user’s role. (If you are creating a
new user, follow the instructions in Creating a User Account Using the Appliance CLI on
page 36.)
IMPORTANT! If you change a role while the user is logged in to the

appliance, the user will be forcibly logged out. When the user logs in again, the
capabilities associated with the new role are available to the user.
Prerequisites
l Admin access
To assign a role to a user:
hostname > enable
2. Assign a role to a user:

hostname (config) # username <username> role <role>
where <role> is one of the roles listed in Assigning Roles for Local User Accounts
on the previous page.
174 © 2021 FireEye

CHAPTER 10: Configuring Access

Groups for Alerts
You can use access groups to control which alerts users with the analyst and monitor roles
can view and manage. The system processes two types of rules to authorize access to
alerts.
l Access group rules define the criteria that must be matched in an alert that the
Central Management appliance receives from a managed Network Security or Email
Security — Server Edition appliance or from a managed ETP instance. If an alert
matches the criteria defined by the access group rules applied to an access group,
users in that access group can view and manage that alert. You can define multiple
access group rules for an access group.
l Authorization rules define the criteria that must be matched in the Central
Management Web UI login request. If there is a match, the user is added to the
access group associated with the rule. You can define multiple authorization rules
for an access group.
For example, suppose a Central Management appliance manages Network Security and
Email Security — Server Edition appliances. An authorization rule specifies that members
of the infosec LDAP group are added to the nx-alerts access group. The access group rules
defined for the nx-alerts access group specify that all alerts from managed Network Security
appliances should be displayed, except for alerts with "minor" severity. When Joe (a
member of the infosec LDAP group) logs in to the Central Management Web UI, he will see
the Alerts > NX pages, but not the Alerts > EX pages. The Alerts > NX pages will show all
major and critical alerts from all managed Network Security appliances.
This feature only affects users with the analyst and monitor roles.
Users with the admin role have unlimited access to alerts, and users with other
roles have no access to alerts by default; however, the admin can configure full UI
access to non-administrators with the aaa authorization access-groups group
<group name> rules rule command. Access groups have no effect on what
users can do with alerts. Analyst and monitor users can both view and manage
the alerts to which they have access.
© 2021 FireEye 175

System Security Guide CHAPTER 10: Configuring Access Groups for Alerts
Analyst and monitor users have no access to the CM Dashboard or the Reports
pages when this feature is enabled.
Task List for Configuring Access Groups

for Alerts
Perform the tasks in the specified order to configure access groups for alerts.
1. Create access groups. See Creating Access Groups for Alerts below.
2. Define access group rules. See Defining Access Group Rules on page 183.
3. Define authorization rules. See Defining Authorization Rules on page 185.
4. Enable access groups. See Enabling and Disabling Access Groups for Alerts on
page 186.
Creating Access Groups for Alerts

You must create access groups before you can use them in access group and authorization
rules.
Prerequisites
l Admin access to the Central Management CLI
Creating Access Groups for Alerts Using the CLI

Use the commands in this topic to create an access group.
To create an access group:

hostname > enable
176 © 2021 FireEye

Release 2021.1 Defining Rules
3. Create the access group:

hostname (config) # aaa authorization access-groups group <access group
name> [description "<description>"]
where:
l access group name is the name of the access group.
l description is optional information about the access group. Enclose the

description in double quotation marks if it includes more than one word.
hostname (config) # show aaa authorization groups group <access group
name>

Example
The following example creates the "nx-alerts" access group on the cm-03 appliance.
cm-03 (config) # aaa authorization access-groups group nx-alerts
cm-03 (config) # show aaa authorization access-groups nx-alerts
AAA Authorization Access-groups Rules : Enabled
-----------------------------------------------------
# Group: nx-alerts
-----------------------------------------------------
No Rules Configured
For an example of a fully configured access group, see Example: Configuring an

Access Groups for Alerts on page 197.
Defining Rules
A rule consists of the statements you define when you create the rule. You use key-value
pairs and other command options to define the statements. The statements do the
following:
l Specify the position of the rule in the rule list, and delete duplicate rules.
l Specify matching criteria to apply to alert objects. These statements are defined in
access group rules.
l Specify matching criteria to apply to login requests, and add optional comments.
These statements are defined in authorization rules.
© 2021 FireEye 177

The system processes all of the rules in the defined sequence, instead of stopping when the
first match is found. For access group rules, this allows the user access to all of the alerts
that match the criteria in all rules defined for the user's access groups. For authorization
rules, this allows the user to be added to multiple access groups and allows users who
meet multiple match criteria to be added to the same access group.
Rule Usage Guidelines

Follow these guidelines when you define rules.
l A rule can include multiple match options, but only one of each type. For example,
a rule cannot have two match-ldap-group <group DN> options. There are two
exceptions:
l The match-access-group <access group> match option, as described in
grant-access-group <access group> on page 183.
l The match-alert-tag <tag name> match option, as described in match-
alert-tag <tag name> on page 180.
l If a rule includes more than one match option (an AND operation), both statements
must be true to achieve a match.
For example, a rule that grants access to the "nx-alerts" access group has two
statements. One statement specifies that the mapped local user name is anne and the
other statement specifies that the user is a member of the infosec LDAP group. Anne
has a local user account on the Central Management appliance, but she is not a
member of the "infosec" LDAP group, so she will not be added to the "nx-alerts"
access group.
l If you want to achieve a match if only one of a series of statements is true (an
OR operation), you must create a separate rule for each statement.
For example, if the matching criteria in the previous example were specified in
separate rules instead of as statements in one rule, both Anne and the members of
the "infosec" LDAP group will be added to the "nx-alerts" access group.
l If you remove all matching criteria statements from an authorization rule, all
analyst and monitor users will be granted access to that access group and will be
subject to the rules defined for it.
l Do not use the match-not command option to remove a match criterion, even if
that command option was used to add the match criterion. For example, use the no
aaa authorization access-groups group nx-alerts rules rule 3 match-
alert-severity command to remove a match criterion that was added using the
match-not-alert-severity minor option.
l Do not include the command option value to remove a match criterion. For
example, in the previous item, minor is not included in the command that
removes the alert severity match criterion.
178 © 2021 FireEye

Command Options
The following tables describe the key-value pairs and other options you can use to define
rules.
l Rule Operation Options below

l Access Group Rule Options below
l Authorization Rule Options on page 181
Rule Operation Options

You can use the following command options to define the position of a rule in the rule list,
modify a rule, and delete duplicate rules.
Command
Description
Option
append Inserts the new rule after the highest-numbered rule, or at position 1 if there
tail are no existing rules.
insert Inserts the new rule at the specified position. If there is already a rule in this
<rule position, that rule and all other rules are moved up one position.
number>
set <rule Creates a new rule at the specified position. If there is already a rule in this
number> position, it is replaced by the new rule.
modify Creates or modifies a rule at the specified position. If there is already a rule
<rule in this position, the old values for an existing match option are retained
number> unless they are modified by new values for that match option.
dup-delete Delete rules that are the same as the specified rule. (Rules that are the same
except for their comments are not deleted.)
Access Group Rule Options

You can use the following command options to define the criteria used to match alerts the
Central Management appliance receives from managed Network Security appliances,
Email Security — Server Edition appliances, and Email Security — Cloud Edition
(ETP) instances. Users in the access group specified in the rule can view and manage the
alerts that meet the match criteria.
© 2021 FireEye 179

Command
Description
Option
match-alert-tag Match the specified restricted tag. (The tag must already be created
<tag name> and designated as "restricted" using the Central Management Web UI.
See the Central Management Administration Guide for details.)
To match multiple tags, add a separate match-alert-tag <tag name>
option for each tag.
match-not-alert- Do not match the specified "restricted" tag.

tag <tag name>
match- Match the specified managed Network Security or Email Security —

appliance- Server Edition appliance name. Use the show cmc appliances
name command on the Central Management appliance to view the
<appliance appliance names.
name>
match-not- Do not match the specified managed appliance name.

appliance-
name
<appliance
name>
match-alert- Match the specified severity level (critical, major, or minor).

severity
<severity>
match-not-alert- Do not match the specified severity level.

severity
<severity>
match-alert- Match the specified source address.

source-ip
<network
prefix>/<mask>
match-not-alert- Do not match the specified source address.

source-ip
<network
prefix>/<mask>
match-alert- Match the specified target address.

target-ip
<network
prefix>/<mask>
180 © 2021 FireEye

Command
Description
Option
match-not-alert- Do not match the specified target address.

target-ip
<network
prefix>/<mask>
match-all-alerts Match all alerts from all managed Network Security appliances, Email
Security — Server Edition appliances, and ETP instances.
match-full-ui- Provide unrestricted UI access.

access
match-yara- Match YARA rules modification and deletion access for users in the
rules-access Network Security appliance.
Authorization Rule Options

You can use the following command options to define the criteria used to match users
logging into the Central Management Web UI. Users whose login requests meet the match
criteria are granted access to the access group specified in the rule.
Command
Description
Option
match-auth- Match the specified authentication method (local, radius, tacacs+, or

method ldap).
<method>
match-not-auth- Do not match the specified authentication method.

method
<method>
match-remote- Match the specified remote user name.

username
<name>
match-not- Do not match the specified remote user name.

remote-username
<name>
match-mapped- Match the specified local user name.

local-username
<name>
© 2021 FireEye 181

Command
Description
Option
match-not- Do not match the specified local user name.

mapped-local-
username
<name>
match-ldap- Match the specified LDAP group Distinguished Name (DN).

group <group
DN>
match-not-ldap- Do not match the specified LDAP group DN.

group <group
DN>
match-ldap- Match the specified LDAP search filter.

search-filter
<string>
match-x509-cert- Match the specified subject field in the client X.509 certificate. The
subject <string> subject field contains the Distinguished Name (DN).
match-x509-cert- Match the specified email address in the Subject Alternate Name
san-email (SAN) field in the X.509 client certificate.
<string>
match-x509-cert- Match the specified user name portion of the email address in the
san-email- X.509 client certificate.
username
<string>
match-x509-cert- Match the specified User Principal Name (UPN) attribute from the
san-upn <string> SAN/Other Name field in the X.509 client certificate.
match-x509-cert- Match the user name from the UPN attribute in the X.509 client
san-upn- certificate.
username
<string>
match-x509-cert- Match the specified Common Name (CN) entry from the DN attribute
subject-cn in the X.509 client certificate.
<string>
182 © 2021 FireEye

Command
Description
Option
match-oidc- Match the specified preferred-username field in the OIDC identity

preferred- token.
username
<string>
match-oidc- Match the specified email field in the OIDC identity token.

email <string>
match-oidc- Match the specified username portion of the email address in the
email-username OIDC identity token.
<string>
grant-access- Grant the user who matches the criteria in the rule access to the
group <access specified access group or groups. To apply the rule to multiple access
group> groups, you can do one of the following:
l Add a separate grant-access-group <access group> option

for each group.
l Use one grant-access-group <access group> option with a
comma-separated list of groups as the <access group>
parameter.
comment Add an optional comment to the rule. Enclose the comment in

"<comment>" double quotation marks if it includes more than one word.
Defining Access Group Rules

Access group rules specify the name of the access group that will have access to the
matched alerts, the position of the rule in the rule list, and the matching criteria to apply to
alert objects.
Prerequisites
l Admin access to the Central Management appliance.
l Access groups have been created.
l If alert matching rules will filter on alert tags: Restricted alert tags and rules have been
created for managed Network Security and Email Security — Server Edition
appliances. For instructions, see the "Filtering Alerts Using Tags and Rules" chapter
of the Central Management Administration Guide.
© 2021 FireEye 183

Defining Access Group Rules Using the CLI

Use the commands in this topic to define an access group rule.
To define an access group rule:

3. Define the rule:

cm-hostname (config) # aaa authorization access-groups group <access
group name> rules rule <operation> <match option 1> [<match option
2>...]
where:
l access group name specifies the name of the access group.
l position option specifies the position of the rule in the list. For a
description of the possible values, see Rule Operation Options on page 179.
l match option specifies the alert criteria to match. For a description of the
possible values, see Access Group Rule Options on page 179.
cm-hostname (config) # show aaa authorization access-groups rules

cm-hostname (config) # write memory
Example
The following example creates a rule that grants users in the nx-alerts access group access
to all major and critical alerts from the acme-nx2500 appliance.
cm-05 (config) # aaa authorization access-groups group nx-alerts rules rule
append tail match appliance-name acme-nx2500 match-not-alert-severity minor
cm-05 (config) # show aaa authorization access-groups group nx-alerts

------------------------------------------------
# Group: nx-alerts
------------------------------------------------
# Rule Statements
------------------------------------------------
#1 Match Appliance Name: acme-nx2500
Not Match Alert Severity : minor

184 © 2021 FireEye

Defining Authorization Rules

Authorization rules specify the position of the rule in the rule list, the matching criteria
that is applied to the login request, and the name of the access group to which the logged-
in Central Management Web UI user will be granted access.
Prerequisites
l Admin access to the Central Management appliance.
Defining Authorization Rules Using the CLI

Use the commands in this topic to define an authorization rule.
To define an authorization rule:

3. Define the rule:

cm-hostname (config) # aaa authorization access-groups rules rule
<operation> <match option 1> [<match option 2>...] grant-access-group
<access group name> [comment "<comment>"]
where:
l position option specifies the position of the rule in the list. For a
description of the possible values, see Rule Operation Options on page 179.
l match option specifies the authorization criteria to match. For a description
of the possible values, see Authorization Rule Options on page 181.
l access group name specifies the name of the access group.
l comment is an optional comment. Enclose the comment in double quotation

marks if it includes more than one word.
cm-hostname (config) # show aaa authorization access-group rules
5. Save your change:

© 2021 FireEye 185

Example
The following example creates a rule that grants users in the infosec LDAP group access to
the alerts defined for the nx-alerts access group.
cm-05 (config) # aaa authorization access-groups rules rule append tail
match-ldap-group infosec grant-access-group nx-alerts
cm-05 (config) # show aaa authorization access-groups rules
# AAA Authorization Access-groups Rules : Enabled

-----------------------------------------------------------
# Rule Statements
-----------------------------------------------------------
# 1 Match LDAP Group : infosec
Grant Access Groups : nx-alerts
For an examples of a fully configured access group, see Example: Configuring an

Enabling and Disabling Access Groups for

Alerts
The access groups for alerts feature is disabled by default. You should configure access
groups before you enable them.
l If you enable access groups before they are configured, analyst and monitor users
will have no access to alerts.
l If access groups are configured but not enabled, analyst and monitor users will have
access to all alerts.
If you later disable access groups for alerts, configured access groups are not removed but
have no effect. Analyst and monitor users in configured access groups will have access to
all alerts after access groups for alerts are disabled.
Prerequisites
l Admin access to the Central Management appliance
Enabling Access Groups for Alerts Using the CLI

Use the commands in this topic to enable the use of access groups for alerts.
186 © 2021 FireEye

Release 2021.1 Enabling and Disabling Access Groups for Alerts
To enable access groups for alerts:
1. Log in to the Central Management appliance.

3. Enable the access group for alerts feature:

cm-hostname (config) # aaa authorization access-groups area alerts
enable [force]
where force suppresses the prompt to confirm your action.

4. If prompted to confirm your action, enter YES.
cm-hostname (config) # show aaa authorization access-groups

Example
The following example enables access groups for alerts on the cm-05 appliance.
cm-05 (config) # aaa authorization access-groups area alerts enable
Type 'YES' to confirm enabling access groups that limit access to certain
objects like alerts for non-admin users: YES
cm-05 (config) # show aaa authorization access-groups
AAA Access-groups enabled for : alerts
----------------------------------------------
# Group: nx-alerts
----------------------------------------------
# Rule Statements
----------------------------------------------
#1 Not Match Alert Severity: minor
...

Disabling Access Groups for Alerts Using the CLI

Use the commands in this topic to disable the use of access groups for alerts.
© 2021 FireEye 187

To disable access groups for alerts:

3. Disable the access group for alerts feature:

cm-hostname (config) # no aaa authorization access-groups area alerts
enable

cm-hostname (config) # show aaa authorization access-groups

Example
The following example disables access groups for alerts on the cm-05 appliance. The nx-
alerts access group is not removed, but has no effect unless access groups for alerts are re-
enabled.
cm-05 (config) # no aaa authorization access-groups area alerts enable
cm-05 (config) # show aaa authorization access-groups
AAA Access-groups enabled for : none
----------------------------------------------
# Group: nx-alerts
----------------------------------------------
# Rule Statements
----------------------------------------------
...
Modifying and Deleting Rules

The following table describes the tasks you can perform to modify and delete rules. The
sections that follow provide examples of some of the tasks.
If you change rule criteria while users are logged in, the changes will take effect
after the user logs out and then logs in again. You can view the users who are
still logged in after a change has been made, and can forcibly log them out. See
Viewing Access Group Users Using the CLI on page 195.
188 © 2021 FireEye

Release 2021.1 Modifying and Deleting Rules
Task Procedure
Change rule Use the modify <rule number> rule management command option,
matching and enter the match option with the new value.
criteria values.
Apply an Use the modify <rule number> rule management command option,
authorization and specify the other access group in the grant-access-group
rule to other <group name> command option. If you want to keep existing access
access groups groups, you must re-enter them. Otherwise, they will be overwritten.
Add a match Use the modify <rule number> rule management command option,
option to a rule and specify the new match option.
Add a Use the modify <rule number> rule management command option,
comment to an and use the comment "<comment>" command option to add the
authorization comment. Enclose the comment in double quotation marks if the
rule comment includes multiple words.
Remove a Use the no aaa authorization access-groups rules rule <rule

comment from number> comment command.
an
authorization
rule.
Delete Use the aaa authorization access-groups rules rule modify

authorization <rule number> dup-delete command.
rules that are
identical to the
specified rule.
Remove Use the no aaa authorization access-groups group <group name>

matching rules rule <rule number> <command option> command. Include
access group the match option but not the value.
rule criteria.
NOTE: Do not use the match-not command option, even if that
command option was used to add the rule criteria. For example, use
match-alert-severity in this command to remove a criterion that
was added using the match-not-alert-severity option.
© 2021 FireEye 189

Task Procedure
Remove Use the no aaa authorization access-groups rules rule <rule

matching number> <command option>. Include the match option but not the
authorization value.
group rule
NOTE: Do not use the match-not command option, even if that
criteria.
command option was used to add the rule criteria. For example, use
match-ldap-group in this command to remove a criterion that was
added using the match-not-ldap-group option.
Remove an Use the no aaa authorization access-groups group <group name>

access group rules rule <rule number> command.
rule.
Remove all Use the no aaa authorization access-groups group <group name>
access group rules all command.
rules.
Remove an Use the no aaa authorization access-groups rules rule <rule

authorization number> command.
rule.
Remove all Use the no aaa authorization access-groups rules all

authorization command.
rules.
Prerequisites
Examples
The following examples illustrate some of the tasks described in the previous table.
Changing Rule Match Option Values

The following example changes the appliance name to match in access group rule 3 to
nx4500-05.
modify 3 match-appliance-name nx4500-05
The following example changes the LDAP group to match in authorization rule 6 to
infosec-hq.
190 © 2021 FireEye

Release 2021.1 Modifying and Deleting Rules
cm-05 (config) # aaa authorization access-groups rules rule modify 6 match-

ldap-group infoseq-hq
Applying an Authorization Rule to Other Access Groups

The following example replaces the access group granted to authorization rule 3 with nx-
east.
access-group ex-alerts
The following example uses two match-access-group command options to add the ex-
alerts access group to authorization rule 2 and retain the nx-alerts access group.
access-group ex-alerts match-access-group nx-alerts
The following example uses a comma-separated list to add the ex-alerts access group to
authorization rule 2 and retain the nx-alerts access group.
access-group ex-alerts,nx-alerts
Adding a Match Option to a Rule

The following example adds a local user match option to authorization rule 3, which is
applied to the nx-east access group.
mapped-local-username analyst1
The following example adds an alert severity match option to access group rule 1.
modify 1 match-not-alert-severity minor
Adding or Replacing an Authorization Rule Comment

The following example adds a comment to authorization rule 6. If a comment already
exists, the command replaces it.
cm-11 (config) # aaa authorization access-groups rules rule modify 6 comment
"Eastern region NX alerts"
Deleting Duplicates of a Specified Authorization Rule

The following example deletes all authorization rules that are identical to rule 4.
cm-07 (config) # aaa authorization access-groups rules rule modify 4 dup-
delete
© 2021 FireEye 191

Removing Matching Access Group Rule Criteria

The following example removes the match-not-alert-severity minor match criterion
from access group rule 11, which is applied to the nx-alerts access group.
cm-05 (config) # no aaa authorization access-groups group nx-alerts rules
rule 3 match-alert-severity
Removing Matching Authorization Group Rule Criteria

The following example removes the match-mapped-local-username analyst1 match
criterion from authorization rule 7.
cm-03 (config) # no aaa authorization access-groups rules rule 7 match-
mapped-local-username
Modifying and Deleting Access Groups

The following table describes the tasks you can perform to modify and delete access
groups. The sections that follow provide examples of each task.
Task Procedure
Add a Use the aaa authorization access-groups group <group name>

description to description <description> command. Enclose the description in
an access double quotation marks if the description includes multiple words.
group.
Remove an Use the no aaa authorization acccess-group group <group name>

access group. command.
Remove a Use the no aaa authorization access-groups group <group name>

description description command.
from an
access group.
Prerequisites
Examples
The following examples illustrate the tasks described in the previous table.
192 © 2021 FireEye

Release 2021.1 Viewing Access Groups, Rules, and Users
Adding a Description to an Access Group

The following example adds a description to the nx-alerts access group.
cm-05 (config) # aaa authorization access-groups group nx-alerts description
"NX2500 alerts"

-------------------------------------------------
# Group: nx-alerts Description: NX2500 alerts
--------------------------------------------------
...
Removing an Access Group

The following example deletes the ex-alerts access group.
cm-01 (config) # no aaa authorization access-groups group ex-alerts
cm-01 (config) # show aaa authoriztion access-groups group ex-alerts
Unknown Access-group: ex-alerts
Removing a Description from an Access Group

The following example removes the description that was added in Adding a Description to
an Access Group above.
cm-05 (config) # no aaa authorization access-groups group nx-alerts
description

--------------------------------------------------
# Group: nx-alerts
--------------------------------------------------
...
Viewing Access Groups, Rules, and Users

You can view whether access groups for alerts are enabled, the configured access groups,
and the rules and statements defined for each access group. You can also view the access
groups granted to logged-in analyst and monitor users.
Prerequisites
l Monitor, Operator, or Admin access to the Central Management CLI
© 2021 FireEye 193

Viewing Access Group Rules and Groups Using the CLI

Use the commands in this section to view the list of defined access group rules and the
access groups that are mapped to the rules.
To view access group rules and groups:

2. Go to CLI enable mode.
3. To view a specific group:

cm-hostname # show aaa authorization access-group group <group name>
4. To view all groups:

cm-hostname # show aaa authorization access-groups
Examples
The following example shows information about the nx-alerts access group.
cm-01 # show aaa authorization access-groups group nx-alerts
AAA Authorization access-groups Rules : Enabled
-----------------------------------------------------------
# Group: nx-alerts
-----------------------------------------------------------
# Rule Statements
-----------------------------------------------------------
Match Appliance Name: nx2500-01
#2 Match Appliance Name: nx4500-03

Match Alert Source IP: 10.1.2.0/24
The following example shows information about all access groups.

cm-01 # show aaa authorization access-groups
AAA Authorization access-groups Rules : Enabled
-----------------------------------------------------------
# Group: nx-alerts
-----------------------------------------------------------
# Rule Statements
-----------------------------------------------------------
Match Appliance Name: nx2500-01
#2 Match Appliance Name: nx4500-03

Match Alert Source IP: 10.1.2.0/24
-----------------------------------------------------------
# Group: ex-alerts Description : Central Region EX
-----------------------------------------------------------
# Rule Statements
194 © 2021 FireEye

Release 2021.1 Viewing Access Groups, Rules, and Users
-----------------------------------------------------------
#1 Match Alert Source IP: 172.1.2.0/24
#2 Match Alert Tag: dll
Viewing Authorization Rules Using the CLI

Use the commands in this section to view authorization rules.
To view authorization rules:

3. View authorization rules:

cm-hostname # show aaa authorization access-groups rules
Example
The following example shows the authorization rules configured on the cm-02 appliance.
cm-02 # show aaa authorization access-groups rules
---------------------------------------------------------
---------------------------------------------------------
# Rule Statements
---------------------------------------------------------
# 1 Match LDAP Group : infosec
Grant Access Groups : nx-alerts
# 2 Match LDAP Group : infosec-hq

Grant Access Groups : ex-alerts
# 3 Match Local Users : Joe Matt Sue

Grant Access Groups : nx-alerts ex-alerts
Viewing Access Group Users Using the CLI

Use the commands in this section to view the access groups to which logged-in analyst
and monitor users have access.
The * to the left of the username in the example indicates the user who ran the
command. The (*) to the right of an access group name indicates that the
associated user was logged in while changes were made to rules for that access
group. The changes will not take effect for that user until the user logs out and
then logs in again. You can use the aaa login-session force-logout
<username> or aaa login-session force-logout all command to log out a
specified user or all users.
© 2021 FireEye 195

To view access group users:

3. View users:
cm-hostname # show users access-groups
Example
The following examples shows the users who are currently logged in to the cm-06
appliance, and the access groups granted to the analyst and monitor users.
cm-06 # show users access-groups
USERNAME REMOTE USERNAME ACCESS-GROUPS
* admin
analyst2 nx-alerts
monitor1 ex-alerts(*)
operator4
196 © 2021 FireEye

Release 2021.1 Example: Configuring an Access Groups for Alerts
Example: Configuring an Access Groups

for Alerts
The following example shows the complete process you follow to configure a new access
group and its associated rules.
cm-04 (config) # aaa authorization access-groups group nx-east description
"eastern region NX alerts"
cm-04 (config) # aaa authorization access-groups group nx-east rules rule
append tail match-not-alert-severity minor match-alert-tag malware-object
comment "major and critical malware-object alerts"
cm-04 (config) # aaa authorization access-groups group nx-east rules rule
append tail match-alert-source-ip 172.1.2.0/24
match-ldap-group intel-hq grant-access-group nx-east
match-ldap-group intel-east grant-access-group nx-east
cm-04 (config) # aaa authorization access-groups area alerts enable
cm-04 (config) # show aaa authorization access-groups group nx-east
---------------------------------------------------------------
# Group: nx-east Description : eastern region NX alerts
---------------------------------------------------------------
# Rule Statements
---------------------------------------------------------------
#1 Comment: major and critical malware-object alerts
Match Alert Tag: malware-object
Not Match Alert Severity: minor
#2 Match Alert Source IP: 172.1.2.0/24
cm-04 (config) # show aaa authorization access-groups rules

---------------------------------------------------------------
---------------------------------------------------------------
# Rule Statements
---------------------------------------------------------------
#1 Match LDAP Group : intel
Grant Access Groups : nx-east
#2 Match LDAP Group : intel-east

Grant Access Groups : nx-east
© 2021 FireEye 197

System Security Guide CHAPTER 10: Configuring Access Groups for YARA Rules
CHAPTER 10: Configuring Access

Groups for YARA Rules
As an administrator, you can use access groups to enable users with analyst and monitor
roles to modify and delete YARA roles in the Network Security appliance. By default, these
users have read-only privilege.
Users that you add to this access group can upload and delete YARA rules in addition to
the privileges assigned to their role.
Follow the below steps to authorize the access group users to modify the YARA rules:
1. Enable the yara_rules area for access groups. See Enabling and Disabling Access
Groups for YARA Rules below.
2. Create an access group. See Creating Access Groups for YARA Rules on page 200.
3. Authorize the group with the access group command option match-yara-rules-
access.
The match-yara-rules-access command option authorizes users of an

access group to modify and delete YARA rules.
See Defining Access Group Rules for YARA Settings on page 201.

4. Add the users required to the access group to let them modify and delete YARA
rules. See Adding a User to the YARA Rules Access Group on page 203
Enabling and Disabling Access Groups for

YARA Rules
The access groups for YARA rules feature is disabled by default. Enable it using the
Network Security appliance CLI.
If you disable access groups for YARA rules, configured access groups are not removed but
have no effect.
Prerequisites
l Admin access to the Network Security appliance
198 © 2021 FireEye

Release 2021.1 Enabling and Disabling Access Groups for YARA Rules
Enabling Access Groups for YARA Rules Using the CLI

Use the commands in this topic to enable the use of access groups for YARA rules access.
To enable access groups for YARA rules:
1. Log in to the Network Security appliance.

hostname > enable
3. Enable the access group for YARA rules feature:

hostname (config) # aaa authorization access-groups area yara_rules
enable
4. If prompted to confirm your action, enter YES.

hostname (config) # show aaa authorization access-groups

Example
The following example enables access groups for YARA rules access on theNetwork
Security appliance.
hostname (config) # aaa authorization access-groups area yara_rules enable
AAA Access-groups enabled for : yara_rules

No Access groups configured.
Disabling Access Groups for Alerts Using the CLI

Use the commands in this topic to disable the use of access groups for YARA rules access.
To disable access groups for YARA rules:

hostname > enable
© 2021 FireEye 199

3. Disable the access group for YARA rules feature:

hostname (config) # no aaa authorization access-groups yara_rules
alerts enable


Example
The following example disables access groups for alerts on the Network Security appliance.
The nx-alerts access group is not removed, but has no effect unless access groups for alerts
are re-enabled.
hostname (config) # no aaa authorization access-groups area yara_rules enable
AAA Access-groups enabled for : none
No Access groups configured.
Creating Access Groups for YARA Rules

You must create access groups before you can use them in access group rules. Specify the
access group name in the Network Security appliance CLI to create it.
Prerequisites
l Admin access to the Network Security CLI.
Creating Access Groups for YARA Rules Using the CLI

Use the commands in this topic to create an access group for YARA rules access.
To create an access group:
1. Log in to the Network Security CLI.

hostname > enable
200 © 2021 FireEye

Release 2021.1 Defining Access Group Rules for YARA Settings
3. Create the access group:

name> [description "<description>"]
where:
l description is optional information about the access group. Enclose the

description in double quotation marks if it includes more than one word.
hostname (config) # show aaa authorization groups group <access group
name>

Example
The following example creates the "special-analysts" access group on the Network Security
appliance.
hostname (config) # aaa authorization access-groups group special-analysts
hostname (config) # show aaa authorization access-groups group special-
analysts
-----------------------------------------------------
# Group: special-analysts
-----------------------------------------------------
No Rules Configured
Defining Access Group Rules for YARA

Settings
Authorize an access group to modify and delete YARA rules in the Network Security
appliance CLI.
The match-yara-rules-access command option authorizes users of an access

group to modify and delete YARA rules.
The rule will match the access rights to YARA rules for users that are part of the access
group.
For more information on defining access group rules, see Defining Rules on page 177.
© 2021 FireEye 201

Prerequisites
Defining Access Group Rules for YARA Settings Using the

CLI
Use the commands in this topic to authorize an access group to modify YARA rules.
To define the access group rule:

hostname > enable
3. Define the rule:

name> rules rule append tail match-yara-rules-access]
where:

hostname (config) # show aaa authorization access-groups group <access
group name>

Example
The following example enables the access group "special-analysts" to modify and delete
YARA rules.
hostname (config) # aaa authorization access-groups group special-analysts
rules rule append tail match-yara-rules-access
hostname (config) # show aaa authorization access-groups group special-
analysts
------------------------------------------------
# Group: special-analysts
------------------------------------------------
# Rule Statements
------------------------------------------------
#1
Match YARA rules access
202 © 2021 FireEye

Release 2021.1 Adding a User to the YARA Rules Access Group
Adding a User to the YARA Rules Access

Group
After an access group is authorized to modify YARA rules, add monitor and analyst users
to the group. You are required to specify the user name and access group in the Network
Security appliance CLI.
Prerequisites
l YARA rules access is granted to the access group.
Adding a User to the YARA Rules Access Group Using the

CLI
Use the commands in this topic to add a user to the YARA rules access group.
To add a user to the access group:

hostname > enable
3. Add a user to the access group:

hostname (config) # aaa authorization access-groups rules rule append
tail grant-access-group <access group name> match-mapped-local-username
<user name>
where:
l user name is the name of the analyst or monitor user.

hostname (config) # show aaa authorization access-groups rules

© 2021 FireEye 203

Example
The following example adds the user "analyst_a" to the "special-analysts" access group on
the Network Security appliance.
hostname (config) # aaa authorization access-groups rules rule append tail
grant-access-group special_analysts match-mapped-local-username analyst_a
hostname (config) # show aaa authorization access-groups rules
--------------------------------------------------------------
--------------------------------------------------------------
# Rule Statements
--------------------------------------------------------------
# 1
Match Map Local Users : analyst_a
Grant Access Groups : special_analysts
204 © 2021 FireEye

Release 2021.1
PART IV: Accounting
l Accounting on page 207
© 2021 FireEye 205

System Security Guide PART IV: Accounting
206 © 2021 FireEye

CHAPTER 11: Accounting

Accounting tracks user activities and resource usage. All user activities that affect the
system, such as configuration changes, are written to an audit log. Audit log messages can
be viewed by issuing the show log audit command, and indicate the following:
l Which user made the change (login and logout details, including the origin,
authentication method, and role).
l Authentication failures and lockouts.
l The interface used to make the change: Command Line Interface (CLI), Web UI,
Serial Console, or LCD Panel Interface.
l The change that was made.
l The date and time the change was made.
l The session ID used to initiate the change. The session ID persists for the duration of
the session, which starts when the user logs in and ends when the user logs out.
Audit log messages are also logged to the system log. The audit log messages in this log
are prefixed with AUDIT: and tagged as described in the following table so you can quickly
locate them.
Message Type Tag
Configuration changes Config change ID
Other actions Action ID
User login User login
User logout User logout
Authentication failure Authentication failure
User account lockout Maximum number of failed logins reached, account

locked
Authorization failure Denying access to
© 2021 FireEye 207

System Security Guide CHAPTER 11: Accounting
Message Type Tag
Execution of CLI Executing command: ...

commands
Miscellaneous Boot manager password changed

Time change detected, clock was moved...
See Managing Audit Logs Using the CLI on the facing page for information about
configuring and viewing audit logs.
NOTE: You can use the aaa accounting CLI command to send audit messages
to TACACS+ servers.
208 © 2021 FireEye

Release 2021.1 Managing Audit Logs Using the CLI
Managing Audit Logs Using the CLI

All user activities that impact the system, such as configuration changes, are automatically
written to a log.
Prerequisites
l Admin access
To manage audit logs:
hostname > enable
2. Display the active audit log file, a list of all audit log files, an archived audit log file,
or selected entries in the active audit log:
hostname (config) # show log audit
3. Enable the override of the global minimum severity level of audit log messages
saved in log files on the local disk:
hostname (config) # logging local override class audit
4. Enable the global minimum severity level of the audit log messages with the
specified severity level:
hostname (config) # logging local override class audit priority
<severityLevel>
You can select the following severity levels:

l none—Disables logging.
l emerg—System failure.
l alert—Immediate action required.
l crit—Critical condition.
l err—Error condition.
l warning—Warning of possible problem.
l notice—Significant, but normal event (the default).
l info—Information only.
l debug—Debugging information.
© 2021 FireEye 209

System Security Guide CHAPTER 11: Accounting
5. Upload the active audit log file to the specified network location:
hostname (config) # logging files audit upload current <path>

210 © 2021 FireEye

Release 2021.1
PART V: Certificates
l Certificate Management on page 213

l Managing HTTPS and MTA Certificates on page 215
l Managing CA Certificates on page 245
l Improving Certificate Security on page 267
l Renaming a Certificate on page 277
© 2021 FireEye 211

System Security Guide PART V: Certificates
212 © 2021 FireEye

System Security Guide The VX Series Appliance
CHAPTER 12: Certificate

Management
FireEye appliances use X.509 (TLS/SSL) certificates to allow secure connections between the
appliance and the Web browser running the Web UI, and to verify remote servers for
various client applications. They also use the certificates to encrypt the emails they forward
to a downstream MTA on the Email Security — Server Edition appliance. They also use
the certificates to secure the connection to a WebDAV server on the File Protect appliance.
The VX Series Appliance

The Virtual Execution appliance has a CLI, but does not have a Web UI. A message such
as the following is displayed when you attempt to access the Virtual Execution appliance
using a Web browser. The provided system self-signed certificate secures the Web session
that displays this message. Information about replacing this certificate with an HTTPS
certificate and adding a Web server chain are included in this guide, although there is little
practical reason to do so.
© 2021 FireEye 213

System Security Guide CHAPTER 12: Certificate Management
System Self-Signed Server Certificate

The appliance automatically generates and maintains a self-signed server certificate with
the reserved name system-self-signed. This is the default certificate for the appliance, and
can be used for Web UI sessions and MTA email forwarding. The appliance hostname is
used in the certificate's Common Name (CN) attribute. If the hostname or other pertinent
system identity information changes, the certificate is automatically regenerated to reflect
the current information. For details, see Regenerating the System Self-Signed Certificate on
page 225.
HTTPS and MTA Server Certificates

Instead of using the system self-signed certificate, you can install an alternate HTTPS or
MTA certificate, such as one issued by a trusted public certificate authority (CA) or your
own organization. The HTTPS certificate has the reserved name web-cert. The MTA
certificate has the reserved name mta-cert. This certificate is not tied to the appliance
hostname. For details, see Managing HTTPS and MTA Certificates on page 215.
Web Server CA Certificate Chains

You can add a certificate chain to an Apache Web server. This establishes a chain of trust
for a server SSL certificate by providing signing CA certificates to the Web browsers
running the Web UI. For example, if the root CA is present on the Web browser, but the
intermediate CAs are absent, the CA chain allows the Web browsers to find the
intermediate CAs, which would otherwise not be possible. For details, see Configuring a
Web Server CA Certificate Chain on page 256.
Certificate Authority (CA) Client

Certificates
The appliance has an internal bundle of well-known trusted CA certificates distributed by
Mozilla. These certificates serve as root CA certificates for HTTP servers that have publicly
issued certificates. However, some SSL-enabled applications (such as the system email
server and the LDAP server) connect to HTTPS servers that have privately issued
certificates. You must add one or more intermediate or trusted private root certificates as
supplemental CA certificates to validate against the private certificates on these servers.
For details, see Adding Supplemental CA Certificates on page 247.
214 © 2021 FireEye

CHAPTER 13: Managing HTTPS

and MTA Certificates
HTTPS certificates (also known as Web or server certificates) are named certificates that the
appliance uses to identify itself to the Web browsers running the Web UI, and to allow the
Web UI to accept HTTPS connections. MTA certificates are named certificates that allow
the appliance to identify itself and to encrypt the emails it forwards to the next-hop
downstream MTA.
MTA Certificates are only available on the Email Security — Server Edition
appliances.
The system self-signed certificate is the default active HTTPS certificate and the default
MTA certificate. You can configure an alternate certificate, which can be a certificate issued
by your own organization (also a self-signed certificate) or a certificate issued by a public
certificate authority (CA).
You can use the following methods to obtain and install a certificate:
l Upload both an existing certificate file and the matching private key file from your
local file system. (Web UI only)
l Enter the public and private key PEM strings at the command line. (CLI only)
l Create your own self-signed certificate. This process automatically generates an
internal matching private key that is paired with the certificate.
l Manually create a Certificate Signing Request (CSR) to obtain a server certificate
from a public certificate authority (CA). (See Obtaining a CA Certificate from a
Trusted Public Certificate Authority (CA) on page 245.)
l Use the Email Security — Server Edition Web UI to create a Certificate Signing
Request (CSR) to obtain an MTA certificate from a public certificate authority (CA).
This process automatically generates an internal matching private key that is paired
with the certificate when you import it, so do not explicitly import a private key
with the CA-provided certificate.
© 2021 FireEye 215

System Security Guide CHAPTER 13: Managing HTTPS and MTA Certificates
NOTE: The wae_proxy_cert and mvx-cloud-cert may be listed as HTTPS certificates.

These are auto-generated certificates used for internal purposes. They are not
appropriate for application to HTTPS.
Usage Guidelines
l Each appliance needs a unique HTTPS certificate and matching private key. The
MTA also needs an certificate and matching private key. The system self-signed
certificate serves as both the HTTPS and MTA certificate by default.
l The certificate and private key must be configured as a Privacy Enhanced Email
(PEM) encrypted ASCII string.
The PEM string must be formatted in the following order:
1. Double quotation marks
2. A new line
3. BEGIN delimiter string
4. ASCII block
5. END delimiter string
6. A new line
NOTE: You can press Enter in the CLI to add a new line.
If a comment is added, it must follow the final double quotation marks and be on
the same line. Any commentary outside the BEGIN and END delimiter strings is
ignored.
The following is an example PEM string (with a truncated ASCII block):
>"
>>----BEGIN CERTIFICATE-----
>MIIEujCCA6KgAwIBAgIJAI/1cFcdOeykMA0GCSqGSIb3DQEBBQ
>UAMIGZMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
>YTERMA8GA1UEBxMITWlscGl0YXMTJDE3GDS9DYEDLO9EWS6Fx=
>.
>.
>.
>----END CERTIFICATE-----
>
>"
l The active HTTPS certificate uses the reserved name web-cert. The active MTA
certificate uses the reserved name mta-cert.
216 © 2021 FireEye

Release 2021.1 Viewing Certificates
l You cannot add a new web-cert or mta-cert certificate if one already exists. You
must delete or rename the existing certificate first.
l After you add the new certificate, you must explicitly activate it for the Web server
or MTA.
l The HTTPS certificate you import or create can have a unique name, but it must be
renamed to "web-cert" before you can activate it.
l The MTA certificate you import or create can have a unique name, but must be
renamed to "mta-cert" before you can activate it.
l The certificate section of the show configuration CLI command output indicates
whether a private key is defined for each certificate. Private key PEM strings are
omitted.
l If a private key has a passphrase, the key must be converted to an unlocked private
key PEM string before it can be imported.
Prerequisites
l Operator or Admin access
Viewing Certificates
The appliance provides a simple way to view the following:
l Common certificate attributes, such as the name, status, and expiration date
l All certificate attributes, which include the signature and public key algorithms in
addition to the common attributes
l Certificate configuration (CLI only)
l Public key PEM string of a certificate (CLI only)
NOTE: See the table in Common Attributes of X.509 Certificates on page 273 for

certificate attribute descriptions.
NOTE: The Web UI also displays the public key of the appliance. This key is
used to authenticate the connection between a Central Management appliance
and its managed appliances. For details, see Obtaining a Host Key Using the
Web UI on page 126.
Prerequisites
l Monitor, Operator, or Admin access
© 2021 FireEye 217

Viewing Certificates Using the Web UI

Use the Certificate Management page to view certificates.
For information about managing certificates, see following topics:
l Regenerating the System Self-Signed Certificate Using the Web UI on page 225

l Managing HTTPS Certificates Using the Web UI on page 227
l Managing MTA Certificates Using the Web UI on page 235
l Activating Named Certificates Using the Web UI on page 240
l Configuring a Web Server CA Certificate Chain on page 256
l Adding Supplemental CA Certificates Using the Web UI on page 248
NOTE: The Keys section at the bottom of the page pertains to Secure Shell (SSH)
host key authentication. For details, see Obtaining a Host Key Using the Web UI
on page 126.
To view certificates:
1. Log in to the managing Central Management Web UI.

218 © 2021 FireEye

3. Select Appliance Settings from the Admin menu.
4. Click the Appliance Settings subtab.
5. Use the Groups drop-down list to select a VX Series appliance or MVX cluster

group.
By default, all appliances in the group are selected, and the page shows the settings
for the first appliance in the group only.
6. (Optional) Use the Appliance drop-down list to select a specific VX Series appliance.

The "Showing" field shows the name of the selected appliance.
If you want the changes you make to the current appliance to be automatically
applied to all other appliances in the group, select the Write changes to group
checkbox.
7. Click Certificates/Keys on the sidebar.

8. View common certificate attributes in any section on the page:
l System Self-Signed Certificate
l HTTPS Configuration
l MTA Certificate Configuration
l CA Certificates
9. Click the link in the Certificate column to view all certificate attributes in a separate
browser window.
Example
The following example shows the attributes of a system self-signed certificate.
After you click system-self-signed, the following window opens. Scroll down to view all of
the data.
© 2021 FireEye 219

NOTE: In this example, the https in the address bar is crossed out because self-
signed certificates are not typically included in the trusted root of the browser.
NOTE: These examples are from an Email Security — Server Edition appliance,

but they are representative of other appliances as well.
Viewing Certificates Using the CLI

Use the commands in this section to view certificate attributes, the certificate configuration,
and the public key PEM string.
Viewing Common Attributes

To view common certificate attributes:

hostname > enable
2. Display the attributes.

l To view common information about all certificates:
hostname # show crypto certificate
l To view common attributes for a specific certificate:

hostname # show crypto certificate name <certificateName>
220 © 2021 FireEye

Viewing All Attributes

To view all certificate attributes:

hostname > enable
2. Show the attributes.

l To view all attributes for all certificates:
hostname # show crypto certificate detail
l To view all attributes for a specific certificate:

hostname # show crypto certificate name <certificateName> detail
Viewing the Certificate Configuration

To view the certificate configuration:

hostname > enable
2. Show the configuration:

hostname # show configuration
3. Scroll to the X.509 certificates configuration section of the output.
NOTE: The command output indicates whether a private key is defined for each
certificate. Private key PEM strings are omitted for security.
Viewing the Public Key PEM String

To view the public key PEM string:

hostname > enable
2. Show the public key PEM string.

l To view the source data for all certificates:
hostname # show crypto certificate public-pem
l To view the source data for a specific certificate:

hostname # show crypto certificate name <certificateName> public-
pem
Examples
Common Attributes for All Certificates
© 2021 FireEye 221

The following example shows common attributes for all certificates in the certificate
database.
hostname # show crypto certificate
Certificate with name 'server' (default-cert)
Private Key: present
Serial Number: 0x71a676d9a1j5d8a316488f9d683kkc0
SHA-1 Fingerprint: 7g04933d77491wgeg2h78d2a6f34s50cech324c78
Validity:
Starts: 2015/02/26 15:40:47
Expires: 2017/11/21 15:40:47
Issuer:
Common Name: acme-hostname
Country: US
State or Province: NY
Locality: Albany
Organization: Acme, Inc
Organizational Unit: IT
Issuer:
Common Name: Symantec Class 3 EV SSLCA - G3
Country: US
Locality: Mountain View
Organization: Symantec Corporation
Organizational Unit: Symantec Trust Network
Certificate with name 'system-self-signed'
Serial Number: 0x54a623d9a1f5d7a207788f2e683ffc0
SHA-1 Fingerprint: 7k04833m77951wgjr2h94d2a6f34b60pgph984v43
Validity:
Starts: 2015/04/22 15:40:47
Expires: 2016/04/21 15:40:47
Subject:
Country: US
Locality: Milpitas
Organization: FireEye, Inc.
Organizational Unit: Network Security Management
Issuer:
Country: US
Locality: Milpitas
All Attributes for a Specific Certificate

The following example shows all attributes for the system self-signed certificate.
hostname # show crypto certificate name system-self-signed detail
Certificate with name 'system-self-signed' (default-cert)
Comment: system-generated self-signed certificate
Serial Number: 0x54a623d9a1f5d7a207788f2e683ffc0
SHA-1 Fingerprint: 7k04833m77951wgjr2h94d2a6f34b60pgph984v43
Version: 3
Subject Public Key Algorithm: rsaEncryption
222 © 2021 FireEye

Subject Public Key Length: 2048 bits

Signature algorithm: sha256WithRSAEncryption
Validity:
Starts: 2015/04/22 15:40:47
Expires: 2016/04/21 15:40:47
Subject: emailAddress=admin,CN=acme-hostname,OU=Network Security
Management,O=FireEye\, Incl,L=Milpitas,ST=California,C=US
Country: US
Locality: Milpitas
E-mail Address: admin
Issuer: emailAddress=admin,acme-hostname,OU=Network Security
Management,O=FireEye\, Incl,L=Milpitas,ST=California,C=US
Country: US
Locality: Milpitas
E-mail Address: admin
Certificate Configuration
The following example shows the certificate configuration for an appliance.
hostname # show configuration
...
##
## X.509 certificates configuration
##
## Certificate name system-self-signed, ID
9c077abarhb9e10d698c98e03431bbba410965b8
## (public-cert config omitted since private-key config is hidden)
crypto certificate min-key-size 2048
crypto certificate secure-hashes-only
##
Public Key PEM String

The following example shows the public key PEM string for the "server" certificate.
hostname # show crypto certificate name server public-pem
-----BEGIN CERTIFICATE-----
MIIDuzCCAqOgAwIBAgIBADANBgkqhkiG9w0BAQUFADB4MQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCQ0ExETAPBgNVBAcMCE1pbGlwdGFzMRQwEgYDVQQKDAtGaXJlRXll
IEluYzEUMBIGA1UECwwLRW5naW5lZXJpbmcxHTAbBgNVBAMMFHZwczEuZW5nLmZp
cmVleWUuY29tMB4XDTE1MDIyNjIzNDA0N1oXDTE3MTEyMTIzNDA0N1oweDELMAkG
A1UEBhMCVVMxCzAJBgNVBAgMAkNBMREwDwYDVQQHDAhNaWxpcHRhczEUMBIGA1UE
CgwLRmlyZUV5ZSBJbmMxFDASBgNVBAsMC0VuZ2luZWVyaW5nMR0wGwYDVQQDDBR2
cHMxLmVuZy5maXJlZXllLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJt3LsgIYXyWiaRoAsLJnSxbQdwLuRZV74qEpVv1cRAwxymVu4/iXSWTFYmU
OZGFeHKK/2R/twISBHBhCuoGUYirg0KiM7bWmFPdAJXID6cAhPghkHwLHPTF4+Po
rXfc2m0W24G1Hi0o10oY7TPe2R5HctwGaoVtQ3znzESsuXKl+8qF+UVaP6qliDeX
Qyc9h/rGLQE50+9jluq1sWHfhszi4ireTqTu18iZesOeWSW+XzVcPRFy8pxwRMoW
w52Eczz2tZNudw2Bnozx25xlOIUvMLvrWeSenonqnrnQBPAtm7g/kBmSE4eHX7cr
D6KxczmuCvAfIZLZBibM2Vu6slUCAwEAAaNQME4wHQYDVR0OBBYEFMT6ayAuFjvN
7yVCVXMQX8Pgd3YtMB8GA1UdIwQYMBaAFMT6ayAuFjvN7yVCVXMQX8Pgd3YtMAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAHTmrw4j6s0ut72n8P1pzGuD
© 2021 FireEye 223

6OYnuufKkHDaCC58g7OMMeOMu11XWScCy/44q2WMs1oNhKrcQHivHilKrAXB8Str
a2bSHcWutnu1OamRmglrkFmhS10NrNUIu5OwluTO3QF7FxA1EBwqEJ/8YrKhQb4p
aL4b0xRuNleRmy4GnR/k3a7Jllf9/qnpXYWIdtkyHOqx/854wxsdOiZYU9U1ZYEe
4Es9hEk5pkRvnioS0lJZWTGmt9a0EjpgZXIMcSxukeyZ4UPKaie8gypIPtK+ia9e
vXwAvTn745uZs06piroFhIOkPkG1H4pahgdi4uPntSosmHI63i0bc9VnN7QK0Rg=
-----END CERTIFICATE-----
224 © 2021 FireEye

Regenerating the System Self-Signed Certificate

The appliance automatically generates and maintains a self-signed server certificate with
the reserved name system-self-signed. This is the global default certificate for the appliance.
It can be used for Web UI sessions and on the Email Security — Server Edition appliance,
MTA email forwarding as well. You cannot delete this certificate, because it ensures secure
access to the appliance Web UI and other applications in the factory default configuration.
If an alternate HTTPS or MTA certificate is designated as the active certificate and is later
deleted, the system self-signed-certificate is automatically restored as the active certificate.
The appliance hostname is the Common Name (CN) attribute for the system self-signed
certificate. The certificate is automatically regenerated if the hostname changes. You can
regenerate the certificate on demand to extend the expiration date, or to get updated default
certificate attributes (such as the organization or email address).
The certificate is valid for one year. If you use the Web UI to regenerate the certificate, the
expiration date is extended by 365 days (or the number of days defined for the "time
remaining" default attribute). You can specify a non-default number of days if you use the
CLI to regenerate the certificate.
IMPORTANT! Self-signed certificates are not included in the trusted root of

many browsers, because they are not issued by a trusted certificate authority.
Security warnings could be displayed to users when they navigate to the
appliance Web UI. To prevent the warning from appearing again, the Web UI
user can add the certificate to the browser's trusted root.
Prerequisites
Regenerating the System Self-Signed Certificate Using the Web

UI
Use the Certificate Management page to manually regenerate the system self-signed
certificate.
NOTE: You can also download the certificate to your local file system, but there is
typically no reason to do so.
© 2021 FireEye 225

NOTE: This example is from an Email Security — Server Edition appliance, but it

is representative of other appliances as well.
To regenerate the system self-signed certificate:
1. Click the Settings tab on all appliances except the HX Series. On the HX Series
appliance, select Appliance Settings from the Admin menu.
2. Click Regenerate.
3. When prompted, click OK to confirm that you want to regenerate the certificate.
4. Confirm that the certificate was regenerated:
l The Time Remaining changes to 365 days, and the Expire Date changes
accordingly.
l A message at the top of the page informs you that the regeneration was
successful.
To download the system self-signed certificate:
1. Click Export.
2. Verify that the system-self-signed.crt file was downloaded to your computer.
Regenerating the System Self-Signed Certificate Using the CLI

Use the commands in this section to regenerate the system self-signed certificate.
IMPORTANT! If the Web server is configured to use the system self-signed

certificate, the web server certificate regenerate command will also
regenerate and replace the system self-signed certificate.
To regenerate the system self-signed certificate:

hostname > enable
226 © 2021 FireEye

Release 2021.1 Managing HTTPS Certificates Using the Web UI
2. Regenerate the certificate:

l To extend the expiration date by 365 days:
hostname (config) # crypto certificate system-self-signed
regenerate
l To extend the expiration date by a different number of days:

hostname (config) # crypto certificate system-self-signed days-
valid <days>

hostname (config) # show crypto certificate name system-self-signed

Example
The following example regenerates the system self-signed certificate and extends the
expiration date by two years.
hostname (config) # crypto certificate system-self-signed regenerate days-
valid 730
hostname (config) # show crypto certificate name system-self-signed
Certificate with name 'system-self-signed'
Comment: system-generated self-signed certificate
SHA-1 Fingerprint: 7g04933d77491wgeg2h78d2a6f34s50cech324c78
Validity:
Starts: 2015/04/25 20:32:50
Expires: 2017/04/22 20:32:50
...
Managing HTTPS Certificates Using the

Web UI
Use the HTTPS Configuration section of the Certificate Management page to do the
following:
l Import the public and private keys for an HTTPS certificate.

l Activate the certificate.
l Export the public key.
© 2021 FireEye 227

NOTE: This example if from an Network Security appliance, but it is

representative of other appliances as well.
Importing an HTTPS Certificate

IMPORTANT! You must select both the public and private key before you click
Update to add the certificate to the certificate database.
To import an HTTPS certificate:
1. Log in to the Central Management Web UI.

3. Select Appliance Settings from the Admin menu.
4. Click the Appliance Settings subtab.
5. Use the Groups drop-down list to select a VX Series appliance or MVX cluster

group.
By default, all appliances in the group are selected, and the page shows the settings
for the first appliance in the group only.
6. (Optional) Use the Appliance drop-down list to select a specific VX Series appliance.

The "Showing" field shows the name of the selected appliance.
If you want the changes you make to the current appliance to be automatically
applied to all other appliances in the group, select the Write changes to group
checkbox.
228 © 2021 FireEye

Release 2021.1 Managing Named Certificates Using the CLI
7. Click Certificates/Keys in the sidebar.

8. Select the certificate public key:
a. Click Choose File in the Certificate field.
b. In the dialog box that opens, navigate to the certificate .pem file in your local
file system.
9. Select the private key:
a. Click Choose File in the Private Key field.
b. In the dialog box that opens, navigate to the private key .pem file in your
local file system.
10. (Optional) Enter a certificate name in the Cert name field.
IMPORTANT! The certificate name must be changed to web-cert before

you can activate it.
11. If you want to activate the certificate, select the After import, activate checkbox.
NOTE: The certificate can be activated later, if you prefer. For details, see
Activating Named Certificates on page 240.
12. Click Update.
Exporting an HTTPS Certificate

NOTE: Because private keys are sensitive, you can export only the public key.
To export the public key:
1. Click the Settings tab on all appliances except the HX Series. On the HX Series,
select Appliance Settings from the Admin menu.

3. Click Export in the Actions column for the HTTPS certificate.
4. Verify that the .crt file was downloaded to your local file system.
Managing Named Certificates Using the

CLI
Use the commands in this section to do the following:
© 2021 FireEye 229

l Import an HTTPS or MTA certificate.
NOTE: You can also download the certificate, as described in

Downloading a Certificate Using the CLI on page 239.
l Generate and regenerate an HTTPS or MTA self-signed certificate.

IMPORTANT! If the certificate you import or generate will be used on the Web
server, you must specify "web-cert" as the certificate name, and then activate the
certificate as described in Activating Named Certificates on page 240. Likewise,
if the certificate will be used on the MTA, you must specify "mta-cert" as the
certificate name, and then activate the certificate.
Importing a Certificate
IMPORTANT! Do not add a private key for an MTA certificate if the certificate
was obtained using a CSR generated from the Certificate Management page in
the Web UI.
To import a certificate and private key:

hostname > enable
2. Import the certificate:

hostname (config) # crypto certificate name <certificateName> public-
cert pem "<pemString>" [comment "<comment>"]
where:
l <certificateName> can be a name of your choice, but must be changed to
"web-cert" or "mta-cert" before it can be activated.
l <pemString> is the public certificate PEM string.
l <comment> is the text for the comment.
IMPORTANT! The PEM string and comment must be formatted as

described in Usage Guidelines on page 216.
230 © 2021 FireEye

3. Import the private key:

l To add the private key directly:
hostname (config) # crypto certificate name <certificateName>
private-key pem "<pemString>"
where <pemString> is the private key PEM string, formatted as described in

Usage Guidelines on page 216.
l To prompt for the private key with secure echo, so asterisks are displayed
instead of the PEM string characters:
prompt-private-key

hostname (config) # show crypto certificate

Creating a Self-Signed HTTPS or MTA Certificate

NOTE: If you do not supply attribute values when you create the self-signed
certificate, the default attribute values will be used.
To create a self-signed HTTPS or MTA certificate:

hostname > enable
© 2021 FireEye 231

2. Create the certificate:

l To use default attribute values:
generate self-signed
where <certificateName> can be a name of your choice, but must be

changed to "web-cert" or "mta-cert" before it can be activated on the Web
server or MTA.
l To use other attribute values:
generate self-signed [<attribute_1> <value>] [<attribute_2>
<value>]...[<attribute_n> <value>]]]
where:
l <certificateName> can be a name of your choice, but must be
changed to "web-cert" or "mta-cert" before it can be activated on the
Web server or MTA.
l <attribute_1>, <attribute_2>, and <attribute_n> are attribute
names, and <value> is the value of the specified attribute. For
descriptions of the attributes and values, see Defining Default
Certificate Attributes on page 273.
Regenerating the Self-Signed HTTPS or MTA Certificate

Regenerating the self-signed certificate regenerates both the public and private keys. It
extends the expiration date by 365 days or the number of days you specify, and gets any
updated default attribute values.
To regenerate the HTTPS or MTA self-signed certificate:

hostname > enable
2. Regenerate the HTTPS certificate:

hostname (config) # crypto certificate name web-cert regenerate [days-
valid <days>]
where <days> is the number of days before the certificate expires. If the days-valid
parameter is not included, the default attribute value is used.
232 © 2021 FireEye

3. (On the Email Security — Server Edition Appliance Only) Regenerate the MTA
certificate:
hostname (config) # crypto certificate name mta-cert regenerate[days-
valid <days>]
where <days> is the number of days before the certificate expires. If the days-valid
parameter is not included, the default attribute value is used.
hostname (config) # show crypto certificate name web-cert
hostname (config) # show crypto certificate name mta-cert

Displaying the Public Key for Export

You can copy the public key PEM string and then paste it into a text file that you can
distribute.
NOTE: Because private keys are sensitive, you can export only the public key.
To display the public key PEM string for export:

hostname > enable
2. Display the public key PEM string:

hostname # show crypto certificate name <certificateName> public-pem
Examples
Importing a Certificate and Key
The following example imports a certificate and its private key.
hostname (config) # crypto certificate name acme.cert3.pem public-cert pem "
>
> -----BEGIN CERTIFICATE-----
> MIID2jJUAsKgAwIBAgIBBjANBgkqhkiG8g0BAQUFADCBsDELMAkGA1UEBhMCVVMx
> FjAUBgNVBAgTNT1hc3NhY2h1c2V0dHMxFDASBgNVBAcTC1dlc3Rib3JvdWdoMRsw
> GQYDVQQKExJUYWxsIE1hcGxlIFN5c3RlbXMxEDAOBgNVBAsTB3Rtkq1lbmcxHjAc
> BgNVBAMTFW9jdGFnb24udGFsbG1hcGxlLmNvbTEkMCIGCSqGSIb3DQEJARYVc2xh
.
.
.
> -----END CERTIFICATE-----
>
> "
Successfully installed certificate with name 'acme.cert3.pem'
© 2021 FireEye 233

hostname (config) # crypto certificate name acme.cert3.pem private-key pem "

>
> -----BEGIN RSA PRIVATE KEY-----
> MIICGTCCAYICAQAwgawxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNl
> dHRzMRQwEgYDVQQHEwtXZXN0Ym9mi3VnaDEbMBkGA1UEChMSVGFsbCBNYXBsZSBT
> eXN0ZW1zMRAwDgYDVMGLEwd0bXMtZW5nMRowGAYDVQQDExF0YjcudGFsbG1hcGxl
> LmNvbTEkMCIGCSqGSIb3DQEJARYVc2xhbnNlckB0YWrebWFwbGUuY29tMIGfMA0G
.
.
.
> -----END RSA PRIVATE KEY-----
>
> "
Creating a Self-Signed Certificate

The following example generates an HTTPS self-signed certificate:
hostname (config) # crypto certificate name acme.selfcert5.pem generate self-
signed
Successfully generated certificate with name 'acme.selfcert5.pem'
Regenerating the Certificate

The following example regenerates the HTTPS self-signed certificate and its private key
and extends the expiration date by two years.
hostname (config) # crypto certificate name web-cert regenerate days-valid
730
Successfully regenerated certificate with name 'web-cert'
hostname # show crypto certificate name web-cert
Certificate with name 'web-cert'
SHA-1 Fingerprint: 7g04933d77491wgba2h78d2a6f34s50cech324c78
Validity:
Starts: 2015/04/25 20:32:50
Expires: 2017/04/22 20:32:50
.
.
Exporting the Public Key PEM String

The following example displays the public key PEM string.
hostname # show crypto certificate name acme-cert12 public-pem
> jjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEDAOBgNVBAcMB1Nh
> HzAdBgkqhkiG9w0BCQEWEGZlYWRtaW5AYWNtZS5jb20wggEiMA0GCSqGSIb3DQEB
> s0KvSMHO/8o0is/2wOuTQ/SF1gnBGZtPWWV0CUOZGHNt9ftAh6RLLvvvVnbguwc7
> HhcNMTUwNDI3MDIzODU2WhcNMTYwNDI2MDIzODU2WjCBjjELMAkGA1UEBhMCVVMx
> .
> .
> -----END CERTIFICATE-----
234 © 2021 FireEye

Release 2021.1 Managing MTA Certificates Using the Web UI
Managing MTA Certificates Using the

Web UI
Use the MTA Certificate Configuration section of the Certificate Management page to do
the following:
l Import the public and private keys for an MTA certificate.

l Create a self-signed MTA certificate.
l Create a Certificate Signing Request (CSR) to obtain a certificate from a certificate
authority (CA).
l Restore the system self-signed certificate as the active MTA certificate.
Importing an MTA Certificate

To import an MTA certificate:

3. Click Import Certificate.
© 2021 FireEye 235

4. Import the certificate:

a. Click Choose File.
b. In the dialog box that opens, navigate to the certificate .pem file in your local
file system.
NOTE: This could be an existing certificate file, or a certificate file
obtained through a CSR. (For details, see Using a Certificate Signing
Request (CSR) to Obtain an MTA Certificate on the facing page.)
c. If you imported an existing certificate file, proceed to the next step. Otherwise,
proceed to step 6.
5. If the certificate you just imported already existed (that is, it was not obtained from a
CSR as described in the previous step), import the matching private key:
a. Click Choose File.
b. In the dialog box that opens, navigate to the private key .pem file in your
local file system.
6. Select the certificate you want to activate after it is imported.
NOTE: The certificate can be activated later, if you prefer. For details, see
Activating Named Certificates on page 240.
7. Click Commit. The certificate is added to the certificate database with the name mta-
cert.
Creating a Self-Signed MTA Certificate

To create a self-signed MTA certificate:

236 © 2021 FireEye

Release 2021.1 Managing MTA Certificates Using the Web UI
3. Click Create Self-Signed Certificate.
4. Provide values for the attributes in the section that opens. For descriptions of the
attributes, see Defining Default Certificate Attributes on page 273.
5. Click Commit. The certificate is added to the certificate database with the name mta-
cert.
Using a Certificate Signing Request (CSR) to Obtain an

MTA Certificate
To use a CSR to obtain an MTA certificate:

3. Click Create Certificate Signing Request.
© 2021 FireEye 237

4. Provide values for the attributes in the section that opens. For descriptions of the
attributes, see Defining Default Certificate Attributes on page 273.
5. Click Commit.
6. Click Export Certificate Signing Request. A message at the top of the page informs
you that the export was successful.
7. Locate the mta-csr.crt file in your local file system, and send it to the certificate
authority (CA).
Tip: To view the CSR, click View Certificate Signing Request.
8. When you receive the certificate from the CA, import it as described in Importing an
MTA Certificate on page 235.
IMPORTANT! Do not import a private key, because the system already

generated one when you created the CSR.
Restoring the System Self-Signed Certificate as the

MTA Certificate
To restore the system self-signed certificate:

3. Click Restore Default.
Exporting an MTA Certificate

NOTE: Because private keys are sensitive, this procedure exports only the
certificate, not the private key.
To export an MTA certificate:

3. Click Export in the Actions column for the MTA certificate you want to export.
4. Verify that the .crt file was downloaded to your local file system.
238 © 2021 FireEye

Release 2021.1 Downloading Certificates
Downloading Certificates
You can download the public and private keys for a certificate from a URL to add the
certificate to the certificate database.
Prerequisites
Downloading a Certificate Using the CLI

Use the commands in this section to download the public and private keys for a certificate.
IMPORTANT! The private key is an optional parameter, but it must be

downloaded to activate the certificate for an application that requires a private
key.
To download a certificate:
hostname > enable
2. Specify the name for the certificate and download it:

hostname (config) # crypto certificate name <certName> fetch public-
cert-url <URL> [private-key-url <URL>] [comment "<comment>"]
where:
l URL is the direct path to the certificate or private key file.
l comment is a description of the certificate. It must be enclosed in double

quotation marks.
3. Verify that the certificate was added to the certificate database:
hostname (config) # show crypto certificate name <certificateName>

Example
This example downloads a certificate and private key, and adds it to the certificate
database with the name "newcert."
hostname (config) # crypto certificate name newcert fetch public-cert-url
http://acme/security/certs/acme.crt private-key-url
http://acme/security/certs/acme.key
© 2021 FireEye 239

hostname (config) # show crypto certificate name newcert

Certificate with name 'newcert'
Serial Number: 0x532gdda69e90b436542ea92e9gd5dor9
SHA-1 Fingerprint: 4563a957349g83264bw2c8b32c0rw5g8d8353246
.
.
.
Activating Named Certificates

The system self-signed-certificate is active on the Web server and Mail Transfer Agent
(MTA) by default. You can activate the web-cert certificate and mta-cert certificate instead.
Prerequisites
l Operator or Admin access.
l The named certificate is in the certificate database.
Activating Named Certificates Using the Web UI

Use the Certificate Management page to activate the web-cert certificate on the Web server,
and on the Email Security — Server Edition appliance to activate the mta-cert certificate on
the MTA.
NOTE: Perform this procedure only if the system self-signed certificate is

currently active on the Web server or MTA.
To activate the certificate on the Web server:
240 © 2021 FireEye

Release 2021.1 Activating Named Certificates
2. Click Certificates/Keys in the sidebar and locate the HTTPS Configuration section.
3. Click Activate in the Actions column for the web-cert certificate.

NOTE: To reactivate the system-self-signed certificate, click system-self-
signed in the list, or click Activate in the column for the system-self-signed
certificate.
To activate the certificate on the MTA:

2. Click Certificates/Keys in the sidebar and locate the MTA Certificate Configuration
section.
3. Click Activate in the Actions column for the mta-cert certificate.
NOTE: To reactivate the system-self-signed certificate, click system-self-signed in

the list, or click Activate in the column for the system-self-signed certificate.
Activating Named Certificates Using the CLI

Use the commands in this section to activate the web-cert certificate on the Web server, and
to activate the mta-cert certificate on the MTA.
© 2021 FireEye 241

NOTE: If you type web server certificate name ? at the command line, a list
of all certificates in the certificates database will be displayed. However, only the
"web-cert" or "system-self-signed" certificate can be activated. Likewise on the
Email Security — Server Edition appliance, if you type email-analysis mta
certificate name ? , a list of all certificates in the certificates database will be
displayed, but only the "mta-cert" or "system-self-signed" certificate can be
activated.
To activate the web-cert certificate on the Web server:

hostname > enable
2. Activate the certificate:

hostname (config) # web server certificate name web-cert

hostname (config) # show web

NOTE: To reactivate the system-self-signed certificate, use the no web server

certificate name or web server certificate name system-self-signed
command.
To activate the mta-cert certificate on the MTA:

hostname > enable
2. Activate the certificate:

hostname (config) # email-analysis mta certificate name mta-cert

hostname (config) # show email-analysis

NOTE: To reactivate the system-self-signed certificate, use the no email-

analysis mta certificate name or email-analysis mta certificate name
system-self-signed command.
242 © 2021 FireEye

Release 2021.1 Activating Named Certificates
Example
The following example activates web-cert on the Web server, which is currently using the
system self-signed certificate.
Web User Interface server:

Web interface enabled: yes
...
HTTPS certificate name: system-self-signed
...

....
HTTPS certificate name: web-cert
...
© 2021 FireEye 243

244 © 2021 FireEye

System Security Guide Obtaining a CA Certificate from a Trusted Public Certificate Authority (CA)
CHAPTER 14: Managing CA

Certificates
The following topics describe how to manage supplemental CA certificates and CA chains.
Obtaining a CA Certificate from a

Trusted Public Certificate Authority (CA)
This section describes how to obtain a CA certificate and CA bundle issued by a trusted
public certificate authority (CA).
l The CA certificate validates the ownership of the public key contained within the
certificate. The public key is used to establish trusted communication between the
appliance and the Web browsers running the Web UI, the Email Security — Server
Edition appliance and a downstream MTA, and the File Protect appliance and a
WebDAV server.
l The CA bundle includes the root and intermediate certificates between the holder of
the CA certificate and the public CA. This bundle constitutes the CA certificate's
chain of trust.
In this procedure, you generate three files:
l An encrypted private key used to decrypt your certificate.

l An unencrypted copy of the private key that you import into the appliance and then
delete. (You cannot import an encrypted private key into the appliance.)
l A Certificate Signing Request (CSR) used to request your certificate.
The example in this section creates a private 2048-bit key named fireeye.key that is
encrypted with DES3. OpenSSL is used to create the private key and the CSR.
© 2021 FireEye 245

System Security Guide CHAPTER 14: Managing CA Certificates
Prerequisites
l System with OpenSSL installed
To obtain a CA certificate:
1. Create a private key:

OpenSSL> genrsa -des3 -out fireeye.key 2048
When prompted, enter a passphrase you will remember, and then enter it again to
confirm it.
2. Create an unencrypted (unlocked) copy of the private key.
OpenSSL> rsa -in fireeye.key -out fireeye-unencrypted.key
When prompted, enter the passphrase you entered in the previous step.
3. Create the CSR:
OpenSSL> req -new -key fireeye.key -out fireeye.csr
or
OpenSSL> req -new -key fireeye-unencrypted.key -out fireeye.csr
If you entered the command with the encrypted key, enter the passphrase you
provided in the first step.
If you are using the Chrome browser, you need to add the Subject Alternative Name
and Alt Names to the new key. For example:
[v3_req]
basicConstraints = CA:FALSE
subjectAltName = @alt_names
[alt_names]
DNS.1 = dnstest.dns.local
DNS.2 = dnstest
246 © 2021 FireEye

Release 2021.1 Adding Supplemental CA Certificates
4. When prompted, provide information for the CSR:

l Country Name—Two-letter country code.
l State or Province Name—Full name, not an abbreviation.
l Locality Name—City where your organization is located.
l Organization Name—Name of your organization.
l Organizational Unit Name—Section or department in the organization.
l Common Name—Fully qualified domain name for the appliance (for
example, fireeye.acme.com). The domain must be accessible over the
Internet.
l Email address (optional)—Press Enter to skip.
l Challenge password—Do not provide. Press Enter to skip.
l Optional company name (optional)—Press Enter to skip.
5. Locate the fireeye.csr file in your local file system, and send it to the public CA.
6. Receive the following from the public CA:
l Signed CA certificate (saved as fireeye.cer)
l CA bundle
l Base-64 encoded copy of the root CA certificate
Be sure to delete the unencrypted copy of the private key after you import it into
the appliance.
Adding Supplemental CA Certificates

CA certificates (also known as peer certificates) are part of a chain of authority used to
verify a remote server or endpoint. SSL-enabled applications can consult the following to
find a suitable CA certificate:
l Public CA bundle: The appliance has an internal bundle of well-known trusted CA

certificates distributed by Mozilla. They serve as root CA certificates for
HTTP servers that have publicly issued certificates.
© 2021 FireEye 247

l Supplemental CA list: Some SSL-enabled applications connect to HTTPS servers

that have privately issued certificates. Examples may include the email server used
to send system event notifications, the LDAP server used to authenticate users, the
server used to transfer files, and the server used to post malware alert notifications.
You must add the trusted private root certificate and intermediate certificates (if
needed) as supplemental CA certificates to validate against the certificates on these
servers. Supplemental CA certificates are stored in the default CA list, which is
empty until supplemental CA certificates are added. The default CA list
supplements the well-known bundle; it does not replace it.
NOTE: A server with a publicly issued certificate could start using a new
certificate that is not yet part of the well-known bundle. In this case, you
must add the new certificate to the default CA list as a supplemental
certificate.
By default, most SSL-enabled applications refer to the well-known bundle first, and then
look for a certificate in the default CA list. You can configure some applications to use only
the well-known bundle. For details, see the email ssl ca-list, ldap ssl ca-list, and
web client ssl ca-list commands in the CLI Reference. An exception is malware event
notifications, where the appliance automatically refers to the default CA list to verify the
identity of the server to which it posts the notifications. Another exception is email
forwarding, where the Email Security — Server Edition appliance automatically refers to
the default CA list to verify the identity of the mail server to which it forwards the emails.
Prerequisites
Adding Supplemental CA Certificates Using the Web UI

Use the CA Certificates section of the Certificate Management page to add a
supplemental CA certificate to the default CA list.
248 © 2021 FireEye

To add a supplemental CA certificate:
appliance select Appliance Settings from the Admin menu.

3. In the "CA Certificates" section of the page, click Add Root/Intermediate
CA Certificate.
4. Click Choose File.

5. In the dialog box that opens, go to the certificate file in your local file system.
6. Click Commit.
Adding Supplemental CA Certificates Using the CLI

Use the commands in this section to add a certificate to the certificate database, and then
add it to the default CA list as a supplemental certificate.
NOTE: You can also download the certificate, as described in Downloading a

Certificate Using the CLI on page 239.
There are two ways you can import a CA certificate:
l Import a private key directly.

l Import a private key by entering it when prompted.
To add a supplemental CA certificate:

hostname > enable
© 2021 FireEye 249

2. Use the following command to import the supplemental certificate:

hostname (config) # crypto certificate name <certName> public-cert pem
"<pemString>" [comment "<comment>"]
The command parameters are defined as follows:

l <certName>—Unique certificate name; it cannot be the name of an existing
certificate in the certificate database.
l <pemString>—The public certificate PEM string.
l <comment>—An optional comment.
IMPORTANT! The PEM string and comment must be formatted as

described in Format Requirements on the facing page.
Example:
hostname (config) # crypto certificate name cert0 public-cert pem
"MIIEujCCA6KgAwIBAgIJAI/1cFcdOeykMA0GCSqGSIb3DQEBBQ
UAMIGZMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTERMA8GA1UEBxMITWlscGl0YXMTJDE3GDS9DYEDLO9EWS6Fx=..."
comment "certificate import example
3. If you want to import a private key directly, use the following command:
hostname (config) # crypto certificate name <certName> private-key pem
"<pemString>"
The command parameters are defined as follows:

l <certName>—Unique certificate name; it cannot be the name of an existing
certificate in the certificate database.
l <pemString>—The public certificate PEM string, formatted as described in
Format Requirements on the facing page.
Example:
hostname (config) # crypto certificate name cert1 private-key pem
"MIIEujCCA6KgAwIBAgIJAI/1cFcdOeykMA0GCSqGSIb3DQEBBQ
UAMIGZMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTERMA8GA1UEBxMITWlscGl0YXMTJDE3GDS9DYEDLO9EWS6Fx=..."
4. If instead you want to import the private key by entering it when prompted and
with secure echo of your response, use the following command:
hostname (config) # crypto certificate name <certName> prompt-private-
key
The <certName> parameter is the unique name by which the certificate is identified.
The following example imports a private key that you enter when prompted.
hostname (config) # crypto certificate name Cert2 prompt-private-key
250 © 2021 FireEye

5. Add the certificate to the default CA list:

hostname (config) # crypto certificate ca-list default-ca-list name
cert3

hostname (config) # show crypto certificate ca-list

Format Requirements

2. A new line
4. ASCII block
6. A new line
If a comment is added, it must follow the final double quotation marks and be on the same
line. Any commentary outside the BEGIN and END delimiter strings is ignored.
>"
>.
>.
>.
>
>"
© 2021 FireEye 251

Configuring a SharePoint CA Certificate

Chain
The File Protect appliance can perform malware analysis scans on accessible files stored in
network shares, collaboration servers, and remote hard drives. CIFS, NFS, WebDAV, and
secure WebDAV remote file access protocols are supported.
When you mount a secure WebDAV share, you must specify a SharePoint CA certificate
chain. You must bundle the certificates in order: first, the root (top-level) certificate, then
any intermediate certificates, and finally the endpoint (SharePoint server) being certified.
Each endpoint and intermediate certificate obtains its authority from the previous CA in
the chain. The server certificate was issued by the first intermediate CA, the first
intermediate certificate was issued by the second intermediate CA, and so on. The last
intermediate CA was issued by the root CA. The root certificate must have a matching
issuer and subject because a top-level CA authority is self-signed.
Each certificate in the chain is validated to make sure the parent-to-child progression is
correct. Although authority is established within the chain, the certificates in the chain are
not automatically verified and trusted by the system. You can optionally verify them as
described in Manually Verifying Certificates on page 262.
You can include a comment string with information such as the domain and expiration
date. The comment is replicated in the comment field of each member certificate.
This section describes how to configure the chain. For information about mounting file
shares, see the File Protect User Guide.
See Obtaining a CA Certificate from a Trusted Public Certificate Authority (CA) on

page 245 if you want to use CA certificates issued by a public CA.
Prerequisites
Configuring a SharePoint CA Certificate Chain Using the

Web UI
Use the WebDAV CA Configuration section of the Certificate Management page to
configure a SharePoint CA certificate chain.
IMPORTANT! See Configuring a SharePoint CA Certificate Chain above for

details about how to bundle the certificates in the chain.
252 © 2021 FireEye

Release 2021.1 Configuring a SharePoint CA Certificate Chain
To configure a SharePoint CA certificate chain:

3. Enter a unique name for the CA chain in the CA Chain Name field. This is the
name you specify when you mount the secure WebDAV share. The name must
begin with a letter or number. The remaining characters in the name can be letters,
numbers, periods (.), dashes (-), and underscores (_).
4. Select the certificate chain file:
a. Click Choose File in the CA Chain Certs File field.
b. In the dialog box that opens, navigate to the file in your local file system that
contains the chain of PEM strings.
5. Click Import CA Chain.
To delete a SharePoint CA certificate chain:

3. Locate the certificate in the CA Chain Name column.
4. Click Delete in the Action column.
Configuring a SharePoint CA Certificate Chain Using the

CLI
Use the commands in this section to configure a SharePoint CA certificate chain.
IMPORTANT: See Configuring a SharePoint CA Certificate Chain on the

previous page for details about how to bundle the certificates in the chain.
© 2021 FireEye 253

To configure a SharePoint CA certificate chain:

hostname > enable
2. Configure the certificate chain:

hostname (config) # crypto certificate sharepoint ca-chain chain-name
<chainName> "<pemChainString>" [cert-comment "<comment>"]
where:
l chainName is a unique name for the CA chain. This is the name you specify
when you mount the secure WebDAV share. The name must begin with a
letter or number. The remaining characters in the name can be letters,
l pemChainString is the chain of PEM strings.
l comment is the text for the comment.
IMPORTANT! The PEM chain string and comment must be formatted

as described in Format Requirements below.

To view the certificates belonging to the chain:
1. Enable the CLI enable mode:

hostname > enable
2. View the certificates:

hostname # show crypto certificate ca-chain [<chainName>] [brief |
detail]
The brief option displays only the chain names. The detail option displays all
available certificate attributes.
To delete a SharePoint CA certificate chain:
1. Enable the CLI configuration mode:

hostname > enable
2. Delete the chain:

hostname (config) # no crypto certificate sharepoint ca-chain chain-
name <chainName>
Format Requirements
254 © 2021 FireEye

Release 2021.1 Configuring a SharePoint CA Certificate Chain

2. A new line
4. ASCII block
6. A new line
>"
>.
>.
>.
>
>"
Examples
Configuring a Certificate Chain
The following example configures a SharePoint CA certificate chain that includes the root
certificate, two intermediate certificates, and the SharePoint server certificate.
hostname (config) # crypto certificate sharepoint ca-chain chain-name acme_
Cert-Dec2017_share "
>
> FjAUB+NVBAgTNT1hc3NhY2h1c2V0dHMxFDASBgNVBAcTC1dlc3Rib3JvdWdoMRsw
> GQYDVQQKExJUYWxsIE1hcGxlIFN5c3RlbXMx/DAOBgNVBAsTB3Rtkq1lbmcxHjAc
...
> -----END CERTIFICATE-------
> HUE457jJheR86GJD3Iye987cdIYuP238DCBsDELMAkGA1UEBhMCVVMxh32Aq0iF7
> V75TYoiuY368pW+Bd8A8345Oc3PIUB4uw0821NMQaq9YEw397Ne409NCDE987c9u
> VE397gi/yTMNXd84Tuq0pie4n451r0oieRxcsWe70abcie$529omE2wXyrwR3784
> NTTdi239csUEi7dgOp391VCWetrnEp983Yr4B14Dw9URwo7NVC3xaY7vA2Aq874=
...
> n4Qw21ou4VeTe8BE29780dv7APR2rc92g4ublselcisla5do3tGBy9873cslIExu
© 2021 FireEye 255

> v38csf8bu/w9UjeRcsltsiv3u23kd+abiY6TRB5596aqin3h4Jh423jc0oWqnr3m
> cAy65Lku53eCsD9Uo0pKmE235Dcwiyti754TDlOUnrd3677903dwr456mHjyDew7
> he3T58ET86udaUOi328VEw78Texpuy457swQmRe7ck3yswo8dmvhts52vBdl43==
...
> 49JysE20gjaasfaMKTSIKEdycTe84mbnn4Qw21ou4Vejt4W9j6e37APR2rc92vde
> g4ublselcisla5do3tGBy9873cslI/xun471sWeid873RiuvY67Wf3873NywpYUm
> ges98R3kc+asdf7683lc09TNTD7utB2894Htdm0982JeubJyiRWe98Ldkey1slfo
> n35De89adkj;298jkgkk38GESlgisU6e3T8UBd2TIu7B184hK3rp98c1rW398vlr
...
>
> " cert-comment "Acme HR SharePoint Server"
Deleting a Certificate Chain

The following example deletes the certificate chain.
hostname (config) # no crypto certificate sharepoint ca-chain chain-name
acme_Cert-Dec2017_share
Configuring a Web Server CA Certificate

Chain
You can add a certificate chain to an Apache Web server. This establishes a chain of trust
for a server SSL certificate by providing signing certificate authority (CA) certificates to the
Web browsers running the Web UI.
You cannot use a self-signed certificate with a CA certificate chain; the Web server
certificate must be issued by a public or private CA. If it was issued by a private CA, you
must add the private CA's root certificate to your employees' Web browsers.
The individual server certificate cannot be included in the chain; the root CA certificate is
optional. You must bundle the certificates in order: first, the intermediate CA that issued
the Web server endpoint certificate being certified, then the other intermediate CAs, and
finally the root CA certificate, if it is included.
Each intermediate certificate obtains its authority from the next CA in the chain. Each
certificate in the chain is validated to make sure the parent-to-child progression is correct.
Although trust is established within the chain, the certificates in the chain are not
automatically verified and trusted by the system. You can optionally verify them as
described in Manually Verifying Certificates on page 262.
You can include a comment string with information such as the domain and expiration
date. The comment is replicated in the comment field of each member certificate.
See Obtaining a CA Certificate from a Trusted Public Certificate Authority (CA) on

page 245 if you want to use CA certificates issued by a public CA.
256 © 2021 FireEye

Release 2021.1 Configuring a Web Server CA Certificate Chain
Prerequisites
l Web UI method: chain.pem file stored on your local machine
Configuring a Web Server CA Certificate Chain Using the

Web UI
Use the Web-Server CA-Chain Configuration section of the Certificate Management page
to configure a Web server CA certificate chain. After you configure the CA chain, you must
activate it so the Web server can use it.
IMPORTANT! See Configuring a Web Server CA Certificate Chain on the

previous page for details about how to bundle the certificates in the chain.
To configure a Web server CA certificate chain:

3. Enter a unique name for the CA chain in the CA Chain Name field. The name must
begin with a letter or number. The remaining characters in the name can be letters,
4. Select the certificate chain file:
a. Click Choose File in the CA Chain Certs File field.
b. In the dialog box, navigate to the file in your local file system that contains
the chain of PEM strings.
© 2021 FireEye 257

5. Click Import CA Chain.

6. Activate the CA chain as described in Activating a Web Server CA Certificate Chain
To delete a Web server CA certificate chain:
3. Locate the certificate in the CA Chain Name column.

4. Click Delete in the Action column.
Configuring a Web Server CA Certificate Chain Using the

CLI
Use the commands in this section to configure a Web server CA certificate chain.
IMPORTANT: See Configuring a Web Server CA Certificate Chain on page 256

for details about how to bundle the certificates in the chain.
To configure a Web server CA certificate chain:

hostname > enable
2. Configure the certificate chain:

hostname (config) # crypto certificate ca-chain chain-name <chainName>
web-server pem-bundle "<pemChainString>" [comment "<comment>"]
where:
l chainName is a unique name for the CA chain. The name must begin with a
letter or number. The remaining characters in the name can be letters,
l pemChainString is the chain of PEM strings.
l comment is the text for the comment.
IMPORTANT: The PEM chain string and comment must be formatted

as described in Format Requirements on the facing page.

hostname (config) # show crypto certificate ca-chain chain-name
<chainName>
258 © 2021 FireEye


5. Activate the CA chain as described in Activating a Web Server CA Certificate Chain

To view the certificates belonging to the chain:
hostname > enable
2. View the certificates:

hostname # show crypto certificate ca-chain chain-name [<chainName>]
[brief | detail]
The brief option displays only the chain names. The detail option displays all
available certificate attributes.
To delete a Web server CA certificate chain:
hostname > enable
2. Delete the chain:

hostname (config) # no crypto certificate ca-chain chain-name
<chainName>
Format Requirements

2. A new line
4. ASCII block
6. A new line
© 2021 FireEye 259

>"
>.
>.
>.
>
>"
Examples
Configuring a Certificate Chain
The following example configures the "apache03" Web server CA certificate chain that
includes two intermediate CAs and the root certificate.
hostname (config) # crypto certificate ca-chain chain-name web-server pem-
bundle apache03 "
>
> FjAUB+NVBAgTNT1hc3NhY2h1c2V0dHMxFDASBgNVBAcTC1dlc3Rib3JvdWdoMRsw
> GQYDVQQKExJUYWxsIE1hcGxlIFN5c3RlbXMx/DAOBgNVBAsTB3Rtkq1lbmcxHjAc
...
> HUE457jJheR86GJD3Iye987cdIYuP238DCBsDELMAkGA1UEBhMCVVMxh32Aq0iF7
> V75TYoiuY368pW+Bd8A8345Oc3PIUB4uw0821NMQaq9YEw397Ne409NCDE987c9u
> VE397gi/yTMNXd84Tuq0pie4n451r0oieRxcsWe70abcie$529omE2wXyrwR3784
> NTTdi239csUEi7dgOp391VCWetrnEp983Yr4B14Dw9URwo7NVC3xaY7vA2Aq874=
...
> 49JysE20gjaasfaMKTSIKEdycTe84mbnn4Qw21ou4Vejt4W9j6e37APR2rc92vde
> g4ublselcisla5do3tGBy9873cslI/xun471sWeid873RiuvY67Wf3873NywpYUm
> ges98R3kc+asdf7683lc09TNTD7utB2894Htdm0982JeubJyiRWe98Ldkey1slfo
> n35De89adkj;298jkgkk38GESlgisU6e3T8UBd2TIu7B184hK3rp98c1rW398vlr
...
>
> "
hostname (config) # show crypto certificate ca-chain chain-name apache03

CA chain name apache03 (web-server):
Certificate with name 'apache03-1'

Chained CA member certificate
(may only be deleted through the chain)

Serial Number: 0x1xxx
SHA-1 Fingerprint: 4xxxxxx
Validity:
...
Subject:
260 © 2021 FireEye

Common Name: acme-intermediate

...
Issuer:
Common Name: xxx-intermediate
...


Serial Number: 0x2xxx
Validity:
...
Subject:
Common Name: xxx-intermediate
...
Issuer:
Common Name: xxx-root-ca
...


Serial Number: 03xxx
Validity:
...
Subject:
...
Issuer:
...
Deleting a Certificate Chain

The following example deletes the "apache04" certificate chain.
hostname (config) # no crypto certificate ca-chain chain-name apache04
Activating a Web Server CA Certificate Chain Using the

CLI
Use the commands in this section to activate a Web server CA certificate chain.
© 2021 FireEye 261

To activate a Web server CA certificate chain:

hostname > enable
2. Activate the certificate chain:

hostname (config) # web server ssl ca-chain <chainName>
where:
l chainName is a unique name for the CA certificate chain. The name must
begin with a letter or number. The remaining characters in the name can be
letters, numbers, periods (.), dashes (-), and underscores (_).

To deactivate a Web Server CA certificate chain:
hostname > enable
2. Deactivate the chain:

hostname (config) # no web server ssl ca-chain
Example
The following example activates the "apache01" certificate chain.
hostname (config) # web server ssl ca-chain apache01
Manually Verifying Certificates

A certificate is valid and will be added to the certificate database if it is formatted correctly,
and in the case of a CA certificate chain, if the certificates are installed in the required
order. A certificate is verified using OpenSSL if it is signed and trusted by the system.
The following certificates are part of the certificate verification path:
l A root certificate is self-signed, and is used to sign intermediate certificates and

endpoint certificates. A root certificate is optional in a CA certificate chain.
262 © 2021 FireEye

Release 2021.1 Manually Verifying Certificates
l An intermediate certificate is signed by its parent (issuer) certificate, which is signed

by its issuer certificate, and so on, until the certification path ends at the root
certificate (if any).
l An endpoint (server) certificate is signed by its issuer certificate. An endpoint
certificate does not sign other certificates.
A certificate is automatically verified when the following are true:
l Root certificate: The certificate is self-signed and the Subject type=CA field is in its
Basic Constraints section.
l Intermediate and endpoint certificate: Its issuer certificate is verified as described

below.
l Issuer (root and intermediate) certificate: Each issuer certificate is in the public CA
bundle or the supplemental CA list. Certificates in these lists are already trusted by
the system.
Verification will fail if the certificate cannot find its issuer certificate or if the issuer
certificate is not trusted by the system.
For example, each endpoint and intermediate CA in a Web server certificate chain obtains
its authority from its issuer certificate, which is the next CA in the chain. The certificates
are installed in a bundle, and must be ordered from the intermediate CA that issued the
endpoint certificate, the other intermediate certificates, and finally through to the root CA (if
any). However, because the issuer certificates are not yet in the supplemental CA list, each
intermediate CA will fail the initial verification check as it is added to the certificate
database. After you add the issuer certificates to the supplemental CA list, you can
manually verify the certificate chain.
This topic describes how to manually verify a certificate chain, an individual certificate, or
a certificate bundle after the issuer certificates are installed and added to the supplemental
CA list.
NOTE: If the certificates in a CA certificate chain are installed in the required

order, the chain of trust will be established, even if the certificates do not pass the
OpenSSL verification described in this topic.
Prerequisites
Manually Verifying Certificates Using the CLI

Use the commands in this section to verify a certificate chain, an individual certificate, or a
certificate bundle.
© 2021 FireEye 263

To verify a certificate chain:

hostname > enable
2. Verify the chain:

hostname (config) # crypto certificate reverify chain-name <chainName>
To verify an individual certificate:

hostname > enable
2. Verify the certificate:

hostname (config) # crypto certificate reverify cert-name <certName>
To verify a certificate bundle:

hostname > enable
2. Verify the bundle:

hostname (config) # crypto certificate reverify bundle-name
<bundleName>
Example
The following example installs the "apache02" Web server CA certificate chain. It shows
that the "apache02-1" and "apache02-2" intermediate certificates failed verification, and the
"apache02-3" self-signed root certificate passed verification. It then adds the two issuer
certificates (apache02-03 and apache02-02) to the supplemental CA list, and manually
verifies the chain.
ex-04 (config) # crypto certificate ca-chain chain-name web-server pem-bundle
apache02 "
>
>-----BEGIN CERTIFICATE---
...
>-----END CERTIFICATE-----
...
...
>
> "
Certificate notice: certificate name apache02-1, ID 6xxxxxx could not be
verified: unable to get issuer certificate
Certificate notice: certificate name apache02-2, ID 7xxxxxx could not be
264 © 2021 FireEye

Release 2021.1 Manually Verifying Certificates
verified: unable to get issuer certificate
Certificate notice: certificate name apache02-3, ID 8xxxxxx is verified:

verify ok
ex-04 (config) # crypto certficiate ca-list default-ca-list name apache02-03

ex-04 (config) # crypto certificate ca-list default-ca-list name apache02-02
ex-04 (config) # reverify chain name apache02

Certification notice: certificate name apache02-1, ID 6xxxxxx is verified:
verify ok
verify ok

verify ok
© 2021 FireEye 265

266 © 2021 FireEye

System Security Guide Specifying the Minimum Key Size Using the CLI
CHAPTER 15: Improving

Certificate Security
You can do the following to improve the security of your certificates:
l Increase the size of the keys to increases the strength of their signatures.
l Specify that only secure hash signature algorithms (sha256WithRSAEncryption,
sha384WithRSAEncryption, or sha512WithRSAEncryption) be used. Certificates
with the sha1WithRSAEncryption signature algorithm will be removed from the
default CA list, and from the Web server and MTA.
IMPORTANT: If the Web server or MTA certificate is removed, it is

replaced by the system self-signed certificate.
You can also modify the minimum Transport Layer Security (TLS) version that should be
used.
Prerequisites
Specifying the Minimum Key Size Using

the CLI
Use the commands in this section to increase the minimum key size.
To specify the minimum key size:
hostname > enable
© 2021 FireEye 267

System Security Guide CHAPTER 15: Improving Certificate Security
2. Specify the size:

hostname (config) # crypto certificate min-key-size <bits>
where <bits> is the minimum number of bits.
IMPORTANT! You cannot generate a self-signed certificate with a key

that is longer than 8192 bits.

Requiring Secure Hashes Using the CLI

Use the commands in this section to require that secure hashes be used.
To specify that secure hashes be used:
hostname > enable
2. Require secure hashes:

hostname (config) # crypto certificate secure-hashes-only

NOTE: To remove the requirement for secure hashes, use the no crypto
certificate secure-hashes-only command.
Reviewing the Minimum Transport Layer

Security (TLS) Version Requirement
You can review the minimum Transport Layer Security (TLS) version requirement using
the CLI or in the logs.
l Reviewing the Minimum Transport Layer Security (TLS) Version Requirement

Using the CLI on the facing page
l Reviewing the Minimum Transport Layer Security (TLS) Version Requirement In the
Logs on page 270
268 © 2021 FireEye

Release 2021.1 Reviewing the Minimum Transport Layer Security (TLS) Version Requirement
If you have HX Series 3.3 or later installed, the Web TLS version also applies to
ports 443 and 6800 (in addition to port 3000 for the Web UI). If you need to verify
this, use an external network mapping and auditing tool such as Qualys or
Nmap.
Reviewing the Minimum Transport Layer Security (TLS)

Version Requirement Using the CLI
Use the CLI commands in this section to review the minimum version requirement setting
for Transport Layer Security (TLS).
To review the required minimum TLS version using the CLI:

hostname > enable
© 2021 FireEye 269

2. Review the minimum TLS version requirement:

The results of this command will look similar to this:

HTTP enabled: no
HTTP port: 8000
HTTP redirect to HTTPS: yes
HTTPS enabled: yes
HTTPS port: 3000
HTTPS protocols: TLSv1.2
HTTPS minimum protocol version: TLSv1.2
HTTPS cipher list: compatible
HTTPS certificate name: system-self-signed
HTTPS CA chain name:
Listen enabled: yes

Listen Interfaces:
Interface: tun0
Inactivity timeout: 7 hr 40 min

Session timeout: 8 hr
Session renewal: 7 hr 55 min
Web file transfer proxy:

Proxy enabled: no
Web file transfer certificate authority:

HTTPS server cert verify: yes
HTTPS supplemental CA list: default-ca-list
Web preferences:
Global alerts auto refresh enabled: yes
HTTPS client minimum protocol version: TLSv1
HTTPS client cipher list: compatible
The HTTPS minimum protocol version line shows the minimum version
requirement for TLS for the appliance.
Reviewing the Minimum Transport Layer Security (TLS)

Version Requirement In the Logs
Use the CLI commands in this section to review the minimum version requirement setting
for Transport Layer Security (TLS) in the logs.
To review the required minimum TLS version in the logs:

hostname > enable
270 © 2021 FireEye

Release 2021.1 Specifying the Minimum Transport Layer Security (TLS) Version Requirement
2. Review the logs for TLS references:

hostname (config) # show log matching tls
The contents of the log file that mention tls will be displayed. For example:
Apr 3 09:29:31 <hostname> mgmtd[5598]: [211771.546] [mgmtd.INFO]:
Forking then execing binary /usr/bin/python with argc 14,argv
"/usr/bin/python /opt/fireeye/share/sfserver/scripts/nginx_
configurator.py --ssl_min_version tls1.2 --is_dmz 0 --prov_cert_enabled
1
Review the output.
Specifying the Minimum Transport Layer

Security (TLS) Version Requirement
Use the commands in this section to specify the minimum version requirement for
Transport Layer Security (TLS) that should be used. The default is to use TLS v1.2.
To specify the required minimum TLS version using the CLI:

hostname > enable
2. Specify the minimum TLS version requirement:

hostname (config) # web server ssl min-version <value>
where:
l <value> is tls1 (TLS v1), tls1.1 (TLS v1.1), or tls1.2 (TLS v1.2). The
default is tls1.2.

To reset the minimum TLS version requirement to the default:
hostname > enable
2. Reset the minimum TLS version requirement to the default (TLS v1.2):
hostname (config) # no web server ssl min-version

© 2021 FireEye 271

Example
The following example sets the minimum TLS version requirement to TLS v1.2.
hostname (config) # web server ssl min-version tls1.2
272 © 2021 FireEye

System Security Guide Common Attributes of X.509 Certificates
CHAPTER 16: Defining Default

Certificate Attributes
All X.509 certificates have common attributes. The default values populate the attributes in
self-signed and regenerated certificates, and in CSRs created from the Email Security —
Server Edition Web UI. You can change the default values as desired. For example, you
could update the contact email address or change the validity period to two years instead
of one.
Prerequisites
Common Attributes of X.509 Certificates

All X.509 certificates have common attributes. The default values populate the attributes in
self-signed and regenerated certificates, and in CSRs created from the Email Security —
Server Edition Web UI. You can change the default values as desired. For example, you
could update the contact email address or change the validity period to two years instead
of one.
The following table describes the certificate attributes and provides the system default
value for each attribute.
CLI
Attribute Web UI Field Description
Keyword
Certificate Certificate cert-name A unique name that identifies the

Name certificate. The name can contain
letters, numbers, and the period (.),
comma (,) and underscore (_)
characters.
© 2021 FireEye 273

System Security Guide CHAPTER 16: Defining Default Certificate Attributes
CLI
Keyword
Common Common common- A fully qualified domain name for the

Name (CN) Name name appliance. An exception is the system-
self-signed certificate, in which the CN
is the appliance hostname.
Organization Organization organization The legal name of your organization.
Organizational Organizational org-unit The department or unit in your

Unit Unit organization using the certificate.
City or City (Locality) locality The city or locality where your

Locality organization is located.
State or State state-or-prov The state or province where your

Province (Province) organization is located.
Country Country country- The country code of the country where

code your organization is located.
Issued By Issued By — This attribute represents the

Distinguished Name (DN) of the
certificate. The DN includes all of the
identification attributes described
above. For brevity, the Web UI shows
only the Common Name and
Organization in the Issued By field.
The CLI has no specific "Issued By" line
of output.
Time Days before days-valid The number of days until the certificate
Remaining expiration will expire.
Expire Date Expire Date — The date and time the certificate will
expire.
Status Status — Whether the certificate is valid. After a

certificate expires, it is no longer valid.
Key Bits — key-size-bits The number of bits in the private key.
Serial Number Serial Number serial-num A unique number that the issuer
assigned to the certificate.
274 © 2021 FireEye

Release 2021.1 Common Attributes of X.509 Certificates
CLI
Keyword
Email Address — email-addr The email address used to contact the

certificate holder (also known as the
certificate subject).
Comment — comment Descriptive information about the

certificate.
Certificate — Certificate The class of algorithm used to generate

Type Type the certificate. Valid values are ECDSA
and RSA.
Private Key — Private Key Whether a matching private key for the
certificate is present.
SHA-1 — SHA-1 A short sequence of bytes used to

Fingerprint Fingerprint authenticate or look up the public key.
Subject Hash — Subject A unique hash value based on the

Hash subject of the certificate.
Version Version Version The X.509 standard version.
Subject Public Public Key Subject The general type of public key
Key Algorithm Algorithm Public Key algorithms that are allowed. Valid
Algorithm values are id-ecPublicKey (unrestricted
elliptical curve algorithms, defined in
RFC 5480) and rsaEncrytion (RSA
encryption algorithms, defined in RFC
2437).
Subject Public Public-Key Subject The length of the public key

Key Length Public Key PEM string.
Length
Signature Signature Signature The public key signature algorithm.

Algorithm Algorithm algorithm
Prerequisites
© 2021 FireEye 275

System Security Guide CHAPTER 16: Defining Default Certificate Attributes
Defining Default Certificate Attributes

Using the CLI
Use the commands in this section to define default certificate attributes.
To define attributes:
hostname > enable
2. Define the default value:

hostname (config) # crypto certificate generation default
<attribute> <value>
3. Repeat the previous step for each attribute you want to change.
5. (Optional) Regenerate the certificates to apply the updated attributes:

regenerate
Example
This example changes the organizational unit to Information Technology. It then
regenerates the web-cert certificate to apply the updated attribute value, and displays the
certificate to verify the change.
hostname (config) # crypto certificate generation default org-unit
"Information Technology"
hostname (config) # crypto certificate name web-cert regenerate

Successfully regenerated certificate with name 'web cert'
hostname (config) # show crypto certificate name web-cert
276 © 2021 FireEye

System Security Guide Renaming a Certificate Using the CLI
CHAPTER 17: Renaming a

Certificate
You can rename certificates that do not have reserved names. Reasons for doing so
include:
l You want to use a named certificate with a private key as the Web server certificate.
Because the Web server requires a certificate with the reserved name of web-cert, you
must rename it before activating it.
l Reusing a certificate name for convenience.
l Saving an older certificate with another name as a backup.
Each certificate name must be unique, so the renaming operation fails if a certificate with
the same name already exists.
Prerequisites
Renaming a Certificate Using the CLI

Use the commands in this section to rename a certificate.
To rename a certificate:
hostname > enable
2. Rename the certificate:

hostname (config) # crypto certificate name <currentName> rename
<newName>

hostname (config) # write
© 2021 FireEye 277

System Security Guide CHAPTER 17: Renaming a Certificate
Example
The following example renames the "server" certificate to "web-cert" so it can be activated
for the Web server, and then activates it.
hostname (config) # crypto certificate name server rename web-cert
278 © 2021 FireEye

Release 2021.1
PART VI: FireEye IAM
l FireEye IAM Overview on page 281

l Managing Your Own FireEye IAM User Account on page 293
l FireEye IAM Concepts and Terminology on page 284
l FireEye IAM Web UI Access on page 285
l FireEye IAM Initial Configuration Task List on page 290
l FireEye IAM Organization on page 313
l FireEye IAM Roles on page 321
l FireEye IAM User Accounts on page 333
l FireEye IAM User Groups on page 359
l FireEye IAM API Keys on page 375
© 2021 FireEye 279

System Security Guide PART VI: FireEye IAM
280 © 2021 FireEye

System Security Guide OAuth 2.0 and OIDC
CHAPTER 18: FireEye IAM

Overview
Identity Access Management (IAM) is a Web service that provides user authentication and
authorization. Authentication is the identification of individuals who can use protected
resources. Authorization determines who can use which resources and in what ways.
FireEye IAM is a multi-tenant Web service that enables you to implement user access
control policies for specific resources and prevent unwanted access to other resources. The
IAM identity management model enables you to manage user accounts and passwords
centrally. Role-based access control policies are used to provision access to users and user
groups.
FireEye IAM supports single sign-on (SSO) authentication to your shared resources. See
Single Sign-On Authentication on page 143.
OAuth 2.0 and OIDC

The OAuth 2.0 protocol provides the identity and policy framework on which FireEye IAM
implements authorization flows between end users or APIs and FireEye applications and
services in the cloud. FireEye IAM manages sessions between users and services by
running the OpenID Connect (OIDC) identity layer on top of OAuth 2.0. OIDC performs the
transfer of requests and responses using a RESTful HTTP API and JSON-based tokens.
© 2021 FireEye 281

System Security Guide CHAPTER 18: FireEye IAM Overview
FireEye IAM acts as an OAuth 2.0 authentication server. It implements OIDC to offer

authentication as a service. Supported FireEye applications and services send the FireEye
IAM authentication server requests to validate end users and APIs. In response to a request
for validation, IAM returns an OIDC token that contains the attributes of the end user or
API.

to manage certificates. See Common Access Card (CAC) for Certificate
The IAM Organization

FireEye creates a secure account, called an IAM organization, in the FireEye private cloud
for each tenant. In this account, you can view your on-premises and cloud-based resources
and create and manage user access control policies and user accounts. Credentials are
created for each user account in the FireEye IAM organization, and the credentials are used
to authenticate end users before they are allowed to access products in the IAM
organization.
OIDC Clients
To be accessible to your IAM organization, a product must be registered under your IAM
organization as an OIDC client and provide information about itself to the FireEye IAM
authentication server. End users who enroll in the FireEye IAM service can authenticate to
OIDC clients to gain access to their services. OIDC clients can verify the identity of an end
user based on the authentication performed by the FireEye IAM authentication and
authorization server in the FireEye public cloud. Authenticated users have specific access
privileges on specific resource types based on product-specific roles assigned to their
accounts.
282 © 2021 FireEye

Release 2021.1 The Default IAM Organization Administrator
FireEye IAM release 18.02 supports the following FireEye appliances and services as OIDC

clients:
l FireEye Central Management release 7.9.3 and later
l FireEye Email Security — Server Edition release 8.0.0 and later
l FireEye Endpoint Security release 3.5.0 and later
l FireEye Network Security release 7.9.3 and later
l FireEye Helix release 1.0 and later
l Helix release 17.01 and later
These products automatically register as OIDC clients under your IAM organization.
The Default IAM Organization

Administrator
When FireEye creates your IAM organization, a default IAM organization administrator
user account is also created and FireEye gives you the credentials. Initially the only user
account in a new IAM organization is the IAM organization administrator. The default
administrator is assigned the following IAM roles:
l IAM Admin―This role enables the user to configure the IAM organization, access
control policies, and user accounts. See IAM Admin Role on page 412.
l Helix―These roles give the user full access to the incident detection and resolution
tracking console. This is described in Entitlements for Helix Roles on page 426.
l FireEye appliances―These roles gives the user full access to all FireEye appliances
and services in the IAM organization. This is described in Entitlements for the
FireEye Appliance Roles on page 494.
Before you can use FireEye IAM authentication and authorization services, the IAM
organization administrator must log in to the IAM Web UI and configure the organization
and provision user access. The default user credentials were provided to you by FireEye.
For additional login information, see FireEye IAM Web UI Access on page 285. Minimum
configuration steps are described in FireEye IAM Initial Configuration Task List on
page 290.
NOTE: The default organization administrator can create IAM Admin users and
delegate to them the task of creating the other user accounts.
© 2021 FireEye 283

FireEye IAM Concepts and Terminology

The following definitions explain some of the fundamental concepts and terminology of
IAM solutions.
Roles
FireEye IAM uses roles to control what users can see and do on the products (the
services and applications) in an IAM organization. A role specifies permissions for
accessing a product type (FireEye appliances or Helix). To allow a user to have certain
access permissions on a certain product type, an administrator assigns a role to the
user account.
A set of system-defined roles, called global roles grant capabilities that correspond to
the set of roles used to control access to FireEye appliances and services through their
local user accounts. Global roles are also provided for accessing supported FireEye
appliances, for accessing Helix, and also for accessing the FireEye IAM Web UI.
If other combinations of permissions are required for accessing the FireEye IAM
Web UI or Helix, you can create your own custom roles that are internal to your own
IAM organization.
Entitlements
FireEye IAM uses entitlements to map roles to user access permissions. Entitlements
are system-defined entities that map a product type to one or many specific access
permissions.
The FireEye IAM Web UI and Helix (previously known as the Threat Analytics
Platform, or TAP) have entitlements that each represents an individual, fine-grained
user access privilege. Thus the global roles for these products map to multiple
entitlements. For details, see Entitlements for the FireEye IAM Web UI Roles on
page 411 and Entitlements for Helix Roles on page 426.
Each role for a FireEye appliance maps to a single entitlement that represents multiple
access privileges. For details, see Entitlements for the FireEye Appliance Roles on
page 494.
284 © 2021 FireEye

Release 2021.1 FireEye IAM Web UI Access
User Accounts
The FireEye IAM organization administrator creates user accounts to allow network
security staff to access the FireEye IAM Web UI, Helix, and supported FireEye
appliances. A user account contains information such as email address, group
memberships, and entitlements that grant access to a single product type or multiple
product types. For more information, see FireEye IAM User Accounts on page 333.
Before a user can log in to a new account, the account must be enrolled in the IAM
organization at a self-service enrollment Web site. For details, see Managing Your Own
FireEye IAM User Account on page 293.
User Groups
To grant the same access privileges a set of user accounts, an IAM Admin can create a
user group. A user group grants its members the combined access privileges specified
by multiple sources:
l Roles that are assigned directly to the user group.
l Roles assigned to each user account that is assigned to the user group
For details, see FireEye IAM User Groups on page 359.
FireEye IAM Web UI Access

The default IAM organization administrator and the IAM Admin users log in to the IAM
Web UI to configure IAM organization settings, user access control policies, user groups,
and user accounts. Other users―users who have been assigned the IAM User role―log in
to the IAM Web UI to manage their own accounts: update personal information, set user
preferences, manage their password, and generate backup codes for two-factor
authentication.
Terms of Service
The FireEye end user license agreement (EULA) governs the use of FireEye products. After
logging in to the IAM Web UI, users must read and accept the EULA if the previously
accepted agreement is older than the current version. User acceptance of the EULA is
logged as a IAM audit event.
You can view the current terms of service at any time in the Legal Terms & Conditions page
of the FireEye corporate website:
https://www.fireeye.com/company/legal.html
© 2021 FireEye 285

Logging In to the FireEye IAM Web UI

End users log in to the FireEye IAM Web UI so that they can authenticate to FireEye
resources registered in the team's IAM organization. Users with IAM Admin accounts use
the IAM Web UI to manage their team's IAM organization in the FireEye private cloud.
Users with IAM User accounts use the Web UI to manage their own user accounts.
NOTE: The enrollment process for new IAM accounts includes initial login to the
IAM Web UI. See Enrolling Your New FireEye IAM User Account on page 295.
To log in to FireEye IAM Web UI:
1. In a browser, go to the FireEye IAM login page for your geographical location:
l https://console.us.fireeye.com
l https://console.eu.fireeye.com
The FireEye IAM login page appears.
2. Enter your IAM account user name (your email address) and password.
286 © 2021 FireEye

3. If two-factor authentication (2FA) is enabled, enter a one-time passcode.
In the following example, the user is entering a one-time passcode that was sent in
an SMS text message.
For a general description of 2FA, see Security in a FireEye IAM Organization on

page 313.
For information about enabling 2FA, see the following topics:

l FireEye IAM Organization Settings on page 315
l Configuring the FireEye IAM Organization on page 318.
For information about logging in to the IAM Web UI when 2FA is enabled, see the
following topics under Managing Your Own FireEye IAM User Account on
page 293:
l About Two-Factor Authentication on page 306
l Setting Up a Smartphone as a Two-Factor Authentication Device on page 307
l Resetting Two-Factor Authentication on Your Smartphone on page 309
l Generating Two-Factor Authentication Codes in Advance on page 310
© 2021 FireEye 287

4. If the Terms and Conditions For FireEye Offerings appears, you can click the
Expand icon ( ) next to the document update date to open the FireEye Legal Terms
& Conditions in a separate browser tab.
Read the EULA terms, then select I have read and agree to the Terms of Service in

the main browser tab and click Next.
The FireEye IAM Web UI opens.

5. If you are the default IAM organization administrator and you are logging in to the
IAM Web UI for the first time, proceed to FireEye IAM Initial Configuration Task
List on page 290.
288 © 2021 FireEye

Logging Out of the FireEye IAM Web UI

A Logout menu item is located under your avatar:
To log out of the FireEye IAM Web UI:
1. Click your avatar (or the default avatar) in the upper right corner of any page.
2. Select Logout.
© 2021 FireEye 289

FireEye IAM Initial Configuration Task

List
The following table summarizes the FireEye IAM initial configuration tasks to be
performed by the default IAM organization administrator:
Task Description
Configure the IAM Organization
Add a Verify the information pre-configured by FireEye, and add a description:

description l IAM organization name
l Your customer ID
l Your Salesforce.com (SFDC) ID
l Product types in your IAM organization
See FireEye IAM Organization on page 313.
Configure (Optional) Customize default security policies:

global l Allowed email domains―Limit usernames to specified email domains.
security l Two-factor authentication―Require or allow up to 3 possession factors.
policies
l Password policy―Customize user password requirements.
l Expiration times―Customize expiration times for Web UI session tokens,
user enrollment links, and API keys.
See FireEye IAM Organization on page 313.
Configure User Access Controls
View global View the global (system-defined) IAM roles and their entitlements.
roles System-defined roles provided by FireEye IAM correspond to the capabilities
granted by the roles implemented on FireEye Central Management, Email
Security — Server Edition, Network Security, and Endpoint Security
appliances and on cloud-based Helix. Global roles are designed to support
the functions that your information security team already performs using
those products.
Add custom (Optional) If you need different groupings of entitlements for IAM Web UI
roles roles or Helix roles, create IAM custom roles.
See FireEye IAM Roles on page 321.
290 © 2021 FireEye

Release 2021.1 FireEye IAM Initial Configuration Task List
Task Description
Provision Users
Create user Create an IAM account for every user that needs access to OIDC clients.
accounts l Specify the user's email address.
l Configure access controls by assigning roles and optional groups.
l Invite the user to enroll.
See FireEye IAM User Accounts on page 333.

NOTE: New users enroll by following emailed links to the enrollment page
for your IAM organization and creating their own passwords. After enrolling,
users can update their account information, preferences, and password by
logging in to the FireEye IAM Web UI with their FireEye IAM credentials.
Create user (Optional) To manage multiple users at once, create an IAM user group and
groups assign roles to the user group.
If you add to the user group a user account that has other roles that were
assigned directly, those roles are added to the user group implicitly.
See FireEye IAM User Groups on page 359.
© 2021 FireEye 291

292 © 2021 FireEye

CHAPTER 19: Managing Your

Own FireEye IAM User Account
l About Managing Your Own User Account on the next page

l Enrolling Your New FireEye IAM User Account on page 295
l Setting User Information and Preferences for Your IAM Account on page 299
l Changing the Password for Your IAM User Account on page 305
l About Two-Factor Authentication on page 306
l Setting Up a Smartphone as a Two-Factor Authentication Device on page 307
l Resetting Two-Factor Authentication on Your Smartphone on page 309
l Generating Two-Factor Authentication Codes in Advance on page 310
The tasks described in this section of the guide require only IAM User access. Other tasks
that require only IAM User access are described in other parts of the guide:
l Viewing the List of Roles on page 323

l Viewing the Lists of User Accounts on page 336
l Viewing the Lists of Internal and External User Groups on page 362
l Viewing, Copying, or Downloading an API Key You Created on page 376
l Creating an API Key on page 379
l Editing an API Key You Created on page 382
l Revoking an API Key You Created on page 384
© 2021 FireEye 293

System Security Guide CHAPTER 19: Managing Your Own FireEye IAM User Account
About Managing Your Own User

Account
Before you log in to your account, you must enroll the account in your IAM organization.
Account Enrollment
When your FireEye IAM account is created, you receive an email message that provides a
link to a self-service enrollment Web site. Your user access privileges are managed by your
IAM organization administrator. At the enrollment site, you configure additional account
information:
l Account password
l Account profile―Nickname and job title

l Account preferences―Time zone and language
l Phone number―Mobile device that receives login verification codes
l Notification method―Email, SMS text message, or disabled
You can update this information at any time. See Changing the Password for Your IAM
User Account on page 305 and Setting User Information and Preferences for Your IAM
Account on page 299.
IAM Username and Password

The user name for your FireEye IAM account is the email address at which you received
the invitation to enroll your new account.
You create the password for your account during the self-enrollment process. An
administrator of your IAM organization configures password strength requirements and
policies for password reuse, invalid login attempts, and inactive accounts.
To view the number of days remaining until your password expires, go to the Manage
Password and Security page (select My Settings > Password & Security). IAM
automatically sends a reminder email 15 days before a user account password is due to
expire. If necessary, the system sends a second reminder one day before the password
expiration date.
If you forget your password, or if you are locked out of your account, contact an IAM
organization administrator and request a password reset for your account.
294 © 2021 FireEye

Release 2021.1 Enrolling Your New FireEye IAM User Account
Phone Number
Your user preferences include your phone number. If two-factor authentication is enabled
for your IAM organization, you must enter a one-time use verification code as a part of
your login process. FireEye IAM sends verification codes to this phone number through
SMS text messages or voice calls.
If you install the Google Authenticator mobile app on your SmartPhone, the app generates
verification codes for your IAM user account. The app generates verification codes even if
your smartphone has no phone or data connectivity
Backup Codes for 2FA

If two-factor authentication is enabled for your IAM organization, you can generate a set of
ten verification codes as a backup measure. In case you do not have your mobile device
with you when you need to access your IAM account, you can authenticate by using one of
the backup verification codes.
Enrolling Your New FireEye IAM User

Account
When your IAM user account is created, you will receive an email message from
fireeyeapps@fireeye.com. The email message invites you to enroll your user account in
your team's IAM organization, and it includes a link to the IAM user self-enrollment site.
The enrollment link is single-use only, and you need to complete your enrollment in a
single session. If you lose your enrollment link, or if your link is no longer valid, contact an
IAM organization administrator and request a re-enrollment link.
NOTE: The link to the enrollment site is tied to your IAM account, and it cannot be
used to enroll another user account.
At the self-enrollment site, you create a password, enter a nickname, select a job title, enter
a phone number, and set your language and local time zone.
Be sure to enter the phone number to which you want IAM to send verification codes for
two-factor authentication. When you configure or change this phone number, IAM sends a
test message to the device so you can verify the number you configured. If 2FA is enabled,
the enrollment process prompts you to generate a set of ten verification codes as a backup
measure.
Finally, to verify your account credentials, the enrollment process prompts you to log in to
the FireEye IAM Web UI using your email address (the address to which the enrollment
invitation was sent) and the password you just created.
© 2021 FireEye 295

Prerequisites
l You have received an invitation to enroll in your FireEye IAM organization.
l You have your phone with you so that you can verify the number.
To enroll your new FireEye IAM user account in the IAM organization:
1. Open the email containing the invitation to enroll in the IAM organization.
2. Click Enroll.
3. Enter your email address―the email address that received the enrollment
invitation―and click Next.
296 © 2021 FireEye

Release 2021.1 Enrolling Your New FireEye IAM User Account
4. Create password twice and click Next.
5. Enter your user profile information and click Next.
In the following example, the message at the bottom of the dialog box informs you
that 2FA is enabled for your IAM organization.
© 2021 FireEye 297

6. If 2FA is enabled, verify your setup.
a. Click Confirm your SMS text code. A verification code is sent to the phone
number you entered in the previous step.
b. When you are prompted, enter the verification code that was sent to your
phone, and then click Next. A list of verification codes appears.
c. Click Download, save the verification codes, and then click Next.
298 © 2021 FireEye

Release 2021.1 Setting User Information and Preferences for Your IAM Account
7. Click Next.
8. Log in to the IAM Web UI. For details, see FireEye IAM Web UI Access on page 285.
9. (Optional) Download the Google Authenticator mobile app to your supported

smartphone. See Setting Up a Smartphone as a Two-Factor Authentication Device
on page 307.
Setting User Information and

Preferences for Your IAM Account
All users can log in to the FireEye IAM Web UI to manage their own account preferences.
The User Information view of the Manage Passwords and Security page enables you to
configure the following information for your account:
l User information―An avatar, nickname, job title, and time zone.

l Contact information―Email address and phone number.
l Account preferences―Language and security message notification method.
© 2021 FireEye 299

The following table describes the panels and fields in the User Information view:
Panel and Fields Description
User Information
(Optional) Click the upload icon and select a local

avatar file (up to 5 MB) to upload.
Nickname (Optional)
Job Title (Optional)
Primary Email The email address that is the primary user of this

account.
Initially this is the email address that was used to
enroll your account. You can use the Email Addresses
panel below to add another email address and
designate that address as the primary.
Phone Number The phone number to which FireEye IAM sends your

security messages (if SMS is your preferred notification
method) and one-time passwords (if you use Google 2-
Step Verification).
Initially this is the phone number specified when you
enrolled your account. You can use the
Phone Numbers panel below to add another phone
number and designate that number as the primary.
300 © 2021 FireEye

Panel and Fields Description
Preferred Notification Method The notification method you prefer for receiving

security messages (such as notices of changes made to
your account) from FireEye IAM:
l Email
l SMS
Primary Organization (Read-only) The name of the local IAM organization

with which you initially registered your account.
Secondary Organization (Read-only) More organization information you

provided when you initially registered your account.
Time Zone (Optional) Select the time zone used to display and

report FireEye IAM events.
Language The default setting is English.
Preferred UI Theme The type of UI background you want, Light or Dark.
Contacts
Contacts The list of email addresses and phone numbers

associated with this user account. Contacts that are
enrolled in the IAM organization are indicated with a
check mark: Other contacts have been sent
verification information but have not yet enrolled.
(Optional) Add another contact to this account.
Email Address l Enter a valid email address that is not already in

use in the IAM organization.
Designate the primary contact if more than one is

listed.
(Optional) Click the settings icon to remove a contact

from the list.
Country Code l Enter a valid phone number that is not already in

use in the IAM organization.
Phone Number
© 2021 FireEye 301

Prerequisites
l IAM Admin or IAM User access to the FireEye IAM Web UI.
To set user information and preferences for your FireEye IAM account:
1. Select My Settings > Profile to go to the Manage User Information and Preferences
page.
2. Click Edit to change from view to edit mode.
3. To upload or update your avatar, click the upload icon and select the avatar file
from your local drive.
4. To change your nickname, click the Enter Nickname field and enter a new
nickname.
5. To change your job title, click Enter Job Title field and enter or select a new job title.
6. To change your time zone, select a new time zone from the Select Time Zone field.
7. To change your Preferred Notification Method, select a method from the list.
8. To change your Preferred Language, select English or Japanese from the list.
NOTE: Selecting Japanese causes sections of the Helix Web UI to be
displayed in Japanese. To see the change take effect, log out of Helix and
then log in again.
9. To change your Preferred UI theme, select either Light or Dark.

10. To change the primary email address associated with your account, if multiple
addresses are listed, select the Primary option for that address.
11. To delete an email address associated with your account, click the settings icon for
that address and then click Remove.
12. To add an email address to your account:
a. Click Add New and select Email Address.
b. Enter the new email address and click Add Email.
c. Open your email message from fireeyeapps@fireeye.com.
302 © 2021 FireEye

d. Click Verify Email in the email message.
If you did not receive the email message, or if the link expired, click Re-send.
13. To change the primary phone number on your account, select the Primary option for
that number.
14. To delete a phone number from your account, click the settings icon for that phone
number, and then click Remove.
15. To add a new phone number to your account:

a. Click Add New and select Phone Number.
b. Enter the country code and phone number, and click Add Phone Number.
c. Check your phone a one-time-password in an SMS text message.
d. Enter the password in the SMS Text Authentication dialog box, and then click
Verify.
If you did not receive the SMS text message, or if the code expired, click
Resend Verification.
© 2021 FireEye 303

Viewing Your IAM Login Activity

Once you are logged into IAM, you can view the Login Activity for your user account. The
Login Activity page shows:
l Number of successful logins

l Number of failed logins
l Login success rate
l Last login time
l Last failed login time
l Details for the last 30 logins
Prerequisites
l You are able to log in to your IAM organization
To view your IAM login activity:
1. Log in to the IAM Web UI.

2. Select My Settings > Login Activity.
3. The last 30 logins are sorted by Date & Time. To resort them another way:
4. Select a Result or Reason to adjust the way the list is displayed.
The page displays the login history information for your user account. The following
information is provided about each login:
l Result of the login:

l Failed
l Success
l Reason for the login:
l Login
l Switch Account
l Reset Password
l Account Locked
l Inactive Account
l Invalid Password
l Password Not Set
l Product URL
304 © 2021 FireEye

Release 2021.1 Changing the Password for Your IAM User Account
l IP Address
l Date & Time (UTC)
Changing the Password for Your IAM

User Account
Use the Password panel in the Manage Passwords and Security page to change the
password for your FireEye IAM account.
NOTE: IAM automatically sends a reminder email 15 days before a user account

password is due to expire. If necessary, the system sends a second reminder one
day before the password expiration date.
Prerequisites
To change your FireEye IAM account password:
1. Log in to the FireEye IAM Web UI.

2. Select My Settings > Password & Security.
3. In the Password panel, click Change Password.
© 2021 FireEye 305

4. Enter your current password.
5. Enter your new password.

6. Enter your new password again.
7. Click Change Password.
About Two-Factor Authentication

Your IAM organization administrator or an IAM Admin can enable or require two-factor
authentication (2FA) an optional second layer of security for logging in to FireEye IAM user
accounts in your organization. FireEye IAM supports Google 2-Step Verification for two-
factor authentication.
Two-Factor Authentication
Two-factor authentication (2FA) is an optional second layer of security for logging in to
FireEye IAM user accounts in an IAM organization. If 2FA is enabled and enforced, even if
someone manages to steal your password, your user name and password credentials are
not sufficient to log in to your account. Two-factor authentication requires a user to provide
an additional verification that only the user can obtain using their smartphone.
When you log in to a FireEye IAM user account that is secured with 2FA, you begin by
entering your user name and password (knowledge factor) as you would normally. The
login page prompts you to enter a single-use verification code (possession factor). The code
is sent to your mobile device by SMS text message or voice call.
After you enter the verification code, you are authenticated and you are logged in to your
account.
306 © 2021 FireEye

Release 2021.1 Setting Up a Smartphone as a Two-Factor Authentication Device
Optional Google Authenticator Mobile App

If you have a supported smartphone, you can configure it as a two-factor authentication
device by installing the Google Authenticator mobile app on it. The app generates
verification codes even if your smartphone has no phone or data connectivity. For
information about managing the optional Google Authenticator app, see the following
topics:
l Setting Up a Smartphone as a Two-Factor Authentication Device below

l Resetting Two-Factor Authentication on Your Smartphone on page 309.
Setting Up a Smartphone as a Two-

Factor Authentication Device
If the FireEye IAM user accounts in your organization are secured using two-factor
authentication, you need a mobile device on which to receive SMS text messages and voice
calls from Google 2-Step Verification. If 2FA was enabled when you enrolled your user
account, the enrollment process prompted you to verify the phone number configured for
your account by sending a test verification code to that number.
To configure a supported smartphone as a two-factor authentication device, install the
Google Authenticator app on it. The app generates verification codes even if your
smartphone has no phone or data connectivity.
Prerequisites
l A supported mobile device. Refer to the FireEye IAM Release Notes.
l A Google account.
To set up a smartphone as a two-factor authentication device:

© 2021 FireEye 307

3. In the Two-Factor Authentication panel, click Configure 2FA App.
4. Enter the password for your FireEye IAM account.
5. Select your smartphone operating system.
6. Click Download Google Authenticator.
308 © 2021 FireEye

Release 2021.1 Resetting Two-Factor Authentication on Your Smartphone
7. Follow the instructions in the Google Account Help page "Install Google
Authenticator" for installing and configuring the Google Authenticator app on your
device.
Resetting Two-Factor Authentication on

Your Smartphone
This procedure describes how to reset the configuration of your smartphone as a two-factor
authentication device and configure the Google Authenticator mobile app. on your device.
Prerequisites
l A supported mobile device. Refer to the FireEye IAM Release Notes.
To reset two-factor authentication on your smartphone:

3. In the Two-Factor Verification panel, click Configure 2FA App.
4. Enter your FireEye IAM user account password in the Google Two-Factor

Authentication dialog box.
5. Select your mobile device operating system.
6. Click Reset.
© 2021 FireEye 309

7. Scan the QR code into your smartphone, and then click Next.
8. Verify your setup.
a. Click Enter code from your smartphone. A verification code is sent to the
phone number configured for your account.
b. When you are prompted, enter the verification code that was sent to your
phone, and then click Verify.
Generating Two-Factor Authentication

Codes in Advance
If 2FA was enabled when you enrolled your user account, the enrollment process prompted
you to generate a set of ten verification codes as a backup measure. In case you do not
have your mobile device with you when you need to access your IAM account, you can
authenticate by using one of the backup verification codes.
This procedure describes how to generate another set of verification codes.
310 © 2021 FireEye

Release 2021.1 Generating Two-Factor Authentication Codes in Advance
Restrictions for Two-Factor Authentication Backup

Codes
l Each code can be used only once.
l The codes must be used in the order listed

l Generating a new set of backup codes invalidates any backup codes you
downloaded previously but have not used.
Prerequisites
To generate a new set of two-factor authentication backup codes:

3. In the Two-Factor Authentication panel, click Generate New Codes.
4. Enter the password for your FireEye IAM account.
© 2021 FireEye 311

5. Click Generate Backup Codes. Each code will allow you log in to your FireEye IAM
account one time.
6. Click Download and save the file, or print a copy.
312 © 2021 FireEye

System Security Guide Security in a FireEye IAM Organization
CHAPTER 20: FireEye IAM

Organization
l Security in a FireEye IAM Organization below

l FireEye IAM Organization Settings on page 315
l Configuring the FireEye IAM Organization on page 318
Security in a FireEye IAM Organization

FireEye IAM provides multiple levels of security.
Allowed Email Domains

As an option, you can configure the system so that user accounts can be created for specific
email domains only,
Single-Factor Authentication
A FireEye IAM account is always secured using the account user name specified by the
administrator, combined with the password created by the user during self-enrollment in
the organization.
Two-Factor Authentication
If the IAM organization is additionally secured by a two-factor authentication (2FA) policy,
a user establishes identity by providing the user name and password followed by up to
three one-time passcodes. By default, all three two-factor authentication options are
Not Enabled, meaning that the IAM organization does not use 2FA.
© 2021 FireEye 313

System Security Guide CHAPTER 20: FireEye IAM Organization
FireEye IAM supports Google 2-Step Verification. With a smartphone enrolled as a Google
two-factor authentication device, the user obtains a one-time-use password from the Google
Authenticator mobile app, an SMS text message, a voice call, or some combination of the
three. If the Google Authenticator mobile app is installed on the user's phone, passwords
can be generated even when no Internet connection or mobile service is available. In case
the authentication device is not available, the user can use a one-time-use password from a
set of backup codes that was generated and stored ahead of time.
User Password Policy

The default password policy enforces password construction requirements, account lockout
after a certain number of failed login attempts, and expiration policies. An administrator
can select individual requirements and change the values associated with the options.
NOTE: IAM automatically sends a reminder email 15 days before a user account

password is due to expire. If necessary, the system sends a second reminder one
day before the password expiration date.
Web UI Session Timeout

Web UI sessions with IAM automatically expire after a certain period of time. An
administrator can also customize this setting.
Role-Based Access Controls

To allow a user to access OIDC clients, the organization administrator assigns the user
account a role for each product type that the user needs to access. System-defined global
roles are created automatically when FireEye creates an IAM organization. Global roles
grant product-specific user access permissions that are geared toward a job function
pertaining to that product. Global roles are provided for each supported FireEye appliance
type.
If your FireEye IAM Web UI role or Helix role has workflows that require a collection of
entitlements not covered by a global role, an administrator can create a custom role.
314 © 2021 FireEye

Release 2021.1 FireEye IAM Organization Settings
FireEye IAM Organization Settings

An IAM organization administrator configures the following settings for the organization:
l Allowed email domains

l Password complexity and password expiration times
l Options for two-factor authentication
l Expiration times for Web UI session tokens, user enrollment links, and API keys
The following table describes the configurable fields in the Organization Settings page:
Field Description
Organization Details and Description
Description A description of this IAM organization.
User Email Addresses
Allowed email domains (Optional) A comma-separated list of email domains allowed for
user accounts.
Default: No domains are specified (all email domains are
allowed).
Authentication Policy
Minimum policies (Optional) The minimum number of user identity factors required,
including the mandatory knowledge factor (the user password).
Increment this value for each possession factor in your policy.
Range: 1–4
Default: 1 (Single-factor authentication only)
© 2021 FireEye 315

Field Description
Options for Two-Factor Authentication
(Optional) Override the default value of any of the two-factor authentication (2FA) settings.
2FA is disabled by default. All 2FA options are Not Enabled and Minimum Policies is 1.
If any 2FA options are Mandatory, users must provide those knowledge factors to
authenticate. If two or more 2FA options are Enabled, users can provide any one of the
knowledge factors.
One-Time Password The policy for using one-time-use passwords generated by the
Google Authenticator app on an Android, Blackberry, or iPhone
device:
l Mandatory
l Enabled
l Not enabled (default)
Text Message The policy for using one-time-use passwords sent by SMS message:
l Mandatory
l Enabled
Voice Call The policy for using one-time-use passwords sent by voice call:
l Mandatory
l Enabled
316 © 2021 FireEye

Release 2021.1 FireEye IAM Organization Settings
Field Description
Password Policy
Password complexity (Optional) Customize the policy for single-factor authentication

and expiration passwords:
parameters l FireEye Policy―All options are selected. (Default)
l Custom Policy—An administrator selects options
individually.
The following options can be selected and edited:

□ Password expires after 60 days
□ Cannot use last 24 passwords
□ Account deactivation due to 90 days of inactivity
□ Allow 3 invalid attempts before lockout
□ Locked account is unlocked after 1800 seconds (30 minutes)
□ After 900 seconds (15 minutes), invalid attempt count is reset
□ At least 12 characters
□ At least 1 lowercase character
□ At least 1 numeral
□ At least 1 special character
□ At least 1 uppercase character
Expiration Details
(Optional) Override the default value of any of the following expiration times. Specify
expiration times in units of seconds, minutes, hours, days, or years by appending the
letter s, m, h, d, or y.
Token expires in Web UI session timeout.

Default: 12h
Link expires in User enrollment link timeout.

Default: 48h
API key expires in API connection timeout.

Default: 90d
© 2021 FireEye 317

Configuring the FireEye IAM

Organization
To configure security settings for the IAM organization, use the Organization Settings page.
Prerequisites
l You have read and understand Security in a FireEye IAM Organization on page 313
and FireEye IAM Organization Settings on page 315.
l You have chosen values for the organization settings listed at the beginning of this
procedure.
l You have IAM Admin access to the FireEye IAM Web UI.
To configure the FireEye IAM organization settings:
2. Select My Settings > My Organization.

The Organization Settings page displays the settings for the IAM organization.
3. (Read-only) Verify the read-only information in the Organization Name, Oracle

Customer ID, and Salesforce ID fields. This identification information was
configured for your IAM organization by FireEye.
4. Enter a brief description of your IAM organization.
318 © 2021 FireEye

Release 2021.1 Configuring the FireEye IAM Organization
5. (Optional) Enter a comma-separated list of email domains allowed for user

accounts. The list is empty by default. If no domains are specified, all email
domains are allowed.
6. (Optional) Use the Set the options for two-factor authentication section of the page
to configure options for two-factor authentication. Refer to the table in FireEye IAM
Organization Settings on page 315.
a. In the Minimum Policies field, select the total number of user identity factors
required.
b. Configure the options requiring users to enter a one-time password (OTP).
Google OTPs can be obtained through different devices.
Configure the two-factor authentication policy by setting the values for the
device options:
l To forego two-factor authentication, leave all of the 2FA options
Not-Enabled and leave the Minimum Policies value set to 1. This is
not recommended.
l To require users to enter a password obtained through a particular
type of authentication device, set that option to Mandatory and
increment the Minimum Policies value.
l To allow users to enter a password obtain through an authentication
device of their choice, set those two or three options to Enabled
7. (Optional) Customize the user password complexity policy by selecting only the
requirements you want enforced. The default FireEye Policy specifies that all of the
requirements must be enforced.
Configure the password policy for users in your organization. Refer to the table in
FireEye IAM Organization Settings on page 315.
© 2021 FireEye 319

8. (Optional) Customize the following expiration times, as described in the table that
begins at FireEye IAM Organization Settings on page 315.
l Web UI session tokens
l User enrollment links
l API key
9. Click Update Organization.
320 © 2021 FireEye

System Security Guide About Roles
CHAPTER 21: FireEye IAM Roles

l About Roles below

l About Entitlements on the next page
l Viewing the List of Roles on page 323
l Viewing the Entitlements Assigned to a Role on page 325
l Creating a Custom Role on page 326
l Editing a Custom Role on page 329
l Deleting Custom Roles on page 331
About Roles
Role-based access controls determine what users can see and do on OIDC clients in the
IAM organization. A role associates a product-specific job function with the product-
specific access privileges needed to perform that job. On an Email Security — Server
Edition appliance, for example, the Analyst role grants users the privileges necessary to
perform email malware analysis tasks.
User accounts can be assigned roles for more than one product type, and they typically are.
A user can be assigned multiple roles for accessing the FireEye Web UI or Helix Web UI.
For access to FireEye appliances, a user is typically assigned a role for each product type in
the IAM organization.
Global Roles
FireEye IAM provides a comprehensive set of system-defined roles, called global roles, for
granting user access to its own Web UI and also to the products that integrate with IAM:
Helix and supported FireEye products. Global roles grant product-specific user access
permissions that are geared toward a job function pertaining to that product. The IAM
© 2021 FireEye 321

System Security Guide CHAPTER 21: FireEye IAM Roles
global roles and the permissions they grant are described in FireEye IAM Entitlements on
page 409.
Global roles are created automatically when FireEye creates an IAM organization, and they
cannot be modified or deleted.
Custom Roles
For the IAM Web UI roles and Helix, if none of the global roles match your workflow
needs, a FireEye IAM administrator can create custom roles for the IAM organization. For
more information, see Creating a Custom Role on page 326.
FireEye IAM does not support custom roles for FireEye appliances.
Fallback Roles
The IAM roles for FireEye appliances include six roles that grant access privileges needed
to perform a specific job function: Admin, Analyst, Auditor, Monitor, Operator, or Reject.
These job-specific roles are product-agnostic rather than product-specific. Each role grants
job-specific access privileges for all supported FireEye appliance types: CM Series,
EX Series, NX Series, and HX Series appliances. The roles act as "fallback roles" because a
FireEye appliance will apply a fallback role only for users that are not assigned any
appliance-specfic roles.
For details, see Fallback Roles for FireEye Appliances on page 504.
About Entitlements
Each role is associated with one or more entitlements. An entitlement specifies that a
service (such as the FireEye IAM Web UI) or an application (such as a Central
Management appliance) can access a particular resource or feature to perform a particular
action.
NOTE: Each application or service that integrates with FireEye IAM has its own
set of entitlements.
322 © 2021 FireEye

Release 2021.1 Viewing the List of Roles
Entitlement names take one of two forms:

<service>.<resource>.<action>
The FireEye IAM Web UI and Helix (previously known as the Threat Analytics
Platform, or TAP) have entitlements that each represents an individual, fine-grained
user access privilege. Thus the global roles for these products map to multiple
entitlements. Examples:
l iam.apikeys.delete―The ability to delete any API key in the IAM organization.
l tap.alerts.add―The ability to add new alerts in Helix.
For more information, see Entitlements for the FireEye IAM Web UI Roles on page 411
and Entitlements for Helix Roles on page 426.
<service>.role.<action>
Each role for a FireEye appliance maps to a single entitlement that represents multiple
access privileges. Examples:
l cms.role.analyst―Analyst privileges on a Central Management appliance.
l appliance.role.auditor―Auditor fallback privileges on all FireEye appliances.
For more information, see Entitlements for the FireEye Appliance Roles on page 494.
Viewing the List of Roles

To view the list of roles in your FireEye IAM organization, use the Role Definitions view of
the Roles page.
© 2021 FireEye 323

The column labeled "# of Entitlements" shows that the FireEye appliance roles have only
one entitlement each. Each entitlement is a collection of user access permissions. By
contrast, the FireEye Appliance Org Admin role, the IAM Web UI roles, and Helix roles
have multiple entitlements.
The following table describes the columns in the Role Definitions view.
Field Description
Name The name of a global or custom role defined in your IAM organization.
You can sort and filter the list on this field. Filtering is case-sensitive,
and it does not match wild card characters.
Product The type of product to which this role applies.
Type Role type:

l Global―A system-defined role mapped to one or more system-
defined entitlements.
l Custom to this org―A custom role.
Description A brief description of the role.

You can sort and filter the list on this field. Filtering is case-sensitive,
and it does not match wild card characters.
# of Entitlements The number of entitlements assigned to the role. Each FireEye appliance
role is associated with only one entitlement which in turn maps to a
collection of user access privileges.
Options Click the Options icon and select an operation to view, edit, or delete.
Prerequisites
To view the list of roles in your organization:

2. Select Organization Settings > Roles. The Role Definitions view lists the global and
custom roles defined in your IAM organization.
3. (Optional) Sort and filter the list on the Name field or the Description field.
324 © 2021 FireEye

Release 2021.1 Viewing the Entitlements Assigned to a Role
Viewing the Entitlements Assigned to a

Role
To view the entitlements assigned to a role in your FireEye IAM organization, use the
Edit Roles view of the Roles page.
The following table describes the fields in the Role Definitions view.
Field Description
Name (Read-only) A unique name for the role.
Description (Read-only) A brief description of the role.
Select Product (Read-only) The product type associated with this role.
Available Entitlements
Entitlements Name of an entitlement that is not assigned to the role.
Description A brief description of the entitlement.
Assigned Entitlements
Entitlements Name of an entitlement that is assigned to the role.
Description A brief description of the entitlement.
© 2021 FireEye 325

Prerequisites
l IAM Admin access to the FireEye IAM Web UI.
To view the entitlements assigned to a role:

3. (Optional) Sort and filter the list on the Name field or the Description field. Filtering
is case-sensitive, and it does not match wild card characters.
4. Click the name of the role you want to view. The Edit Roles page shows you which
entitlements are assigned to the selected role.
The entitlements assigned to a global role are specific to the product for which the
role grants user access. Custom roles can have entitlements for one or more
products.
Creating a Custom Role

To create a custom role in your FireEye IAM organization, use the Role Definitions view of
the Roles page. You need to specify a role name that is unique in your IAM organization,
and you need to select a product type. Within the selected product type, you can assign
multiple entitlements to the custom role.
NOTE: You can use a global role as a template for determining which

entitlements to grant to a custom role. For lists of the entitlements granted to
each role, as well as a full list of all Helix entitlements, see FireEye IAM
Entitlements on page 409.
TIP: If the organization will have a large number of custom roles, use a
naming convention that enables you to filter and sort on the Name field or the
Description field to quickly find a group in the main view of the Roles page.
Prerequisites
To create a custom role:

326 © 2021 FireEye

Release 2021.1 Creating a Custom Role
3. Click Add.
4. Enter a name and a description for the role and click Next.
5. Select a product type for the role, and then click Next.
© 2021 FireEye 327

6. Assign entitlements to the role. Repeat the following steps for each entitlement you
want to assign the custom role.
a. In the Available Entitlements list on the left, locate the entitlement you want
to assign.
b. In the Access column for that entry, click Grant.
The entitlement moves from the Available Entitlements list to the Assigned
Entitlements list on the right.
In the following example, browse, edit, read, and add entitlements are about to be
assigned to a new custom role.
7. If you need to remove an entitlement from the role, do the following:

a. In the Assigned Entitlements list on the right, locate the entitlement you want
to remove from the role.
b. In the Access column for that entry, click Remove.
The entitlement moves from the Assigned Entitlements list to the Available
Entitlements list on the left.
8. After you have finished specifying entitlements, click Create Role.
9. Click OK.
The list in the Role Definitions view contains the name of the new custom role. The
value in the Type field is Custom to This Org.
328 © 2021 FireEye

Release 2021.1 Editing a Custom Role
Editing a Custom Role

You can change the name, description, and role assignment of a custom role in your
FireEye IAM organization. To edit a custom role, use the Role Definitions view of the Roles
page.
NOTE: You cannot edit or delete global roles, and you cannot change the product
type of a custom role.
NOTE: If you change a role while an affected user is logged in, the user is forcibly
logged out. When the user logs in again, the user has the capabilities provided by
the new definition of the role.
Prerequisites
To edit a custom role:

© 2021 FireEye 329

3. (Optional) Sort and filter the list on the Name field or the Description field.
4. Click the name of the custom role you want to edit. The Edit Role view shows
details about the selected role.
5. To change the name or description of a custom role, enter new text in the Name or
Description fields.
6. To add an entitlement to the custom role, do the following:
a. In the Available Entitlements list, find the entitlement you want to add.
b. Go to the Options column and click Grant.
7. To remove an entitlement from the custom role, do the following:
a. In the Assigned Entitlements list, find the entitlement you want to remove.
b. Go to the Options column and click Remove.
8. Verify that the entitlement names are updated in the Available Entitlements list and
in the Assigned Entitlements list.
9. Click Update Role.
330 © 2021 FireEye

Release 2021.1 Deleting Custom Roles
Deleting Custom Roles

You can delete custom roles individually, or you can delete multiple custom roles at once.
To delete custom roles from your FireEye IAM organization, use the Role Definitions view
of the Roles page.
NOTE: You cannot edit or delete global roles, and you cannot change the product
type of a custom role.
Prerequisites
To delete custom roles:

3. (Optional) Sort and filter the list on the Name field or the Description field. Filtering
is case-sensitive, and it does not match wild card characters.
4. To delete an individual role:
a. Select the Options icon and select Remove.
b. Click OK.
© 2021 FireEye 331

5. To delete multiple custom roles at once:
a. Select the checkbox for each role you want to delete.
b. Click Remove.
c. Click OK.
332 © 2021 FireEye

System Security Guide About User Accounts
CHAPTER 22: FireEye IAM User

Accounts
l About User Accounts below

l About External User Accounts on the next page
l Viewing the Lists of User Accounts on page 336
l Viewing the Roles Assigned to a User Account on page 338
l Creating a User Account on page 340
l Adding an External User Account on page 343
l Editing a User Account on page 347
l Resetting the Password for a Local User Account on page 352
l Re-Enrolling a Local User Account on page 353
l Deleting User Accounts on page 355
l Disabling and Enabling User Accounts on page 357
About User Accounts

A user account represents a person or service who authenticates against the FireEye IAM
server to access on-premises and cloud-based resources in your IAM organization. IAM
users typically log in at the Web UI of a resource or the FireEye IAM service. IAM users
can also programmatically access the API of the FireEye IAM service.
User Account Creation

Initially the only user account in a new IAM organization is the IAM organization
administrator, which is the default user account created for the organization by FireEye.
© 2021 FireEye 333

System Security Guide CHAPTER 22: FireEye IAM User Accounts
The organization administrator is responsible for provisioning other FireEye IAM user
accounts in the organization.
NOTE: The default organization administrator can create IAM Admin users and
delegate to them the task of creating the other user accounts.
To provision a user account, an administrator specifies a user name that is an email

address, assigns user access permissions, and then emails the end user an invitation to
enroll the account in the IAM organization. During the enrollment process, an end user
creates their own password and enters user preferences.
Permissions Granted by Directly Assigned Roles

When you create a user account, you grant access permissions by assigning roles directly
to the account. If no role is assigned, the user cannot log in to cloud-based FireEye Helix,
nor to any on-premises and cloud-based FireEye appliances.
Permissions Granted by Membership in a User Group

After a user account is created, you can modify its permissions by assigning the user to a
user group. A user group can have permissions attached through directly assigned roles. A
user group also inherits the roles directly assigned to its members. For more information,
see FireEye IAM User Groups on page 359.
The Potential Impact of Deleting a User Account

When you delete a user local account from your IAM organization, FireEye IAM implicitly
removes instances of that account from any groups to which the user might be assigned.
Removing a user from a user group―whether done explicitly or implicitly―might reduce
the access privileges of the users that remain in those groups.
About External User Accounts

A user account defined in a different IAM organization can be invited to enroll in your
IAM organization. After the external user enrolls, the account is visible in the FireEye IAM
Web UI. For example, you might add an external account to allow a FireEye Customer
Support engineer to access your organization. You can disable this access later by
removing the external user account from your IAM organization.
334 © 2021 FireEye

Release 2021.1 About External User Accounts
Permissions Assigned in This Organization

An external user's access privileges in your organization are specified when you create the
account and invite the user to enroll. The user's permissions within your IAM organization
cannot be viewed or modified in the user's primary organization or in any other
organization in which the user is enrolled. To terminate an external user's access to your
organization, you delete the account from your list of users.
Limitations for Managing an External User Account

The following limitations apply to managing external user accounts:
l You cannot re-enroll an external user. This must be done from the user's primary
organization.
l You cannot reset the password for an external user. This must be done from the
user's primary organization.
l Deleting an external user account removes the account from the list of External
Users in this IAM organization. The account remains intact in its primary
organization.
© 2021 FireEye 335

Viewing the Lists of User Accounts

To view the lists of user accounts in your FireEye IAM organization, use the Users page.
The main view of the Users page lists internal users and external users separately.
The following table describes the columns in the lists on the Users page:
Field Description
Email (Read-only) The email address used to create this account.

You can sort and filter the list on this field. Filtering is case-sensitive, and
it does not match wild card characters.
Nickname An optional nickname entered by the account user.

Phone Number (Read-only) A contact phone number entered by the account user.

336 © 2021 FireEye

Release 2021.1 Viewing the Lists of User Accounts
Field Description
Internal user accounts only
Status (Read-only) The enrollment status of the user account:

l Active—The user account is defined in this IAM organization.
l Inactive—The user account has been deactivated due to inactivity.
l Invited—The user has been invited, but the account is not yet
enrolled.
l Locked—The user account is locked.
Options Operation you can perform on the user account:

l View/Edit―View or edit the role assignments for this user account.
l Reset Password―Reset the password of a locked-out user.
l Re-Enroll―Send the user a new enrollment link.
l Disable―Disable the user account.
l Enable―Enable the user account.
l Remove―Remove the user account.
External user accounts only
Status (Read-only) The enrollment status of the external user account:

l Active—The user has been added, and the account has enrolled.
l Invited—The user has been invited, but the account is not yet
enrolled.
Options Operations you can perform on the external user account:

l View/Edit―View or edit the roles assigned in this organization.
l Remove―Remove from the list of external users in this organization.
Prerequisites
To view the lists of user accounts:
2. Select Organization Settings > Users.

The Users page lists all FireEye IAM user accounts known to your IAM
organization.
The Internal Users panel lists user accounts that are defined in your organization.
The External Users panel lists user accounts that are defined in other organizations
but which the organization administrator has added and assigned roles.
© 2021 FireEye 337

3. (Optional) Sort and filter the list on the Email field, the Nickname, field, or the
Phone Number field.
Viewing the Roles Assigned to a User

Account
To view the roles assigned to a FireEye IAM user account, use the Edit User view of the
Users page.
Roles directly assigned to a user account are listed in the Assigned Products list on right.
The Assigned Products list does not show the roles that the user is assigned indirectly
through membership in a FireEye IAM user group. To see those privileges, you must know
the user account's user group memberships. See FireEye IAM User Groups on page 359.
338 © 2021 FireEye

Release 2021.1 Viewing the Roles Assigned to a User Account
The following table describes the fields in lists in the Edit User view:
Field Description
Email (Read-only) The user's email address. In FireEye IAM, the account user
name is an email address.
If this is an internal user account, this the email address that was used
to enroll the account in this organization (the user's primary
organization).
If this is an external user account, this is the email address that was
used to enroll the account in a different organization (the user's
primary organization).
External user (In the External Users list only) The name of the external user's
organization primary organization.
Available Products
Products (Read-only) A product type for which the user is not assigned roles.
Assign Roles If you want to assign the user roles for a product type in this list, click
Grant in this column.
Assigned Products
Products Assigned (Read-only) The products for which the user has roles assigned.
Roles (Read-only) Roles for this product type that are assigned to the user.
Options Click the Options icon and select an operation to perform on this role:
l Configure―Assign or remove individual roles for this product.
l Remove―Remove all assigned roles for this product.
Prerequisites
© 2021 FireEye 339

To view the roles assigned to a user account:

organization.
3. Select the user account you want to view.

The Assigned Products panel lists the product-specific roles assigned directly to the
user. It does not show roles assigned to the account indirectly through membership
in a FireEye IAM user group.
In the following example, the user is assigned four roles from three products.
Creating a User Account

You create a new user account by defining it in your IAM organization and inviting the
user to enroll. You need to specify the user's email address and the product-specific roles to
be assigned to the user. User accounts can be assigned roles for more than one product
type, and they typically are. A user can be assigned multiple roles for accessing the FireEye
Web UI or Helix Web UI. For access to FireEye appliances, a user is typically assigned a
role for each product type in the IAM organization.
340 © 2021 FireEye

Release 2021.1 Creating a User Account
Until the user enrolls, the account has a Status value of Invited. After the user completes
the enrollment process, the account has a Status value of Active. For details about the user
account enrollment process, see the instructions in Enrolling Your New FireEye IAM User
Account on page 295. Also see Viewing the Lists of User Accounts on page 336 and
Viewing the Roles Assigned to a User Account on page 338.
To create a new user account, you start at the Users page. The main view of the Users page
lists internal users and external users separately. After the user account is created, it
appears in the Internal Users panel.
The Invite User View

The following table describes the fields in the Invite User view (used to create a new
internal user account) and the Add User view (used to add a user account from another
organization):
Field Description
Email Enter the user's email address. In FireEye IAM, the account user name
is an email address.
l If you are creating a new user account in this organization, enter
the email address that will be used to enroll the account in this
organization (the user's primary organization).
l If you are adding a user account that is defined in an external
organization, enter the email address that was used to enroll the
account in the that organization (the user's primary organization).
NOTE: When you view the lists of all user accounts, the Internal Users
list and the External Users list can be sorted and filtered on the Email
column.
External user (Only if you are adding an external user account) Enter the name of the
organization external user's primary organization.
Available Products
Products A product type for which the user currently is not assigned roles.
Assign Roles If you want to assign the user roles for a product in this list, click
© 2021 FireEye 341

Field Description
Assigned Products
Products Assigned A product type for which roles are assigned to the user.
Roles The roles that the user is currently assigned for this product type.
Options Operations you can perform on this role:

l Remove―Remove all roles for this product from the user account.
Prerequisites
l The email address by which the user will be enrolled in the organization.
To create a user account:

organization.
3. Click Invite in the Internal Users panel.

4. Enter the user's email address and then click Next.
NOTE: Later, during the self-enrollment process, the user can create a password and
specify a nickname, phone number, and other information.
342 © 2021 FireEye

Release 2021.1 Adding an External User Account
5. Find the product type in the Available Products list and click Grant.
6. In the Roles tab, select checkboxes for the roles you want to assign the user.
7. Click Assign.
8. To assign the user roles for another product type, repeat steps 5 through 7.
9. After all roles have been assigned, click Invite. The user is sent a link to the FireEye
IAM enrollment portal.
The user account appears in Internal Users panel of the Users main view. The
Status value Invited. After the user completes the self-enrollment process, the Status
value changes to Active.
Adding an External User Account

To allow a user defined in a different IAM organization to access resources in your own
IAM organization, you can add an external user account to your organization, assigning
roles that grant the account selected access privileges in your organization. An external
user account can be used to allow a partner or FireEye support engineer to access your
FireEye appliances.
© 2021 FireEye 343

NOTE: By default, FireEye Customer Support can access your IAM organization
through the external user groups that are automatically added to your
organization when it is created: FireEye Support - Level 1 and
FireEye Support - Levels 2 & 3. Unlike an external user account, an external user
group accesses the resources in your organization with privileges controlled by its
owning organization. See About Internal User Groups on page 359.
To give the external user account access to your IAM organization, you need to know the
name of the user's primary organization (the organization where the account is defined
and enrolled) and the email address for that user account. To specify the access privileges
granted to the external user, you assign the account one or more roles for each product the
user is allowed to access in your organization. User accounts can be assigned roles for
more than one product type, and they typically are. A user can be assigned multiple roles
for accessing the FireEye Web UI or Helix Web UI. For access to FireEye appliances, a user
is typically assigned a role for each product type in the IAM organization.
An external user account retains the access privileges granted in your organization until
you edit the account's role assignments or remove the account from the list of external
users in your organization.
To add an external user account, you start at the Users page. The main view of the Users
page lists internal users and external users separately. After the external user account is
added, it appears in the External Users panel.
The following table describes the fields in the Invite User view (used to create a new
internal user account) and the Add User view (used to add a user account from another
organization):
Field Description
Email Enter the user's email address. In FireEye IAM, the account user name
is an email address.
l If you are creating a new user account in this organization, enter
the email address that will be used to enroll the account in this
organization (the user's primary organization).
l If you are adding a user account that is defined in an external
organization, enter the email address that was used to enroll the
account in the that organization (the user's primary organization).
NOTE: When you view the lists of all user accounts, the Internal Users
list and the External Users list can be sorted and filtered on the Email
column.
External user (Only if you are adding an external user account) Enter the name of the
organization external user's primary organization.
344 © 2021 FireEye

Release 2021.1 Adding an External User Account
Field Description
Available Products
Products A product type for which the user currently is not assigned roles.
Assign Roles If you want to assign the user roles for a product in this list, click
Assigned Products
Products Assigned A product type for which roles are assigned to the user.
Roles The roles that the user is currently assigned for this product type.
Options Operations you can perform on this role:

l Remove―Remove all roles for this product from the user account.
Prerequisites
l The email address by which the user is enrolled in the other IAM organization.
l The name of the external user's primary organization.
To add a user account from a different organization:

organization.
© 2021 FireEye 345

3. Click Add in the External Users panel.

4. Enter the email address under which the user is enrolled in their primary IAM
organization, and then click Next.
5. Select the name of the external user's primary organization and click Next.
6. In the Available Products list, locate the product type and click Grant.
346 © 2021 FireEye

Release 2021.1 Editing a User Account
7. In the Roles tab of the Assign Access for Product dialog box, select the check box for
each product-specific role you want to assign the user.
8. Click Assign.
9. To assign the external user roles for another product type, repeat steps 7 through 9.
10. After all roles have been assigned, click Add. The user account appears in the
External Users panel of the Users main view.
Editing a User Account

This procedure describes how to change the access privileges granted to a user account in
your IAM organization. To add or remove privileges, you add or remove the roles assigned
directly to the user account. User accounts can be assigned roles for more than one product
type, and they typically are. A user can be assigned multiple roles for accessing the FireEye
Web UI or Helix Web UI. For access to FireEye appliances, a user is typically assigned a
role for each product type in the IAM organization.
Changes to a user's role assignments are made product by product. First you select a
product type, then you change the user's role assignments for that product.
IMPORTANT! When you delete a user local account from your IAM

organization, FireEye IAM implicitly removes instances of that account from
any groups to which the user might be assigned. Removing a user from a user
group―whether done explicitly or implicitly―might reduce the access
privileges of the users that remain in those groups.
© 2021 FireEye 347

To change a user's role assignments, use the Edit User view of the Users page and the
Roles tab of the Assign Access for Product dialog box.
The following table describes the fields in lists in the Edit User view:
Field Description
Email (Read-only) The user's email address. In FireEye IAM, the account user
name is an email address.
If this is an internal user account, this the email address that was used
to enroll the account in this organization (the user's primary
organization).
If this is an external user account, this is the email address that was
used to enroll the account in a different organization (the user's
primary organization).
External user (In the External Users list only) The name of the external user's
organization primary organization.
348 © 2021 FireEye

Field Description
Available Products
Products (Read-only) A product type for which the user is not assigned roles.
Assign Roles If you want to assign the user roles for a product type in this list, click
Assigned Products
Products Assigned (Read-only) The products for which the user has roles assigned.
Roles (Read-only) Roles for this product type that are assigned to the user.
Options Click the Options icon and select an operation to perform on this role:
l Remove―Remove all assigned roles for this product.
From the Add User view or the Edit User view, there are two ways to open the Assign
Access for Product dialog box for a product type:
l While creating a new user account―Go to the Available Roles list and click Grant
for the product type.
l While editing an existing user account―Go to the Assigned Roles list, click the
Options icon for the product type, and select Configure.
The following table describes the fields in the Roles tab of the Assign Access for Product
dialog box.
Field Description
(Checkbox or Select roles to assign to the user, and then click Assign.
radio button)
Role The name of a FireEye IAM role for the selected product.
# of Permissions The number of permissions granted by the role. Hover over the number
in this column to view the list of permissions associated with the role.
Prerequisites
© 2021 FireEye 349

To remove all roles for a specific product:

organization.
3. Click the user account you want to edit and click Edit.
The Available Products panel on the left side of the page lists product types that
currently have no roles assigned to the user.
The Assigned Products panel on the right side of the page lists the product types
that currently have roles assigned to the user. The Roles column shows the roles the
user is assigned for each product in this list.
4. In the Assigned products list, find the product type whose roles you want removed.
5. Click the Options icon and select Remove.
6. Click Save.
7. To change more role assignments for the user, go back to step 3.
To assign or remove individual roles:

organization.
350 © 2021 FireEye

3. Click the name of the user account you want to edit and click Edit.
The Available Products panel on the left side of the page lists product types that
currently have no roles assigned to the user.
The Assigned Products panel on the right side of the page lists the product types
that currently have roles assigned to the user. The Roles column shows the roles the
user is assigned for each product in this list.
4. Open the Assign Access for Product dialog box for the product type for which you
want to assign or remove a role.
l If you want to assign a role for a product type that currently has no roles
assigned to the user, click Grant in the Assign Roles column for that product.
l If you want to assign or remove a role for a product type that currently has
roles assigned to the user, click the Options icon and select Configure.
The Assign Access for Product dialog box opens for the selected product type.
5. Select or clear the checkbox for each role you want to assign or remove from the user
account.
6. Click Assign.
7. To change more role assignments for the user account, repeat steps 9 through 11.
8. Click Save.
© 2021 FireEye 351

Resetting the Password for a Local User

Account
You can reset the password of a local user who has forgotten their account password.
FireEye IAM automatically emails the user a link to a password reset page for that account.
You can also copy the link to the clipboard of your local system.
NOTE: You cannot reset the password of an external user.
To reset the password of a local user account, use the Users page.
Prerequisites
To reset the password of a local user account:

organization.
352 © 2021 FireEye

Release 2021.1 Re-Enrolling a Local User Account
Phone Number field.
4. Find the user account that needs the password reset.
5. Click the Options icon for that user account and select Reset Password.
6. Click OK.
FireEye IAM automatically sends the user a link to a password reset page for that
account.
7. (Optional) To copy the link to the password reset page, click Copy Links near the
top of the page and click the Copy icon.
Save the link. If the user did not receive the automated email message, you can send
the link again using your own email account.
Re-Enrolling a Local User Account

You can re-enroll an internal user whose enrollment link has expired. When you re-enroll a
user, FireEye IAM automatically sends the user a link to the re-enrollment page for that
account.
NOTE: You cannot re-enroll an external user.
© 2021 FireEye 353

To re-enroll a local user account, use the Users page.
Prerequisites
To re-enroll a local user account:

organization.
Phone Number field.
4. Find the user account you need to re-enroll.
5. Click the Options icon for that user account and select Re-Enroll.
6. Click OK.
FireEye IAM automatically sends the user a re-enrollment link.
354 © 2021 FireEye

Release 2021.1 Deleting User Accounts
7. (Optional) To copy the re-enrollment link, click Copy Links near the top of the page
and click the Copy icon.
Save the link. If the user did not receive the automated email message, you can send
the link again using your own email account.
Deleting User Accounts

You can delete users from the Internal Users lists individually, or you can delete multiple
users at once. This removes the account definition from your IAM organization.
You can remove users from the External Users list individually, or you can remove
multiple external users at once. Removing an external user does not remove the account
definition from its primary IAM organization.
To delete user accounts from your FireEye IAM organization, use the Users page.
© 2021 FireEye 355

IMPORTANT! When you delete a user local account from your IAM

organization, FireEye IAM implicitly removes instances of that account from
any groups to which the user might be assigned. Removing a user from a user
group―whether done explicitly or implicitly―might reduce the access
privileges of the users that remain in those groups.
Prerequisites
To delete user accounts:

organization.
3. To delete an individual user:
a. Click the Options icon for the user you want to delete, and select Remove.
b. Click OK.
4. To delete multiple users:
a. Select the checkbox for each user you want to delete.
b. Click Remove.
c. Click OK.
356 © 2021 FireEye

Release 2021.1 Disabling and Enabling User Accounts
Disabling and Enabling User Accounts

You can disable and enable user accounts. Disabling an account locks it, keeping it from
use until you enable it.
To disable or enable user accounts from your FireEye IAM organization, use the Users
page.
Prerequisites
To disable or enable user accounts:

organization.
3. To disable a user account:
a. Click the Options icon for the user you want to disable, and select Disable.
b. Click OK.
4. To enable a user account:
a. Click the Options icon for the user you want to enable, and select Enable.
b. Click OK.
© 2021 FireEye 357

358 © 2021 FireEye

System Security Guide About Internal User Groups
CHAPTER 23: FireEye IAM User

Groups
l About Internal User Groups below

l About External User Groups on the next page
l Viewing the Lists of Internal and External User Groups on page 362
l Viewing the Roles and Users Assigned to an Internal User Group on page 364
l Creating an Internal User Group on page 367
l Editing an Internal User Group on page 371
l Deleting Internal User Groups on page 373
About Internal User Groups

An internal user group simplifies the task of granting a collection of user accounts the
same access privileges to the OIDC clients registered in your IAM organization. Any
existing user accounts known to your IAM organization can be assigned to a user group:
l Primary users―User accounts defined in your IAM organization.

l External users―User accounts defined in a different IAM organization that you
enrolled in your IAM organization and to whom you assigned roles for accessing
your organization.
User Group Access Privileges

A user group's access privileges are a combination of the roles directly assigned to it and
the roles directly assigned to its members. Adding a user account to a user group will
increase the group's access privileges if the user's directly assigned roles grant privileges
that the group does not already have. Removing a user account from a user group will
© 2021 FireEye 359

System Security Guide CHAPTER 23: FireEye IAM User Groups
reduce the group's access privileges if the user's directly assigned roles grant privileges
that the group does not have through other sources.
NOTE: Deleting a user group removes access privileges that other users received
through their membership in that group.
One System-Defined User Group

When FireEye creates an IAM organization, a system-defined Organization Owners user
group is created. This group contains all users who are also organization owners. Users in
this group can access all roles of all assigned products. You cannot modify or delete the
Organization Owners user group.
About External User Groups

An external user group allows one IAM organization to have user accounts that have
access privileges in another IAM organization. A user group that is listed in your IAM
organization as an external user group is defined in its primary (or "owning") IAM
organization, where it is an internal user group. It is a user group that was created for the
purpose of accessing the OIDC client resources of another IAM organization.
NOTE: External user groups are defined in their owning IAM organizations by

FireEye Customer Support only, and they are added to other IAM organizations
by FireEye Customer Support only.
You cannot view the list of users in an external user group, and you cannot modify or
delete an external user group.
External user groups―groups that are defined in a different IAM organization and can
access your IAM organization―are listed in two pages of the FireEye IAM Web UI:
l Organization Settings
l User Groups.
360 © 2021 FireEye

Release 2021.1 About External User Groups
External User Group Names Displayed in the

Organization Settings Page
External user group names are displayed in the Organization Settings page (select
My Settings > My Organization). In the Available User Groups section of the page, the
Select User Groups field displays the external user groups that can access your IAM
organization.
External User Group Names Listed in the User Groups

Page
In the User Groups page (select Organization Settings > User Groups), the External User
Groups panel lists the external user groups that can access your IAM organization.
Two System-Defined External User Groups

By default, your FireEye IAM organization includes two external user groups that are
defined in an IAM organization administered by FireEye Customer Support. These groups
enable the Customer Support team to remotely troubleshoot authentication and
authorization issues in your IAM organization.
© 2021 FireEye 361

When FireEye created your IAM organization, they automatically added the following
FireEye Customer Support internal user groups as external user groups in you IAM
organization:
l FireEye Support - Level 1―Users in this group can log in to your IAM organization

with read-only access to all services and product types in the organization.
l FireEye Support - Levels 2 & 3―Users in this group can log in to your IAM
organization with full access to all services and product types in the organization.
The Web UI does not list the members of an external user group. You cannot modify or
delete an external user group.
Viewing the Lists of Internal and External

User Groups
To view the lists of user groups associated with your FireEye IAM organization, use the
User Groups page.
The page lists user groups in two panels:
l User Groups―This panel lists user groups that are defined in your IAM
organization. Access privileges granted to the members of an internal user group are
applicable within your IAM organization only.
362 © 2021 FireEye

Release 2021.1 Viewing the Lists of Internal and External User Groups
l External User Groups―This panel lists user groups that are defined in external

IAM organizations. that FireEye Customer Support added to your IAM organization.
You cannot view, edit, or delete the users in external groups, and you cannot edit or
delete external user groups.
A user group that is listed in the External User Groups panel for your IAM organization can
access your IAM organization as allowed by the roles assigned to that user group in its
owning organization. From the perspective of the owning organization, that same user group
is listed with a Scope value of External in the User Groups panel (list of internal user
groups).
The following table describes the columns in the User Groups page.
Field Description
User Groups — Groups created in your organization
Name The name of a group defined in your IAM organization. You can sort and
filter the list on this field.
NOTE: The Organization Owners group is automatically added to every

IAM organization created. This group contains all users who are also
organization owners. Users in this group can access all roles of all assigned
products.
Description A brief description of the group.
Scope Where the user group is used:

l Internal―The access privileges defined for this group are applicable in
this IAM organization only.
l External―The access privileges defined for this group are applicable
only in the external IAM organization where the group is defined.
Options Click the icon and select an operation to perform on the user group:
l View/Edit
l Remove
External User Groups — Externally created groups that have access to your organization
Name The name of a group defined in an external organization but whose user
credentials and privileges in the owning organization are accessible to this
organization. You can sort and filter the list on this field.
Description A brief description of the group.
Owning The name of the external IAM organization where this group is defined.
Organization
NOTE: A user group that appears in this list also appears in the owning
Name
organization's User Groups list with a Scope value of External.
© 2021 FireEye 363

Prerequisites
To view the list of user groups in your organization:
2. Select Organization Settings > User Groups.

The User Groups page lists all FireEye IAM user groups known to your IAM
organization.
The Internal User Groups panel lists user groups that are defined in your
organization. The External User Groups panel lists user groups that are defined in
other organizations but which FireEye has added to your organization.
3. (Optional) Sort and filter either of the lists on the Name field. Filtering is case-
sensitive, and it does not match wild card characters.
Viewing the Roles and Users Assigned to

an Internal User Group
To view the roles and user accounts assigned to an internal user group, use the Edit User
Group view of the User Groups page.
364 © 2021 FireEye

Release 2021.1 Viewing the Roles and Users Assigned to an Internal User Group
The following table describes the fields in the Edit User Group view.
Field Description
Name The name of the user group. You can edit the text in this field.
Description A brief description of the user group. You can edit the text in this field.
Available Roles
Name The name of a role that is not assigned to the group.

You can sort and filter the list on this field. Filtering is case-sensitive, and it
does not match wild card characters.

Access To add a role to the group, click Grant in this column. The role name moves
to the Assigned Roles list to the right.
Assigned Roles
Name The name of a role that is assigned to the group.


Access To remove a role from the group, click Remove in this column. The role name
moves to the Available Roles list to the left.
Available Users
Email The email address of a primary or external user that is not assigned to the
group.
Type (Read-only) Primary organization of the user account:

l Internal―The user account is defined in this IAM organization
l External―The user account is defined in an external IAM organization.
Access To add a user to the group, click Grant in this column. The group name
moves to the Assigned Users list to the right.
© 2021 FireEye 365

Field Description
Assigned Users
Email The email address of a primary or external user that is assigned to the group.

User Type (External groups only) Select the user's membership type in this group:
l User―Has read-only privileges on the user group.
l Owner―Has read-only privileges and receives notifications about
changes made to the group
NOTE: An external group must have one or more owners.
Access To remove a user from the group, click Remove in this column. The group
name moves to the Available Users list to the left.
Prerequisites
To view the roles and user accounts assigned to a user group:

organization.
3. (Optional) Sort and filter either of the lists on the Name field. Filtering is case-
sensitive, and it does not match wild card characters.
366 © 2021 FireEye

Release 2021.1 Creating an Internal User Group
4. Select the role you want to view. Use either of the following methods:
l Click the role name in the first column.
l Click the Options icon and select View/Edit.
The Edit User Group view appears, and the Assigned Roles panel lists the roles
assigned directly to the user group.
NOTE: The entitlements assigned to a global role are specific to the

product for which the role grants user access. Custom roles can have
entitlements for one or more products.
Creating an Internal User Group

To create an internal user group in your FireEye IAM organization, use the User Groups
page.
The Internal User Groups list (the list of all groups defined in this IAM organization) and
the External User Groups list (the list of externally defined groups accessible by this IAM
organization) can be sorted and filtered on the Description column. The fields in this page
are described in Viewing the Lists of Internal and External User Groups on page 362.
The following table describes the fields in the Add User Group view of the User Groups
page.
Field Description
Name Enter the name of the new group.

NOTE: When you view the User Groups list (the list of all groups defined in
this organization) and the External User Groups list (the list of externally
defined groups accessible by this organization), either list can be sorted and
filtered on the Name column.
Description Enter a brief description of the group.
© 2021 FireEye 367

Field Description
Available Roles
Name The name of a role that is not assigned to the group.


Access To add a role to the group, click Grant in this column. The role name moves
to the Assigned Roles list to the right.
Assigned Roles
Name The name of a role that is assigned to the group.


Access To remove a role from the group, click Remove in this column. The role name
moves to the Available Roles list to the left.
Available Users
Email The email address of a primary or external user that is not assigned to the
group.

Access To add a user to the group, click Grant in this column. The group name
moves to the Assigned Users list to the right.
368 © 2021 FireEye

Release 2021.1 Creating an Internal User Group
Field Description
Assigned Users
Email The email address of a primary or external user that is assigned to the group.

User Type (External groups only) Select the user's group member type:
l User―Has read-only privileges on the user group.
l Owner―Has read-only privileges and receives notifications about
changes made to the group
An external group must have one or more owners.
Access To remove a user from the group, click Remove in this column. The group
name moves to the Available Users list to the left.
Prerequisites
To create a user group:

organization.
© 2021 FireEye 369

3. Click Add. The Add User Group view appears.
4. Enter a name and a description for the group.
5. Click Next to view the panels that enable you to assign roles to the group.
6. To assign a role to the user group, find the role in Name column of the Available
Roles list and click Grant in the Options column. The role name moves from the
Available Roles list to the Assigned Roles list on the right.
370 © 2021 FireEye

Release 2021.1 Editing an Internal User Group
7. Click Next to view the panels that enable you to assign users to the group.
In the Available Users panel, the entry for your own user account displays You
Cannot Grant in the Access column.
8. To assign a user account to the user group, find the user account in the Available
Users list on the left side of the page, and then click Grant in the Options column.
The user name moves from the Available Users list to the Assigned Users list to the
right.
9. Click Add User Group.
The name of the new group appears in the User Groups panel of the User Groups
main view.
Editing an Internal User Group

You can edit an internal user group in your FireEye IAM organization by adding roles or
user accounts and by removing roles or user accounts.
NOTE: Removing a user account from a user group will reduce the group's
access privileges if the user's directly assigned roles grant privileges that the
group does not have through other sources. A user group derives its access
privileges though the roles directly assigned to it and through the roles directly
assigned to its members.
© 2021 FireEye 371

To edit an internal user group, use the User Groups page.
Prerequisites
To edit a user group:

organization.
3. Click the name of the user group you want to edit. The Edit User Group view shows
details about the selected group.
4. To assign a role to the group:

Find the role in the Available Roles list and click Grant in the Options column. The
role name moves from the Available Roles list to the Assigned Roles list on the
right.
372 © 2021 FireEye

Release 2021.1 Deleting Internal User Groups
5. To remove a role from the group:

Find the role in the Available Roles list and click Remove in the Options column.
The role name moves from the Assigned Roles list to the Available Roles list on the
left.
6. To assign a user to the group:

Find the user in the Available Users list and click Grant in the Options column. The
user name moves from the Available Users list to the Assigned Users list on the
right.
7. To remove a user from the group:

Find the user in the Available Users list and click Remove in the Options column.
The user name moves from the Assigned Users list to the Available Users list on the
left.
8. Click Add User Group.
Deleting Internal User Groups

You can delete internal user groups individually, or you can delete multiple internal user
groups at once. To delete user groups from your FireEye IAM organization, use the User
Groups page.
NOTE: The Organization Owners group is a system-defined default group, and it

cannot be modified or deleted.
© 2021 FireEye 373

NOTE: Deleting a user group revokes all access privileges that users received
through their membership in that group. The affected users retain the access
privileges granted through any roles directly assigned to their account.
Prerequisites
To delete user groups:

organization.
3. (Optional) Sort and filter the list on the Name field.
4. To delete an individual group:
a. Select the Options icon and select Delete.
b. Click OK.
5. To delete multiple groups at once:
a. Select the checkbox for each group you want to delete.
b. Click Delete.
c. Click OK.
374 © 2021 FireEye

System Security Guide Viewing All API Keys for the Organization
CHAPTER 24: FireEye IAM API

Keys
l Viewing All API Keys for the Organization below

l Viewing, Copying, or Downloading an API Key You Created on the next page
l Creating an API Key on page 379
l Editing an API Key You Created on page 382
l Revoking an API Key You Created on page 384
Viewing All API Keys for the

Organization
To view the list of all API keys in the organization, start at the API Keys view of the
Organization Settings > API Keys page. This view lists all of the API keys created for the
IAM organization. From this view, you can revoke API keys that were created using your
FireEye IAM account only.
© 2021 FireEye 375

System Security Guide CHAPTER 24: FireEye IAM API Keys
Prerequisites
To view the list of all API keys in the IAM organization:

2. Select Organization Settings > API Keys.
The page lists all API keys created in this IAM organization.
Viewing, Copying, or Downloading an

API Key You Created
To view, copy, or download an API key created using your FireEye Cloud user account,
start at the API Keys view of the My Settings > API Keys page. This view lists the API
keys created using your FireEye IAM account.
376 © 2021 FireEye

Release 2021.1 Viewing, Copying, or Downloading an API Key You Created
The following table describes the columns in the list of API keys:
Field Description
Description Descriptive name for the API key.
Entitlements Access rights granted to the API.
Products Product types to which the API is granted access.
Created On Date and time that the API key was created.
Expires In Time remaining before the API key expires.
Options Click the Options icon and select an operation to perform on the API key:
l View/Edit
l Revoke
Prerequisites
To view, copy, or download an API key you created:
2. Select My Settings > API Keys.
The page displays the list of API keys you created.
3. To view details about an API key, do one of the following:

l Click the text link in the Description column.
© 2021 FireEye 377

The editing view of the API key appears.
4. To copy the API key to the clipboard:

a. Click the Copy icon:
b. Save the contents of the clipboard to a local file.
378 © 2021 FireEye

Release 2021.1 Creating an API Key
5. To download the API key to a local file:

a. Click the Download icon:
b. Save the download file (apikey.txt) to your local drive.
Creating an API Key

To create an API key, start at the API Keys view of the My Settings > API Keys page, and
then open the Create API Key dialog box. This view lists the API keys created using your
FireEye IAM account.
The following table describes the panels and fields in the Create API Key dialog box:
Field Description
API Key with If selected, the access privileges of this API Key will be based upon
entitlements manually selected entitlements.
© 2021 FireEye 379

Field Description
API Key with If selected, the access privileges of this API Key will be based upon
groups the associated groups and will be applicable to all organizations
with which the groups are linked. Any modifications made to the
associated groups will dynamically affect the access privileges of
the API key.
API Key Name Name of the API key.
API key expires in Expiration period for the API key.

Expiration times are specified using s, m, h, d, or y, for seconds,
minutes, hours, or days, or years.
Default: 90d
Depending on the programmatic changes you are enabling, you will need to assign the API
key the product and product-specific entitlements needed to make those changes.
For example, suppose the API key will be used to create IAM organization user accounts
that need particular access privileges on Helix. The API key used to make these changes
must be assigned Product “IAM” and “Threat Analytic Platform” and you grant the
necessary set of entitlements under each product.
Prerequisites
380 © 2021 FireEye

Release 2021.1 Creating an API Key
To create an API key:
3. Click Create API Key.

4. Select either API Key with entitlements or API key with groups to specify the API
Key type.
5. Enter a name for the API key.
6. Enter the expiration period for the API key.
7. Specify the product types for which the API key needs access privileges.
To do this, click to open the Products list and then click to select product types.
8. Click Next.
© 2021 FireEye 381

9. From the Available Entitlements list, select the product-specific entitlements to grant
access rights to the API key.
l To grant all entitlements in the list, click Grant All.
l To grant individual entitlements, click Grant for each entry.
10. Click Create API Key.
Editing an API Key You Created

To edit an API key created using your FireEye Cloud user account, start at the API Keys
view of the My Settings > API Keys page. This view lists the API keys created using your
FireEye IAM account.
Field Description
l View/Edit
l Revoke
Prerequisites
382 © 2021 FireEye

Release 2021.1 Editing an API Key You Created
To edit an API key created using this account:
3. View the API key details. Use either of the following methods:

l Click the text in the Description column.
The page shows the entitlements granted by the API key.
4. Edit the name of the API key.

5. Click Update API Key.
© 2021 FireEye 383

Revoking an API Key You Created

You can revoke API keys individually, or you can revoke multiple API keys at once,
provided that the keys were created using your FireEye Cloud user account. To revoke API
keys, use the API Keys view of the My Settings > API Keys page. This view lists the API
keys created using your FireEye IAM account.
.
Field Description
l View/Edit
l Revoke
Prerequisites
384 © 2021 FireEye

Release 2021.1 Revoking an API Key You Created
To revoke an API key created using this account:
3. To revoke an individual API key:
a. Locate the API key you want to revoke.

If you want to see the entitlements for an API key, click the linked text in the
Descriptions column. Click the browser Back button to return to the list of API
keys.
b. Click the Options icon and select Revoke.
c. Click OK.
4. To revoke multiple API keys at once:
a. Select the checkboxes for the API keys you want to revoke.
If you want to see the entitlements for an API key, click the linked text in the
Descriptions column. Click the browser Back button to return to the list of API
keys.
b. Click Revoke.
c. Click OK.
© 2021 FireEye 385

386 © 2021 FireEye

Release 2021.1
PART VII: Appendices
l Capabilities of FireEye Appliance Local Roles on page 389

l FireEye IAM Entitlements on page 409
© 2021 FireEye 387

System Security Guide PART VII: Appendices
388 © 2021 FireEye

APPENDIX A: Capabilities of
FireEye Appliance Local Roles
l Capabilities of Local Roles on the next page

o Admin Role
o Analyst Role
o Auditor Role
o Monitor Role
o Operator Role
o Reject Role
o Access Messages
l Capabilities of Local Roles on Endpoint Security Appliances on page 397

o Admin Role on page 404
o Analyst Role on page 404
o API Admin Role on page 405
o API Analyst Role on page 405
o Auditor Role on page 405
o fe_services User on page 406
o Investigator Role on page 406
o Monitor Role on page 406
o Operator Role on page 407
o Senior Analyst Role on page 404
o Access Messages on page 407
© 2021 FireEye 389

System Security Guide APPENDIX A: Capabilities of FireEye Appliance Local Roles
Capabilities of Local Roles

The following sections provide detailed information about the capabilities of roles on
appliances:
l Capability Categories below

l Capability Descriptions on page 393
l Access Messages on page 396
Capability Categories
The capabilities associated with the roles are divided into five categories: System
Administration, Malware Analysis, Auditing, All Users, and Web Services API. The
following tables list the capabilities in each category and show which roles have access to
the functionality granted by the capabilities.
IMPORTANT! The FireEye services role has the same capabilities as the

Monitor role but allows access to the FireEye as a Service feature.
System Administration
The following table lists the System Administration capabilities and associated roles.
Capability Admin Monitor Operator Analyst Auditor
Authentication (AAA) X
Authentication (AAA) (view) X X X
CM Series X X
CM Series (view) X X X
CM Series Proxy X
CM Series Proxy (view) X X X
CM Series Client (LMS) X X
CM Series Client (LMS) (view) X X X
Crypto X X
390 © 2021 FireEye

Release 2021.1 Capabilities of Local Roles
Crypto (view) X X X
Detection X X
Detection (view) X X X X
Diagnostics X X
Health (view) X X X X
FireEye Database (fedb) X X
FireEye Database (fedb) (view) X X X
Licenses X X
Licenses (view) X X X
Network X X
Network (view) X X X
Stats X X
Stats (view) X X X
System Admin X
System X X
System (view) X X X
System Logs X X X
Malware Analysis
The following table lists the Malware Analysis capabilities and associated roles.
Alerts X X X
Alerts (view) X X X
Analysis X X
Analysis (view) X X X
Monitor Legacy X X
© 2021 FireEye 391

Notifications X X
Notifications (view) X X X X
Reports X X X
Reports (view) X X X
Auditing
The following table lists Auditing capabilities and associated roles.
Audit Logs X X X
All Users
The following table lists the capabilities available to all roles (except API Analyst and
API Monitor).
Manage Own Account X X X X X
All Users X X X X X
Web Services API

The following table lists the Web Service API capabilities and associated roles.
Capability API Analyst API Monitor Admin
Alerts X X
Alerts Create X
Alerts View X X X
All Users X X X
Analysis X X
Analysis View X X X
392 © 2021 FireEye

Capability API Analyst API Monitor Admin
Email Analysis X X
Email Analysis View X
File Analysis X
File Analysis View X X
Reports View X X X
Web Services Access X X
Capability Descriptions
The following table describes the functionality provided by each capability.
Capability Description
Alerts Ability to annotate or acknowledge alerts, which indicate the detection

of malware.
Alerts (view) Read-only access to the "Alerts" functionality. If a subnet is configured

on the local account, the view could be filtered by subnet.
All Users Commands and functionality available to users in all roles (except
API Analyst and API Monitor).
Analysis Ability to analyze malware.
Analysis Read-only access to "Analysis" functionality.

(view)
Audit Logs Ability to view audit logs, but not system logs.
Authentication Configuration of authentication, authorization, and accounting (AAA).

(AAA)
Authentication Read-only access to "Authentication (AAA)" functionality.

(AAA) (view)
CM Series Ability to configure managed appliances and appliance records

remotely.
NOTE: The "CM Series" capabilities are available only on the Central
Management appliance.
CM Series Read-only access to "CM Series" functionality.

(view)
© 2021 FireEye 393

CM Series Management of appliances by the Central Management appliance. (A

Client (LMS) managed appliance is also known as a client or LMS.)
CM Series Read-only access to "CM Series Client (LMS)" functionality.

Client (LMS)
(view)
CM Series Ability to fully control remote managed appliances both by executing

Proxy commands remotely from the Central Management appliance and by
sending proxied actions and queries.
CM Series Read-only access to "CM Series Proxy" functionality.

Proxy (view)
Crypto Management of cryptological functions such as Internet Protocol

Security (IPsec) and certificates.
Crypto (view) Read-only access to "Crypto" functionality. Sensitive information such

as private keys may be obfuscated.
Detection Management of system configuration and data that affect malware

detection efficacy, such as downloading and managing guest images
and security content.
Detection Read-only access to "Detection" functionality.

(view)
Diagnostics Access to diagnostic tools such as debug dumps (sysdumps), ping, and
traceroute.
FireEye Management of the FireEye database, such as backing it up and

Database restoring it.
(fedb)
FireEye Read-only access to "FireEye Database (fedb)" functionality.

Database
(fedb) (view)
Health Ability to view summary information about current system status.

(Detailed information is available with the "System (view)" capability.)
Licenses Management of license keys.
Licenses Read-only access to "Licenses" functionality.

(view)
394 © 2021 FireEye

Manage Own Ability to change one's own local account password and to manage
Account local SSH client functionality (authorized keys, identities, and known
hosts) for one's own local account.
NOTE: This functionality is available only to locally

authenticated users; that is, users who were authenticated
using the configuration they are now attempting to change.
Remotely authenticated users cannot change local account
information, even if they are mapped to the same or a
different local user name.
Monitor Functionality that the "monitor" capability had prior to the introduction
Legacy of roles, which is not permitted according to the strict interpretation of
the "monitor" role.
Network Ability to manage network configuration, such as interfaces and

routers.
Network Read-only access to "Network" functionality.

(view)
Notifications Ability to configure user notifications about malware-related events

(such as alerts) and system-related events (such as low disk space).
Notifications Read-only access to "Notifications" functionality.

(view)
Reports Ability to generate reports.
Reports (view) Read-only access to "Reports" functionality, such as viewing generated

reports.
Stats Ability to manage statistics.
Stats (view) Read-only access to "Stats" functionality.
System General system administration functions.
System Admin Both general system administration functions and sensitive functions
that require a higher level of authorization.
System (view) Read-only access to the "System" and "System Admin" functionality.
System Logs Ability to read system logs, but not audit logs.
© 2021 FireEye 395

Access Messages
The functionality that is available to a user depends on the user's role, which includes a
set of capabilities.
l If a user enters an unavailable command, an % Unrecognized command <command>

message is displayed.
l If a user does not have access to a page or control in the Web UI, it is either not
shown or the action is ignored and a message is displayed.
l If a user has limited access to a CLI command and enters the command with
unauthorized parameters, an % Insufficient authorization...message is
displayed.
l If an Admin user enters a CLI command that displays data that should not be
shown (such as plain text passwords), asterisks (***) are displayed to mask the
data.
396 © 2021 FireEye

Release 2021.1 Capabilities of Local Roles on Endpoint Security Appliances
Capabilities of Local Roles on Endpoint

Security Appliances
The following sections provide detailed information about the roles and their associated
capabilities:
l Endpoint Security Appliance Capabilities and Authorized Local Roles below

l Admin Role on page 404
l Analyst Role on page 404
l Senior Analyst Role on page 404
l API Admin Role on page 405
l API Analyst Role on page 405
l Auditor Role on page 405
l fe_services User on page 406
l Investigator Role on page 406
l Monitor Role on page 406
l Operator Role on page 407
l Access Messages on page 407
Endpoint Security Appliance Capabilities and Authorized

Local Roles
On an Endpoint Security appliance, roles have associated capabilities. The functionality
provided by each capability and the roles authorized to perform each capability are
described in the following table.
In general, if a user is assigned an AAA role that has Web UI access, the actions they can
perform occur mostly in the Web UI. In the CLI, only the show commands are available for
these roles. The exceptions to this are the admin role (which can perform all available
functions in the CLI) and the operator role (which can perform HX appliance software
maintenance functions in the CLI, but cannot run CLI commands related to HX Series
configuration settings).
If a user is assigned an AAA role that has API access, the actions they can perform occur
only in the API. The only exception to this is the fe_services user, who can perform all
available functions in the CLI and API, but has no access to the Web UI.
© 2021 FireEye 397

Authorized
AAA Roles
Web UI Access Access the Web UI. admin

analyst
Users with auditor roles have access to logs only.
analyst_sr
Users with monitor roles have access to the Appliance auditor
Settings and Health Check, and are able to view investigator
Appliance Updates only. monitor
operator
API Access Access the API api_admin

api_analyst
fe_services
CLI Access Access the CLI admin (full

access)
analyst (show
commands
only)
analyst_sr
(show
commands
only)
auditor (show
commands
only)
fe_services
(full access)
investigator
(show
commands
only)
monitor
(show
commands
only)
operator
(appliance
image
management,
show
commands
only)
398 © 2021 FireEye

Authorized
AAA Roles
FireEye as a Manage services fe_services

Service (FaaS)
Acquisitions View acquisitions admin

(view) analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
Agent Clone Manage cloned agents admin
Agent Clone View cloned agents admin

(view) analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
operator
Agent Manage agent configuration settings and deploy them admin (Web
Configurations to the agents UI)
api_admin
(API)
operator
(Web UI
partial)
Agent Perform agent diagnostics admin

Diagnostics fe_services
Agent View agent diagnostics admin

Diagnostics fe_services
(view)
Alerts Manage and view alerts admin

analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
© 2021 FireEye 399

Authorized
AAA Roles
Approve Approve containment requests and stop containment of admin

Containment host endpoints api_admin
fe_services
investigator
Audit Viewer Request and view audit data. admin

analyst
In the Web UI, this includes processing acquisition data
analyst_sr
and reviewing it in the Audit Viewer, In the API, this
api_admin
involves searching for audit data in acquisitions using
api_analyst
a script.
fe_services
investigator
Authentication Maintain authorization settings for user accounts admin

(AAA) fe_services
Authentication View authorization settings for user accounts admin

(AAA) (view) monitor
operator
Dashboard Select links on the Web UI dashboard admin

analyst
analyst_sr
investigator
Dashboard View the Web UI dashboard admin

(view) analyst
analyst_sr
investigator
operator
Data Request data acquisitions admin

Acquisitions analyst
analyst_sr
(Live
api_admin
Response)
api_analyst
fe_services
investigator
400 © 2021 FireEye

Authorized
AAA Roles
Enterprise Run enterprise searches admin

Search analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
File Request file acquisitions admin

Acquisitions analyst_sr
api_admin
api_analyst
fe_services
investigator
Health Check Review system health admin

View analyst
analyst_sr
fe_services
investigator
monitor
operator
Hosts Maintain host lists admin

analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
Hosts (view) View host lists admin

analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
operator
Host Sets Maintain host sets admin

operator
© 2021 FireEye 401

Authorized
AAA Roles
Host Sets View host sets admin

(view) analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
operator
Indicator Maintain and view indicators and custom indicators admin

analyst
analyst_sr
api_admin
api_analyst
fe_services
investigator
Module Install, uninstall, enable, disable, and upgrade modules admin

Administration api_admin
investigator
Module Data View module data pages all roles
Appliance Maintain appliance licenses admin

Licenses fe_services
operator
Appliance View appliance licenses admin

Licenses (view) fe_services
monitor
operator
Logs View logs and customize log settings admin

auditor
fe_services
operator
Manage Own Change the password for the specific user account admin
Account analyst
analyst_sr
auditor
investigator
monitor
operator
402 © 2021 FireEye

Authorized
AAA Roles
Network Maintain network settings admin

operator
Network View network settings admin

(View) fe_services
monitor
operator
PKI Import and export HX certificates for the agent admin

population
Stats Manage statistics admin

operator
Stats (view) View statistics admin

fe_services
monitor
operator
Appliance Perform general system administration functions for admin

Settings the appliance (but not sensitive functions). These operator
(general) include setting the date and time, modifying DTI
network settings, managing notifications, modifying
network settings, changing certificates and keys,
managing appliance licenses, and changing the login
banner.
Appliance View appliance settings. admin

Settings (view) fe_services
monitor
operator
Appliance Perform general and sensitive administrative functions admin

Settings for the appliance. These include managing user fe_services
(sensitive) accounts (AAA) and appliance backup and restore
functionality.
System Perform system diagnostics admin

Diagnostics operator
© 2021 FireEye 403

Admin Role
On an Endpoint Security appliance, Administrators (users assigned the admin role) have
full access to all Endpoint Security Web UI and CLI product functionality, except for the
Web UI My Account Settings page. Administrators do not have access to the API.
Administrators do not change their passwords on the My Account Settings page. Use the
User Account Settings page to change administrator passwords.
Analyst Role
On an Endpoint Security appliance, Analysts (users assigned the analyst role) can perform
most Endpoint Security appliance functions, with the following exceptions.
l They cannot approve containment requests or stop containment of host endpoints.

l They cannot request file acquisitions.
l They can view, but not maintain, host sets.
l They can view, but not resolve, cloned agents.
l They have read-only access to DTI settings and do not have access to other
Endpoint Security appliance or agent configuration settings.
l They cannot view or maintain user accounts.
l They cannot view or manage statistics.
l They cannot run or view agent diagnostics.
l They can only run CLI show commands.
l They have no access to the API.
l They have read-only access to the appliance Health Check page and appliance
updates.
Analysts change their passwords on the My Account Settings page. To access the My
Account Settings page, select Change My Password on the Hi, <user name> menu.
Senior Analyst Role

On an Endpoint Security appliance, Senior Analysts (users assigned the analyst_sr role)
can perform most Endpoint Security appliance functions, with the following exceptions.
l They cannot approve containment requests or stop containment of host endpoints.

404 © 2021 FireEye

updates.
Senior analysts change their passwords on the My Account Settings page. To access the
My Account Settings page, select Change My Password on the Hi, <user name> menu.
API Admin Role
Users assigned the api_admin role have no access to Endpoint Security appliance
functionality via the Web UI. They have basic and extended API authorization for
Endpoint Security appliance features. The extended authorization allows them to maintain
custom policy channels and to contain hosts. (Custom policy channels can be used to
distribute custom configuration files to agents running on hosts in specified host sets.)
API Administrators cannot run CLI commands or change their passwords. An Endpoint
Security appliance administrator (user role Admin) must change their passwords, if
necessary.
See the Endpoint Security REST API Guide.
API Analyst Role
On an Endpoint Security appliance, users assigned the api_analyst role have no access to
Endpoint Security appliance functionality via the Web UI. They only have basic API
authorization for Endpoint Security appliance features. API Analysts cannot run
CLI commands or change their passwords. An Endpoint Security appliance administrator
(user role Admin) must change their passwords, if necessary.
See the HX Series REST API Guide.
Auditor Role
On the Endpoint Security appliance, Auditors (users assigned the auditor role) only have
access to Endpoint Security appliance log management functions. They can run CLI show
commands and change their passwords on the My Account Settings page. They have no
access to other product features.
© 2021 FireEye 405

To access the My Account Settings page, select Appliance Settings at the top of the page.
fe_services User
On an Endpoint Security appliance, the fe_services user has no access to Endpoint
Security appliance functionality via the Web UI.
l They have basic API access to Endpoint Security appliance features.

l They can approve containment requests and stop containment of host endpoints.
l They cannot maintain custom policy channels in the API.
l They can run all CLI commands.
You cannot use the fe_services user or create additional fe_services users unless you have
an MD_ACCESS license. In addition, the password for the fe_services user cannot be
changed.
Investigator Role
On an Endpoint Security appliance, Investigators (users assigned the investigator role) can
perform all Endpoint Security appliance functions, with the following exceptions.

updates.
Investigators change their passwords on the My Account Settings page. To access the My
Monitor Role
On an Endpoint Security appliance, Monitors (users assigned the monitor role) have read
access to Endpoint Security appliance settings, user accounts, the Health Check page, and
the Appliance Update page, but cannot take action.
406 © 2021 FireEye

Monitors change their passwords on the My Account Settings page. To access the My
Operator Role
On an Endpoint Security appliance, Operators (users assigned the operator role) have little
access to regular Endpoint Security product functionality, but they can perform some
administrative functions.
l They can search for a host on the Hosts page. They cannot perform other host,
indicator, acquisition, or investigative functions.
l They can maintain host sets, agent version lists, and the server address list for
agents.
l They can perform agent upgrades.
l They can adjust DTI, network, certificate and key, license, and login banner settings.
l They can view, but not maintain, user accounts.
l They can obtain appliance health checks, manage appliance logs, and perform
appliance updates.
Operators change their passwords on the My Account Settings page. To access the My
Access Messages
If an Endpoint Security appliance user attempts an action that is outside the capabilities
assigned their role, the system responds with a message.
l If a user enters an unavailable command, the message % Unrecognized command

<command> is displayed.
l If a user does not have access to a page or control in the Web UI, either it is not
shown, or the user's action is ignored and a message is displayed.
l If a user has limited access to a CLI command and enters the command with
unauthorized parameters, the message % Insufficient authorization... is
displayed.
l If an admin user enters a CLI command that displays data that should not be
shown (such as plain-text passwords), asterisks (***) are displayed to mask the data.
© 2021 FireEye 407

408 © 2021 FireEye

APPENDIX B: FireEye IAM

Entitlements
l Entitlements for the FireEye IAM Web UI Roles on page 411

o IAM Admin Role on page 412
o IAM User Role on page 416
o FireEye Super Admin Role on page 419
o SCIM Admin Role on page 424
l Entitlements for Helix Roles on page 426

o All FireEye Helix Entitlements on page 427
o FaaS Analyst Role on page 437
o TAP Analyst Limited Role on page 445
o TAP Analyst Role on page 438
o TAP Cloud Collector Role on page 452
o TAP Content Limited Role on page 454
o TAP Federated Analyst Role on page 455
o TAP Federated Analyst Limited Role on page 463
o TAP Federated Organization Administrator Role on page 473
o TAP Organization Administrator Role on page 483
l Entitlements for FireEye Threat Intelligence Roles on page 491
o Threat Intelligence—Included Role on page 491
© 2021 FireEye 409

System Security Guide APPENDIX B: FireEye IAM Entitlements
l Entitlements for the FireEye Appliance Roles on page 494

o About IAM Global Roles for FireEye Appliances on page 495
o Central Management Appliance Roles on page 496
o Email Security — Server Edition Appliance Roles on page 498
o Network Security Appliance Roles on page 500
o Endpoint Security Appliance Roles on page 502
o Fallback Roles for FireEye Appliances on page 504
o FireEye Appliance Org Admin Role on page 507
410 © 2021 FireEye

Release 2021.1 Entitlements for the FireEye IAM Web UI Roles
Entitlements for the FireEye IAM

Web UI Roles
l IAM Admin Role on the next page

IAM Admin access to the IAM Web UI allows the user to perform most system
administration tasks. The role grants full access to the IAM organization security
policies, user access controls, and user deployment.
l IAM User Role on page 416

IAM User access to the IAM Web UI allows the user to manage their own password
and personal information, set user preferences, and generate backup codes for two-
factor authentication. The IAM User role also grants permission to create API keys
and to view, edit, and revoke API keys created from their own user account.
l FireEye Super Admin Role on page 419

FireEye Super Admin access to the IAM Web UI is reserved for use by FireEye
Customer Support staff only. The role grants full access to the OIDC client
registration, IAM organization API keys, and IAM audit event logging.
l SCIM Admin Role on page 424

SCIM Admin access to the IAM Web UI is reserved for use by FireEye Customer
Support staff only. The role grants full API access to the SCIM services that support
FireEye ETP user profile migration.
© 2021 FireEye 411

IAM Admin Role

IAM Admin access to the IAM Web UI allows the user to perform most system
administration tasks. The role grants full access to the IAM organization security policies,
user access controls, and user deployment.
NOTE: IAM Admin is a global role, and it cannot be modified or deleted.
Unlike the FireEye Super Admin role, the IAM Admin role does not grant visibility or
access to OIDC clients, IAM audit events, or other IAM organizations.
Viewing the Roles and Entitlements

To view the entitlements assigned to the role, filter the list of roles to show only IAM
Web UI roles, and then drill down from the IAM Admin role to its component entitlements.
Requirements
To view the entitlements associated with the IAM Admin role:
2. Select Organization Settings > Roles. The Roles page lists the IAM global roles and
custom roles in your IAM organization.
3. Filter the list on the Description column, specifying the match string IAM in all
uppercase letters. (The filter is case-sensitive.) The list refreshes and shows only the
roles that grant access to the IAM Web UI.
412 © 2021 FireEye

4. Click IAM Admin in the Name column.
The Assigned Entitlements panel lists the entitlements assigned to the role.
List of Entitlements
The entitlements granted by the IAM Admin role are described in the following table.
These entitlements are a superset of the entitlements granted by the IAM User role.
Shaded entries in the table indicate entitlements that are not granted by the IAM User role.
Entitlement Description
API Keys
iam.apikeys.add Add IAM API keys to your organization
iam.apikeys.browse Browse IAM API keys for your organization
iam.apikeys.delete Delete IAM API keys for your organization
iam.apikeys.edit Edit IAM API keys for your organization
iam.apikeys.read View IAM API keys for your organization
© 2021 FireEye 413

API Keys Created Using This IAM Admin Account
iam.apikeys.self.add Add IAM API keys
iam.apikeys.self.browse Browse IAM API keys created by this user account
iam.apikeys.self.delete Delete IAM API keys created by this user account
iam.apikeys.self.edit Edit IAM API keys created by this user account
iam.apikeys.self.read View IAM API keys created by this user account
IAM Entitlements
iam.entitlements.browse Browse IAM entitlements
iam.entitlements.read View the settings for IAM entitlements
User Groups
iam.groups.add Add IAM user groups
iam.groups.browse Browse IAM user groups
iam.groups.delete Delete IAM user groups
iam.groups.edit Edit IAM user group settings
iam.groups.read View IAM user group settings
Users in User Groups
iam.groups.users.browse Browse users in IAM user groups
Your IAM Organization
iam.orgs.self.edit Edit the settings for your own IAM organization
iam.orgs.self.read View the settings for your own IAM organization
Data Policies
iam.policies.add Add IAM data policies
iam.policies.browse Browse IAM data policies
iam.policies.delete Delete IAM data policies
iam.policies.edit Edit the settings for IAM data policies
iam.policies.read View the settings for IAM data policies
414 © 2021 FireEye

Products
iam.products.browse Browse the products accessible to the IAM organization
iam.products.read View the list of all products supported for IAM
Roles
iam.roles.add Add IAM roles
iam.roles.browse Browse IAM roles
iam.roles.delete Delete IAM roles
iam.roles.edit Edit the settings for IAM roles
iam.roles.read View the settings for IAM roles
Settings
iam.settings.edit Edit IAM settings
iam.settings.read View IAM settings
Other User Accounts
iam.users.add Add other IAM user accounts
iam.users.browse Browse other IAM user accounts
iam.users.delete Delete other IAM user accounts
iam.users.edit Edit the settings for other IAM user accounts
iam.users.read View the settings for other IAM user accounts
Your Own User Account
iam.users.self.add Re-create your own IAM user account
iam.users.self.browse Browse your own IAM user account
iam.users.self.delete Delete your own IAM user account
iam.users.self.edit Edit your own IAM user account settings
iam.users.self.read View your own IAM user account settings
© 2021 FireEye 415

IAM User Role

IAM User access to the IAM Web UI allows the user to manage personal information, set
user preferences, manage their password, and generate backup codes for two-factor
authentication.
NOTE: IAM User is a global role, and it cannot be modified or deleted.
Unlike the IAM Admin role, the IAM User role is limited to read-only access to IAM
organization settings, user access control policies, user groups, and other user accounts.
The IAM User role has no visibility to API keys created by other accounts, OIDC clients,
IAM audit events, or other IAM organizations.

To view the entitlements assigned to the role, filter the list of roles to show only IAM
Web UI roles, and then drill down from the IAM User role to its component entitlements.
Requirements
To view the entitlements associated with the IAM User role:
416 © 2021 FireEye

4. Click IAM User in the Name column.
The entitlements granted by the IAM User role are described in the following table. These
entitlements are a subset of the entitlements granted by the IAM Admin role.
API Keys
IAM Entitlements
iam.entitlements.read View the settings for IAM entitlements
User Groups
© 2021 FireEye 417

iam.groups.users.browse Browse IAM user group members
iam.orgs.self.read View the settings for your IAM organization
Data Policies
iam.policies.read View the settings for IAM data policies
Products
iam.products.browse Browse the products accessible to the IAM organization
iam.products.read View the list of all products supported for IAM
Roles
iam.roles.read View IAM role settings
IAM Settings
User Accounts
418 © 2021 FireEye

FireEye Super Admin Role

FireEye Super Admin access allows the user to manage OIDC client registration, IAM
organization API keys, and IAM audit event logs. Only FireEye Customer Support staff can
assign this role.
NOTE: FireEye Super Admin is a global role, and it cannot be modified or

deleted. It is also a reserved role that is used by FireEye Customer Support only.

Although you cannot assign the FireEye Super Admin role, you can view the role's
entitlements. To view the entitlements assigned to the role, filter the list of roles to show
only IAM Web UI roles, and then drill down from the FireEye Super Admin role to its
component entitlements.
Requirements
To view the entitlements associated with the FireEye Super Admin role:
4. Click FireEye Super Admin in the Name column.
© 2021 FireEye 419

The following table describes the entitlements granted by the FireEye Super Admin role for
the IAM Web UI.
NOTE: FireEye assigns this role to FireEye Customer Support staff only.
The FireEye Super Admin role grants the user a super-set of the entitlements granted by
the IAM Admin role. The shaded table entries indicate entitlements that are not granted by
the Admin role.
API Keys for the IAM Organization
iam.apikeys.add Add IAM API keys
iam.apikeys.browse Browse any IAM API keys in the organization
iam.apikeys.delete Delete any IAM API keys in the organization
iam.apikeys.edit Edit the settings for any IAM API keys in the organization
iam.apikeys.read View the settings for any IAM API keys in the organization
API Keys Created Using This IAM Admin Account
IAM Entitlements
iam.entitlements.read View IAM entitlement settings
420 © 2021 FireEye

User Groups
iam.groups.add Add IAM user groups
iam.groups.delete Delete IAM user groups
iam.groups.edit Edit IAM user group settings
iam.groups.users.browse Browse users in IAM user groups
OIDC Clients
iam.oidc.clients.add Add IAM OIDC clients
iam.oidc.clients.browse Browse IAM OIDC clients
iam.oidc.clients.delete Delete IAM OIDC clients
iam.oidc.clients.edit Edit IAM OIDC client settings
iam.oidc.clients.read View IAM OIDC client settings
All IAM Organizations
iam.orgs.add Add a IAM organization
iam.orgs.browse Browse other IAM organizations
iam.orgs.delete Delete other IAM organizations
iam.orgs.edit Edit the settings for other IAM organizations
iam.orgs.read View the settings for other IAM organizations
iam.orgs.self.edit Edit your own IAM organization settings
iam.orgs.self.read View your own IAM organization settings
Traffic Light Protocol
iam.orgs.tlp.edit Edit the TLP settings for any IAM organization
iam.orgs.tlp.read View the TLP settings for any IAM organization
© 2021 FireEye 421

All Users in an Organization
iam.orgs.users.browse Browse users in any IAM organization
Data Policies
iam.policies.add Add IAM policies
iam.policies.delete Delete IAM data policies
iam.policies.edit Edit IAM data policy setting
iam.policies.read View IAM data policy settings
Products
iam.products.add Add IAM products
iam.products.browse Browse IAM products
iam.products.delete Delete IAM products
iam.products.edit Edit IAM product settings
iam.products.read ViewIAM product settings
Roles
iam.roles.add Add IAM roles
iam.roles.delete Delete IAM roles
iam.roles.edit Edit IAM role settings
iam.roles.read View IAM role settings
IAM Settings
iam.settings.edit Edit IAM settings
422 © 2021 FireEye

Other User Accounts
iam.users.add Add other IAM user accounts
iam.users.delete Delete other IAM user accounts
iam.users.edit Edit other IAM user account settings
iam.users.read View other IAM user account settings
iam.users.self.add Re-create your own IAM user account
iam.users.self.delete Delete your own IAM user account
© 2021 FireEye 423

SCIM Admin Role
SCIM Admin access gives the user full API access to the FireEye System for Cross-Domain
Management (SCIM) services. FireEye IAM uses SCIM services to facilitate migration of
ETP user profiles to FireEye IAM. Only FireEye Customer Support staff can assign this role.
NOTE: SCIM Admin is a global role, and it cannot be modified or deleted. It is

also a reserved role that is used by FireEye Customer Support only.

Although you cannot assign the SCIM Admin role, you can view the role's entitlements. To
view the entitlements assigned to the role, filter the list of roles to show only IAM Web UI
roles, and then drill down from the SCIM Admin role to its component entitlements.
Requirements
To view the entitlements associated with the SCIM Admin role:
4. Click scim in the Name column.
424 © 2021 FireEye

The IAM SCIM Admin role grants the entitlements listed in the following table.
NOTE: FireEye assigns this role to FireEye Customer Support staff only.
The shaded table entries indicate entitlements that are not granted by any other role for the
FireEye IAM Web UI.
Operations on SCIM Groups
iam.scim.groups.add Add IAM SCIM user groups
iam.scim.groups.browse Browse IAM SCIM user groups
iam.scim.groups.delete Delete IAM SCIM user groups
iam.scim.groups.edit Edit the settings for IAM SCIM user groups
iam.scim.groups.read View the settings for IAM SCIM user groups
Operations on SCIM Users
iam.scim.users.add Add IAM SCIM user accounts
iam.scim.users.browse Browse IAM SCIM user accounts
iam.scim.users.delete Delete IAM SCIM user accounts
iam.scim.users.edit Edit the settings for IAM SCIM user accounts
iam.scim.users.read View the settings for IAM SCIM user accounts
© 2021 FireEye 425

Entitlements for Helix Roles

FireEye IAM provides the following global roles for Helix (previously known as the Threat
Analytics Platform, or TAP).
l All FireEye Helix Entitlements on the facing page

l FaaS Analyst Role on page 437
l TAP Analyst Limited Role on page 445
l TAP Analyst Role on page 438
l TAP Cloud Collector Role on page 452
l TAP Content Limited Role on page 454
l TAP Federated Analyst Role on page 455
l TAP Federated Analyst Limited Role on page 463
l TAP Federated Organization Administrator Role on page 473
l TAP Organization Administrator Role on page 483
426 © 2021 FireEye

Release 2021.1 Entitlements for Helix Roles
All FireEye Helix Entitlements

The tables in this section list all of the Helix (formerly known as TAP) entitlements. You
can create custom roles and add entitlements to them as needed for granular control and
security. For information about creating a custom role, see Creating a Custom Role on
page 326.
For example, a user with a custom role that grants the tap.dashboards.read entitlement but
not the tap.dashboards.edit entitlement can view individual dashboards, but cannot edit
them.
If a user lacks the entitlements to view data or perform actions in the Helix Web UI, the
data or action will not be available or an error message will be returned.
Alerts
tap.alerts.add Whether a user can create new alerts
tap.alerts.browse Whether a user can browse all alerts
tap.alerts.edit Whether a user can edit alerts and their notes
tap.alerts.read Whether a user can view all individual alerts and their notes
Alerts—Federated
tap.federated.alerts.add Whether a user can create new federated alerts
tap.federated.alerts.browse Whether a user can browse all alerts aggregated from child
organizations
tap.federated.alerts.edit Whether a user can edit federated alerts and their notes
tap.federated.alerts.read Whether a user can view all individual federated alerts and their
notes
Alert Suppressions
tap.alert.suppressions.add Whether a user can create new alert suppressions
tap.alert.suppressions.browse Whether a user can browse all alert suppressions
tap.alert.suppressions.edit Whether a user can edit alert suppressions
tap.alert.suppressions.read Whether a user can view all individual alert suppressions
© 2021 FireEye 427

Alert Suppressions—Federated
tap.federated.alert.suppressions.add Whether a user can create new federated alert suppressions
tap.federated.alert.suppressions.browse Whether a user can browse all alert suppressions across child
organizations
tap.federated.alert.suppressions.edit Whether a user can edit federated alert suppressions
tap.federated.alert.suppressions.read Whether a user can view all individual federated alert

suppressions
Analytics
tap.analytics.browse Whether a user can browse all analytical advisories
tap.analytics.edit Whether a user can edit individual analytical trainings
Appliance Groups
tap.appliances.groups.add Whether a user can add appliance groups
tap.appliances.groups.browse Whether a user can browse appliance groups
tap.appliances.groups.delete Whether a user can delete appliance groups
tap.appliances.groups.edit Whether a user can edit appliance groups
tap.appliances.groups.read Whether a user can view individual appliance groups
Appliance Intelligence Feeds

tap.appliances.intel_feeds.add Whether a user can add appliance intel feed data
tap.appliances.intel_feeds.browse Whether a user can browse appliance intel feed data
tap.appliances.intel_feeds.delete Whether a user can delete appliance intel feed data
tap.appliances.intel_feeds.edit Whether a user can edit appliance intel feed data
tap.appliances.intel_feeds.read Whether a user can view individual appliance intel feed data
Appliance Management
tap.appliance.management Whether a user can access appliance actions and configurations
Appliances
tap.appliances.add Whether a user can add appliances
tap.appliances.browse Whether a user can browse appliances
tap.appliances.delete Whether a user can delete appliances
tap.appliances.edit Whether a user can edit appliances
tap.appliances.read Whether a user can view individual appliance data
428 © 2021 FireEye

Archive Searches
tap.archivesearch.add Whether a user can create new archive searches
tap.archivesearch.admin Whether a user can modify other users' archive searches
tap.archivesearch.browse Whether a user can view all archive searches
tap.archivesearch.delete Whether a user can delete archive searches
tap.archivesearch.edit Whether a user can edit archive searches
tap.archivesearch.read Whether a user can view individual archive searches
Archive Searches—Federated
tap.federated.archivesearch.add Whether a user can create new federated archive searches
tap.federated.archivesearch.browse Whether a user can view all federated archive searches
tap.federated.archivesearch.delete Whether a user can delete federated archive searches
tap.federated.archivesearch.edit Whether a user can edit federated archive searches
tap.federated.archivesearch.read Whether a user can view individual federated archive searches
Assets
tap.assets.add Whether a user can add assets
tap.assets.browse Whether a user can browse assets
tap.assets.delete Whether a user can delete assets
tap.assets.edit Whether a user can edit assets
tap.assets.read Whether a user can view asset data
Cases—Federated
tap.federarated.cases.add Whether a user can added federated cases
tap.federated.cases.browse Whether a user can browse all aggregated cases in child

organizations
tap.federated.cases.delete Whether a user can delete federated cases
tap.federated.cases.edit Whether a user can edit federated cases
tap.federated.cases.read Whether a user can view federated cases
© 2021 FireEye 429

Dashboards
tap.dashboards.add Whether a user can create a new dashboard
tap.dashboards.admin Whether a user can modify other users' dashboards
tap.dashboards.browse Whether a user can browse all dashboards
tap.dashboards.delete Whether a user can delete dashboards
tap.dashboards.edit Whether a user can edit dashboards
tap.dashboards.read Whether a user can view all individual dashboards
Dashboards—Federated
tap.federated.dashboards.add Whether a user can create a new federated dashboard
tap.federated.dashboards.browse Whether a user can browse federated dashboards
tap.federated.dashboards.delete Whether a user can delete federated dashboards
tap.federated.dashboards.edit Whether a user can edit federated dashboards
tap.federated.dashboards.read Whether a user can view all individual federated dashboards
Events
tap.events.browse Whether a user can browse all events on alerts and incidents
tap.events.read Whether a user can view individual events on alerts or incidents
Incidents
tap.incidents.add Whether a user can create a new incident
tap.incidents.browse Whether a user can browse all incidents
tap.incidents.delete Whether a user can delete incidents
tap.incidents.edit Whether a user can edit incidents and their notes
tap.incidents.read Whether a user can view all individual incidents and their notes
Indicators
tap.indicators.add Whether a user can create a new indicator
tap.indicators.browse Whether a user can browse all indicators
tap.indicators.delete Whether a user can delete indicators
tap.indicators.edit Whether a user can edit indicators
tap.indicators.read Whether a user can view individual indicators
430 © 2021 FireEye

Intel Feeds—Federated
tap.federated.intel_feeds.add Whether a user can create new federated intel feeds or observables
tap.federated.intel_feeds.browse Whether a user can browse all intel feeds or observables

propagated from parent and child organizations
tap.federated.intel_feeds.delete Whether a user can delete federated intel feeds or observables
tap.federated.intel_feeds.edit Whether a user can edit individual federated intel feeds or

observables
tap.federated.intel_feeds.read Whether a user can view all individual federated intel feeds or
observables
Lists
tap.lists.add Whether a user can create a new customer list
tap.lists.browse Whether a user can browse customer lists
tap.lists.delete Whether a user can delete customer lists
tap.lists.edit Whether a user can edit customer lists
tap.lists.read Whether a user can view individual customer lists
Packet Capture Jobs

tap.pcapjobs.add Whether a user can create a new PCAP job
tap.pcapjobs.browse Whether a user can browse PCAP jobs
tap.pcapjobs.delete Whether a user can delete PCAP jobs
tap.pcapjobs.edit Whether a user can edit PCAP jobs
tap.pcapjobs.read Whether a user can view individual PCAP jobs
Packet Capture Sensors

tap.pcapsensors.add Whether a user can create a new PCAP sensor
tap.pcapsensors.browse Whether a user can browse PCAP sensors
tap.pcapsensors.delete Whether a user can delete PCAP sensors
tap.pcapsensors.edit Whether a user can edit PCAP sensors
tap.pcapsensors.read Whether a user can view individual PCAP sensors
© 2021 FireEye 431

Policies
tap.rbac.policy.add Whether a user can create new data policies
tap.rbac.policy.browse Whether a user can view all data policies
tap.rbac.policy.constraint.add Whether a user can create new data policy constraints
tap.rbac.policy.constraint.browse Whether a user can view all data policy constraints
tap.rbac.policy.constraint.delete Whether a user can delete individual data policy constraints
tap.rbac.policy.constraint.edit Whether a user can edit individual data policy constraints
tap.rbac.policy.constraint.read Whether a user can view individual data policy constraints
tap.rbac.policy.delete Whether a user can delete individual data policies
tap.rbac.policy.edit Whether a user can edit individual data policies
tap.rbac.policy.read Whether a user can view individual data policies
tap.rbac.policy.user.browse Whether a user can view all users assigned to individual data
policies
Reports
tap.reports.add Whether a user can create new reports
tap.reports.admin Whether a user can modify other users' reports
tap.reports.browse Whether a user can view reports
tap.reports.delete Whether a user can delete reports
tap.reports.edit Whether a user can edit individual reports
tap.reports.read Whether a user can view individual reports
Reports—Federated
tap.federated.reports.add Whether a user can create new federated reports
tap.federated.reports.browse Whether a user can view federated reports
tap.federated.reports.delete Whether a user can delete federated reports
tap.federated.reports.edit Whether a user can edit individual federated reports
tap.federated.reports.read Whether a user can view individual federated reports
432 © 2021 FireEye

Rule Packs
tap.rulepacks.add Whether a user can create new rule packs
tap.rulepacks.browse Whether a user can browse rule packs
tap.rulepacks.delete Whether a user can delete rule packs
tap.rulepacks.edit Whether a user can edit rule packs
tap.rulepacks.read Whether a user can view individual rule packs
Rules
tap.rules.add Whether a user can create a new rule
tap.rules.browse Whether a user can view rules
tap.rules.delete Whether a user can delete rules
tap.rules.edit Whether a user can edit rules
tap.rules.read Whether a user can view individual rules and their notes
Saved Searches
tap.savedsearch.admin Whether a user can modify other users' saved searches
Scheduled Searches
tap.scheduledsearch.add Whether a user can create new scheduled searches
tap.scheduledsearch.admin Whether a user can modify other users' scheduled searches
tap.scheduledsearch.browse Whether a user can browse scheduled searches
tap.scheduledsearch.delete Whether a user can delete scheduled searches
tap.scheduledsearch.edit Whether a user can edit individual scheduled searches
tap.scheduledsearch.read Whether a user can view individual scheduled searches
Scheduled Searches—Federated
tap.scheduledsearch.add Whether a user can create new federated scheduled searches
tap.scheduledsearch.browse Whether a user can browse federated scheduled searches
tap.scheduledsearch.delete Whether a user can delete federated scheduled searches
tap.scheduledsearch.edit Whether a user can edit individual federated scheduled searches
tap.scheduledsearch.read Whether a user can view individual federated scheduled searches
© 2021 FireEye 433

Searches
tap.search.browse Whether a user can execute a search
tap.search.regex Whether a user can execute a regular expression search
Security Orchestrator
tap.security_ Whether a user can browse Security Orchestrator playbook details
orchestrator.playbook.browse and execution results
tap.security_ Whether a user can read Security Orchestrator playbook details

orchestrator.playbook.read and execution results
tap.security_ Whether a user can add a new Security Orchestrator playbook

orchestrator.playbook.add plugin
tap.security_ Whether a user can execute a Security Orchestrator playbook

orchestrator.playbook.execute
tap.security_ Whether a user can delete an existing Security Orchestrator

orchestrator.playbook.delete playbook plugin
tap.security_ Whether a user can browse Security Orchestrator device

orchestrator.playbook.config.browse configurations
tap.security_ Whether a user can read a Security Orchestrator device

orchestrator.playbook.config.read configuration
tap.security_ Whether a user can add a new device in a Security Orchestrator

orchestrator.playbook.config.add playbook
tap.security_ Whether a user can modify a Security Orchestrator device

orchestrator.playbook.config.edit configuration
Sensors
tap.sensors.add Whether a user can add sensors
tap.sensors.browse Whether a user can browse sensor data
tap.sensors.delete Whether a user can delete sensors
tap.sensors.edit Whether a user can edit sensors
tap.sensors.read Whether a user can view individual sensor data
434 © 2021 FireEye

Threats
tap.threats.browse Whether a user can browse all threats
tap.threats.read Whether a user can view all individual threats and notes
tap.threats.edit Whether a user can edit all threats and notes
tap.threats.suppressions.browse Whether a user can browse all threats suppressions
tap.threats.suppressions.read Whether a user can view all individual threats suppressions
tap.threats.suppressions.edit Whether a user can edit threats suppressions
Users
tap.rbac.user.add Whether a user can create new users
tap.rbac.user.browse Whether a user can browse all users
tap.rbac.user.constraint.browse Whether a user can view all role constraints for individual users
tap.rbac.user.delete Whether a user can delete individual users
tap.rbac.user.edit Whether a user can edit individual users
tap.rbac.user.permission.browse Whether a user can view all permissions for individual users
tap.rbac.user.policy.add Whether a user can assign data policies to individual users
tap.rbac.user.policy.browse Whether a user can view all data policies for individual users
tap.rbac.user.policy.delete Whether a user can revoke data policies for individual users
tap.rbac.user.policy.edit Whether a user can reassign data policies to individual users
tap.rbac.user.read Whether a user can view individual users
tap.rbac.user.search Whether a user can search all individual users
Widgets
tap.widgets.add Whether a user can create a new widget
tap.widgets.browse Whether a user can browse widgets
tap.widgets.delete Whether a user can delete widgets
tap.widgets.edit Whether a user can edit widgets
tap.widgets.read Whether a user can view individual widgets
© 2021 FireEye 435

Widgets—Federated
tap.federated.widgets.add Whether a user can create a new federated widget
tap.federated.widgets.browse Whether a user can browse federated widgets
tap.federated.widgets.delete Whether a user can delete federated widgets
tap.federated.widgets.edit Whether a user can edit federated widgets
tap.federated.widgets.read Whether a user can view individual federated widgets
436 © 2021 FireEye

FaaS Analyst Role

FaaS Analyst access to FireEye Helix allows to user to manage hidden content within a
Helix instance.
NOTE: FaaS Analyst is a global role, and it cannot be modified or deleted.

To view the entitlements assigned to the role, filter the list of roles to show only the
FaaS Analyst role and then drill down from the FaaS Analyst role to its component
entitlements.
Requirements
To view the entitlements associated with the FaaS Analyst role:
3. Filter the list on the Name column, specifying the match string FaaS in all
uppercase letters. (The search is case-sensitive.)
4. Click FaaS Analyst in the Name column.

The Helix entitlements granted by the global FaaS Analyst role follow. These entitlements
allow the user to manage hidden content within specific Helix resources.
l tap.alerts.hidden l tap.rules.hidden
l tap.archivesearch.hidden l tap.scheduledsearch.hidden
l tap.dashboards.hidden l tap.search.hidden
l tap.lists.hidden l tap.widgets.hidden
l tap.rulepacks.hidden
© 2021 FireEye 437

TAP Analyst Role

TAP Analyst access allows the user to view data and perform all actions within Helix,
except for assigning and editing user permissions.
NOTE: TAP Analyst is a global role, and it cannot be modified or deleted.

To view the entitlements assigned to the role, filter the list of roles to show Helix (TAP)
roles, and then drill down from the TAP Analyst role to its component entitlements.
Requirements
To view the entitlements associated with the TAP Analyst role:
3. Filter the list on the Name column, specifying the match string TAP in all uppercase
letters. (The search is case-sensitive.) The list refreshes and shows only the roles that
grant access to Helix.
4. Click TAP Analyst in the Name column.

5. The Assigned Entitlements panel lists the entitlements assigned to the role.
The Helix entitlements granted by the global TAP Analyst role are described in the
following tables.
Alert Suppressions
438 © 2021 FireEye

Alerts
Analytics
Appliance Groups

Appliances
© 2021 FireEye 439

Archive Searches
Assets
Dashboards
Events
Incidents
440 © 2021 FireEye

Indicators
Lists
Packet Capture Jobs


© 2021 FireEye 441

Reports
Rule Packs
Rules
Scheduled Searches
Searches
442 © 2021 FireEye









Sensors
Threats
© 2021 FireEye 443

Widgets
444 © 2021 FireEye

TAP Analyst Limited Role

TAP Analyst Limited access allows the user to view data and perform all actions within
Helix, except for assigning or editing user permissions and executing regex searches.
NOTE: TAP Analyst Limited is a global role, and it cannot be modified or

deleted.

To view the entitlements assigned to the role, filter the list of roles to show only Helix
(TAP) roles, and then drill down from the TAP Analyst Limited role to its component
entitlements.
Requirements
To view the entitlements associated with the TAP Analyst Limited role:
4. Click TAP Analyst (limited) in the Name column.

The Helix entitlements granted by the global TAP Analyst Limited role are described in the
following tables.
Alert Suppressions
© 2021 FireEye 445

Alerts
Analytics
Appliances
Appliance Groups

446 © 2021 FireEye

Archive Searches
Assets
Dashboards
Events
Incidents
© 2021 FireEye 447

Indicators
Lists
Packet Capture Jobs


448 © 2021 FireEye

Reports
Rule Packs
Rules
Scheduled Searches
Searches
© 2021 FireEye 449









Sensors
Threats
450 © 2021 FireEye

Widgets
© 2021 FireEye 451

TAP Cloud Collector Role

TAP Cloud Collector access gives the user limited access to view data and perform actions
in Helix related to Cloud Collector sensors.
NOTE: TAP Cloud Collector is a global role, and it cannot be modified or deleted.

(TAP) roles, and then drill down from the TAP Cloud Collector role to its component
entitlements.
Requirements
To view the entitlements associated with the TAP Cloud Collector role:
4. Click TAP Cloud Collector in the Name column.

The Helix entitlements granted by the global TAP Cloud Collector role are described in the
following tables.
Packet Capture Jobs

452 © 2021 FireEye


© 2021 FireEye 453

TAP Content Limited Role

TAP Content Limited prevents the user from viewing data or performing actions within
Helix. You can temporarily disable a user's access to Helix by assigning the TAP Content
Limited role instead of deleting the user account. Depending on the circumstances, this
might be preferable for auditing purposes.
NOTE: TAP Content Limited is a global role, and it cannot be modified or

deleted.

(TAP) roles, and then drill down from the TAP Content Limited role to its component
entitlements.
Requirements
To view the entitlements associated with the TAP Content Limited role:
4. Click TAP Content Limited in the Name column.

The TAP Content Limited role has no entitlements.
454 © 2021 FireEye

TAP Federated Analyst Role

TAP Federated Analyst access allows the user to view data and perform all actions within
Helix, except for assigning and editing user permissions. It also gives the user the
federated view and the ability to take actions on behalf of child organizations.
NOTE: TAP Federated Analyst is a global role, and it cannot be modified or

deleted.

(TAP) roles, and then drill down from the TAP Federated Analyst role to its component
entitlements.
Requirements
To view the entitlements associated with the TAP Federated Analyst role:
4. Click TAP Federated Analyst in the Name column.

The Helix entitlements granted by the global TAP Federated Analyst role are described in
the following tables.
Alerts
© 2021 FireEye 455

Alert Suppressions
Analytics
Appliances
Appliance Groups

456 © 2021 FireEye

Archive Searches
Assets
Cases—Federated

organizations
Dashboards
© 2021 FireEye 457

Events
Incidents
Indicators


observables
observables
458 © 2021 FireEye

Lists
Packet Capture Jobs


Reports
© 2021 FireEye 459

Reports—Federated
Rules
Rule Packs
Scheduled Searches
Searches
460 © 2021 FireEye









Sensors
Threats
© 2021 FireEye 461

Widgets
Widgets—Federated
462 © 2021 FireEye

TAP Federated Analyst Limited Role

TAP Federated Analyst Limited access allows the user to view data and perform all
actions within Helix, except for assigning or editing user permissions and executing regex
searches. It also gives the user the federated view and the ability to take actions on behalf
of child organizations.
NOTE: TAP Federated Analyst Limited is a global role, and it cannot be modified

or deleted.

(TAP) roles, and then drill down from the TAP Federated Analyst Limited role to its
Requirements
To view the entitlements associated with the TAP Federated Analyst Limited role:
4. Click TAP Federated Analyst (limited) in the Name column.

© 2021 FireEye 463

The Helix entitlements granted by the global TAP Federated Analyst Limited role are
described in the following tables.
Alerts
Alerts—Federated
organizations
notes
Alert Suppressions
organizations

suppressions
Analytics
464 © 2021 FireEye

Appliances
Appliance Groups

Archive Searches
© 2021 FireEye 465

Assets
Cases—Federated

organizations
Dashboards
466 © 2021 FireEye

Events
Incidents
Indicators


observables
observables
© 2021 FireEye 467

Lists
Packet Capture Jobs


Policies
policies
468 © 2021 FireEye

Reports
Reports—Federated
Rules
Rule Packs
© 2021 FireEye 469

Scheduled Searches
Scheduled Searches—Federated
tap.scheduledsearch.add Whether a user can create new federated scheduled searches
tap.scheduledsearch.browse Whether a user can browse federated scheduled searches
tap.scheduledsearch.delete Whether a user can delete federated scheduled searches
tap.scheduledsearch.edit Whether a user can edit individual federated scheduled searches
tap.scheduledsearch.read Whether a user can view individual federated scheduled searches
Searches
Searches—Federated
tap.federated.search.browse Whether a user can execute a search across child organizations





470 © 2021 FireEye



Sensors
Threats
Widgets
© 2021 FireEye 471

Widgets—Federated
472 © 2021 FireEye

TAP Federated Organization Administrator Role

TAP Federated Organization Administrator access gives the user full access to view data
and perform all actions in Helix. It also gives the user the federated view and the ability to
take actions on behalf of child organizations.
NOTE: TAP Federated Organization Administrator is a global role, and it cannot

be modified or deleted.

(TAP) roles, and then drill down from the TAP Federated Organization Administrator role
to its component entitlements.
Requirements
To view the entitlements associated with the TAP Federated Organization Administrator

role:
4. Click TAP Federated Organization Administrator in the Name column.

© 2021 FireEye 473

The entitlements granted by the TAP Federated Organization Admin role are described in
the following tables.
Alerts
Alerts—Federated
organizations
notes
Alert Suppressions
organizations

suppressions
Analytics
474 © 2021 FireEye

Appliances
Appliance Groups

Archive Searches
© 2021 FireEye 475

Assets
Cases—Federated

organizations
Dashboards
476 © 2021 FireEye

Events
Incidents
Indicators


observables
observables
© 2021 FireEye 477

Lists
Packet Capture Jobs


Policies
policies
478 © 2021 FireEye

Reports
Reports—Federated
Rules
Rule Packs
Saved Searches
© 2021 FireEye 479

Scheduled Searches
Searches
Searches—Federated
tap.federated.search.browse Whether a user can execute a search across child organization
tap.federated.search.regex Whether a user can execute a regular expression search across child
organizations








480 © 2021 FireEye

Sensors
Threats
Users
© 2021 FireEye 481

Widgets
Widgets—Federated
482 © 2021 FireEye

TAP Organization Administrator Role

TAP Organization Administrator access gives the user full access to view data and
perform all actions in Helix.
NOTE: TAP Organization Administrator is a global role, and it cannot be

modified or deleted.

(TAP) roles, and then drill down from the TAP Organization Administrator role to its
Requirements
To view the entitlements associated with the TAP Organization Administrator role:
4. Click TAP Organization Administrator in the Name column.

The Helix entitlements granted by the global TAP Organization Administrator role are
described in the following tables.
Alerts
© 2021 FireEye 483

Alert Suppressions
Analytics
Appliances
Appliance Groups

484 © 2021 FireEye

Archive Searches
Assets
Dashboards
Events
Incidents
© 2021 FireEye 485

Indicators
Lists
Packet Capture Jobs


486 © 2021 FireEye

Policies
policies
Reports
Rules
© 2021 FireEye 487

Rule Packs
Saved Searches
Scheduled Searches
Searches





488 © 2021 FireEye



Sensors
Threats
© 2021 FireEye 489

Users
Widgets
490 © 2021 FireEye

Release 2021.1 Entitlements for FireEye Threat Intelligence Roles
Entitlements for FireEye Threat

Intelligence Roles
FireEye IAM provides a single global role for FireEye Threat Intelligence:
l Threat Intelligence—Included Role below
Threat Intelligence—Included Role

The FireEye Threat Intelligence—Included role allows access to alert-based intelligence
reports and analysis tools.
NOTE: FireEye Threat Intelligence—Included is a global role, and it cannot be

modified or deleted.

To view the entitlements assigned to the role, filter the list of roles to show only the Threat
Intelligence—Included role.
Requirements
To view the entitlements associated with the FireEye Threat Intelligence—Included role:
3. Filter the list on the Description column, specifying the match string INTEL in all
uppercase letters. (The search is case-sensitive.) The list refreshes and shows only
the roles that grant access to FireEye Threat Intelligence.
© 2021 FireEye 491

4. Click FireEye Threat Intelligence - Included in the Name column.

492 © 2021 FireEye

Release 2021.1 Entitlements for FireEye Threat Intelligence Roles
Users assigned the FireEye Threat Intelligence—Included role have access to the FireEye
iSIGHT Intelligence Portal (FIIP) directly from the Helix Web UI.
The entitlements granted by the Included role are described in the following table.
intel.rbi.operational Whether a user can access the FireEye iSIGHT Intelligence Portal (FIIP) from the Helix
Web UI.
intel.report.show Whether a user can view a FIIP report from the Helix Web UI.
intel.tmh Whether a user can access Threat Media Highlights from the Helix Web UI.
intel.tools.analysis Whether a user can access FIIP analysis tools from the Helix Web UI.
© 2021 FireEye 493

Entitlements for the FireEye Appliance

Roles
This section describes the entitlements for global roles that FireEye IAM provides for
FireEye appliances:
l About IAM Global Roles for FireEye Appliances on the facing page
l Central Management Appliance Roles on page 496
l Email Security — Server Edition Appliance Roles on page 498
l Network Security Appliance Roles on page 500
l Endpoint Security Appliance Roles on page 502
l Fallback Roles for FireEye Appliances on page 504
l FireEye Appliance Org Admin Role on page 507
The following table summarizes the IAM global roles for FireEye appliances.
Appliance
Role Central Email Security — Server Network Endpoint
Management Edition Security Security
Admin ✔ ✔ ✔ ✔
Analyst ✔ ✔ ✔ ✔
Analyst SR ― ― ― ✔
API Admin ― ― ― ✔
API Analyst ― ― ― ✔
Auditor ✔ ✔ ✔ ✔
FE Service ― ― ― ✔
Investigator ― ― ― ✔
Monitor ✔ ✔ ✔ ✔
Operator ✔ ✔ ✔ ✔
Reject ✔ ✔ ✔ ✔
494 © 2021 FireEye

Release 2021.1 Entitlements for the FireEye Appliance Roles
About IAM Global Roles for FireEye Appliances

The following FireEye IAM global roles are provided for each of the supported FireEye
appliance types (CM Series, EX Series, NX Series, and HX Series appliances):
l Admin―This is a "super user" role for each appliance type. The primary function of
this role is to configure the system.
l Analyst―This role focuses on the detection of appliance-specific malware type and

taking appropriate action, including setting up alerts and reports.
l Auditor―This role reviews audit logs for the appliance type and performs forensic
analysis to trace how events occurred.
l Monitor―This role has read-only access to some of the Admin role capabilities for
the appliance type, and it has access to some appliance-specific malware analysis
functions.
l Operator―This role has a subset of the Admin role capabilities for the appliance
type. Its primary function is configuring and monitoring the system.
l Org Admin
This is a "super user" role for all appliance types. The primary function of this role
is to configure the system.
l Reject―This role is denied access of any kind to the appliance type.
The following FireEye IAM global roles are provided for HX Series appliances only:
l API Admin―This role grants basic and extended API authorization for HX Series
appliance features. The extended authorization allows a user to maintain custom
policy channels and to contain hosts.
l API Analyst―This role grants only basic API authorization for HX Series appliance
features.
l Analyst SR―This role is the same as the Analyst role, except the Analyst SR role
can also request file acquisitions. An Analyst SR cannot approve containment
requests or stop containment of host endpoints.
l FE Services―This role is for a FireEye as a Service (FAAS) analyst on HX Series
appliances that have an MD_ACCESS license. The role does allow the user to create
additional FE Services users unless an MD_ACCESS license is installed.
l Investigator―This role is the same as the Analyst SR role for HX Series appliances,
but the Investigator can also stop containment of host endpoints.
© 2021 FireEye 495

Central Management Appliance Roles

FireEye IAM provides global roles that correspond to the six roles for Central Management
appliance local user accounts. The local roles are described in Capabilities of Local Roles
on page 390.
Viewing the Roles

To view the list of Central Management appliance roles, filter the list of roles on the Name
column.
Requirements
1. Select Organization Settings > Roles.
2. Filter the list on the Name column, specifying the match the string CM in all capital
letters. (The filter is case-sensitive.) The list refreshes and shows only the roles that
grant access to Central Management appliances.
The global roles for Central Management appliances each map to a single
entitlement that represents multiple access privileges.
496 © 2021 FireEye

To view the list of IAM roles for FireEye Central Management appliances:
2. Filter the list on the Name column, specifying the match the string NX in all capital
grant access to Central Management appliances.
The global roles for Central Management appliances each map to a single
entitlement that represents multiple access privileges.
The IAM global roles for Central Management appliances have the following entitlements:
FireEye
Central Management Appliance Entitlement Description
Role
CM Series Admin cms.role.admin Admin role for CMS
CM Series Analyst cms.role.analyst Analyst role for CMS
CM Series Auditor cms.role.auditor Auditor role for CMS
CM Series Monitor cms.role.monitor Monitor role for CMS
CM Series Operator cms.role.operator Operator role for CMS
CM Series Reject cms.role.reject Reject access to CMS
© 2021 FireEye 497

Email Security — Server Edition Appliance Roles

FireEye IAM provides global roles that correspond to the six roles for Email Security —
Server Edition appliance local user accounts. The local roles are described in Capabilities
of Local Roles on page 390.
Viewing the Roles

To view the list of Email Security — Server Edition appliance roles, filter the list of roles on
the Name column.
Requirements
To view the list of IAM roles for FireEye Email Security — Server Edition appliances:
2. Filter the list on the Name column, specifying the match the string EX in all capital
grant access to Email Security — Server Edition appliances.
The global roles for Email Security — Server Edition appliances each map to a
single entitlement that represents multiple access privileges.
498 © 2021 FireEye

The IAM global roles for Email Security — Server Edition appliances have the following
entitlements:
FireEye
Email Security Appliance Entitlement Description
Role
EX Series Admin ex.role.admin Admin role for EX
EX Series Analyst ex.role.analyst Analyst role for EX
EX Series Auditor ex.role.auditor Auditor role for EX
EX Series Monitor ex.role.monitor Monitor role for EX
EX Series Operator ex.role.operator Operator role for EX
EX Series Reject ex.role.reject Reject access to EX
© 2021 FireEye 499

Network Security Appliance Roles

FireEye IAM provides global roles that correspond to the six roles for Network Security
on page 390.
Viewing the Roles

To view the list of Network Security appliance roles, filter the list of roles on the Name
column.
Requirements
To view the list of IAM roles for FireEye Network Security appliances:
2. Filter the list on the Name column, specifying the match the string NX in all capital
grant access to Network Security appliances.
The global roles for Network Security appliances each map to a single entitlement
that represents multiple access privileges.
500 © 2021 FireEye

The IAM global roles for Network Security appliances have the following entitlements:
FireEye
Network Security Appliance Entitlement Description
Role
NX Series Admin nx.role.admin Admin role for NX
NX Series Analyst nx.role.analyst Analyst role for NX
NX Series Auditor nx.role.auditor Auditor role for NX
NX Series Monitor nx.role.monitor Monitor role for NX
NX Series Operator nx.role.operator Operator role for NX
NX Series Reject nx.role.reject Reject access to NX
© 2021 FireEye 501

Endpoint Security Appliance Roles

FireEye IAM provides global roles that correspond to the eleven roles for Endpoint Security
on Endpoint Security Appliances on page 397.
Viewing the Roles

To view the list of Endpoint Security appliance roles, filter the list of roles on the Name
column.
Requirements
To view the list of IAM roles for FireEye Endpoint Security appliances:
2. Filter the list on the Name column, specifying the match the string HX in all capital
grant access to HX Series appliances.
The global roles for Endpoint Security appliances each map to a single entitlement
that represents multiple access privileges.
502 © 2021 FireEye

The IAM roles for Endpoint Security appliances have the following entitlements:
hx.role.api_admin API Admin role for HX
hx.role.api_analyst API Analyst role for HX
hx.role.admin Admin role for HX
hx.role.analyst Analyst role for HX
hx.role.analyst_sr Analyst SR role for HX
hx.role.auditor Auditor role for HX
hx.role.fe_services FE Services role for HX
hx.role.investigator Investigator role for HX
hx.role.monitor Monitor role for HX
hx.role.operator Operator role for HX
hx.role.reject Reject access to HX
© 2021 FireEye 503

Fallback Roles for FireEye Appliances

The IAM roles for FireEye appliances include six roles that grant access privileges needed
to perform a specific job function. The roles correspond in name to IAM roles for
CM Series, EX Series, NX Series, and HX Series appliances:
l FireEye Admin
l FireEye Analyst
l FireEye Auditor
l FireEye Monitor
l FireEye Operator
l FireEye Reject
These job-specific roles are product-agnostic rather than product-specific. Each role grants
job-specific access privileges for all supported FireEye appliance types: CM Series,
EX Series, NX Series, and HX Series appliances. The roles act as "fallback roles" because a
FireEye appliance will apply a fallback role only for users that are not assigned any
appliance-specfic roles.
As an example, the FireEye Auditor role grants permissions typically needed by Auditors
on CM Series, EX Series, NX Series, and HX Seriesappliances.
Fallback Entitlements for HX Series Appliance Roles

The following roles are specific to HX Series appliances only, and IAM does not provide
fallback roles for these roles:
l HX Series appliance Analyst SR

l HX Series appliance API Admin
l HX Series appliance API Analyst
l HX Series appliance FE Services
l HX Series appliance Investigator
If a user account is not assigned any HX Series appliance roles, then HX Series appliance
local role capabilities are used for these roles.
Viewing the Roles

To view the list of fallback roles for FireEye appliances, filter the list of roles on the Name
column.
504 © 2021 FireEye

Requirements
To view the list of IAM roles for FireEye appliances:

2. Filter the list on the Name column, specifying the match the string
FireEye Appliance in mixed-case letters as shown. (The filter is case-sensitive.)
The list refreshes and shows only the six fallback roles for FireEye appliances, plus
the FireEye Appliance Org Admin role.
Each global fallback role maps to a single entitlement that represents a collection of
individual access privileges for a specific role for any appliance type.
For each type of FireEye appliance fallback role―Admin, Analyst, Auditor, Monitor,
Operator, and Reject―there is a single entitlement that grants role-specific (not appliance-
specific) privileges for all of the FireEye appliance types:
appliance.role.admin The fallback Admin permissions for any type of FireEye appliance
appliance.role.analyst The fallback Analyst permissions for any type of FireEye appliance
appliance.role.auditor The fallback Auditor permissions for any type of FireEye appliance
appliance.role.monitor The fallback Monitor permissions for any type of FireEye appliance
© 2021 FireEye 505

appliance.role.operator The fallback Operator permissions for any type of FireEye appliance
appliance.role.reject The fallback Reject permissions for any type of FireEye appliance
506 © 2021 FireEye

FireEye Appliance Org Admin Role

The FireEye Appliance Org Admin grants the user the entitlements of all of the FireEye
appliance fallback roles, plus the entitlements of all of the FireEye appliance roles. The
entitlements enable the user to manage user roles for every supported FireEye appliance
type (CM Series, EX Series, NX Series, and HX Series appliances).
NOTE: FireEye Appliance Org Admin is a global role, and it cannot be modified

or deleted.
Viewing the Entitlements

To view the entitlements assigned to the role, filter the list of roles to show only FireEye
Appliance roles, and then drill down from the FireEye Appliance Org Admin role to its
Requirements
© 2021 FireEye 507

To view the list of IAM roles for the FireEye appliance fallback roles:

2. Filter the list on the Name column, specifying the match the string
FireEye Appliance in mixed-case letters as shown. (The filter is case-sensitive.)
The list refreshes and shows only the six fallback roles for FireEye appliances, plus
the FireEye Appliance Org Admin role.
The FireEye Appliance Org Administrator role combines all of the IAM global roles
for FireEye appliances with the six FireEye appliance fallback roles.
3. Click FireEye Appliance Org Admin in the Name column.
The FireEye Appliance Organization Administrator role has the following 41 entitlements:
FireEye Appliance fallback roles for all appliance types
appliance.role.admin Admin role for all FireEye appliances
appliance.role.analyst Analyst role for all FireEye appliances
appliance.role.auditor Auditor role for all FireEye appliances
appliance.role.monitor Monitor role for all FireEye appliances
appliance.role.operator Operator role for all FireEye appliances
appliance.role.reject Reject access to all FireEye appliances
508 © 2021 FireEye

Malware Analysis appliance roles
ax.role.admin Admin role for AX
ax.role.analyst Analyst role for AX
ax.role.auditor Auditor role for AX
ax.role.monitor Monitor role for AX
ax.role.operator Operator role for AX
ax.role.reject Reject access to AX
Central Management appliance roles
cms.role.admin Admin role for CMS
cms.role.analyst Analyst role for CMS
cms.role.auditor Auditor role for CMS
cms.role.monitor Monitor role for CMS
cms.role.operator Operator role for CMS
cms.role.reject Reject access to CMS
Email Security — Server Edition appliance roles
ex.role.admin Admin role for EX
ex.role.analyst Analyst role for EX
ex.role.auditor Auditor role for EX
ex.role.monitor Monitor role for EX
ex.role.operator Operator role for EX
ex.role.reject Reject access to EX
Endpoint Security appliance roles
hx.role.admin Admin role for HX
hx.role.analyst Analyst role for HX
hx.role.analyst_sr Analyst SR role for HX
hx.role.api_admin API Admin role for HX
hx.role.api_analyst API Analyst role for HX
hx.role.auditor Auditor role for HX
© 2021 FireEye 509

hx.role.fe_services FE Services role for HX
hx.role.investigator Investigator role for HX
hx.role.monitor Monitor role for HX
hx.role.operator Operator role for HX
hx.role.reject Reject access to HX
Network Security appliance roles
nx.role.admin Admin role for NX
nx.role.analyst Analyst role for NX
nx.role.auditor Auditor role for NX
nx.role.monitor Monitor role for NX
nx.role.operator Operator role for NX
nx.role.reject Reject access to NX
510 © 2021 FireEye

Technical Support
For technical support, contact FireEye through the Support portal:

https://csportal.fireeye.com
Documentation
Documentation for all FireEye products is available on the FireEye Documentation Portal
(login required):
https://docs.fireeye.com/
© 2021 FireEye 511

FireEye, Inc. | 601 McCarthy Blvd. | Milpitas, CA | 1.408.321.6300 | 1.877.FIREEYE | www.fireeye.com
© 2021 FireEye, Inc. All rights reserved. FireEye is a registered trademark of FireEye, Inc. All other brands,
products, or service names are or may be trademarks or service marks of their respective owners.

SSEC SSG 2021.1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSEC SSG 2021.1 PDF

Uploaded by

Copyright:

Available Formats

F I R E E Y E T E C H N I C A L

SYSTEM SECURITY / 2021

Copyright © 2021 FireEye, Inc. All rights reserved.

FireEye Contact Information:

PART II: Authentication 21

CHAPTER 2: Authentication Methods 23

CHAPTER 3: Local Authentication 29

Managing Account Status 40

CHAPTER 4: Remote Authentication 65

CHAPTER 5: Common Access Card (CAC) for Certificate Authentication 79

Configuring a CA Certificate Bundle 81

Verifying Certificate Authentication Status Using the Web UI 113

CHAPTER 6: Secure Shell (SSH) Authentication 115

CHAPTER 7: Single Sign-On Authentication 143

When SSO Authentication Is Disabled 146

CHAPTER 8: Configuring SAML Authentication and Authorization on

PART III: Authorization 171

CHAPTER 9: Assigning Roles for Local User Accounts 173

CHAPTER 10: Configuring Access Groups for Alerts 175

Creating Access Groups for Alerts 176

CHAPTER 10: Configuring Access Groups for YARA Rules 198

PART IV: Accounting 205

CHAPTER 11: Accounting 207

PART V: Certificates 211

CHAPTER 12: Certificate Management 213

CHAPTER 13: Managing HTTPS and MTA Certificates 215

Activating Named Certificates Using the Web UI 240

CHAPTER 14: Managing CA Certificates 245

CHAPTER 15: Improving Certificate Security 267

CHAPTER 16: Defining Default Certificate Attributes 273

CHAPTER 17: Renaming a Certificate 277

PART VI: FireEye IAM 279

CHAPTER 18: FireEye IAM Overview 281

Two-Factor Authentication 306

CHAPTER 20: FireEye IAM Organization 313

CHAPTER 21: FireEye IAM Roles 321

CHAPTER 22: FireEye IAM User Accounts 333

Permissions Granted by Directly Assigned Roles 334

CHAPTER 23: FireEye IAM User Groups 359

CHAPTER 24: FireEye IAM API Keys 375

PART VII: Appendices 387

APPENDIX A: Capabilities of FireEye Appliance Local Roles 389

APPENDIX B: FireEye IAM Entitlements 409

FireEye Super Admin Role 419

Technical Support 511

PART II: Authentication

l Local—Users are authenticated against the local username database. This is

IMPORTANT! The FireEye software uses the remote authentication methods as

Defining the Authentication Order Using the CLI

To define the authentication order:

2. To specify the authentication tool order, use the following command:

To configure the authentication:

4. Configure the IP address and secret of the RADIUS server:

5. Configure the IP address and secret of the TACACS+ server:

7. Configure the IP address of the LDAP server, as a fallback mechanism:

8. Configure the base of the user tree for LDAP:

9. Configure the LDAP user schema name for LDAP:

10. Configure the base of the group tree for LDAP:

11. Configure the LDAP group schema name for membership:

12. Save your changes:

Enabling or Disabling the Log Out

To enable the log out message setting:

3. Save your changes.