About authentication
Portal can use LDAP, RADIUS, or TACACS+ authentication servers in addition to local password user authentication (the default), or it can use SAML 2.0 authentication instead of the other types. Once authenticated, a remote user can be assigned a role (authorized) either by the authentication server or identity provider, or by a default role configured in Portal. If authentication and authorization succeed, the appliance logs the user in. If either authentication or authorization fails, the appliance displays an error message and records an unsuccessful login attempt in the audit logs.
When using remote authorization:
• You can configure a maximum of two RADIUS and two TACACS+ remote servers.
• You can specify a sequence of authentication types with prioritized servers in each type. For example, you can specify LDAP, RADIUS, TACACS+, and Local as the sequence to be used when authenticating users. Place each authentication server in the order you want requests to be processed.
• Command accounting is not supported.
For RADIUS and TACACS+, traffic is encrypted using a shared secret when a request is sent to an authentication server. If you use LDAPS://, then all traffic is encrypted between Portal and the LDAP server. If you use LDAP://, then all traffic will not be encrypted between Portal and the LDAP server. The credentials used to connect to authentication servers is not stored in an encrypted format by Portal.
Adding a message to the login screen
Portal allows the administrator to add a message to the login screen.
1. Log in to the Portal UI as an administrative user.
2. Choose Administration > Account Management: Authentication.
3. On the General tab, enter a message in the Login Banner text box.
4. When you are satisfied with your message, click Apply. Otherwise, click Revert to return to the previous saved settings
The login banner appears at the top of the login page.
About web session inactivity
Web session inactivity settings are under Administration > Account Management: Authentication.
The default timeout for web session inactivity is 60 minutes. You can change the timeout duration by enabling logout after inactivity and entering a time in minute format. The minimum time allotted is 15 minutes.
You will be notified about the inactivity and prompted to log back in.
About remote authentication
By default, Portal installs a local user admin with a System Administrator role. This user is stored in a local file. Portal also supports remote authentication using LDAP, RADIUS, and TACACS+ authentication servers, as well as SAML identity providers. Remote authentication enables an authenticated user to sign in on any Portal system in the management network. A remote user does not need a local account to be authenticated when using LDAP, RADIUS, TACACS+, or SAML.
The authorization (roles) for a remote user can be specified by:
• the remote authentication server using a RADIUS or TACACS+ Vendor Specific Attribute.
• mapping LDAP groups and users with the auth ldap mapped-* commands.
• a default role configured in Portal.
A remote user:
• does not inherit a role from a local account of the same username.
• sees the same private files when logged in using remote authentication as if they were authenticated locally.
Configuring a sequence of authentication types
When LDAP, RADIUS, and TACACS+ authentication servers are configured in Portal you can add them to a sequence of authentication types (LDAP, RADIUS, TACACS+, or Local) to be used when a user signs in. Authentication requests are made from the highest priority authentication type (1) to the lowest. For RADIUS and TACACS+ authentication types, requests are sequentially made to the configured servers in the order they appear in on the RADIUS and TACACS+ tabs. Authentication requests are made until a server accepts or rejects a request or the authentication types are exhausted.
• If a server does not respond, authentication proceeds to the next server.
• If authentication is rejected, there is no provision to try the next server of the same authentication type. For example, if two RADIUS servers are configured and the first server rejects a user, the second RADIUS server is not contacted. You can choose to try the next authentication type if a higher-priority authentication type rejects a request. See
Setting the sequence of authentication types for details.
If not careful, you can lock yourself out of Portal by:
– removing local authentication from the sequence, and the remote servers (LDAP, RADIUS or TACACS+) are unreachable.
– clearing the Try next method on reject check box.
We recommend checking that authentication using LDAP, RADIUS, and TACACS+ works successfully before you remove local authentication or clearing the "Try next method on reject." check box.
If locked out, contact Riverbed Support to recover the Portal virtual appliance.
Specifying authentication types
1. Choose Administration > Account Management: Authentication and select the General tab.
A table shows the authentication types currently selected (Local by default).
2. Click Add to display a pop-up menu with other available authentication types.
3. Click Submit following an authentication type to add it to the table.
4. When finished click the x in the upper-right corner of the pop-up menu.
Setting the sequence of authentication types
1. Choose Administration > Account Management: Authentication and select the General tab.
A table shows the authentication types currently selected (Local by default).
2. The priority of each authentication type is shown in column 1, highest (1) to lowest.
3. Use three icons on the right-side of each table row to change a row’s priority:
– Click ^ to raise an authentication type’s priority.
– Click v to lower an authentication type’s priority.
– Click x to remove the authentication type.
4. Selecting the Try next method on reject check box (below the table) tries the next authentication type if a higher priority authentication type rejects a request. By default, this box is checked and a rejected request tries the next authentication type in the sequence.
About LDAP authentication
Up to two LDAP authentication servers, one primary and one secondary, can be configured via the command-line interface. By default, Portal uses the primary LDAP server. In case there is a connection failure, Portal will contact the secondary LDAP server. To ensure a seamless switch-over from primary to secondary, configure the same bind credentials and LDAP data in Portal for both servers.
When you enable or disable LDAP, it will automatically be added to, or removed from, the authentication sequence. When LDAP is enabled, you can configure its priority relative to other authentication types via the web UI. See
Configuring a sequence of authentication types.If you are planning to configure LDAP to use secure communication (that is, LDAPS://), you will need your X.509 certificate ready to paste into the terminal.
LDAP command-line configuration wizard
Use the CLI-based wizard to configure LDAP. Here is an example session from login to exit:
~:$ ssh admin@Portal-1.riverbed.com
admin@Portal-1.riverbed.com's password:
Last login: Thu Jan 24 12:05:00 2019 from user-machine.riverbed.com
localhost > enable
localhost # configure terminal
localhost (config) # auth ldap add
LDAP server URI (e.g.: ldap://hostname.com): ldap://primary-ldap.riverbed.com
ldap://primary-ldap.riverbed.com added.
localhost (config) # auth ldap add
LDAP server URI (e.g.: ldap://hostname.com): ldap://secondary-ldap.riverbed.com
ldap://secondary-ldap.riverbed.com added.
localhost (config) # auth ldap enable
LDAP enabled.
localhost (config) # auth ldap configure
Bind DN [default]: CN=service-user,OU=Users_NonHuman,DC=acme,DC=com
Bind password:
Secure communication?
a) off
b) on
c) start TLS
Choose option [a]: c
Server priority order:
Id URI
1 ldaps://primary-ldap.riverbed.com
2 ldaps://secondary-ldap.riverbed.com
Reverse priority order (yes/no) [no]:
User group attribute [member]:
User login attribute [uid]: sAMAccountName
Search base [base]: DC=acme,DC=com
Search scope:
a) sub
b) one
c) base
Choose option [a]:
Enter/Paste CA certificate. Press Ctrl+D when done.
-----BEGIN CERTIFICATE-----
MIIDkTCCAnmgAwIBAgIETaE/njANBgkqhkiG9w0BAQsFADB5MQswCQYDVQQGEwJVUzETMBEGA1UE
CBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzERMA8GA1UEChMIUml2ZXJiZWQx
FTATBgNVBAsTDFN0ZWVsQ2VudHJhbDETMBEGA1UEAxMKTERBUCBBZG1pbjAeFw0xODA0MDIyMjM4
MThaFw0xOTAzMjgyMjM4MThaMHkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYw
FAYDVQQHEw1TYW4gRnJhbmNpc2NvMREwDwYDVQQKEwhSaXZlcmJlZDEVMBMGA1UECxMMU3RlZWxD
ZW50cmFsMRMwEQYDVQQDEwpMREFQIEFkbWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAylAj2hm5BnrNA7bjy4yA2sM+BmnpDVfRlf87KLes5Obf2u2PH2mzncURWkV3WUknpPjZbqqg
i7GM+nUV1HzgoPmmKY+E+twxtM+KHoQj1u82htJGI2PO2M7HWRki7pfj03bd5CWrVPYzN8nRRCCj
Swb1taU+suz7zsMsRxK6lhRS7pqiKRDBmpSIo+srVWxmjS8T5lf2bkFCta+AegXAJtylSd7lpgTG
eyEHChGmv5J0C6FKwtTX0/MwTk3A1+3spYzBeunmSZJDl766EYRICUwDnMfvBN464nZ3hhHEYyf1
nStaljZcbE/I54yX9o5jJt8gauQabUNZPyPlFzK6bwIDAQABoyEwHzAdBgNVHQ4EFgQU6fbBgIz7
Mu6cRCnLzWB6cQuQaSkwDQYJKoZIhvcNAQELBQADggEBACZp4CSg3rWo8j94GrQfsdQtXJ/PGJKi
ah3JioETykfxV7X/8++qTsWaoMiXwr1Bk6341vyYEOYOovMwHz9/7Uin6/rMVNT9O86iNeMP9AXz
mKgwrG4owQ3/+lwThn14gDCRFfYCLxC+Z2Fr6DDmkoxA/b6L3f1HR1ZuRuRnl4GTujkvux4VMwzV
oDThz14NByDv3MbjifPv6zovuX4LQYaF80qKQ2A1VQQbbzBR1hGuYP3XsBPS5ug3fazB5ol7xZPt
zOPxfTSwnI91NLgsBwa+DmHlrSvHaYqQFXehwa9G6wKnODNbmdhaDclttBaxzmNUGusYAeYGDgAd
Ds2EIBI=
-----END CERTIFICATE-----
Require TLS certificate?
a) never
b) demand
Choose option [a]: b
LDAP server configured.
localhost (config) # exit
localhost # exit
Connection to Portal-1.riverbed.com closed.
~:$
LDAP configuration commands
Here is a list of the LDAP configuration commands:
• auth ldap enable—Enables LDAP authentication.
• auth ldap disable—Disables LDAP authentication.
When you disable LDAP, it is automatically removed from the authentication sequence.
• auth ldap add—Adds a primary or secondary LDAP server.
Include the LDAP server URL in this format as a parameter to this command: ldap[s]://host:port
• auth ldap delete—Deletes an LDAP server.
• auth ldap configure—Starts the LDAP configuration wizard.
The configuration wizard will prompt for this data:
– Bind DN—A new distinguished name with which to bind to the directory server.
– Bind password—The clear text password with which to bind.
– Secure communication—Select one of these options: off (clear communication), on (use SSL), or TLS (use TLS).
– User group attribute—The LDAP group attribute to associate with the roles defined in Portal.
– User login attribute—The attribute to use when constructing the attribute value assertion for retrieving a directory entry for a user’s login name.
– Search base—The default base distinguished name (DN) to use for searches.
– Search scope—Select one of these options: sub (search in the sub-tree), one (only search at current level), or base (only search at the base DN level).
– TLS CA certificate—The X.509 certificate for peer authentication (pasted as a text string). The wizard will not prompt for this if you selected “a) off” for “Secure communication?”.
– TLS require certificate—Specifies if the LDAP connection should be made with a certificate. Select either never (false) or demand (true). The wizard will not prompt for this if you selected “a) off” for “Secure communication?”.
• auth ldap mapped-groups list—Lists the roles mapped to LDAP groups.
• auth ldap mapped-groups add—Maps a role to an LDAP group.
• auth ldap mapped-groups delete—Removes the association of a role to an LDAP group.
• auth ldap mapped-users list—Lists the roles mapped to LDAP users.
• auth ldap mapped-users add—Maps a role to an LDAP user.
• auth ldap mapped-users delete—Removes the association of a role to an LDAP user.
• auth ldap status—Shows LDAP server status and configuration.
• show ldap—Shows LDAP server status and configuration.
Configuring RADIUS authentication
Up to two RADIUS authentication servers can be configured and managed on the RADIUS Configuration tab. A toolbar in the top-left corner of the configured servers is used to add or delete servers. Mouse over the right end of a row containing a selected server to edit or delete that server. When the first authentication server is specified, a priority table appears above the configured servers, along with a drop-down menu used to specify the encryption protocol used.
1. Choose Administration > Account Management: Authentication and select the Radius tab.
A table shows the configured RADIUS Servers.
2. Click Add in the toolbar. A New RADIUS Server window is displayed.
3. Specify a host, identified using:
– an IPv4 address.
– a hostname.
4. Specify the UDP port used for authentication.
5. Specify the shared secret key used to encrypt traffic to and from the server. Select Enable to make this field editable.
6. Specify the timeout period in seconds. Up to 30 seconds can be entered.
7. When finished, click Save. To discard any entries, click x in the upper-right corner of the window.
Setting the RADIUS encryption protocol
You can change the encryption protocol used by the RADIUS servers (default PAP). Select from this list of protocols:
• CHAP
• MSCHAP1
• MSCHAP2
• PAP
Setting RADIUS server priority
When the first authentication server is specified, a Priority table appears above the configured servers.
1. Choose Administration > Account Management: Authentication and select the Radius tab.
A table shows the authentication servers configured.
2. The priority of each server is shown in column 1, highest (1) to lowest.
3. Use the two icons on the right-side of each table row to change a row’s priority:
– Click ^ to raise an authentication type’s priority.
– Click v to lower an authentication type’s priority.
Configuring TACACS+ authentication
Up to two TACACS+ authentication servers can be configured and managed on the TACACS+ Configuration tab. A toolbar in the top-left corner of the configured servers is used to add or delete servers. Mouse over the right end of a row containing a selected server to edit or delete that server. When the first authentication server is specified, a priority table appears above the configured servers, along with a drop-down menu used to specify the encryption protocol used.
1. Choose Administration > Account Management: Authentication and select the TACACS+ tab.
A table shows the configured TACACS+ Servers.
2. Click Add in the toolbar. A New TACACS+ Server window is displayed.
3. Specify a host, identified using:
– An IPv4 address
– A hostname
4. Specify the UDP port used for authentication.
5. Specify the shared secret key used to encrypt traffic to and from the server. Select Enable to make this field editable.
6. When finished, click Save. To discard any entries, click x in the upper-right corner of the window.
Setting the TACACS+ timeout
Select the timeout period in seconds (default three seconds) in the Timeout box. A time from 1 to 30 seconds can be selected.
Setting TACACS+ server priority
When the first authentication server is specified, a priority table appears above the configured servers.
1. Choose Administration > Account Management: Authentication and select the TACACS+ tab.
A table shows the authentication servers configured.
The priority of each server is shown in column 1, highest (1) to lowest.
2. Use the two icons on the right-side of each table row to change a row’s priority:
– Click ^ to raise an authentication type’s priority.
– Click v to lower an authentication type’s priority.
Setting up RADIUS and TACACS+ remote authentication
A RADIUS or TACACS+ authentication server needs information about Portal before it can successfully respond to an authentication request. A summary of the required information and an example configuration for RADIUS and TACACS+ servers is provided below. These instructions assume you have an existing authentication server to which you are adding a Portal. For information on setting up an authentication server, please see the documentation that came with the authentication server.
Adding RADIUS server information
To modify or create a vendor file, add and save a Portal attribute to the Riverbed RADIUS vendor file.
The Riverbed RADIUS vendor ID is 17163.
• Add the attribute 'Riverbed-Roles-List' with value 10, type 'string' to the file.
• Here is an example showing this change added to a FreeRADIUS authentication server:
/usr/share/freeradius/dictionary.riverbed
# -*- text -*-
VENDOR Riverbed 17163
BEGIN-VENDOR Riverbed
ATTRIBUTE Riverbed-Local-User 1 string
ATTRIBUTE Riverbed-Roles-List 10 string
END-VENDOR Riverbed
The example above also shows the attribute used by Riverbed SteelHead.
A vendor ID can only be used in a single file. If there is an existing file using the Riverbed vendor ID add the Portal attribute to the existing file and save the change.
Adding available roles
Optionally, the authorization (roles) for a remote user can be specified by the RADIUS server using a Vendor Specific Attribute (VSA). If the remote server does not return the VSA, then the default role configured in Portal is assigned. If the VSA is present, but empty or if no default roles are configured in Portal, no roles are assigned to you.
The vendor value is a comma-separated list of role names (case sensitive). Valid values match the roles created in Portal.
Adding TACACS+ server information
Optionally, the authorization (roles) for a remote user can be specified by the TACACS+ server using the Vendor Specific Attribute (VSA) "riverbed-roles-list", added under the "system" service.
An example of a defined role appears below.
user = tacplus {
login = cleartext "tacplus"
service = system {
riverbed-roles-list = "System Administrator"
}
}
About SAML 2.0 authentication
SAML 2.0 authentication facilitates single sign-on for use with one or more Portal systems or other Alluvio products accessed from a single browser session. When SAML 2.0 is enabled, Portal relies on a specified SAML 2.0 identity provider (IdP) for authentication. The homepage will show a button for you to log in through SAML 2.0. If you want to log in through local authentication, you can still do so from the login screen. If the SAML 2.0 IdP is unable to authenticate a user for any reason, that user will not be able to launch a Portal web UI session. Note that SAML 2.0 authentication can be disabled via the Portal CLI, using the no saml enable command.
When SAML 2.0 is enabled, the first time you initiate access to a Portal system in a browser session, Portal will redirect you to the SAML 2.0 IdP for authentication. Upon successful authentication, the IdP will redirect you back to the Portal system, and the UI will open. The IdP will send back the user role corresponding to the username being authenticated, and that user will have permissions in Portal as defined by that role. As long as you keep that browser session active, any subsequent Portal session, even if you log out of the system, quit the browser tab, or access a new system, will begin immediately without requiring you to reauthenticate. You will need to reauthenticate with the IdP if you quit the browser session in which you had authenticated earlier.
Configuring SAML 2.0 authentication
1. Choose Administration > Account Management: Authentication and select the SAML 2.0 tab.
2. (Optional) The NameID field specifies that Portal uses as the authenticated user’s name. If this field is left blank (the default), Portal will use the SAML 2.0 NameID field. If this field is populated, Portal will look for a SAML 2.0 attribute of the same name and use it as the username. In either case, if a username is not found, you will not be allowed to log in.
3. In the IdP Metadata field, paste in the XML metadata that identifies the identity provider you wish to use. This step is manual, and you need to acquire the XML metadata from your IdP separately.
4. Leave the Roles Attribute field set to memberOf, unless your IdP has been configured to use a different attribute.
5. (Optional) If you need to acquire XML metadata that identifies your Portal system (the service provider), click the Download as XML link to obtain it.
6. (Optional) Select whether you will return signed authentication requests or require signed assertions when interfacing to the identity provider.
7. (Optional) Specify a fully qualified domain name, if you wish to use one. This is needed only if Portal is unable to determine this on its own, or if it otherwise obtains a host address that is not the same as what is required from a web browser.
8. (Optional) Import or generate a certificate that will verify the identity of your Portal system (the service provider), if you wish.
9. Click Apply to implement your changes, then click Test to see what will happen without committing to the configuration changes. If the results of the test are satisfactory, click Enable SAML 2.0 and click Apply again. Click Revert to return to the last saved configuration.
About auto single sign-on
You can enable the flag auth_auto_sso to let users automatically redirect to the SSO login page when SAML is configured.
To enable/disable the flag, log in to the Portal appliance via CLI and edit Portal’s server settings file by running following commands:
ssh admin@<host>
enable
configure terminal
portal-core server-settings
Look for the setting auth_auto_sso and set its value to true to enable auto redirect or false to disable it.
Disabling the flag does not disable SAML 2.0. However, you will not be automatically redirected to the SSO login page allowing you to enter credentials if you choose to use any other authentication module.
About user administration
Controls are used for creating and managing user accounts for Portal.
• Local Users—Create and manage individual user accounts, including their role-based privileges. The Local Users tab shows details for each existing user account. User accounts can be added, edited, or deleted.
• Roles and Permissions—Configure roles and permissions.
• Password Policy—Configure global login and password policies for all user accounts.
Creating a new user account
Click Add in the Local Users tab to display the New User dialog. Provide this information:
• Name—The user account's unique ID. User account names must be from 2 to 32 characters long and start with a letter. Lowercase alphanumeric characters, dash, and underscore can be used.
• Description—Type a brief explanation of the user account's purpose, if desired.
• Password—Type the user account's password.
• Verify Password—Type the user account's password again to ensure that it is defined explicitly.
• Password Never Expires—Click this option if there is no need for the user to change the account password periodically.
• Roles—Specify one or more of the user roles defined on the appliance. The set of valid roles is user defined; only the System Administrator role is built in.
Editing a user account
To edit an existing user account, mouse over it and click the pencil icon to display the Edit User dialog.
The Edit User dialog provides the same controls as the New User dialog.
Deleting a user account
You can delete the admin account that is provided by default. The system does not prompt you for confirmation before executing this action.
1. Mouse over the user to be deleted.
2. Click the x at the end of the row.
3. Click Delete to remove the user, or click Cancel to keep the user.
Roles and permissions
Role Based Access Control (RBAC) protects the system by assigning different access privileges to different user roles. User roles are then assigned to user accounts. A user's privileges on the system are determined by which roles the system administrator assigns to their account. Each account can be assigned one or more roles.
Some features of the product are accessible to all users. Others are accessible to only users whose user roles have the required permissions. If a user account does not have a role with permissions for a feature, then the menu choice for the feature is not displayed.
The product is preconfigured with a set of default roles, including the System Administrator role. You can use the Roles and Permissions tab of the Administration > Account Management: User Administration page to create additional user roles.
Creating a new user role
1. Choose Administration > Account Management: User Administration and select the Roles and Permissions tab.
2. Click Add.
3. Enter a name for the role.
4. Enter a description of the role. This is visible on other pages and is optional.
5. Select the access permissions that this role will give the user accounts to which it is assigned. You can mouse over the Permission name for a brief description of the associated user privileges.
6. Click Save.
The definition of the new role is displayed on the Roles and Permissions tab of the Administration > Account Management: User Administration page. After being defined, the role becomes available to be assigned to individual user accounts on the Local Users tab of the Administration > Account Management: User Administration page.
If more than one role is assigned to a user account, the user receives the highest level of privilege available from any of the roles.
Editing a user role
1. Choose Administration > Account Management: User Administration and select the Roles and Permissions tab.
2. Mouse over the row for the role you want to edit. This displays an edit icon (pencil) and a Delete icon. Choose the edit icon to display the Edit Role page.
3. Edit the role definition.
4. Click Apply to make the changes, or click Revert to return to the previous definition.
Password policy
The Account Policy tab enables you to configure global settings that affect all user accounts:
• Allow Empty Passwords
• Minimum Password Length
• Minimum Number of Lowercase Characters
• Minimum Number of Uppercase Characters
• Minimum Number of Digits
• Minimum Number of Symbols
• Maximum Number of Character Repeats
• Minimum Number of Character Changes
• Check the Password For Common Words
• Number of Days a User Must Wait Between Password Change
• Number of Previous Passwords to Check