Configuring general security settings

In WinSec Controller software versions 1.5.0 and later, local, RADIUS, and TACACS+ authentication methods are supported. Settings to prioritize local, RADIUS, and TACACS+ authentication methods for the system and to set the authorization policy and default user for RADIUS and TACACS+ authorization systems are under Administration > Roles & Users: General Settings.

Make sure to put the authentication methods in the order in which you want authentication to occur. If authorization fails on the first method, the next method is attempted, and so on, until all of the methods are attempted.

These configuration options are available under Authentication Methods:

Authentication Methods specifies the authentication method. Select an authentication method from the drop-down list. The methods are listed in the order in which they occur. If authorization fails on the first method, the next method is attempted, and so on, until all of the methods have been attempted.

For RADIUS/TACACS+, fallback only when servers are unavailable prevents local login if the RADIUS or TACACS+ server denies access, but allow local login if the RADIUS or TACACS+ server is not available.

Safety Account creates a safety account so that admin or sys admin users can log in to the WinSec Controller even if remote authentication servers are unreachable. A safety account increases security and conforms to US National Institute of Standards and Technology (NIST) requirements. Only the selected safety account will be allowed to log in in cases where the AAA server isn’t reachable. (Only one user can be assigned to the safety account.) Settings to create a system administrator user are under Administration > Roles & Users: Users. For details, see “Managing user permissions” on page 554.

Safety Account User selects the user from the drop-down list.

Authorization Policy appears only for some Authentication Methods. Optionally, select one of these policies from the drop-down list:

• Remote First checks the remote server first for an authentication policy, and only checks locally if the remote server doesn’t have one set. This is the default behavior.

• Local Only only checks the local server. All remote users are mapped to the user specified. Any vendor attributes received by an authentication server are ignored.

AAA Default Role (For RADIUS/TACACS+ logins) selects the role and permissions for RADIUS/TACACS+ logins. The role determines the user’s network privileges. The default setting is admin. For more information on roles, see About roles.

You set up Security Assertion Markup Language (SAML) in the Administration > SAML page.

WebUI access defaults to “local auth.” Enabling SAML disables “local auth” on WebUI access.

Security Assertion Markup Language (SAML) 2.0 is an XML standard that acts as an authentication interface between the WinSec Controller and an identity provider (IdP). You can use the IdP to provide additional requirements for authentication, such as a multifactor authentication based on a common access card (CAC) or personal identity verification (PIV).

When the WinSec Controller receives a login request, it determines if SAML is enabled. If SAML is enabled, user authentication through AAA is disabled and the WinSec Controller redirects the authentication request to the IdP. The IdP authenticates the user and redirects the user to the WinSec Controller, which allows access.

To enable IdP authentication, you configure the WinSec Controller and the IdP with XML metadata that provides detailed appliance identification. The metadata also establishes a trust relationship between the WinSec Controller and the IdP.

Administrators must add users to the IdP server to provide them login access, and those users need to correspond to the WinSec Controller users. You can have one-to-one mapping of users between IdP and the WinSec Controller, or you can have multiple users on IdP map to single account on the WinSec Controller, such as the admin account. (You have to create individual user accounts on the WinSec Controller for one-to-one mapping as the user accounts determine the access permissions.)

If a user who has not been set up in the IdP tries to log in to the WinSec Controller, the login fails on the IdP login page. If the user has been set up but their user mapping has not been defined in the IdP, the login succeeds but the WinSec Controller displays an error page.

SAML authentications are only available in the Management Console web interface; they are not available through the CLI. Users can log in to a SAML-enabled WinSec Controller through the CLI, but they are authenticated using the local authentication methods.

If you cannot log in using SAML (for example, if the IdP server is unavailable), you can log in through the CLI and disable SAML using the no enable saml command. Once SAML is disabled, you revert to the previously configured authentication method for the web interface. For command details, see the Riverbed Command-Line Interface Reference Manual.

You must be logged in as the administrator to enable or disable SAML.

4. Under SAML Configuration, enter Identity Provider Metadata. Click Browse to get content of a file, or copy and paste the content.

5. Select the Sign Authentication Request check box to have WinSec sign the SAML authentication request sent to the identity provider. Signing the initial login request sent by WinSec allows the identity provider to verify that all login requests originate from a trusted service provider.

6. Select the Requires Signed Assertions check box if the IdP signs the assertion response. Some SAML configurations require signed assertions to improve security.

7. Select the Requires Encrypted Assertions check box if the SAML identity provider encrypts the assertion section of the SAML responses. Even though all SAML traffic to and from the WinSec Controller is already encrypted by the use of HTTPS, this option adds another layer of encryption.

8. In the Username Attribute field, enter the name of the IdP variable that carries the username. The Username attribute is mandatory and must be sent by your identity provider in the SAML response to align the login with a configured WinSec Controller account.

9. In the Member of Attribute field, enter the name of the IdP variable that carries the role of the user. The role must match with a local WinSec Controller user. This setting is mandatory.

11. Under Enable SAML, click Enabled. Once SAML is enabled, only users with IdP credentials can log in to the WinSec Controller graphical user interface.

You can create roles for specific types of users and activities. For example, you might create a role for a small group of network admins, empowering that role to change network-related settings but limiting access to security settings like certificate management.

For custom roles, you can set permissions to read only, read and write (edit), or deny. These items are read-only for all roles and users: dashboard, help, and pending actions. Users assigned the admin role can change the password policy and licenses, and you can provision edit permission for those settings to a custom role, but we recommend limiting edit access to admin users.

Four default roles, which cannot be modified, provide convenient starting points:

• admin—This role has the most expansive capabilities, with edit permission for nearly every setting except password policy and licenses.

• monitor—This role can be provisioned to users who need only to monitor the system or generate system dump (sysdump) files. The only editable setting for users with this role is the User Specific > About setting.

• network—This role provides edit permission to network-related and maintenance-related settings. These settings are restricted to read-only: replication users, secure peering (IPsec), replication statistics, password policy, licenses. We recommend assigning this role to users that administer SteelHeads and other network administrators.

• replication—This role provides edit permission to most settings except base interfaces, password policy, and licenses settings, which are read-only for this role. We recommend assigning this role to users who also administer Windows systems and who need to configure replication users, the secure vault, and diagnostics and statistics settings.

To edit or remove a custom role, you need to select it. Select the row to edit that role, enter updated values, and click Submit. Click Remove selected row to delete it.

You can add and remove users. You can also change a user’s role, email, full name, description, and password.

3. Enter a username for the account, the full name of the user, an email address for the user, and a description of the account.