NetWorker 19.1 Security Configuration Guide PDF
NetWorker 19.1 Security Configuration Guide PDF
Version 19.1
Dell believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS-IS.” DELL MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND
WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. USE, COPYING, AND DISTRIBUTION OF ANY DELL SOFTWARE DESCRIBED
IN THIS PUBLICATION REQUIRES AN APPLICABLE SOFTWARE LICENSE.
Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property
of their respective owners. Published in the USA.
Dell EMC
Hopkinton, Massachusetts 01748-9103
1-508-435-1000 In North America 1-866-464-7381
www.DellEMC.com
Figures 7
Tables 9
Preface 11
Chapter 1 Introduction 17
1 Revision history........................................................................................................... 11
2 Style conventions........................................................................................................13
3 Configuration options................................................................................................. 26
4 Default password policy requirements ....................................................................... 55
5 NetWorker Authentication Service CLI options ......................................................... 56
6 NMC user roles and associated privileges...................................................................60
7 Allowed Operations for each NetWorker privilege ..................................................... 69
8 Privileges associated with each NetWorker User Group............................................. 73
9 Operations that require entries in the servers file .....................................................102
10 NetWorker Server log files........................................................................................ 108
11 NMC server log files................................................................................................... 111
12 Client log files............................................................................................................ 112
13 Message types ..........................................................................................................116
14 Raw log file attributes that manage log file size......................................................... 119
15 Raw log file attributes that manage the log file trimming mechanism........................ 119
16 NetWorker Authentication Service log files............................................................... 131
17 Setting TCP parameters for each operating system..................................................138
18 Standard NetWorker Client port requirements to NetWorker server........................ 140
19 Additional service port requirements for Snapshot clients........................................ 140
20 Service port requirements for storage nodes ............................................................ 141
21 NetWorker server program port requirements.......................................................... 142
22 Port requirements to NMC server to each NetWorker client ....................................143
23 nsrports options........................................................................................................ 145
24 Port requirements for NetWorker communications with applications........................146
25 Levels available for the nsrck process....................................................................... 170
26 Security event resources and attributes - resource database (RAP)......................... 177
27 Security event resources and attributes - NetWorker client database...................... 179
28 Message types ......................................................................................................... 183
29 Auditlog rendered service attributes......................................................................... 184
01 May 20, 2019 First release of the document for NetWorker 19.1.
Related documentation
The NetWorker documentation set includes the following publications, available on the
Support website:
l NetWorker E-LAB Navigator
Provides compatibility information, including specific software and hardware
configurations that NetWorker supports. To access E-LAB Navigator, go to
https://elabnavigator.emc.com/eln/elnhome.
l NetWorker Administration Guide
Describes how to configure and maintain the NetWorker software.
l NetWorker Network Data Management Protocol (NDMP) User Guide
Describes how to use the NetWorker software to provide data protection for
NDMP filers.
l NetWorker Cluster Integration Guide
Contains information related to configuring NetWorker software on cluster servers
and clients.
l NetWorker Installation Guide
Note: Contains information that is incidental, but not essential, to the topic.
Typographical conventions
The following type style conventions are used in this document:
Bold Used for interface elements that a user specifically selects or clicks,
for example, names of buttons, fields, tab names, and menu paths.
Also used for the name of a dialog box, page, pane, screen area with
title, table label, and window.
Italic Used for full titles of publications that are referenced in text.
Monospace Used for:
l System code
l System output, such as an error message or script
l Pathnames, file names, file name extensions, prompts, and
syntax
l Commands and options
You can use the following resources to find more information about this product,
obtain support, and provide feedback.
Where to find product documentation
l https://www.dell.com/support
l https://community.emc.com
Log Settings
A log is a chronological record that helps you to examine the sequence of
activities surrounding or leading up to an operation, procedure, or event in a
security-related transaction from beginning to end. This chapter describes how to
access and manage the logs files available in NetWorker.
Note: You can use the NetWorker Management Console or the authc_mgmt
command line tool to perform all the configurations.
l Internal authentication authority settings (Local users and groups)—Defines
information about local user accounts and groups. The NetWorker Authentication
Service creates a built-in local administrator account during the installation
process. When you install the NMC server software, the NMC installation process
creates a default service account svc_nmc_nmc_server_name.
l External authentication authority configuration settings—Defines information
about the LDAP and AD servers that the NetWorker Authentication Service can
use to authenticate user access.
l Access permissions—Defines access permissions for users to manage the local
database. Currently, two levels of permissions exist for users: FULL_CONTROL
and Everyone. To configure the access permissions, use the authc_config
command line tool.
l Service options—Defines the options for the NetWorker Authentication Service,
for example, token and user options such as password policy configurations.
The NetWorker Authentication Service database provides a hierarchical security
model for users and groups, which enables you to define access levels, authentication,
and authorization in a multi-tenant configuration. The NetWorker Authentication
Service provides the following organizational hierarchy:
l Tenant—Top-level organizational container for the NetWorker Authentication
Service. Each external authentication authority in the local database is assigned to
a tenant. A Tenant can contain one or more Domains but the domain names must
be unique within the tenant. NetWorker Authentication Service creates one built-
in tenant name Default, which contains the Default domain. Creating multiple
tenants helps you to manage complex configurations. For example, service
providers with restricted datazones (RDZ) can create multiple tenants to provide
isolated data protection services to tenant users.
l Domain—An organizational container that contains one external authentication
authority configuration. NetWorker Authentication Service creates one built-in
domain name Default, which contains the local user database.
l Configuration— A configuration name and ID that uniquely identifies one tenant,
domain, and external authority mapping.
The following figure provides an example of a NetWorker Authentication Service
database with the following hierarchy:
l Three external authentication authority configurations:
n LDAP_database1 contains the configuration information for an LDAP directory.
n LDAPS_database contains the configuration information for an LDAPS
directory.
n AD_database1 contains the configuration information for an AD directory.
l Four domains, the Default domain, the three user-defined domains, the Accounting
domain, the IT domain, and the HR domain.
l One tenant, the Default tenant.
Managing authentication
The NetWorker Authentication Service is a web-based application that provides
authentication services to other applications.
The NetWorker Authentication Service maintains a local user database to verify the
credentials of a user account. You can also configure the NetWorker Authentication
Service to use an external authority database, for example LDAP or AD. When you
configure an external authority database, the NetWorker Authentication Service
communicates directly with an LDAP or AD server to authenticate users.
You can use command line tools to configure and manage the authentication.
Note: If the authc server is installed in Java-9, and in case you try to execute the
authc command/ script using Java-8, you will not be allowed to execute the
script. This issue is most likely to occur when you have both Java-8 and Java-9
running on the setup.
To resolve this issue you can perform either of the following:
l Include Djavax.net.ssl.trustStorePassword=XXXXX in CLI script.
l Copy key keystore.password and value from authc-server.app.properties to authc-
server.cli.properties.
Using NMC Console to configure LDAP, AD, or LDAPS authentication to manage NetWorker
servers
On NetWorker servers, you can use the NMC Console window to configure the
NetWorker Authentication Service to authenticate users in an AD or LDAP directory.
After creating an AD or LDAP provider, you can also edit the external authority within
the Console.
About this task
Note: The LDAP Configuration wizard is only supported from the NetWorker 18.1
release.
Procedure
1. (Optional) Create a tenant in the local database for the external authority. If
you do not create a tenant, the configuration uses the Default tenant, which has
an ID of 1. To create a tenant, type the following command:
where:
l name is the name of the tenant, without spaces. The maximum number of
characters is 256. Specify ASCII characters in the tenant name only.
l alias is alias of the tenant name. The maximum number of characters is 256.
l tenant_description is a user-defined description of the tenant. The maximum
number of characters is 256.
5. Right-click in the External Authority pane and select New from the drop-down.
The Create External Authentication Authority dialog displays.
Figure 3 Create External Authentication Authority
8. In the Configuration Parameters pane, if you are not using the default port
389, type the correct Port Number.
9. In the Configuration Parameters pane, for the User Group field, type the
name of a user account that has full read access to the LDAP or AD directory in
the format " CN=XXXX,OU=YYYY", and then type the User DN password.
XXXX is the common name and YYYY is the organizational unit name.
Alternatively, if there is no OU configured, you can specify the CN and DC
components instead. The NMC Property Help provides more information and
examples for the User Group field.
10. If any of the default values populated in the Advanced Configuration
Parameters fields do not match your LDAP/LDAPS/AD server configuration,
change the values accordingly. If these values do not match your configuration,
the provider creation process fails.
11. Click OK.
Note: All fields in the Configuration Parameters pane of the dialog are
mandatory. If you click OK and any of these fields is missing, NMC displays
an error message.
Validation of the provider occurs during the connection attempt with the server.
If the domain or FQDN could not be validated, then an error will be logged in
NMC.
Results
After creating a provider, you can double-click on the entry in the External Authority
pane to view the properties of the provider. The Edit External Authentication
Authority dialog displays.
Within this dialog, you can modify any of the read/write fields. Note that the
Authority Name and Tenant fields will be greyed out. You can only modify these
fields when you create the provider in the Create External Authentication Authority
dialog.
When you change any of the fields and click OK, a prompt appears requesting you to
re-enter the password. After a message displays indicating that the change was
successful, close the Edit External Authentication Authority dialog and then re-open
to view the change.
Note: After you log in as an AD or LDAP user, ensure that you do not change the
Group Search Path and the User Search Path values. If you change the Group
Search Path and the User Search Path values, the earlier saved values are lost,
and you cannot access information related to users, groups, and so on.
Procedure
1. (Optional) Create a tenant in the local database for the external authority, and
then determine the tenant ID assigned to the tenant. If you do not create a
tenant, the configuration uses the Default tenant, which has an ID of 1. Perform
the following steps:
a. To create a tenant, type the following command:
where:
l name is the name of the tenant, without spaces. The maximum number of
characters is 256. Specify ASCII characters in the tenant name only.
l alias is alias of the tenant name. The maximum number of characters is
256.
l tenant_description is a user-defined description of the tenant. The
maximum number of characters is 256.
Note: Ensure that you have a space before each -D. If you do not have a
space before the -D switch, authc_config appends the -D to the
previous option value and ignores the option value to which the -D is
associated with.
The following table provides more information about each configuration option.
Default value: NO
-D "config-user-object-class=user_object_class" userObjectClass Required. The object class that identifies the users
in the LDAP or AD hierarchy. For example,
inetOrgPerson.
Default value: No
The following figure provides an example of the key group attributes that you use
when you configure the AD authority.
Figure 5 Group properties in ADSI Edit
NetWorker provides a template file that you can modify with the configuration values
that are specific to your environment, and then run to configure AD authentication.
The location and name of the file differs on Windows and Linux:
l AD template file:
n Windows—C:\Program Files\EMC NetWorker\nsr\authc-server
\scripts\authc-create-ad-config.bat.template
n Linux—/opt/nsr/authc-server/scripts/authc-create-ad-
config.sh.template
To use the template file, perform the following steps:
1. Use a text editor to open the file.
2. Replace the variables enclosed in <> with the values that are specific to your
configuration. The following output provides an example of the contents of the file
after substituting the attributes for your configuration:
Note: In this example, to restrict NMC and NetWorker servers access to only
users in the NetWorker_admins group, you must configure the NMC Roles on
the NMC server and the User Groups resource on the NetWorker server. The
section "User authentication and authorization" provides more information.
3. Save the file, and then remove the .template extension.
4. Use the authc_mgmt command with the -e query-ldap-users option along
with the query-domain and query-tenant options to confirm that you can
successfully query the AD directory:
The following figure provides an example of the key group attributes that you use
when configuring the LDAP authority.
Figure 7 Group properties in LDAPAdmin
NetWorker provides a template file that you can modify with the configuration values
that are specific to your environment, and then run to configure AD authentication.
The location and name of the file differs on Windows and Linux:
Ankush uid=Ankush,ou=AlbertaPeople,dc=alberta,dc=emc,dc=com
IDD uid=IDD,ou=AlbertaPeople,dc=alberta,dc=emc,dc=com
nike1 uid=nike1,ou=AlbertaPeople,dc=alberta,dc=emc,dc=com
nike2 uid=nike2,ou=AlbertaPeople,dc=alberta,dc=emc,dc=com
sampar1
uid=sampar1,ou=AlbertaPeople,dc=alberta,dc=emc,dc=com
where:
l java_path is /opt/nre/java/latest on UNIX if NRE is installed.
java_path is /usr/java/latest if NRE is not installed.
l java_path is C:\Program Files\NRE\Java on Windows if NRE is
installed. java_path is C:\Program Files\Java if NRE is not installed.
l "password" is the Java trust keystore password.
Note: By default the password is set to changeit.
2. (Optional) If the keystore contains expired trusted Java certificates for the
LDAPS server, delete the certificates:
java_path/bin/keytool -delete -alias
LDAPS_server -keystore
java_path/lib/security/cacerts -storepass
"password"
where:
l LDAPS_server is the hostname of the LDAPS server.
l "password" is the Java trust keystore password.
Note: The time on NetWorker server must be in sync with the LDAPS
server.
3. To obtain a copy of the CA certificate from the LDAPS server, use the
openssl command:
where:
Note: The openssl command may display two certificates. The second
certificate is usually the CA certificate.
where:
l LDAPS_server is the hostname of the LDAPS server.
l java_path is /opt/nre/java/latest on UNIX if NRE is installed.
java_path is /usr/java/latest if NRE is not installed.
l java_path is C:\Program Files\NRE\Java on Windows if NRE is
installed. java_path is C:\Program Files\Java if NRE is not installed.
6. When prompted to trust the certificate, type Yes, and then press Enter.
7. Restart the NetWorker server after importing the new certificate into the
cacerts store file.
Note: This step is mandatory in order for the newly imported certificate to
get honored by the Authentication Service.
-D "config-domain=IDDS"
-D "config-server-address=ldaps://ldaps.emc.com:636"
-D "config-user-dn=cn=Directory Manager"
-D "config-user-dn-password=1.Password"
-D "config-user-id-attr=uid"
-D "config-user-object-class=inetOrgPerson"
-D "config-user-search-path=ou=People,dc=talisman-ds6,dc=com"
-D "config-group-member-attr=uniqueMember"
-D "config-group-name-attr=cn"
-D "config-group-object-class=groupOfUniqueNames"
-D "config-group-search-path=ou=Group,dc=talisman-ds6,dc=com"
-D "config-object-class=objectclass"
-D "config-active-directory=n"
-D "config-search-subtree=y"
Note: When you define the config-server-address option, ensure that you
specify ldaps as the protocol and the appropriate LDAPS port number.
9. To confirm that you can successfully query the LDAP directory, use the
authc_mgmt command with the -e query-ldap-users option. For example:
Workaround
l Ensure that the date and time on the NetWorker server is in sync with the LDAP
server.
l Verify if the certificate is a valid one by running the openssl s_client -connect
<LDAPS server:636> -CAfile <certificate> command. If the command
returns the following message:
This message means that the certificate has expired and cannot be used. The
notAfter field shows the validity of this certificate. Due to differences noticed in
the output of the keytool command, it is recommended that you use the
OpenSSL tool.
For example:
3. To determine the tenant name that is associated with the tenant, use the
authc_config with the -e find-tenant option:
For example, to display information about a tenant with tenant ID 33, type:
To view all the available operations, use the authc_config -help command.
4. To query the external authority database, use the authc_mgmt command with
one of the query options:
For example, to display the group membership for a specific user in the
iddconfig, perform the following steps:
a. If the username is not known, to determine the username, use the
authc_mgmt command with the -e query-ldap-users option. For example,
type:
Administrator
cn=Administrator,cn=Users,dc=iddlab,dc=local
Konstantin cn=Konstantin,cn=Users,dc=iddlab,dc=local
Katherine cn=Katherine,cn=Users,dc=iddlab,dc=local
Viktoryia cn=Viktoryia,cn=Users,dc=iddlab,dc=local
Patrick cn=Patrick,cn=Users,dc=iddlab,dc=local
Liam cn=Liam,cn=Users,dc=iddlab,dc=local
Meghan cn=Meghan,cn=Users,dc=iddlab,dc=local
NetWorker cn=NetWorker,dc=iddlab,dc=local
Error executing command. Failure: I/O error on POST request for "
host":Connection to host refused; nested exception is
org.apache.http.conn.HttpHostConnectException: Connection to host refused
This error messages appears when the NetWorker Authentication Service cannot
connect to the LDAP or AD server by using the port number specified in the config-
server-address option in the external authentication authority configuration.
To resolve this issue, correct the port number defined in the config-server-address
option.
For example, to update the config-server-address value in the config-server-address
in the iddconfig configuration, type the following command:
Error executing command. Failure: 400 Bad Request. Server message: Failed to
perform LDAP task task: Cannot resolve host 'hostname'
This error messages appears when the NetWorker Authentication Service cannot
resolve the host name of the LDAP or AD server specified in the config-server-
address option in the external authentication authority configuration.
To resolve this issue, perform the following tasks:
l Ensure that the NetWorker server can resolve the hostname and IP address of the
LDAP or AD server, and that the LDAP or AD server can resolve the hostname and
IP address of the NetWorker server.
l Ensure that the hostname or IP address that you specified in the config-server-
address option is correct.
If required, update the config-server-address value. For example, to update the
config-server-address value in the config-server-address in the iddconfig
configuration, type the following command:
7. In the Password and Confirm Password fields, specify a password for the user
that meets the password policy settings that are defined for the environment.
The default password policy requires that the password meets the following
minimum requirements:
l Nine characters long
l One uppercase letter
l One lowercase letter
l One special character
l One numeric character
Note: Managing local database password policies on page 54 describes
how to change the default password policy requirements.
Procedure
1. From the Console window, click Setup.
2. In the left pane, select Users.
3. Right-click the user, and then select Delete.
4. To confirm the deletion, click Yes.
If the user had saved customized reports, a dialog box prompts for the
username to reassign to those reports. Otherwise, you can delete the reports.
For example, to create a group that is named test, type the following command:
To display information about a group named test, type the following command:
Note: You specify the group ID value when you create a user or add a user to an
existing group.
Creating users
To create a user, use the -e add-user option:
For example, to create a user account Patd and add the account to a group named
test, type:
For example, to update the email address for the user account PatD, type the
following command:
For example, to view details about the user account PatD, type:
User DN : cn=PatD,cn=Users,dc=bu-
iddnwserver2,dc=IddLab,dc=local
User Enabled : true
User Groups : [132]
For example, to set the user-must-change-password option for the user Patd, type:
The user cannot manage the NetWorker Authentication Service until the password is
changed. For example:
The authc_mgmt UNIX man page and the NetWorker Command Reference Guide
provides detailed information about all the configuration options.
Group Id : 164
Group Name : authgroup
Group Details:
Group DN : cn=authgroup,cn=Groups,dc=bu-
iddnwserver2,dc=IddLab,dc=local
Group Users : PatD
Note: The output abbreviates the Group DN Pattern and Group DN values.
Use the find-permission option to see the complete value information.
The UNIX man page and the NetWorker Command Reference Guide provides detailed
information about how to use authc_config to manage permissions.
where:
n "username" is the name of the user whose password you want to change, or
local administrator account.
n "current_password" is the current password for the username that you
specified.
n "new_password" is the new password for the username that you specified.
For example, to change the password for the local administrator account, type the
following command:
Note: To change the password without typing the new password in the
command string, do not include the -D password-new-value="new_password"
option. The command will prompt you for the new password and will not
display the characters.
l To use the administrator account to change the password for any user, use the -e
update-user option with the -D user-name and -D user-password options:
authc_mgmt -u administrator -p "current_password" -e update-user -D
user-name=username -D user-password="new_password"
where:
n "current_password" is the password for the administrator account.
n "username" is the name of the user whose password you want to change.
n "new_password" is the new password that you want to set for the user.
For example, to change the password for a local user who is named Noelle to
".Mynewpass1", type the following command:
For example, to create the Base64 encoded password for a password value
of "1.Password", type:
The command displays the encoded text for the password value
"1.Password": MS5QYXNzd29yZA==
{
"local_users": [
{
"user name": "administrator",
"password": "MS5QYXNzd29yZA=="
}]
}
4. Rename the authc-local-config.json.template file to authc-local-
config.json.
5. Copy the authc-local-config.json file to the Tomcat conf folder.
By default, the conf folder is/nsr/authc/conf on Linux and C:\Program
Files\EMC NetWorker\authc-server\tomcat\conf on Windows.
Note: If the NetWorker server is also the NMC server, start the NMC
server service. Type the following commands: net start gstd
l For Linux, type the following commands:
/etc/init.d/networker stop
/etc/init.d/networker start
When the NetWorker Authentication Service starts, the startup process checks
for the authc-local-config.json. If the file exists and the password
<Connector port="9090"
protocol="org.apache.coyote.http11.Http11NioProtocol"
SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="/nsr/authc/conf/authc.keystore " keystorePass="$
{keystore.password}"
keyAlias="emcauthctomcat" keyPass="${tckey.password}"
clientAuth="false" sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2, TLSv1.1, TLSv1"
ciphers="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384" />
To disable TLS 1.0 and TLS 1.1, update to indicate the following:
sslEnabledProtocols="TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384"
/>
l Linux- /nsr/authc/conf
Option Id: 2
Name : TokenStartTimeDeltaInMinutes
Value : -15
TokenTimeoutInMinutes
The SAML token expiration timeout in minutes. The default value is 480 minutes (8
hours).
Note: The TokenTimeoutInMIintes parameter is case sensitive.
Option Id: 3
Name : TokenTimeoutInMinutes
Value : 720
PasswordExpirationDay Maximum number of days that a user can use a password before
s the user must change the password. The default value is 90.
To control the password policy requirement for user accounts, perform the following
steps:
l To modify password policy requirements, type the following command:
where option is one of the password policy options in the previous table.
For example, to change the default password expiration policy from 90 days to 30
days, type:
For example:
Note: The find-all-options operation does not display options that you
have not changed from the default values.
l To review the details about a specific option that has been modified from the
default value, type:
authc_config -u username -p "password" -e find-option -D option-
id=option_id
Argument Purpose
admin_service_default_ Defines the web protocol to use when you connect to the
protocol NetWorker Authentication Service. The default value is https.
admin_service_default_ Defines the url to use when you connect to the NetWorker
url Authentication Service. The default value is localhost.
admin_service_default_ Defines the port number to use when communicating with the
port NetWorker Authentication Service. The default value is 9090.
admin_service_default_ Defines the tenant to use, to validate the username that you specify
tenant with the CLI command. When you use this option, you do not
require the -t argument to define a username that is not in the
Default tenant.
Argument Purpose
admin_service_default_ Defines the default domain to use to validate the username that you
domain specify with the CLI command. When you use this option, you do
not require the -d argument to define a username that is not in the
Default domain.
admin_service_default_ Defines the username that runs the CLI command. When you use
user this option, you do not require the -u argument with the CLI
commands.
admin_service_default_ Defines the password of the user that runs the CLI command.
password When you use this option, you do not require the -p argument with
the CLI commands.
"port" : "9091"
9. Save the authc-server-app.json file.
10. On the NetWorker server, start the NetWorker services.
NMC server authorization on page 60 provides more information about NMC roles.
Operations that you perform in the NetWorker Administration GUI always use token-
based authentication. As a result, NetWorker uses the users and groups that are
specified in the External roles attribute of a User Group to determine the privileges
that are assigned to the user that begins the operation.
User group management on page 74 provides more information about the User
Group resource.
Client-initiated backup and recovery authentication and authorization
To use token-based authentication with a command line (CLI) backup or recovery
operation on a NetWorker host, first run the nsrlogin command. When you run the
nsrlogin command, the NetWorker host contacts the NetWorker Authentication
Service to validate the user log in credentials. When the NetWorker Authentication
Service successfully validates the credentials, the application issues an authentication
token to the NetWorker host for the user account that you used to run the command.
The NetWorker host caches the token and confirms that the user account has the
appropriate privileges to perform the operation. The user account can perform secure
client-initiated backup and recovery operations with the authenticated user until the
token expires or a user runs the nsrlogout command.
Note: When you do not use the nsrlogin command to enable token-based
authentication, NetWorker uses the NetWorker 8.2.x and earlier authentication
method. This authentication method relies on operating system authentication to
validate the user privileges.
Token expiration
The token policies that are defined in the NetWorker Authentication service database
determine how long a token remains valid:
l When the token for a CLI authenticated user expires, in-progress user-initiated
operations complete, but the user cannot start new operations until a new token is
issued to the user. To issue a new token for a CLI operation, the user must run the
nsrlogin command again.
l When the token expires while a user is connected to the NetWorker
Administration window, a token expiration message appears and the connection
to the NetWorker server closes. A prompt appears requesting that the user
specify their password and generate a new token. After a new token is issued, the
user can re-establish the connection to the NetWorker server.
l When the token expires while a user is connected to the NMC GUI, a token
expiration message appears and the user is prompted to specify their password
and generate a new token. After a new token is issued, the user can use the NMC
GUI.
Troubleshooting authorization errors and NetWorker server access issues on page 81
provides more information about how to resolve token expiration messages that
appear on a NetWorker server.
The NMC server controls how an authenticated user accesses a managed NetWorker
server. When you enable the User Authentication for NetWorker system option on
the NMC server, you can grant and restrict NetWorker server access and privileges to
individual user accounts. When you disable the User Authentication for NetWorker
option, access requests to a NetWorker server appear to come from the gstd process
owner on the NMC server. All NMC users that access the NetWorker server are
granted the same access and privilege rights that are assigned to the gstd process
owner account.
The NMC server enables the User Authentication for NetWorker system option by
default. When you enable the option, the NMC server software creates a separate
network connection from the NMC server to a NetWorker server for each NMC user
that has an Administration window open to that server. Additional network
connections might require access to additional firewall service ports.
When you do not set the User Authentication for NetWorker system option, there is
only one network connection from the NMC server to the managed NetWorker server.
User authorization
User authorization settings control the rights or permissions that are granted to a user
and enable access to a resource managed by NetWorker.
Console Security l Add, delete, and modify NetWorker Authentication Service local
Administrator database users.
Console User All tasks except for those tasks that are explicitly mentioned for the
Console Security Administrator and the Console Application
Administrator.
Tasks include:
tenant_name\domain_name\user_name
where:
l tenant_name is the name of the tenant that you specified when you
configured the external authentication authority configuration on the
NetWorker Authentication Service. If you use the Default tenant, you are
not required to specify the tenant name.
l domain_name is the name of the domain that you specified when you
configured the external authentication authority configuration on the
NetWorker Authentication Service.
l user_name is the name of the user in the LDAP or AD directory, which you
added to the External Roles attribute or is a member of the group that you
added to the External Roles attribute.
Server authorization
The NetWorker server provides a mechanism to authorize users that perform
operations from a command prompt and from the NMC GUI.
2. Click Enterprise.
3. Right-click the NetWorker server, and then select Launch Application.
4. On the NetWorker Administration window, select Servers.
5. In the left navigation pane, select User Groups.
6. On the User Groups window, right-click Security Administrators, and then
select Properties.
7. In the External Roles attribute, paste the dn of the user or group that you
copied from the Console Security Administrator role.
8. Click OK.
9. On the User Groups window, right-click Application Administrators, and then
select Properties.
10. In the External Roles attribute, paste the dn of the user or group that you
copied from the Console Security Administrator role.
11. Click OK.
12. Close the NetWorker Administration and NMC windows.
13. Connect to the NMC server with an LDAP or AD user, and then connect to the
NetWorker server .
14. Confirm that you can view server resources, for example Directives.
l In the Enterprise window—The user sees all the hierarchy folders, but only the
allowed NetWorker servers appear in the folders.
l In the Events window—The user sees only events from allowed NetWorker
servers.
l In the Reports window—The user only sees reporting data from allowed
NetWorker servers and as a result, reports can vary among users. For example, a
shared backup summary report entitled “Building C Backups” displays different
data for different users (even when each user runs the report simultaneously)
when the privileges of the users include different NetWorker servers. This applies
to all report types.
Note: A NetWorker server only appears in a list of reports when there is data
available on which to report.
l In the Setup window:
n The user sees properties for all users, in addition to its own properties and
privileges.
n The user can modify its own properties, but not privileges. Only the Console
Security Administrator can view and modify user privileges.
l User groups
l Security Audit log resource
l Server resource
Note: The Change Security Settings privilege requires
that you also set the following prerequisite privileges:
View Security Settings, Create Security Settings, and
Delete Security Settings.
l User groups
l Audit log resource
l Server resource
Delete Security Settings The ability to delete user created user groups. You cannot
delete preconfigured user groups.
Configure NetWorker The ability to configure resources that are associated with the
NetWorker server, storage nodes, and clients. For example
creating, editing, and deleting resources.
Users can only recover files with the user privileges for that
operating system. To perform save set or NDMP recoveries,
users with the privilege must log in to the local host as root
(UNIX) or administrator (Windows).
Users can only back up files with the user privileges for that
operating system. To run the
nsrpolicy command or to perform NDMP backups, users
with this privilege must log in to the local hosts as root (UNIX)
or administrator (Windows). To allow scheduled backups to
operate correctly, the root user (UNIX) or administrator
(Windows) on the client has this privilege automatically.
Recover Remote Data Allows users to recover data for a back up performed on
another server.
3. For new user groups only, right-click User Group, and then select Create.
4. To modify a user group, right-click the user group, and then select Properties.
5. In the Name attribute, type a name for the user group.
Note: You cannot modify the name of an existing user group.
6. In the External roles attribute, specify the dn of the users and groups.
Modifying NetWorker user group membership for NMC on page 76 provides
more information.
7. In the Privileges attribute, select the privileges to assign to the user group.
8. Click OK.
Copying user groups
Use NMC to copy a User Group.
Before you begin
Use NMC to connect to the NetWorker server with a user that is a member of the
Application Administrators or Database Administrators user group.
Procedure
1. From the Administration window, click Server.
2. Click User Groups.
3. Right-click the user group to edit, and then select Copy.
The Create User Group dialog box appears, and contains the same information
as the user group that was copied, except for Name attribute.
4. In the Name attribute, type a name for the new user group.
5. Edit the other attributes as appropriate, and then click OK.
Deleting user groups
Use the NMC GUI to delete User Groups.
Before you begin
Use NMC to connect to the NetWorker server with a user that is a member of the
Application Administrators or Database Administrators user group.
Procedure
1. From the Administration window, click Server.
2. Click User Groups.
3. Right-click the user group to edit, and then select Delete.
4. When prompted, to confirm the deletion, click Yes.
Note: You cannot delete a preconfigured user group.
based on the user membership that is defined in the External Roles attribute of a
user group.
l Operations that you perform within the NMC and the NetWorker Administration
window do not use the Users attribute to determine the level of authorization that
is assigned to a user.
l Use the External Roles attribute to manage local database, LDAP, AD user, and
group membership.
Note: When you restrict user group membership to users and groups in the
External Roles attribute only, use the nsrlogin command to authenticate
the user before you run NetWorker CLI commands.
l NetWorker module applications, such as NMDA and NMM do not use token-based
authentication and rely on GSS to authenticate OS users. Use the User attribute
to manage OS user and group membership for GSS authentication.
Note: When a user belongs to many operating system groups, the total
number of characters for all the group names can exceed the buffer size that
NetWorker users to store the group names. NetWorker excludes characters
and group names that exceed the buffer size. If you add a group to Users
attribute that is not in the buffer for a userid, NetWorker does not consider
the user to be a member of the User Group.
Modifying NetWorker user group membership for NMC
Use the External roles field in the User Group resource to manage local database,
LDAP, and AD user and group access to the NetWorker server.
Before you begin
Use NMC to connect to the NetWorker server with a user that is a member of the
Security Administrators user group on the NetWorker server.
Procedure
1. On the Administration window, click Server.
2. Click User Groups.
3. Right-click the user group, and then select Properties.
4. Modify the External roles attribute. To add NetWorker Authentication Service
local database users or groups, click the + sign, and then select the users or
groups. When you add an LDAP or AD user or group, specify the distinguished
name (DN).
The following sections provide more information about how to get the dn for
the user or group in an AD or LDAP external authentication authority, and how
to add the NMC service account.
Note: It is recommended that you specify usernames when your user
accounts are a member of a large number of groups.
4. On the String Attribute Editor window, with the entire dn highlighted, right-click
in the value field, and then select Copy. The following figure provides an example
of copying the group DN in the ADSI Editor.
Figure 12 Copying the group DN
"query-tenant=IDD" -D
"query-domain=ldapdomain"
For example, to specify a user who is named patrick on a host that is named
jupiter, enter this line in the Users attribute: user=patrick,host=jupiter or
user=patrick,host=jupiter.emc.com
Note: The formats user@host, host and user, and similar formats are
ambiguous as to whether host or domain is intended. It is recommended
that you use the name=value format.
This example shows what to enter to provide NetWorker administrative
privileges to the following:
In the Users field, type the following information:
l The user root from any host.
l The user operator from the hosts mars and jupiter .
l Any users, valid hosts for the users, and valid domains for the users and host
that are included in the netgroup netadmins. For example:
user=root
user=operator,host=jupiter
user=operator,host=mars.emc.com
&netadmins
user, which provides CLI operations with token-based authentication until the token
expires.
Before you begin
Ensure that the user that the NetWorker Authentication Service validates has the
appropriate User Group privileges to run the CLI commands.
About this task
Perform the following steps on a NetWorker Client on which you initiate the CLI
commands, or the requesting host.
Procedure
1. To validate a user and generate a token for the user, use the nsrlogin
command:
where:
l -s NetWorker_server—Specifies the name of the NetWorker Server. Use
this option when you use the nsrlogin command on a NetWorker host that
is not the NetWorker Server.
l -H authentication_host—Specifies the name of the NetWorker
Authentication Service host. Use this option when you use the nsrlogin
command on a NetWorker host that is not the NetWorker Server. This
option is only required when you do not use the -s option.
l -P port—Specifies the NetWorker Authentication Service port number.
Use this option when you do not use the -s option and when the NetWorker
Authentication Service does not use the default port number 9090 for
communications.
l -t tenant— Specifies the tenant name that the NetWorker Authentication
Service should use to verify the username and password. When you omit this
option, NetWorker Authentication Service uses the Default tenant to verify
the user credentials.
l -d logindomain—Specifies the domain name that the NetWorker
Authentication Service should use to verify the username and password with
an external authentication authority. When you omit this option, the
NetWorker Authentication Service uses the local user database to verify the
user credentials.
l -u username—Specifies the username that the NetWorker Authentication
Service should validate to generate a token.
l -p "password"—Specifies the password that the NetWorker
Authentication Service should use to verify the username. If you do not
specify the password, the nsrlogin command prompts you to provide the
password.
For example, to generate a token for user Konstantin in the idddomain domain
and the idd tenant, type the following command:
Authentication succeeded.
Results
The CLI command uses the authenticated token, until the token expires. By default
the token expiration period is 480 minutes or 8 hours. When the token expires and the
user tries to run a CLI command, the command fails with a permissions error and a
message similar to the following appears to indicate that the token has expired:
Security token has expired
To resolve this issue, run the nsrlogin command again to generate a new
authenticated token.
Note: To revoke the user token and enable the CLI commands to use the Users
attribute in the Usergroups resources to authenticate users, use the nsrlogout
command. The nsrlogout UNIX man page and the NetWorker Command
Reference Guide provides detailed information about the nsrlogout command.
Unable to connect to server: Unable to set user privileges based on user token for
SYSTEM: security token has expired
This message is displayed when the NetWorker Administration window is open and
the token expires for the authenticated user.
To resolve this issue:
1. Click OK. The NetWorker Administration window closes.
2. In the Console GUI, select the NetWorker server, and then select Launch
NetWorker Administration. The Enter Credentials window is displayed.
3. In the Enter Credentials window, specify the password of the user, and then click
OK. The NetWorker Authentication Service validates the user credentials and if
the validation succeeds, generates a new token for the session.
Unable to query resource database: security token has expired
This message is displayed when you run a CLI tool as an authenticated user but the
user token has expired.
To resolve this issue, run the nsrlogin command to generate a new token for the
user.
Unable to connect to server: Unable to authenticate with server "server-name":
Authentication error
This issue is seen if the NMC (gstd) service and NetWorker server (nsrd) service are
installed on separate hosts. When you log in to NMC and click the tabs and options the
error: “Unable to connect to server: Unable to authenticate with server networker-
server: Authentication error: why = Server rejected credentials” is displayed. This
issue arises due to peering conflict or incorrect permission settings.
To resolve the issue, clear the peering information:
1. Run the following command on theNetWorker Server:
nsradmin -p nsrexec
p type: nsr peer information; name: nmc-server-name
delete
yes
nsradmin -p nsrexec
p type: nsr peer information; name: nmc-server-name
delete
yes
Note: The hostname is case sensitive. You must use the hostname that is
displayed in the NMC console.
If the issue persists, then run the following command on the NetWorker Server:
communication. Perform the following steps to change the host that provides user
authentication to the NMC server.
Procedure
1. Connect to the NMC server with an Administrator account on Windows or the
root account on UNIX.
2. Stop the EMC gstd process:
l Linux—/etc/init.d/gstd stop
l Windows—Stop the EMC GST Database Service service.
5. To establish the trust, type the following command on each NetWorker Server
that is not local to the NetWorker Authentication Service that NMC uses for
authentication:
nsrauthtrust -H Authentication_service_host -P
Authentication_service_port_number
where:
l The location of the nsrauthtrust command differs on Linux and
Windows:
n Linux—/usr/sbin
n Windows—C:\Program Files\EMC NetWorker\nsr
l Authentication_service_host is the hostname of the NetWorker Server that
authenticates the NMC Server host.
l Authentication_service_port_number is the port number used by the
NetWorker Authentication Service. The default port number is 9090.
For example:
nsrauthtrust -H nwserver.corp.com -P 9090
nsraddadmin -H Authentication_service_host -P
Authentication_service_port_number
For example:
nsraddadmin -H nwserver.corp.com -P 9090
Component authentication
NetWorker hosts and daemons use the nsrauth mechanism to authenticate
components and users, and to verify hosts. The nsrauth GSS authentication
mechanism is a strong authentication that is based on the Secure Sockets Layer
(SSL) protocol.
Note: HP-UX depends on the OpenSSL library available on the operating system.
OpenSSL 0.9.8e or later is required for NetWorker modules to function correctly.
Following version SSLv3, SSL was renamed to Transport Security Layer (TLS)
starting with TLSv1. For Windows, nsrauth uses the SSL/TLS protocol that is
implemented by RSA BSAFE. For UNIX and Linux, nsrauth uses the SSL/TLS protocol
that is implemented by the OpenSSL library. NetWorker 9.1 and later uses TLSv1.2.
Earlier NetWorker versions that have not been updated use TLSv1.0.
The nsrexecd service on each NetWorker host provides the component
authentication services. The first time the nsrexecd process starts on a host, the
process creates the following unique credentials for the host:
l 2048-bit RSA private key
l 1024-bit RSA private key, for backward compatibility
l Self-signed certificate or public key
l NW Instance ID
l my hostname
NetWorker stores these credentials in the NSRLA resource found in the local
NetWorker client database, nsrexec. These credentials are known as local host
authentication credentials. NetWorker uses the local host authentication credentials
to uniquely identify the host, to other NetWorker hosts in the datazone.
When a NetWorker host communicates with other NetWorker hosts, the nsrauth
process creates an NSR Peer Information resource in the nsrexec database of the
target host that contains local host authentication credentials for the initiating host.
When a NetWorker host starts a session connection to another host, the following
steps occur:
1. The nsrexecd daemon on the initiating host contacts the nsrexecd daemon on
the target host.
2. The nsrexecd daemon on the initiating host sends the local host authentication
credentials to the target host.
3. The target host compares the local host authentication credentials with the
information that is stored in the local NSR Peer Information resource:
l If the information provided by the initiating host matches the information that
is stored in the NSR Peer Information resource on the remote host, the
nsrexecd daemon creates a session key and establishes an SSL connection
between the two hosts. NetWorker uses AES-256 bit encryption to encrypt
the data that is exchanged between the two hosts.
l If the information provided by the initiating host does not match the
information that is stored in the NSR Peer Information resource on the
remote host, the remote host requests the certificate from the initiating host:
n If the certificate provided by the initiating host matches the certificate that
is stored on the remote host, the nsrexecd daemon creates a session key
and establishes an SSL connection between the two hosts. NetWorker uses
AES-256 bit encryption to encrypt the data that is exchanged between the
two hosts.
n If the certificate provided by the initiating host does not match the
certificate that is stored on the remote host, NetWorker drops the
connection between the two hosts.
l If the remote host does not contain a NSR Peer Information resource for the
initiating host, the remote host uses the information that is provided by the
initiating host to create a NSR Peer Information resource. NetWorker uses
the session key to establish an SSL connection between the two hosts.
Component authentication uses the AES-256 bit encryption method.
Note: For compatibility with earlier NetWorker releases, NetWorker supports
oldauth authentication. It is recommended that you use nsrauth authentication
and only enable oldauth authentication when two hosts cannot authenticate by
using nsrauth. The oldauth authentication method is not secure. Modifying the
authentication methods used by NetWorker hosts on page 88 provides more
information.
3. Display the NSRLA resource and view the current settings for the administrator
attribute:
print
4. Update the value of the administrator attribute to include the owner of the gstd
process on the NMC server:
append administrator:"user=gstd_owner,host=NMC_host"
where:
l gstd_owner is the user account that starts the gstd daemon on UNIX or the
EMC GST service on Windows. By default, the process owner is the
SYSTEM user on Windows and is the root user on UNIX.
l NMC host is the hostname of the NMC server.
For example, to add the SYSTEM account on a Windows NMC server that is
named win.emc.com to a UNIX NetWorker client named unix.emc.com, type:
IP_Address[mask], authentication_method[/
authentication_method]...
where:
l IP_Address[mask] is a single IP address, a single host name, or an IP address
and netmask range. You can specify the number of bits for the mask value or
use the full subnet mask address.
l authentication_method is nsrauth, for strong authentication or oldauth for
legacy authentication.
mnd.emc.com,nsrauth
l To configure all hosts on the 137.69.168.0 subnet to only use nsrauth when
communicating with the host, type:
137.69.160.0/24, nsrauth
l To configure all hosts in the datazone to use nsrauth when communicating
with the host except for a host with the IP address 137.69.160.10, which
should try oldauth first, type the following two lines:
137.69.160.10, oldauth/nsrauth
0.0.0.0, nsrauth
4. Click OK.
5. On the target host, restart the NetWorker services or daemons.
nsradmin -p nsrexec
. type: nsrla
where:
nsradmin -p nsrexec
. type: NSRLA
For Windows paths, use a forward slash (/) when you specify the path.
For example, when the mnd_credentials.txt file is in c:\users, specify:
c:/users/mnd_credentials.txt.
Results
NetWorker exports the local host credential information to the file you specify, on the
target host.
nwinstcreate -ix
this issue, import a copy of the local host credentials for the host into the local NSRLA
resource. This workaround ensures that the local host credentials for the host match
the information that is stored in the NSR Peer Information resource on all other
hosts in the datazone. Resolving conflicts between the local host credentials and NSR
Peer Information resource on page 98 describes how to resolve this issue if an
exported copy of the local host credential information is not available.
Importing local host credentials by using NMC
Connect to the NetWorker server with NMC and import the local host credentials.
Before you begin
The account that you use to connect to the NetWorker server must have permission
to access the NSRLA database on the target host.
Procedure
1. Copy the file that contains the exported local host credentials to the target
host.
2. On UNIX platforms, ensure that the root user has read and write permissions
for the credential file.
For example: chmod 600 export_file_name
3. On the Administration window, select Hosts.
The Hosts Management window appears.
4. In the Hosts pane, right-click the target host, and then select Configure Local
Agent.
5. On the Advanced tab, in the NW instance info operations attribute, select
Import.
6. In the NW instance info file attribute, specify the path and name of the file
that contains the exported information.
For Windows paths, use a forward slash (/) when you specify the path.
For example, when the mnd_credentials.txt file is in c:\users, specify:
c:/users/mnd_credentials.txt.
7. Click OK.
Results
NetWorker imports the local host credential information to the target host.
Importing localhost credentials by using nsradmin
Use the nsradmin program to import local host credentials from a file into the
NSRLA resource of a host.
Before you begin
Connect to the target host with an account that has administrator access to the
NSRLA database. You must configure access privileges to the NetWorker client
database.
Procedure
1. Copy the file that contains the exported local host credentials to the target
host.
2. On UNIX platforms, ensure that the root user has read and write permissions
for the credential file.
For example: chmod 600 export_file_name
nsradmin -p nsrexec
. type: NSRLA
For Windows paths, use a forward slash (/) when you specify the path.For
example, when the mnd_credentials.txt file is in c:\users, specify: c:/
users/mnd_credentials.txt.
For example, when the mnd_credentials.txt file is in c:\users, specify:
c:/users/mnd_credentials.txt.
quit
Procedure
1. Copy the file that contains the exported local host credentials to the target
host.
2. To connect to the NetWorker server, use the NMC.
3. On the View menu, select Diagnostic mode.
4. On the Administration window, select Hosts.
The Hosts Management window appears.
5. Right-click the target host, and then select Host Details.
6. In the Certificates pane, right-click, and then select New.
7. On the Create certificate window, in the Change certificate list box, select
Load certificate from file.
8. In the Name field, type the Name value from the credential file.
9. In the Instance ID field, type the NW Instance ID value from the credential file.
10. In the Peer Hostname field, type the My Hostname value from the credential
file.
11. In the Change certificate list box, select Load certificate from file.
12. In the Certificate file to load attribute, specify the path and name of the file
that contains the exported local host credentials.
For Windows paths, use a forward slash (/) when you specify the path. For
example, when the mnd_credentials.txt file is in c:\users, specify: c:/
users/mnd_credentials.txt.
13. On UNIX platforms, ensure that the root user has read and write permissions
for the credential file.
For example: chmod 600 export_file_name
14. Click OK.
Creating the NSR Peer Information by using nsradmin
Use the nsradmin program on a host to create an NSR Peer Information resource for
a host.
Before you begin
Connect to the target host with an account that has administrator access to the
NSRLA database. You must configure access privileges to the NetWorker client
database.
Procedure
1. Copy the file that contains the exported local host credentials to the target
host.
2. Connect to the nsrexec database:
nsradmin -p nsrexecd
where:
l hostname is value that appears in the Name attribute in the credential file.
l NW_instance_id is the value that appears in the NW Instance ID attribute in
the credential file.
l my_hostname is the value that appears in the My hostname attribute in the
credential file.
6. Update the new NSR Peer Information resource to use the exported
certificate:
For Windows paths, use a forward slash (/) when you specify the path. For
example, when the mnd_credentials.txt file is in c:\users, specify: c:/
users/mnd_credentials.txt.
7. When prompted to update the resource, type Yes.
8. Display the hidden properties:
option hidden
Results
The target host creates a new NSR Peer Information resource for the initiating host
the next time that the initiating host attempts to establish a connection with the
target host.
Deleting the NSR Peer Information resource by using nsradmin
To delete the NSR Peer Information resource for the initiating host, use the
nsradmin command on the target host.
Before you begin
Connect to the target host with an account that has administrator access to the
NSRLA database. You must configure access privileges to the NetWorker client
database.
Procedure
1. Connect to the nsrexec database:
nsradmin -p nsrexec
2. Set the query type to the NSR Peer Information resource of the initiating host:
show
4. Print the attributes for the NSR Peer Information resource and confirm that
the name and peer hostname attributes match the hostname of the initiating
host:
delete
quit
Results
The target host creates a new NSR Peer Information resource for the initiating host
the next time that the initiating host attempts to establish a connection with the
target host.
Resolving conflicts between the local host credentials and NSR Peer Information resource
After two NetWorker hosts successfully authenticate each other, the target host
creates an NSR Peer Information resource to store the local host credentials of the
initiating host. The target host uses attributes that are stored in the NSR Peer
Information resource to validate connection requests from the target host. When
unexpected data loss or corruption occurs in the NSRLA resource of the initiating
host, the nsrexecd process creates new local host credentials. When a host with new
local host credentials attempts to connect another host, the target host rejects the
connection request if an NSR Peer Information resource exists for the initiating host
because the credentials do not match the contents of the NSR Peer Information
resource.
When the local host credentials change for a host, all target hosts that have had a
prior connection with the host rejects a connection attempt. To resolve this issue,
type the following command to remove NSR Peer Information resources from the
nsrexec database:
nsradmin -s NetWorker_server -p nsrexec -C -y "NSR peer information"
where you specify the -s NetWorker_server option when you type the command
from the target host.
Alternately, perform the following steps:
l Manually delete the NSR Peer Information resource for the initiating host in the
NetWorker client database of each target host.
Note: If the NetWorker server is the initiating host, delete the NSR Peer
Information resource on each host in the datazone.
l Import a backup copy of the local host credentials on the initiating host.
Procedure
1. On the Administration window, select Configuration.
2. In the left navigation pane, expand the NetWorker server, and then expand the
Local Hosts resource.
3. Right-click the target host, and then select Configure Local Agent.
4. Select the NetWorker host with the NSR Peer Information resource that you
want to modify.
5. In the Certificate window, right-click the certificate that you want to delete,
and then select Properties.
6. On the Create certificate window, in the Change certificate list box, select
Load certificate from file.
7. In the Certificate file to load attribute, specify the path and name of the file
that contains the exported local host credentials.
If you receive the error, User username on machine hostname is not
on administrator list, you cannot modify the resource until you
configure the NSRLA access privileges on the target host. The section
"Configuring NSRLA access privileges" provides more information.
8. Click OK.
Importing localhost credentials by using nsradmin
Use nsradmin to import the certificate and private key into the NSR Peer
Information resource for a NetWorker host.
Before you begin
Connect to the target host with an account that has administrator access to the
NSRLA database. You must configure access privileges to the NetWorker client
database.
Procedure
1. Connect to the nsrexec database:
nsradmin -p nsrexec
2. Set the query type to the NSR Peer Information resource of the initiating host:
option hidden
4. Print the attributes for the NSR Peer Information resource and confirm that
the name and peer hostname attributes match the hostname of the initiating
host:
5. Update the new NSR Peer Information resource to use the exported
certificate:
For Windows paths, use a forward slash (/) when you specify the path. For
example, when the mnd_credentials.txt file is in c:\users, specify: c:/
users/mnd_credentials.txt.
6. When prompted to update the resource, type Yes.
7. Display the hidden properties:
option hidden
Results
NetWorker generates a new certificate for the NetWorker host. Delete all existing
Peer Information resources for the host, on other NetWorker hosts. Deleting the
NSR Peer Information resource on page 96 describes how to delete the resource.
Procedure
1. Connect to the nsrexec database:
nsradmin -p nsrexec
Component authorization
NetWorker provides you with the ability to restrict remote program executions or
client-tasking rights on a NetWorker host.
You can also:
l Define users that can access the data of a NetWorker host and recover the data to
a different NetWorker host.
l Restrict client-initiated backups to the NetWorker server.
l Configure the NetWorker server to prevent the start up of new save and recover
sessions.
Remote directed recovery Add the FQDN or shortname of the administering client to the
servers file on the destination client.
NDMP DSA backup Add the FQDN or shortname of the NetWorker client that
starts the backup.
Note: For NDMP, the servers file resides in the
NetWorker Server.
Note: Before adding the FQDN or shortname to the NetWorker server file, ensure
that the host name resolution for FQDN or short name is working correctly.
The software installation process on Windows and Solaris allows you to specify a list
of hosts to add to the servers file. To change the servers file after the installation
completes or to specify hosts on operating systems that do not allow you to configure
the file during the installation process, use a text editor to edit the servers file. The
servers file resides in the following locations:
l On UNIX and Mac NetWorker hosts:/nsr/res
l On Windows NetWorker hosts:NetWorker_installation_path\res
When you add a NetWorker host to the servers file, ensure that you perform the
following tasks:
l Specify the FQDN or shortname for the host.
l Specify one hostname on each line.
l Restart the nsrexecd service on the host, after you save the file.
Note: If the servers file is empty or does not exist, then any NetWorker host has
client-tasking rights to the host.
On UNIX computers, you can start the nsrexecd daemon with the -s servername
option to assign client-tasking rights to a host. The use of the -s option to start the
nsrexecd daemon supersedes the use of the servers files to restrict client-tasking
rights.
5. Click OK.
Procedure
1. From the Administration window, click Server.
2. In the left navigation pane, right-click the NetWorker server, and then select
Properties.
3. On the Security tab, in the Accept new recover sessions attribute, select No.
GST_LDAP_USING_2FA="true"
export GST_LDAP_USING_2FA
This chapter describes how to access and manage the logs files available in
NetWorker.
Windows:
Windows:
NetWorker Log file name and location that is defined by the UNIX only, OS log file.
Servergenerated syslog system log configuration file. Note: NetWorker does not modify the
syslog.conf file to configure
messages
local0.notice and local0.alert.
local0.notice and
Vendor specific documentation describes
local0.alert
how to configure local0.notice and
local0.alert
Windows:
Windows:
Windows:
Windows:
/nsr/logs/
NetWorker_server_sec_audit.raw
Windows:
C:\Program Files\EMC
NetWorker\Management\logs
\gstd.raw
Windows:
C:\Program Files\EMC
NetWorker\Management\logs
\gstdbupgrade.log
Windows:
C:\Program Files\EMC
NetWorker\Management\logs
\web_output
Windows:
C:\Program Files\EMC
NetWorker\Management\nmcdb
\pgdata\db_output
Windows Bare Metal The following files in the Contains the recovery
Recovery (BMR) X:\Program Files\EMC workflow of the
NetWorker\nsr\logs\ DISASTER_RECOVERY:\ and
directory: any errors that are related to
recovering the save set files
ossr_director.raw
or Windows ASR writer
errors. Use the
nsr_render_log program
to view the contents of the
log file.
CloudBoost - NetWorker The following log files in the These files appear on a client
Client direct-enabled NetWorker
/nsr/logs/cloudboost
Client and contain information
directory: about data stored on a
CloudBoost device. The
MagFS.log.ERROR.date- severity of the message
timestamp.pid.txt determines which log file that
MagFS.log.FATAL.date- error message is written to.
timestamp.pid.txt The maximum size of the log
MagFS.log.INFO.date- files are 100 MB.
timestamp.pid.txt Before a client direct backup,
the save process
checks the size of the file.
When the maximum size
is reached, save starts an
automatic trimming
mechanism, which renames
and compresses the log file.
The maximum number of
versions for a file is 10. When
the number of renamed log
files reaches the maximum
version value, NetWorker
removes the oldest log when a
new version of the log file is
created.
Note: The
Troubleshooting manual
backups section of the
NetWorker Administration
Guide describes how to
use the
CB_LOG_DIR_LOCATION
environment variable to
change the default log file
location.
where:
n raw_filename is the name of the unrendered file. For example, daemon.raw
n output_filename is the name of the file to direct the output to
n -c suppresses the category
n -m suppresses the message ID
n -e suppresses the error number
n -a suppresses the activity ID
n -p suppresses the process ID
n -t suppresses the thread ID
n -h suppresses the hostname
n -y suppresses the message severity
where:
n hostname is the name of the host that contains the .raw file.
n raw_filename is the name of the unrendered file. For example, daemon.raw
n output_filename is the name of the file to direct the output to
n -c suppresses the category
n -e suppresses the error number
n -m suppresses the message ID
n -p suppresses the process ID
n -a suppresses the activity ID
l To render a .raw file and only view log file messages for a specific device, type:
nsr_render_log -c -empathy -F devicename raw_filename
1>output_filename 2>&1
l To render a .raw file and only view certain messages severities, type:
nsr_render_log -c -empath -Y message_severity 1>output_filename
2>&1
where message_severity is one of the severity types listed in the following table.
Table 13 Message types
Type Description
Informational Information that may be useful, but does not require any specific action.
Warning A temporary problem that NetWorker software may resolve or prompt you to
resolve.
Critical Errors that you are required to resolve, to ensure successful NetWorker
operations.
The UNIX man page and the NetWorker Command Reference Guide provides
detailed information about the nsr_render_log program and the available
options.
For backward compatibility with previous releases of the NetWorker software, runtime
rendered log files contain the following attributes:
l Message ID
l Date and time of message
l Rendered message
Procedure
1. To access the NSRLA database, from a command prompt, use the nsradmin
program:
nsradmin -p nsrexec
5. To define the path and file name for the rendered log file, use the Runtime
rendered log attribute.
For example, to save rendered messages to the file rendered.log in the
default NetWorker logs directory on a Windows host, type:
Table 14 Raw log file attributes that manage log file size
Attribute Information
Maximum size MB Defines the maximum size of the log files.
Default: 2 MB
Maximum versions Defines the maximum number of the saved log files.
Default: 10
Runtime rollover by size When set, this attribute invokes an automatic hourly check of
the log file size.
Default: disabled
Runtime rollover by time When set, this attribute runs an automatic trimming of the log
file at the
defined time, regardless of the size. The format of the variable
is
HH:MM (hour:minute).
Default: undefined
How the trimming mechanism trims the log files differs depending on how you define
the log file size management attributes. The following table summarizes the trimming
behavior.
Table 15 Raw log file attributes that manage the log file trimming mechanism
Table 15 Raw log file attributes that manage the log file trimming mechanism (continued)
When you do not configure runtime rollover l NetWorker checks the log file size when
by time or runtime rollover by size the nsrexecd process starts on the
computer.
l When the log file size exceeds the size
that is defined by the maximum size MB
attribute, NetWorker renames the
existing log file to
log_file_name_date_time.raw then
creates a new empty log file.
Note: When the nsrd daemon or
NetWorker Backup and Recover Server
service runs for a long time, the size of
the log file can become much larger than
the value defined by maximum size MB.
Managing raw log file size for the daemon.raw, networkr.raw, and gstd.raw files
To configure the NetWorker software to rollover the .raw file by time, perform the
following steps.
Procedure
1. Log in to the NetWorker host with root on UNIX or Administrator on Windows.
2. To access the NSRLA database, use the nsradmin program:
nsradmin -p nsrexec
6. Update the runtime rollover by time attribute with the time that you want to
rollover the log file.
For example, to configure the gstd.raw file to rollover at 12:34 AM, type:
attributes. The NetWorker server records these changes in the rap.log file, which is
located in the NetWorker_install_dir\logs directory. Each entry in the
rap.log file consists of the user action, the name of the user that performed the
action, the name of the source computer, and the time of the change. NetWorker logs
sufficient information in the rap.log file to enable an administrator to undo any
changes. The Monitor RAP attribute is enabled by default. To disable the attribute
setting, perform the following steps.
Before you begin
Use NMC to connect to the NetWorker server with a user that is a member of the
Application Administrators or Database Administrators user group.
About this task
Note: In NetWorker 8.0 and later, the Security Audit Log feature provides the
NetWorker server and the NMC server with the ability to log specific security
audit events that are related to their operations.
Procedure
1. From the Administration window, select Server.
2. From the View menu, select Diagnostic mode.
3. Right-click the NetWorker server name in the left navigation pane, and then
select Properties.
4. On the General tab, select the Disabled button for the Monitor RAP attribute.
2. From a command prompt , start the daemon, and then specify the troubleshoot
level.
For example:
l To start the nsrexecd daemon in troubleshoot mode, type:
Where filename is the name of the text file that NetWorker uses to store the
troubleshoot messages.
3. After you collect the necessary troubleshoot information, perform the following
steps:
a. Stop the NetWorker processes by using the nsr_shutdown command.
b. Restart the processes by using the NetWorker startup script:
l On Solaris and Linux, type:
/etc/init.d/networker start
l On HP-UX, type:
/sbin/init.d/networker start
l On AIX, type:
/etc/rc.nsr
c. Click Start.
c. Click Start.
Results
NetWorker stores the troubleshoot information in the daemon.raw file.
After you finish
After you capture the troubleshoot information, stop the NetWorker services, remove
the -D parameter, and then restart the services.
2. Edit the file and specify the following at beginning of the file:
GST_DEBUG=x
export GST_DEBUG
/etc/init.d/gst stop
then
/etc/init.d/gst start
l AIX: Type:
/etc/rc.gst start
then
/etc/rc.gst stop
Results
NMC stores the troubleshoot information in the gstd.raw file.
After you finish
After you capture the troubleshoot information, stop the gstd daemon, remove the
environment variable from the startup file, and then restart the gstd daemon.
where:
l PID is the process id of the process.
l x is a number between 0 and 9.
Note: 0 turns off troubleshoot.
Results
NetWorker logs the process troubleshoot information in the daemon.raw file.
After you finish
To turn off troubleshoot, type:
where:
l x is a number between 1 and 99.
l file_sytem_objects is the name of the files or directory to backup.
l filename is the name of the file that stores the troubleshoot information.
Note: The NetWorker Command Reference Guide provides detailed information
about all the available backup options and how to use the save command.
2. To create or modify the recover job, use the Recovery wizard. On the Select
the Recovery Options window, select Advanced Options.
3. In the Debug level attribute, select a troubleshooting level between 0 and 9.
4. Complete the remaining steps in the Recovery Wizard.
Results
NetWorker logs the troubleshoot recovery information to the recover log file.
Running a recovery job in troubleshoot mode by using nsrtask
Use the nsrtask command to run a recovery job that is created by the Recovery
wizard, from a command prompt.
Procedure
1. On the NetWorker server, type: nsradmin.
2. From the nsradmin prompt:
a. Set the resource attribute to the Recover resource:
. type: nsr recover
b. Display the attributes for the Recover resource that you want to
troubleshoot:
print name:recover_resource_name
c. Make note of the values in the recover, recovery options, and recover
stdin attributes. For example:
recover command: recover;
recover options: -a -s nw_server.corp.com -c
mnd.corp.com -I - -i R;
recover stdin:
“<xml>
<browsetime>
May 30, 2013 4:49:57 PM GMT -0400
</browsetime>
<recoverpath>
C:
</recoverpath>
</xml>”;
where:
l nw_server.corp.com is the name of the NetWorker server.
l mnd.corp.com is the name of the source NetWorker client.
3. Confirm that the nsrd process can schedule the recover job:
a. Update the Recover resource to start the recover job:
update: name: recover_resource_name;start time: now
where recover_resource_name is the name of the Recover resource.
b. Exit the nsradmin application
c. Confirm that the nsrtask process starts.
If the nsrtask process does not start, the review the daemon.raw file on
the NetWorker server for errors.
4. To confirm that the NetWorker server can run the recover command on the
remote host, on the NetWorker server type the following command:
d. When the recover command completes, review the recover output for
errors. If the recover command fails, then review the values that are
specified in the Recover resource for errors.
7. To review the details of the Recover job, use the jobquery command. From a
command prompt on the NetWorker server, type: jobquery
8. From the jobquery prompt, perform one of the following steps:
l Set the query to the Recovery resource and display the results of all
recovery jobs for a Recovery resource:
Where jobid is the jobid of the Recover job that you want to review.
Note: Review the daemon.raw file on the NetWorker server to obtain the
jobid for the recovery operation.
where:
l x is a number between 1 and 99.
l file_sytem_objects is the name of the files or directory to recover.
l filename is the name of the file that stores the troubleshoot information.
Note: The NetWorker Command Reference Guide provides detailed information
about all the available recovery options and how to use the recover command.
Windows:
Refer to the Apache website for detailed information about the Apache Tomcat log
files.
maintains. When the size of the authc-server.log reaches the maximum file
size value, NetWorker Authentication Service copies the contents of the log file
to a new log file with the naming convention authc-serverdate.log. By
default, NetWorker Authentication Service maintains one rollover log file.
To increase the number of rollover log files to 4, modify the
log4j.appender.app.MaxBackupIndex attribute to appear as follows:
log4j.appender.app.MaxBackupIndex=4
This chapter describes how to ensure NetWorker uses secure channels for
communication and how to configure NetWorker in a firewall environment.
Service ports
The service ports are also known as inbound, destination, or listening ports. The TCP
server processes that run on each NetWorker host use service ports to listen for
inbound connections. The service ports are meant to provide specific services on the
ports that are reserved for them.
NetWorker uses two types of service ports:
l Fixed ports—NetWorker uses two fixed ports: TCP/7937 and TCP/7938. Include
these ports in the service port range of each NetWorker host. NetWorker uses
these ports to start connections.
l Variable ports—NetWorker dynamically opens ports. A NetWorker host can
allocate any port in the defined service port range and the NetWorker daemons
select the dynamic ports within that range randomly. The default range is
7937-9936 and you can narrow or expand this range.
To increase security in the environment, reduce the variable ports range to specify
only the minimum number of service ports that the NetWorker software requires. The
minimum value depends on the installation type and the number of hosted NetWorker
devices. NetWorker stores the service port range for a host in the NSR Local Agent
(NSRLA) resource in the NetWorker client database (nsrexec). The service ports can
be modified using the nsrports command.
Connection ports
Connection ports are also known as outbound ports, source ports, or communication
ports. NetWorker processes use connection ports to connect to a service. The
NetWorker software requires one connection port for any type of communication
between the client, storage node, and server.
NetWorker uses a default range, 0-0, to indicate that the NetWorker software allows
the operating system to select the port for TCP clients. Port 0-0 indicates that any
available port from the operating system can be used for outbound communication.
The operating system reserves connection ports for short-term use and reuses the
ports as needed. The operating system might allow you to configure the dynamic port
range, for example, by using the netsh program on Windows. NetWorker does not
require changes to this range and it is recommended that you use the default dynamic
port range.
The use of the default port range does not cause security concerns. It is
recommended that you do not change the range for any NetWorker hosts in the
datazone. NetWorker performance problems or random malfunctions can occur when
the range is too narrow. The connection ports can be modified using the nsrports
command.
Note: If the firewall time out is shorter than the common 1 hour value, further
decrease these values. The network overhead as a result of enabling TCP
KeepAlive is minimal.
The following table summarizes the Wait Time Before Probing and Interval
Between Retry Probes parameters for each operating system.
extra service ports for the NetWorker storage node. The minimum number of service
ports that a storage node requires is 5. This number includes the four TCP service
ports that are required for a NetWorker client and one service port for the storage
management process, nsrsnmd. NetWorker requires additional ports and the amount
differs for each device type used.
Use the following formulas to calculate storage node port requirements:
l For NDMP-DSA devices: 5 + #backup_streams
l For tape devices: 5 + #devices + #tape_libraries
l For AFTD or Data Domain Boost devices: 5 + #nsrmmds
where:
l #devices is the number of devices that are connected to the storage node.
l #tape_libraries is the number of jukeboxes that the storage node accesses. The
storage node has one nsrlcpd process for each jukebox.
l #nsrmmds is the sum of the Max nsrmmd count attribute value of each device
that the NetWorker storage node manages.
The following table summarizes the port requirements specific to the storage node
programs.
l #tape_libraries is the number of jukeboxes that the storage node accesses. The
storage node has one nsrlcpd process for each jukebox.
l #nsrmmdsis the sum of the Max nsrmmd count attribute value of each device
that the NetWorker storage node manages.
To accommodate growth in the environment and the addition of new devices, allocate
extra service ports for the NetWorker server.
Note: The Software Configuration wizard requires one service port. The port is
dynamic and closes when the wizard closes. If you use the Software Configuration
wizard, add one additional port to the service port range.
The following table summarizes the port requirements specific to the Server
programs.
Note: If you restrict unattended firewall for security reasons, then use the storage
node attributes mmds for disabled devices and Dynamic nsrmmds unselected
(static mode) to prevent a listener from starting on an inactive nsrmmd port.
administrator list of the NSR system port ranges resource and enable remote updates
of the attribute.
Procedure
1. Connect to the target NetWorker host.
2. To connect to the nsrexec database, from a command prompt, use the
nsradmin program:
nsradmin -p nsrexec
3. Display the current administrators list:
p NSR system port ranges
In this example, only the local users can update the attributes in the NSR
system port ranges resource:
For example, if you connect to the NMC server with the NMC administrator
from the NMC client mnd.mydomain.com, type:
Enabling updates of the NSR system port ranges resource on page 143
describes how to provide user accounts with the ability to modify the service
port attribute.
l If you see accounts in the Administrators attribute, then update the
Service ports attribute with the calculated service port range. For multiple
ranges, type one range per line.
4. In the Service ports attribute, specify the calculated service port range. For
multiple ranges, type one range per line.
Note: It is recommended that you do not change the Connection ports
attribute from the default value 0-0.
5. Click Ok.
6. On the NetWorker host, stop, and then start the NetWorker services or
daemons.
Option Description
-s target_hostname Optional. Use this option when updating the port range for a remote
NetWorker host. Enabling updates of the NSR system port ranges
resource on page 143 describes how to enable remote access of the
NSR system port ranges resource.
-S range Sets the service port range to the value specified by range. The
default range is 7937-7941. If the range is not a consecutive set of
ports, use a space to separate the port values.
-C range Sets the connection port range to the value specified by range. It is
recommended that you do not change the connection ports attribute
from the default value 0-0.
For example, to modify the service port attribute in the NSR system port ranges
resource on myclient.emc.com, perform the following steps:
Procedure
1. Display the current port range:
nsrports -s myclient.emc.com
2. Update the service port range. Separate multiple port ranges with a space. For
example:
Note: If you do not have permission to update the NSR system port ranges
attribute, an error message similar to the following appears: nsrexecd:
User 'username' on machine 'hostname' is not on
'administrator' list. Enabling updates of the NSR system port
ranges resource on page 143 describes how to enable user access to update
the NSR system port ranges resource.
nsrports -s myclient.emc.com
2 ports in range
7939-9936
10000 (HTTP)
10024 (Persistence
Service)
27001
In this example:
l The Service port attribute on each client specifies a minimum of four service
ports, for example: 7937–7940.
Note: To simplify the configuration, configure each client to use the same four
service port numbers.
l The firewall must allow outbound traffic, to the IP address of each NetWorker
Client, on each of the service ports that are defined in the Service port attribute
on the NetWorker Client. Because each client can specify the same port numbers,
the firewall only needs to allow four ports for each client IP address. These port
numbers can be a subset of the port numbers that are used by the NetWorker
Server, as in this example.
l In pseudo syntax, the firewall rule for the service ports would look like this:
TCP, Service, src 192.167.10.*, dest 192.167.10.101, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.102, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.103, ports
7937-7940, action accept
...
NetWorker host with the appropriate port range, then restart the NetWorker
services for each host.
In pseudo syntax, the firewall rule for the service ports would look like this:
TCP, Service, src 192.167.10.*, dest 192.167.10.*, ports
7937-7958, action accept
This example requires you to only open service ports for the NetWorker Server on the
firewall to allow inbound traffic. Calculate the service port requirements for the
NetWorker Server with this formula:
l The Service port attribute on each client specifies a minimum of four service
ports, for example: 7937–7940.
Note: To simplify the configuration, configure each client to use the same four
service port numbers.
l The firewall must allow outbound traffic, to the IP address of each NetWorker
Client, on each of the service ports that are defined in the Service port attribute
on the NetWorker Client. Because each client can specify the same port numbers,
the firewall only needs to allow four ports for each client IP address. These port
numbers can be a subset of the port numbers that are used by the NetWorker
Server, as in this example.
l In pseudo syntax, the firewall rule for the service ports would look like this:
TCP, Service, src 192.167.10.*, dest 192.167.10.101, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.102, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.103, ports
7937-7940, action accept
...
This example requires you to only open service ports for the NetWorker Server on the
firewall to allow inbound traffic. Calculate the service port requirements for the
NetWorker Server with this formula:
14 +(num devices)+(num libraries) + 1 (client push)= 14 + 6 + 1 +1 = 22
In this example:
l The Service ports attribute of the NetWorker Server contains the range:
7937-7958.
l The firewall must allow inbound traffic to the IP address of the NetWorker Server
on each service port with the exception of the UDP port. In this example, 22 ports
in the range of 7937 to 7958 must allow inbound traffic to the NetWorker server.
l In pseudo syntax, the firewall rule for the service ports would look like the
following:
TCP, Service, src 192.167.10.*, dest 192.167.10.126, ports
7937-7958, action accept
Calculating service ports in a bi-directional firewall environment with Data
Domain
This example shows how to apply the basic rules to a sample network with clients A, B
and C, one storage node X, and a Data Domain appliance in an insecure network,
which uses Data Domain Cloud Tier devices. The NetWorker server and NMC server
are in a secure network. A single firewall separates the secure network from the
insecure network. The NetWorker server has a tape library and six drives. The client
sends backup data to the Data Domain appliance and each client acts as an NMC
client.
the NetWorker client. These port numbers can be a subset of the port numbers
that the NetWorker server uses.
l In pseudo syntax, the firewall rules for the service ports would look like the
following:
TCP, Service, src 192.167.10.*, dest 192.167.10.101, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.102, ports
7937-7940, action accept
TCP, Service, src 192.167.10.*, dest 192.167.10.103, ports
7937-7940, action accept
Troubleshooting
This section contains solutions to some common problems encountered when you
configure NetWorker in a firewalled environment.
Backups appear to stop responding or slow down dramatically
When you configure a firewall to drop packets outside an allowed range, but the
firewall configuration does not allow for proper NetWorker connectivity:
l NetWorker will not get proper notification that a connection is not possible.
l The socket connections might not close correctly and remain in a TCP FIN_WAIT
state. As a result, NetWorker requires more ports for client connectivity.
To avoid these issues, configure the firewall to reject packets outside the allowed
range. When the firewall rejects packets, NetWorker receives an immediate
notification of any connection failures and the remaining operations continue.
If you cannot configure the firewall to reject packets, reduce the TCP timeout values
on the NetWorker server’s operating system to reduce the impact of the problem. The
NetWorker Performance Optimization Planning Guide describes how to change TCP
timeout values.
Cannot bind socket to connection port range on system hostname
This message appears in the savegroup messages or in stdout during manual
operations when there are insufficient connection ports available and NetWorker
cannot establish a connection.
To resolve this issue, ensure that the Connection port attribute in the NSR System
Port ranges resource is 0-0 on the host that is specified by hostname.
Failed to bind socket for service_name service: Can't assign requested address
This message appears when a NetWorker daemon cannot register to a port within the
service port range because all ports are in use by other daemons and processes.
To resolve this issue, increase port range in the Service ports attribute in the NSR
System port ranges resource on the NetWorker host and make a corresponding
change in the firewall rules.
Service is using port port_number which is outside of configured ranges: range
This message appears in the Logs window when a NetWorker daemon attempts to
register to a port that is not within the service port range. This can occur because the
port requirements of the NetWorker host exceed the number of service ports that are
defined in the range.
To resolve this issue, increase port range in the Service ports attribute in the NSR
System port ranges resource on the NetWorker host and make a corresponding
change in the firewall rules.
Note: Communications between NetWorker processes on the same host do not
follow defined rules. For example, the NetWorker server daemons communicate
internally outside of the defined port range. Do not configure a firewall to limit the
range for TCP traffic inside a single system.
Connection refused
This message appears when the NetWorker host cannot establish a portmapper
connection on port 7938.
To resolve this issue, ensure that the NetWorker software can register an RPC
portmapper connection on port 7938.
Connection reset by peer
This message appears when the connection between two NetWorker hosts closes
prematurely.
To resolve this issue, configure the datazone to send a keep alive signal between the
hosts at an interval that is shorter than the time out period defined on the firewall.
Special considerations for firewall environments on page 137 describes how to
configure the TCP keep alive signal.
Unable to obtain a client connection to nsrmmgd (version #) on host hostname
This message appears on a Windows host when the Windows firewall Allow list on the
NetWorker server does not contain the nsrmmgd process.
When this error message appears:
l A library that is configured on the NetWorker storage node will not enter “ready”
state.
l Multiple nsrlcpd processes are started on the storage node.
To resolve this issue, ensure that the firewall is turned on, then add the nsrmmgd
process to the Allow list of the Windows firewall on the NetWorker server host.
nsrndmp_save: data connect:failed to establish connection
This message appears during an NDMP-DSA backup when a Windows NetWorker
server uses Windows firewall, but an inbound rule for port 10000 does not exist.
To resolve this issue, perform the following steps:
1. Log in to the NetWorker server as a Windows administrator.
2. In the Windows Firewall application, on the Advanced properties select Inbound
Rules > New Rule.
3. Select Program, and then click Next.
4. Select This Program Path.
5. Click Browse. Select the binary nsrdsa_save.exe, and then click Next.
6. Select Allow the connection, and then click Next.
7. Leave the default Profiles selections enabled, and then click Next.
8. Provide a name for the rule, and then click Finish.
9. Edit the new rule.
10. On the Protocols and Ports tab, perform the following steps:
To resolve this issue, ensure that the firewall rules allow communication between the
NMC server and NetWorker server on the port that you configured for the NetWorker
Authentication Service. The default port is 9090.
This chapter describes the settings available to ensure the protection of the data
handled by NetWorker.
5. In the Users field, specify the list of users that have access to the AES pass
phrases in one of the following formats:
l user=username
l username@hostname
l hostname
l host=hostname
l user=username, host=hostname
Note: If you enter a hostname or host=hostname in the Users attribute,
then any user on the specified host can recover the files for the client. To
enter a username without specifying the host, enter user=username.
6. Click OK.
Results
Only users that you specify in the Users field can modify the Datazone pass phrase
attribute in the NSR resource.
4. Click OK.
Results
NetWorker generates the datazone encryption key that is based on the pass phrase.
To recover the data, you must know the datazone pass phrase that was in the
Datazone pass phrase attribute at the time of the backup.
<< / >>
+aes: *
Results
The backup operation encrypts the backup data based on the value specified in the
Datazone pass phrase in the NSR resource, on the NetWorker server.
where pass_phrase is the pass phrase that is specified in the Datazone pass
phrase attribute of the NSR resource on the NetWorker server at the time of
the backup.
When you recover data that requires different pass phrases, use additional -p
pass_phrase options to specify each required pass phrase.
2. Confirm that the recover operation successfully recovers the data.
When you specify an incorrect pass phrase:
l NetWorker creates 0kb files but does not recover the data into the files.
l The recover output reports a message similar to the following:
Invalid decryption key specified
where:
l pass_phrase is the pass phrase that is specified in the Datazone pass
phrase attribute of the NSR resource on the NetWorker server at the time
of the backup. When you recover data that requires different pass phrases,
use additional -p pass_phrase options to specify each required pass
phrase.
l filesystem_object is the full path to the data that you want to recover.
Data integrity
NetWorker enables you to verify the integrity of the backup data and the integrity of
the NetWorker server databases.
Procedure
1. On the Administration window, click Media.
2. In the left navigation pane, select Media Pools.
3. On the Media Pools window, right-click the pool, and then select Properties.
4. On the Configuration tab, select Auto media verify.
5. Click OK.
Procedure
1. Connect to the NetWorker host as an administrator.
2. In the NetWorker User program, from the Operation menu, select Verify Files.
3. Select the data that you want to verify.
4. From the View menu, select Required volumes.
The Required Volumes window appears with the list of volumes that contain
the data that you want to verify. Mount the volumes in devices.
5. Click Start.
The Verify Files status window appears and provides the progress and results
of the Data Verification process. The output displays data mismatch messages
to alert you to any detected data changes since the backup.
Results
Verification also determines if a hardware failure kept the NetWorker server from
completing a successful backup. The Verify files feature provides a way to test the
ability to recover data.
The following output provides an example where the Verify Files process verifies four
files, and reports that one file, recover_resource.txt has changed since the
backup:
Verify Files
Requesting 4 file(s), this may take a while...
Verify start time: 28/10/2013 3:46:36 PM
Requesting 1 recover session(s) from server.
91651:winworkr: Successfully established AFTD DFA session for
recovering save-set ID '4285011627'.
C:\data\mnd.raw
C:\data\pwd.txt
C:\data\lad.txt
32210:winworkr: DATA MISMATCH FOR C:\data\recover_resource.txt.
C:\data\
Received 4 file(s) from NSR server `bu-iddnwserver'
Verify completion time: 28/10/2013 3:46:48 PM
Verifying the integrity of the NetWorker server media data and client file
indexes
NetWorker provides you with the ability to manually check the integrity and
consistency of the media database and client file index by using the nsrim and nsrck
commands.
Level Description
1 Validates the online file index header, merging a journal of changes
with the existing header. Moves all save set record files and the
corresponding key files to the appropriate folder under the
C:\Program Files\EMC NetWorker\nsr\index
\client_name\db6 folder on Windows hosts or the /nsr/index/
client_name/db6 directory on UNIX hosts.
2 Performs a level 1 check and checks the online file index for new and
cancelled saves. Adds new saves to the client file index, and removes
cancelled saves.
3 Performs a level 2 check and reconciles the client file index with the
media database. Removes records that have no corresponding media
save sets. Removes all empty subdirectories under db6 directory.
4 Performs a level 3 check and checks the validity of the internal key
files for a client file index. Rebuilds any invalid key files.
6 Performs a level 5 check and extracts each record from each save
time, to verify that each record can be extracted from the database.
Re-computes the digest of each save time and compares the results
with the stored digest. Rebuilds internal key files.
The UNIX man page and the NetWorker Command Reference Guide provides detailed
information about how to use the nsrck command and the available options.
Data erasure
During a backup operation, NetWorker stores data in save sets on physical or virtual
volumes. NetWorker stores information about the save sets in the media database and
client file indexes.
Based on user-defined policies, NetWorker automatically performs media database
and client file index management, which expires data on volumes and makes the data
eligible for erasure. You can also manually erase data and remove data from the media
database and client file indexes.
The nsrim process uses policies to determine how to manage information about save
sets in the client file index and media database. When the savegrp process starts
nsrim, NetWorker checks the timestamp of the nsrim.prv file. If the timestamp of
the file is greater than or equal to 23 hours, then the nsrim process performs the
following operations:
l Removes entries that have been in a client file index longer than the period
specified by the browse policy from the client file index.
l Marks save sets that have existed longer than the period specified by the
retention policy for a client as recyclable in the media index.
l Deletes the data that is associated with recyclable save sets from an advanced file
type device and removes the save set entries from the media database.
l Marks a tape volume as recyclable when all the save sets on the tape volume are
marked recyclable. NetWorker can select and relabel recyclable volumes when a
backup operation requires a writeable volume. When NetWorker relabels a
recyclable tape volume, NetWorker erases the label header of the volume and you
cannot recover the data.
NetWorker relabels a volume at the time of a backup or clone when a set of defined
selection criteria is met. Use the Recycle start and Recycle interval attributes on the
Miscellaneous tab of a Pool resource to schedule automatic volume relabeling for
eligible volumes in a pool. The NetWorker Administration Guide provides more
information.
Procedure
1. On the Administration window, click Devices.
2. In the left navigation pane, select Devices.
3. In the Device window, right-click on the AFTD device, and then select Label.
4. (Optional) in the Target Media Pool field, select a different pool.
5. Click OK.
6. If prompted to overwrite label, then right-click the label operation in the
Operations Status window to confirm intent to overwrite the existing volume
label with a new label, and then select Supply Input.
A question window appears displaying this message:
Label <labelname> is a valid NetWorker label. Overwrite it
with a new label
7. Click Yes.
When you install NetWorker in a data zone, each client is automatically configured to
use security audit logging. Any audit logging configuration changes that you set on the
NetWorker server are automatically communicated to all NetWorker 8.0 and later
clients in the data zone. NetWorker automatically configures existing NetWorker
clients to send security audit messages to the nsrlogd daemon when you:
l Update the NetWorker server software.
l Create new client resources.
Examples of security audit events that generate security audit messages include:
l Authentication attempts: Successful and unsuccessful attempts to log in to an
NMC Server.
l Account management events: Password changes, privilege changes and when
users are added to the list of remote administrators.
l Changes to program authorization: Deleting or adding peer certificates and
redefining which binaries a user can execute remotely.
l Changes to the daemon.raw and audit log configurations.
l Events that can lead to the general compromise or failure of the system.
Single data zone: The NetWorker server hosts the nsrlogd daemon
By default, the nsrlogd daemon runs on the NetWorker server.
In this configuration, the nsrlogd daemon receives security audit messages from:
l The gstd and nsrexecd processes on the NMC server.
l The nsrexecd process on each NetWorker client in the data zone.
l The daemons that run on the NetWorker server.
Advantages:
l The NetWorker server daemons generate the majority of the security audit
messages. In this configuration, the audit log messages are not sent over the
network and will not increase network traffic.
l Security audit messages from each NetWorker client are sent to the NetWorker
server. Additional network ports and routes to other networks are not required to
send security audit messages.
The following figure provides an example of this configuration.
Multiple data zones: The NMC server hosts the nsrlogd daemon
In this configuration, the nsrlogd daemon runs on the NMC server and the NMC server
manages multiple NetWorker data zones. The NMC server must be configured as a
client, on each NetWorker server.
Advantages:
l Centralized logging of the security audit messages. The security audit log for each
NetWorker server is stored on the NMC server.
Disadvantages:
l If the nsrlogd daemon is not accessible, either because the daemon fails or
because of a message routing difficulty, security related events are not recorded.
l The NetWorker server daemons generate the majority of the security audit
messages. In this scenario, the security audit log messages are sent over the
network and increase network traffic.
l Each NetWorker host in each datazone must have a route to the NMC server.
The following figure provides an example of this configuration.
Figure 19 The NMC server is the audit log server for multiple data zones
Figure 20 Each NetWorker server in a data zone is the audit log server
Security events
The security audit log feature detects and reports configuration changes that can
result in inappropriate access or damage to a NetWorker server. NetWorker logs
successful and unsuccessful attempts to create and delete security-related resources
and modifications of security-related resource attributes in the audit log file.
Resource database
The following table summarizes which resources and attributes the security audit log
monitors in the resource database (RAP).
Authentication method
Auditlog filepath
Auditlog hostname
Table 26 Security event resources and attributes - resource database (RAP) (continued)
Auditlog severity
Archive users
Backup command
Executable path
Password
Remote access
Remote user
Password
Encryption
Password
Password
Proxy
Username
Name
Users
Notifications Action
Mail Program
Table 26 Security event resources and attributes - resource database (RAP) (continued)
Users
Remote user
Name
Privileges
Users
Resource identifier
Resource Attribute
NSR log Administrator
Log path
Maximum size MB
Maximum versions
Name
Owner
Certificate
Name
NW instance ID
Peer hostname
Table 27 Security event resources and attributes - NetWorker client database (continued)
Resource Attribute
Features
Name
Product version
Connection ports
Service ports
NSRLA Administrator
Auth methods
Certificate
My hostname
Name
NW instance ID
private key
VSS writers
where:
l The TimeStamp is 03/03/12 14:28:39.
l The Category is 0.
l The ProgramName is nsrd.
l The RenderedMessage is Failed to modify Resource type: 'NSR
usergroup', Resource name: 'Users' for Attribute: 'users' by user: 'administrator'
on host: 'nwserver.emc.com'.
nsrd Permission denied, user 'username' on 'hostname' does not have 'privilege1'
or 'privilege2' to create configure this resource - resource_type
This message appears when a user attempts to create a security-related resource but
does not have the required privileges on the NetWorker server.
For example:
15/08/2014 9:11:43 AM 3 nsrd Permission denied, user 'debbie'
on 'bu-iddnwserver.iddlab.local' does not have 'Create
Application Settings' or 'Configure NetWorker' privilege to
create this resource -
NSR client.
nsrd Permission denied, user 'username' on host: 'hostname' does not have
privilege1' or 'privilege2 privilege to configure this resource - resource_type
This message appears when a user attempts to modify a security-related attribute in a
resource but does not have the required privileges.
For example:
15/08/2014 9:03:45 AM 3 nsrd Permission denied, user 'debbie'
on 'bu-iddnwserver.iddlab.local' does not have 'Configure
gstd Console: User 'username' logged out of Console server on host 'hostname'
This message appears when a user closes the Console window and connection to the
Console server.
For example:
14/08/2014 4:36:21 PM 0 gstd Console: User 'administrator'
logged out of Console server on host 'bu-
iddnwserver.iddlab.local'
8. (Optional) In the security audit log in the auditlog severity attribute, change
the audit message severity to increase or decrease the volume of messages that
are saved.
The following severity levels are available.
Type Description
Informational Information that may be useful, but does not require any specific action.
Warning A temporary problem that NetWorker software may resolve or prompt you to
resolve.
Critical Errors that you are required to resolve, to ensure successful NetWorker
operations.
Note: This field also controls remote client security audit configuration. At
the information, notice and warning levels, nsrd broadcasts the security
configuration to all clients during startup. At other levels, when supported
clients request the security configuration from the NetWorker server as
needed, the nsrd daemon does not broadcast security configuration during
startup.
9. (Optional) use a third party logging service to send security audit log messages
to by using the auditlog rendered service attribute.
The following table describes the available options. Each option enables
NetWorker to write unrendered security audit log messages to the
NetWorker_server_sec_audit.raw file only. To render the log file in to a
readable format, use the nsr_render_log program.
Option Description
None The default value.
syslog Also writes rendered security audit log messages to the UNIX syslog.
eventlog Also writes rendered security audit log messages to the Windows
Event Log.
10. (Optional) In the auditlog rendered locale attribute, specify the locale for the
rendered audit log file. If this attribute is empty, the default locale en_US is
used. The Multi-locale datazone considerations section in the NetWorker
Installation Guide describes how to install and configure the NetWorker software
on a machine that uses a non-English locale.
The following figure provides an example of the Security Audit Log Properties
resource.
Figure 21 Security Audit Log resource
For example:
l If the host specified in the auditlog hostname attribute supports security
audit logging and the nsrlogd daemon is successfully started, a message
similar to the following appears:
The process nsrlogd was successfully configured on host
'security_audit_log_hostname' for server
'NetWorker_server'.
l If the host specified in the auditlog hostname attribute does not support
security audit logging or the nsrlogd daemon does not start successfully, a
message similar to the following appears:
The security audit log daemon nsrlogd is probably not
running. 'Unable to connect to the nsrexecd process on
host 'client_name'. '355:Program not registered'.'.
Ensure that the host 'client_name' can be reached. If
required, restart the host.
l If a service port is not available on the host that is specified in the auditlog
hostname attribute, the nsrlogd daemon fails to start and a message
similar to the following appears:
Process nsrlogd was spawned on
'security_audit_log_hostname', but nsrlogd could not
open an RPC channel. 'Unable to connect to the nsrlogd
process on host 'security_audit_log_hostname'.
'352:Remote system error'
l If the path specified in the auditlog filepath attribute does not exist, a
message similar to the following appears:
Unable to open the output file '/proc/
NetWorker_server_sec_audit.raw' for the security audit
log. No such file or directory
Note: Users that belong to the Security Administrators User Group, but not
the Application Administrators User Group cannot see messages in the Logs
window.
This chapter describes the configuration changes that are to be done to harden the
NetWorker.
Enabling HTTPS
To enable HTTPS, you can use either self signed or NetWorker generated certificates.
You can enable HTTPS by following one of the method:
1. Redirect HTTP to HTTPS port
2. HTTPS Redirect
<IfDefine !SSL_PORT>
Define SSL_PORT <choose a port number for which you want
https to be on>
</IfDefine>
<IfDefine !SSL_PORT>
Define SSL_PORT 9111
</IfDefine>
3. Locate the line that defines the current listen port of 9000. Below the line, add
Listen ${SSL_PORT}
Listen 9000
Listen ${SSL_PORT}
4. Locate the section that defines the VirtualHost for port 9000 and modify the
section as shown below:
This section enables HTTPS and creates a rewrite rule to redirect requests
through port 9000 to the newly created HTTPS port. The section marked as
<IP Address of the NMC Console Host> has to be updated with the IP address
or name of the NMC host.
<VirtualHost *:9000>
ServerName localhost:9000
RewriteEngine On
Rewritecond %{HTTPS} !On
Rewriterule (.*) https://<IP Address of the NMC Console
Host>:${SSL_PORT}/%{REQUEST_URI}
</VirtualHost>
5. Locate the section that defines the VirtualHost of the newly created HTTPS
port. Update the certificate settings for https, SSL protocol, and the ciphers to
be used.
<VirtualHost *:${SSL_PORT}>
Servername localhost:${SSL_PORT}
SSLEngine on
SSLCertificateFile "/nsr/certs/<certificate file>"
SSLCertificateKeyFile "/nsr/certs/<public key>"
SSLCACertificateFile "/nsr/certs/”<chain file>"
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLCipherSuite
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3:!
TLSv1.0:!TLSv1.1:!ADH:!MEDIUM:!LOW:@STRENGTH
</VirtualHost>
HTTPS Redirect
Use this method if you want to restrict all the requests on port 9000 to https
Before you begin
To enable HTTPS you will need to have the following three files for configuration:
1. Public key file used to generate the initial certificate.
2. Generated certificate file
3. Chain file that includes the server certificate file
Procedure
1. Open the httpd.conf file and locate for the line # gstconfig bEgIn
2. Locate the line that defines the current listen port of 9000. Below the line, add
Listen 9000 https
Listen 9000
Listen 9000 https
3. Locate the section that defines the VirtualHost for port 9000 and comment the
section by adding # as shown below:
#<VirtualHost *:9000>
#ServerName localhost:9000
#RewriteEngine On
#Rewritecond %{HTTPS} !On
#Rewriterule (.*) https://<IP Address of the NMC Console
Host>:${SSL_PORT}/%{REQUEST_URI}
#</VirtualHost>
4. Locate the section that defines the VirtualHost that contains the HTTPS
enablement. Update the certificate settings for https, SSL protocol, and the
ciphers to be used.
<VirtualHost *:9000>>
Servername localhost:9000
SSLEngine on
SSLCertificateFile "/nsr/certs/<certificate file>"
SSLCertificateKeyFile "/nsr/certs/<public key>"
SSLCACertificateFile "/nsr/certs/”<chain file>"
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLCipherSuite
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3:!
TLSv1.0:!TLSv1.1:!ADH:!MEDIUM:!LOW:@STRENGTH
</VirtualHost>
2. Modify the codebase attribute by changing http to https and replacing the http
port with the port number
For example, codebase= http://IPADDR_REPLACE_AT_RUNTIME(<IP
of server>):9000/ should be changed to https://
IPADDR_REPLACE_AT_RUNTIME(<IP of server>):<SSL_PORT>/
3. Restart the GST services.
2. Locate the line </web-app> and add the following above that line.
<error-page>
<error-code>404</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>
<error-page>
<error-code>400</error-code>
<location>/error.jsp</location>
</error-page>
3. Add a new file with the name error.jsp in the webapps directory of the
distribution.
The location of the file:
l Windows: C:\Program Files\EMC NetWorker\nsr\authc-server\tomcat
\webapps
l Linux: /nsr/authc/webapps
4. Using an editor, edit the error.jsp file and add the following content
<html>
<head>
<title>NSR Authentication Services Error</title>
</head>
<body> Page Not Found! </body>
</html>
2. Search for the string Connector port of 9090 and add the following lines in the
Connect port setting
<Connector port="9090"
protocol="org.apache.coyote.http11.Http11NioProtocol"
Server =" "
SSLEnabled="true"
maxThreads="150"
scheme="https"
secure="true"
xpoweredBy="false"
allowTrace="false"
deployXML="false"
keystoreFile="keystore file" keystorePass="keystore passwd"
keyAlias="emcauthctomcat" keyPass="${tckey.password}"
clientAuth="false"
sslProtocol="TLS"
ciphers="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SH
A256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC
_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM
_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"/>
Procedure
1. Remove the ciphers that are not required.
<Connector port="9090"
protocol="org.apache.coyote.http11.Http11NioProtocol"
SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="/nsr/authc/conf/authc.keystore " keystorePass="$
{keystore.password}"
keyAlias="emcauthctomcat" keyPass="${tckey.password}"
clientAuth="false" sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2, TLSv1.1, TLSv1"
ciphers="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384" />
To disable TLS 1.0 and TLS 1.1, update to indicate the following:
sslEnabledProtocols="TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384"
/>