System and user accounts

Change password for the super user account: You cannot delete the built-in administrator superuser (nsroot). Therefore, change the default password for that account to a secure password. To change the default password for the admin user, perform the following steps:

1. Log on as the superuser and open the configuration utility.
2. In the navigation pane, expand the Systems node.
3. Select the Users node.
4. On the System Users page, select the nsroot user.
5. Select Change Password.
6. Type the required password in the Password and Confirm Password fields.
7. Click OK.

Create an alternative superuser account: To create a superuser account, run the following commands:

add system user <newuser> <password>

bind system user <newuser> superuser 0
<!--NeedCopy-->

Use this superuser account instead of the default nsroot superuser account.

For NetScaler SDX deployments, an administrator must change the default credentials for the NetScaler SDX and its GUI management console after the initial setup. To change the password for the default user, perform the following steps:

1. Log on as the superuser and open the configuration utility.
2. In the navigation pane, expand the Systems node.
3. Select the Users node.
4. On the System Users page, select the default user.
5. Select Modify.
6. Type the required password in the Password and Confirm Password fields.
7. Click OK.

Strong password for system user:

We recommend using a strong password for system users accounts created in NetScaler. Examples of password complexity requirements are as follows:

• The password must have a minimum length of eight characters.
• The password must not contain dictionary words or a combination of dictionary words.
• The password must at least include one uppercase letter, one lowercase letter, one number, and one special character.

Strong passwords can be enforced by setting two parameters, one for the minimum length of passwords and the other to enforce password complexity:

set system parameter -minpasswordlen <positive_integer> -
-strongpassword ( ENABLED | DISABLED )
<!--NeedCopy-->

In deployments where multiple administrators are required, consider using an external authentication method to authenticate users, for example RADIUS, TACACS+, or LDAP(S). For more information, see External user authentication.

Lock system user account for management access: NetScaler enables you to lock a system user for 24 hours and deny access to the user. NetScaler supports the configuration for both system user and external users. At the command prompt type:

set aaa parameter –persistentLoginAttempts DISABLED

Now, to lock a user account, at the command prompt, type:

lock aaa user test

For information on how to configure this feature by using the GUI, see User account and password management.

Unlock a locked system user account for management access: System users and external users can be locked for 24 hours using the lock authentication, authorization, and auditing user command. The NetScaler enables you to unlock the locked system user. At the command prompt, type:

unlock aaa user test For information on how to configure this feature by using the GUI, see User account and password management.

Disable management access for system user account: When external authentication is configured on NetScaler and as an admin that you prefer to deny access to system users to log on to management access, you must disable the localAuth option in the system parameter.

Note:

External server must be configured.

At the command prompt, type the following:

set system parameter localAuth <ENABLED|DISABLED>

Example:

set system parameter localAuth DISABLED For information on how to configure this feature by using the GUI, see User account and password management.

Force password change for administrative users: For nsroot secured authentication, NetScaler prompts the user to change the default password to a new one if the forcePasswordChange option is enabled in the system parameter. You can change your nsroot password either from CLI or GUI, on your first login with the default credentials. At the command prompt, type:

set system parameter -forcePasswordChange ( ENABLED | DISABLED )

For example of how to configure this feature, see User account and password management.

Access the NetScaler Using SSH Keys and No Password: In deployments where there is a requirement to administer many NetScaler appliances, consider using SSH Keys and No Password. For information on how to configure this feature, see Access a NetScaler appliance by using SSH keys and no password.

Create the system main key for data protection: From Citrix ADC 12.1 to Citrix 13.0–71.44, it is necessary to create a system main key to protect certain security parameters, such as service accounts passwords required for the LDAP authentication and locally stored authentication, authorization, and auditing User Accounts.

Note:

From Citrix 13.0 build 76.31 and later, a random system main key is created by default automatically with the upgrade process. Ensure to update KEK frequently in accordance with the organization’s password policy.

To create the system main key:

1. Using the CLI, log in as a system administrator.
2. Enter the following command:

create kek <passphrase>
<!--NeedCopy-->

Note:

• After the create kek command is run, KEK is used for most password encryptions (local user passwords do not get encrypted with KEK).
• You must not delete the KEK file. If you have shell access and you delete the key fragment files by mistake, it might result in configuration loss, synchronization failure, logon failure. Note the following.
  • Always use an older configuration file matching to the build being installed when downgrading; else logon, source configuration, synchronization, failover might fail.
  • If any of the key fragment files are lost or corrupted, the encryption /decryption of sensitive data results in failure which might in turn result in configuration loss, synchronization failure, logon failure.
• The pass phrase must be at least 8 characters long.

Update key encryption key on a deployed NetScaler:

NetScaler supports updating the KEK on a deployed ADC. Use the following command to update the KEK.

update kek -level <basic | extended> 
<!--NeedCopy-->

The update KEK command is supported only on the NSIP interface. The command supports the following two options.

• Basic: Backs up old keys, creates keys, and responds. If any of the file updates fail, the system reports an error and reverts to the original state.
• Extended: Backs up old keys and creates keys. Updates config files such as ns.conf and ns.conf.0 under the default and non-default partitions. During the update, blocks all configuration changes. After the update is done, NetScaler responds. If any of these file updates fail, the system reports an error and reverts to the original state.

Previously, NetScaler only supported the default per node KEK. There was no option to update the KEK.

As a security best practice, KEK must be changed frequently in accordance with the organization’s password policy.

Use access control lists:

By default, all protocols and ports, including GUI and SSH, are accessible on NetScaler. Access control lists (ACLs) can help you to manage NetScaler securely by allowing only explicitly specified users to access ports and protocols.

Recommendations for controlling access to NetScaler:

• Consider using NetScaler Gateway to limit access to NetScaler to the GUI only. For administrators who require methods of access in addition to the GUI, the NetScaler Gateway must be configured with a default ‘DENY’ ACL for ports 80, 443, and 3010, but with an explicit ‘ALLOW’ for trusted IP addresses to access these ports.

This policy can be extended for use with the range of trusted IP addresses with the following NSCLI command:

add acl local_access allow -srcip 192.168.0.1-192.168.0.3 -destip 192.168.0.1-192.168.0.3

apply acls
<!--NeedCopy-->

• If you use SNMP, explicitly allow SNMP traffic with ACL. The following is a set of sample commands:

add acl snmp1-ssh ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 161 -protocol udp

add acl snmp2-ssh ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 –destport 161 -protocol udp

apply acls
<!--NeedCopy-->

In the preceding example, the command provides access for all SNMP queries to the two defined subnets, even if the queries are to the appropriately defined community.

You can enable management functions on NSIP and SNIP addresses. If enabled, provide access to the NSIP, SNIP, addresses with ACLs for protecting the access to the management functions. The administrator can also configure NetScaler such that it is not accessible with the ping command.

• Open Shortest Path First (OSPF) and IPSEC are not a TCP or UDP based protocol. Therefore, if you need NetScaler to support these protocols, explicitly allow the traffic using these protocols by using an ACL. Run the following command for defining an ACL to specify OSPF and IPSEC by protocol numbers:

add acl allow_ospf allow -protocolnumber 89

add acl allow_ipsec allow -protocolnumber 50
<!--NeedCopy-->

• If an XML-API Web service is used, complete the following tasks to secure the API interface:
• Provide permission to the host for accessing the interface by using an ACL. For example, run the following commands to enable the hosts in the 10.0.0.1-20 and 172.16.0.1-20 IP address range to access the XML-API interface:

add acl xml-api1 ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

add acl xml-api2 ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

apply acls
<!--NeedCopy-->

• To apply ACLs for the internal ports, use the following command:

set l3param -implicitACLAllow DISABLED
<!--NeedCopy-->

Note:

The default value for the implicitACLAllow command is ENABLED.

• To remove ACLs from the internal ports, use the following command:

set l3param -implicitACLAllow ENABLED
<!--NeedCopy-->

• You can achieve extra security by using a client-side certificate. For more information about client-side certificates and client authentication, see Client authentication or Knowledge Center article CTX214874: How to Create and Use Client Certificates on NetScaler Appliance with Firmware 10.1 and Above.

Use role-based access control for administrative users:

NetScaler includes four command policies or roles such as operator, read-only, network, and superuser. You can also define command policies, create different administration accounts for different roles, and assign the command policies that are necessary for the role to the accounts. The following is a set of sample commands to restrict the read-only access to the read-only user:

add system user readonlyuser

bind system user readonlyuser read-only 0
<!--NeedCopy-->

For further information on configuring users, user groups, or command policies, see User, user groups, and command policies.

Configure system session timeout:

A session timeout interval is provided to restrict the time duration for which a session (GUI, CLI, or API) remains active when not in use. For NetScaler, the system session timeout can be configured at the following levels:

• User level timeout. Applicable to the specific user.

GUI: Navigate to System > User Administration > Users, select a user, and edit the user’s timeout setting. CLI: At the command prompt, enter the following command:

set system user <name> -timeout <secs>
<!--NeedCopy-->

• User group level timeout. Applicable to all users in the group.

GUI: Navigate to System > User Administration > Groups, select a group, and edit the group’s timeout setting. CLI: At the command prompt, enter the following command:

set system group <groupName> -timeout <secs>
<!--NeedCopy-->

• Global system timeout. Applicable to all users and users from groups who do not have a timeout configured.

GUI: Navigate to System > Settings, click Set global system parameters, and set the ANY Client Idle Time-out (secs) parameter. CLI: At the command prompt, enter the following command:

set system parameter -timeout <secs>
<!--NeedCopy-->

The timeout value specified for a user has the highest priority. If a timeout is not configured for the user, the timeout configured for a member group is considered. If timeout is not specified for a group (or the user does not belong to a group), the globally configured timeout value is considered. If a timeout is not configured at any level, the default value of 900 seconds is set as the system session timeout.

You can also restrict the timeout value so that the session timeout value cannot be configured beyond the timeout value configured by the administrator. You can restrict the timeout value between 5 minutes to 1 day. To restrict the timeout value:

• GUI: Navigate to System > Settings, click Set global system parameters, and select the Restricted Timeout field.
• CLI: At the command prompt, enter the following command:

set system parameter -restrictedtimeout <ENABLED/DISABLED>
<!--NeedCopy-->

After the user enables the restrictedTimeout parameter, and if the timeout value is already configured to a value larger than 1 day or less than 5 minutes, the user is notified to change the timeout value. If the user does not the change the timeout value then, by default, the timeout value will be reconfigured to 900 secs (15 minutes) during the next reboot.

You can also specify timeout durations for each of the interfaces you are accessing. However, the timeout value specified for a specific interface is restricted to the timeout value configured for the user that is accessing the interface. For example, consider a user publicadmin has timeout value of 20 minutes. Now, when accessing an interface, the user must specify the timeout value that is within 20 minutes.

To configure the timeout duration at each interface:

• CLI: Specify the timeout value on the command prompt by using the following command:

set cli mode -timeout <secs>
<!--NeedCopy-->

• API: Specify the timeout value in the login payload.