Configure SSH Multi-Factor Authentication on OneFS Using Duo
Thu, 27 Jan 2022 21:03:07 -0000
|Read Time: 0 minutes
Duo Security at Cisco is a vendor of cloud-based multi-factor authentication (MFA) services. MFA enables security to prevent a hacker from masquerading as an authenticated user. Duo allows an administrator to require multiple options for secondary authentication. With multi-factor authentication, even though a hacker steals the username and password, he cannot be authenticated to a network service easily without a user’s device.
SSH Multi-Factor Authentication (MFA) with Duo is a new feature introduced in OneFS 8.2. Currently, OneFS supports the SSH MFA with Duo service through SMS (short message service), phone callback, and Push notification via the Duo app. This blog describes how to integrate OneFS SSH MFA with the Duo service.
Duo supports many kinds of applications, such as Microsoft Azure Active Directory, Cisco Webex, and Amazon Web Services. For a OneFS cluster, it appears as a "Unix Application" entry. To integrate OneFS with the Duo service, you must configure the Duo service and the OneFS cluster. Before configuring OneFS with Duo, you need to have Duo account. In this blog, we used a trial version account for demonstration purposes.
Failback mode
By default, the SSH failback mode for Duo in OneFS is “safe”, which allows common authentication if the Duo service is not available. The “secure” mode will deny SSH access if the Duo service is not available, including the bypass users, because the bypass users are defined and validated in the Duo service. To configure the failback mode in OneFS, specify the --failmode option using the following command:
# isi auth duo modify --failmode
Exclusion group
By default, all groups are required to use Duo unless the group is configured to bypass Duo auth. The groups option allows you to exclude or specify dedicated user groups from using Duo service authentication. This method provides a way to configure users so they can still SSH into the cluster even when the Duo service is not available and failback mode is set to “secure”. Otherwise, all users may be locked out of the cluster in this situation.
To configure the exclusion group option, add an exclamation character “!” before the group name and preceded by an asterisk to ensure that all other groups use Duo service. For example:
# isi auth duo modify --groups=”*,!groupname”
Note: zsh shell requires the “!” to be escaped. In this case, the example above should be changed to:
# isi auth duo modify --groups=”*,\!groupname”
Prepare the Duo service for OneFS
1. Use your new Duo account to log into the Duo Admin Panel. Select the Application item from the left menu, then click Protect an Application, as shown in Figure 1.
Figure 1 Protect an Application
2. Type “Unix Application” in the search bar. Click Protect this Application to create a new UNIX Application entry.
Figure 2 Search for UNIX Application
3. Scroll down the creation page to find the Settings section. Type a name for the new UNIX Application. Try to use a name that can recognize your OneFS cluster, as shown in Figure 3. In the Settings section, you can also find the Duo’s name normalization setting.
By default, Duo username normalization is not AD aware. This means that it will alter incoming usernames before trying to match them to a user account. For example, "DOMAIN\username", "username@domain.com", and "username" are treated as the same user. For other options, refer to here.
Figure 3 UNIX Application Name
4. Check the required information for OneFS under the Details section, including API hostname, integration key, and secret key, as shown in Figure 4.
Figure 4 Required Information for OneFS
5. Manually enroll a user. In this example, we are creating a user named admin, which is the default OneFS administrator user. Switch the menu item to Users and click the Add User button, as shown in Figure 5. For details about user enrollment in the Duo service, refer to the Duo documentation Enrolling Users.
Figure 5 User Enrollment
6. Type the user name, as shown in Figure 6.
Figure 6 Manually User Enrollment
7. Find the Phones settings in the user page and click the Add Phone button to add a device for the user. See Figure 7.
Figure 7 Add Phone for User
8. Type your phone number.
Figure 8 Add New Phone
9. (optional) If you want to use Duo push authentication methods, you need to install the Duo Mobile app in the phone and activate the Duo Mobile app. As highlighted in Figure 9, click the link to activate the Duo Mobile app.
Figure 9 Activate the Duo Mobile app
The Duo service is now prepared for OneFS. Now let's go on to configure OneFS.
Configuring and verifying OneFS
1. By default, the authentication setting template is set for “any”. To use OneFS with the Duo service, the authentication setting template must not be set to “any” or “custom”. It should be set to “password”, “publickey”, or “both”. In the following example, we are configuring the setting to “password”, which will use user password and Duo for SSH MFA.
# isi ssh modify --auth-settings-template=password
2. To confirm the authentication method, use the following command:
# isi ssh settings view| grep "Auth Settings Template"
Auth Settings Template: password
3. Configure the required Duo service information and enable it for SSH MFA, as shown here. Use the same information as when we set up the UNIX Application in Duo, including API hostname, integration key, and secret key.
# isi auth duo modify --enabled=true --failmode=safe --host=api-13b1ee8c.duosecurity.com --ikey=DIRHW4IRSC7Q4R1YQ3CQ --set-skey Enter skey: Confirm:
4. Verify SSH MFA using the user “admin”. An SMS passcode and the user’s password are used for authentication in this example, as shown in Figure 10.
Figure 10 SSH MFA Verification
You have now completed the configuration on your Duo service portal and OneFS cluster as well! SSH users have to be authenticated with Duo, therefore, you can further strengthen your OneFS cluster security with MFA enabled.
Author: Lieven Lin
Related Blog Posts
OneFS Key Manager Rekey Support
Mon, 24 Jul 2023 19:16:34 -0000
|Read Time: 0 minutes
The OneFS key manager is a backend service that orchestrates the storage of sensitive information for PowerScale clusters. To satisfy Dell’s Secure Infrastructure Ready requirements and other public and private sector security mandates, the manager provides the ability to replace, or rekey, cryptographic keys.
The quintessential consumer of OneFS key management is data-at-rest encryption (DARE). Protecting sensitive data stored on the cluster with cryptography ensures that it’s guarded against theft, in the event that drives or nodes are removed from a PowerScale cluster. DARE is a requirement for federal and industry regulations, ensuring data is encrypted when it is stored. OneFS has provided DARE solutions for many years through secure encrypted drives (SEDs) and the OneFS key management system.
A 256-bit key (MK) encrypts the Key Manager Database (KMDB) for SED and cluster domains. In OneFS 9.2 and later, the MK for SEDs can either be stored off-cluster on a KMIP server or locally on a node (the legacy behavior).
However, there are a variety of other consumers of the OneFS key manager, in addition to DARE. These include services and protocols such as:
Service | Description |
---|---|
CELOG | Cluster event log |
CloudPools | Cluster tier to cloud service |
Electronic mail | |
FTP | File transfer protocol |
IPMI | Intelligent platform management interface for remote cluster console access |
JWT | JSON web tokens |
NDMP | Network data management protocol for cluster backups and DR |
Pstore | Active directory and Kerberos password store |
S3 | S3 object protocol |
SyncIQ | Cluster replication service |
SmartSync | OneFS push and pull replication cluster and cloud replication service |
SNMP | Simple network monitoring protocol |
SRS | Old Dell support remote cluster connectivity |
SSO | Single sign-on |
SupportAssist | Remote cluster connectivity to Dell Support |
OneFS 9.5 introduces a number of enhancements to the venerable key manager, including:
- The ability to rekey keystores. Rekey operation will generate a new MK and re-encrypt all entries stored with the new key.
- New CLI commands and WebUI options to perform a rekey operation or schedule key rotation on a time interval.
- New commands to monitor the progress and status of a rekey operation.
As such, OneFS 9.5 now provides the ability to rekey the MK, irrespective of where it is stored.
Note that when you are upgrading from an earlier OneFS release, the new rekey functionality is only available once the OneFS 9.5 upgrade has been committed.
Under the hood, each provider store in the key manager consists of secure backend storage and an MK. Entries are kept in a SQLite database or key-value store. A provider datastore uses its MK to encrypt all its entries within the store.
During the rekey process, the old MK is only deleted after a successful re-encryption with the new MK. If for any reason the process fails, the old MK is available and remains as the current MK. The rekey daemon retries the rekey every 15 minutes if the process fails.
The OneFS rekey process is as follows:
- A new MK is generated, and internal configuration is updated.
- Any entries in the provider store are decrypted and encrypted with the new MK.
- If the prior steps are successful, the previous MK is deleted.
To support the rekey process, the MK in OneFS 9.5 now has an ID associated with it. All entries have a new field referencing the MK ID.
During the rekey operation, there are two MK values with different IDs, and all entries in the database will associate which key they are encrypted by.
In OneFS 9.5, the rekey configuration and management is split between the cluster keys and the SED keys:
Rekey component | Detail |
---|---|
SED |
|
Cluster |
|
SED keys rekey
The SED key manager rekey operation can be managed through a DARE cluster’s CLI or WebUI, and it can either be automatically scheduled or run manually on demand. The following CLI syntax can be used to manually initiate a rekey:
# isi keymanager sed rekey start
Alternatively, to schedule a rekey operation, for example, to schedule a key rotation every two months:
# isi keymanager sed rekey modify --key-rotation=2m
The key manager status for SEDs can be viewed as follows:
# isi keymanager sed status Node Status Location Remote Key ID Key Creation Date Error Info(if any) ----------------------------------------------------------------------------- 1 LOCAL Local 1970-01-01T00:00:00 ----------------------------------------------------------------------------- Total: 1
Alternatively, from the WebUI, go to Access > Key Management > SED/Cluster Rekey, select Automatic rekey for SED keys, and configure the rekey frequency:
Note that for SED rekey operations, if a migration from local cluster key management to a KMIP server is in progress, the rekey process will begin once the migration is complete.
Cluster keys rekey
As mentioned previously, OneFS 9.5 also supports the rekey of cluster keystore domains. This cluster rekey operation is available through the CLI and the WebUI and may either be scheduled or run on demand. The available cluster domains can be queried by running the following CLI syntax:
# isi keymanager cluster status Domain Status Key Creation Date Error Info(if any) ---------------------------------------------------------- CELOG ACTIVE 2023-04-06T09:19:16 CERTSTORE ACTIVE 2023-04-06T09:19:16 CLOUDPOOLS ACTIVE 2023-04-06T09:19:16 EMAIL ACTIVE 2023-04-06T09:19:16 FTP ACTIVE 2023-04-06T09:19:16 IPMI_MGMT IN_PROGRESS 2023-04-06T09:19:16 JWT ACTIVE 2023-04-06T09:19:16 LHOTSE ACTIVE 2023-04-06T09:19:11 NDMP ACTIVE 2023-04-06T09:19:16 NETWORK ACTIVE 2023-04-06T09:19:16 PSTORE ACTIVE 2023-04-06T09:19:16 RICE ACTIVE 2023-04-06T09:19:16 S3 ACTIVE 2023-04-06T09:19:16 SIQ ACTIVE 2023-04-06T09:19:16 SNMP ACTIVE 2023-04-06T09:19:16 SRS ACTIVE 2023-04-06T09:19:16 SSO ACTIVE 2023-04-06T09:19:16 ---------------------------------------------------------- Total: 17
The rekey process generates a new key and re-encrypts the entries for the domain. The old key is then deleted.
Performance-wise, the rekey process does consume cluster resources (CPU and disk) as a result of the re-encryption phase, which is fairly write-intensive. As such, a good practice is to perform rekey operations outside of core business hours or during scheduled cluster maintenance windows.
During the rekey process, the old MK is only deleted once a successful re-encryption with the new MK has been confirmed. In the event of a rekey process failure, the old MK is available and remains as the current MK.
A rekey may be requested immediately or may be scheduled with a cadence. The rekey operation is available through the CLI and the WebUI. In the WebUI, go to Access > Key Management > SED/Cluster Rekey.
To start a rekey of the cluster domains immediately, from the CLI run the following syntax:
# isi keymanager cluster rekey start Are you sure you want to rekey the master passphrase? (yes/[no]):yes
Alternatively, from the WebUI, go to Access under the SED/Cluster Rekey tab, and click Rekey Now next to Cluster keys:
A scheduled rekey of the cluster keys (excluding the SED keys) can be configured from the CLI with the following syntax:
# isi keymanager cluster rekey modify –-key-rotation [YMWDhms]
Specify the frequency of the Key Rotation field as an integer, using Y for years, M for months, W for weeks, D for days, h for hours, m for minutes, and s for seconds. For example, the following command will schedule the cluster rekey operation to run every six weeks:
# isi keymanager cluster rekey view Rekey Time: 1970-01-01T00:00:00 Key Rotation: Never # isi keymanager cluster rekey modify --key-rotation 6W # isi keymanager cluster rekey view Rekey Time: 2023-04-28T18:38:45 Key Rotation: 6W
The rekey configuration can be easily reverted back to on demand from a schedule as follows:
# isi keymanager cluster rekey modify --key-rotation Never # isi keymanager cluster rekey view Rekey Time: 2023-04-28T18:38:45 Key Rotation: Never
Alternatively, from the WebUI, under the SED/Cluster Rekey tab, select the Automatic rekey for Cluster keys checkbox and specify the rekey frequency. For example:
In an event of a rekeying failure, a CELOG KeyManagerRekeyFailed or KeyManagerSedsRekeyFailed event is created. Since SED rekey is a node-local operation, the KeyManagerSedsRekeyFailed event information will also include which node experienced the failure.
Additionally, current cluster rekey status can also be queried with the following CLI command:
# isi keymanager cluster status Domain Status Key Creation Date Error Info(if any) ---------------------------------------------------------- CELOG ACTIVE 2023-04-06T09:19:16 CERTSTORE ACTIVE 2023-04-06T09:19:16 CLOUDPOOLS ACTIVE 2023-04-06T09:19:16 EMAIL ACTIVE 2023-04-06T09:19:16 FTP ACTIVE 2023-04-06T09:19:16 IPMI_MGMT ACTIVE 2023-04-06T09:19:16 JWT ACTIVE 2023-04-06T09:19:16 LHOTSE ACTIVE 2023-04-06T09:19:11 NDMP ACTIVE 2023-04-06T09:19:16 NETWORK ACTIVE 2023-04-06T09:19:16 PSTORE ACTIVE 2023-04-06T09:19:16 RICE ACTIVE 2023-04-06T09:19:16 S3 ACTIVE 2023-04-06T09:19:16 SIQ ACTIVE 2023-04-06T09:19:16 SNMP ACTIVE 2023-04-06T09:19:16 SRS ACTIVE 2023-04-06T09:19:16 SSO ACTIVE 2023-04-06T09:19:16 ---------------------------------------------------------- Total: 17
Or, for SEDs rekey status:
# isi keymanager sed status Node Status Location Remote Key ID Key Creation Date Error Info(if any) ----------------------------------------------------------------------------- 1 LOCAL Local 1970-01-01T00:00:00 2 LOCAL Local 1970-01-01T00:00:00 3 LOCAL Local 1970-01-01T00:00:00 4 LOCAL Local 1970-01-01T00:00:00 ----------------------------------------------------------------------------- Total: 4
The rekey process also outputs to the /var/log/isi_km_d.log file, which is a useful source for additional troubleshooting.
If an error in rekey occurs, the previous MK is not deleted, so entries in the provider store can still be created and read as normal. The key manager daemon will retry the rekey operation in the background every 15 minutes until it succeeds.
Author: Nick Trimbee
OneFS Password Security Policy
Mon, 24 Jul 2023 20:08:49 -0000
|Read Time: 0 minutes
Among the slew of security enhancements introduced in OneFS 9.5 is the ability to mandate a more stringent password policy. This is required to comply with security requirements such as the U.S. military STIG, which stipulates:
Requirement | Description |
---|---|
Length | An OS or network device must enforce a minimum 15-character password length. |
Percentage | An OS must require the change of at least 50% of the total number of characters when passwords are changed. |
Position | A network device must require that when a password is changed, the characters are changed in at least eight of the positions within the password. |
Temporary password | The OS must allow the use of a temporary password for system logons with an immediate change to a permanent password. |
The OneFS password security architecture can be summarized as follows:
Within the OneFS security subsystem, authentication is handled in OneFS by LSASSD, the daemon used to service authentication requests for lwiod.
Component | Description |
---|---|
LSASSD | The local security authority subsystem service (LSASS) handles authentication and identity management as users connect to the cluster. |
File provider | The file provider includes users from /etc/password and groups from /etc/groups. |
Local provider | The local provider includes local cluster accounts such as anonymous, guest, and so on. |
SSHD | The OpenSSH Daemon provides secure encrypted communications between a client and a cluster node over an insecure network. |
pAPI | The OneFS Platform API provides programmatic interfaces to OneFS configuration and management through a RESTful HTTPS service. |
In OneFS AIMA, there are several different kinds of backend providers: Local provider, file provider, AD provider, NIS provider, and so on. Each provider is responsible for the management of users and groups inside the provider. For OneFS password policy enforcement, the local and file providers are the focus.
The local provider is based on an SamDB style file stored with prefix path of /ifs/.ifsvar, and its provider settings can be viewed by the following CLI syntax:
# isi auth local view System
On the other hand, the file provider is based on the FreeBSD spwd.db file, and its configuration can be viewed by the following CLI command:
# isi auth file view System
Each provider stores and manage its own users. For the local provider, isi auth users create CLI command will create a user inside the provider by default. However, for the file provider, there is no corresponding command. Instead, the OneFS pw CLI command can be used to create a new file provider user.
After the user is created, the isi auth users modify <USER> CLI command can be used to change the attributes of the user for both the file and local providers. However, not all attributes are supported for both providers. For example, the file provider does not support password expiry.
The fundamental password policy CLI changes introduced in OneFS 9.5 are as follows:
Operation | OneFS 9.5 change | Details |
---|---|---|
change-password | Modified | Needed to provide old password for changing so that we can calculate how many chars/percent changed |
reset-password | Added | Generates a temp password that meets current password policy for user to log in |
set-password | Deprecated | Doesn't need to provide old password |
A user’s password can now be set, changed, and reset by either root or admin. This is supported by the new isi auth users change-password or isi auth users reset-password CLI command syntax. The latter, for example, returns a temporary password and requires the user to change it on next login. After logging in with the temporary (albeit secure) password, OneFS immediately forces the user to change it:
# whoami admin # isi auth users reset-password user1 4$_x\d\Q6V9E:sH # ssh user1@localhost (user1@localhost) Password: (user1@localhost) Your password has expired. You are required to immediately change your password. Changing password for user1 New password: (user1@localhost) Re-enter password: Last login: Wed May 17 08:02:47 from 127.0.0.1 PowerScale OneFS 9.5.0.0 # whoami user1
Also in OneFS 9.5 and later, the CLI isi auth local view system command sees the addition of four new fields:
- Password Chars Changed
- Password Percent Changed
- Password Hash Type
- Max Inactivity Days
For example:
# isi auth local view system Name: System Status: active Authentication: Yes Create Home Directory: Yes Home Directory Template: /ifs/home/%U Lockout Duration: Now Lockout Threshold: 0 Lockout Window: Now Login Shell: /bin/zsh Machine Name: Min Password Age: Now Max Password Age: 4W Min Password Length: 0 Password Prompt Time: 2W Password Complexity: - Password History Length: 0 Password Chars Changed: 0 Password Percent Changed: 0 Password Hash Type: NTHash Max Inactivity Days: 0
The following CLI command syntax configures OneFS to require a minimum password length of 15 characters, a 50% or greater change, and 8 or more characters to be altered for a successful password reset:
# isi auth local modify system --min-password-length 15 --password-chars-changed 8 --password-percent-changed 50
Next, a command is issued to create a new user, user2, with a 10-character password:
# isi auth users create user2 --password 0123456789 Failed to add user user1: The specified password does not meet the configured password complexity or history requirements
This attempt fails because the password does not meet the configured password criteria (15 chars, 50% change, 8 chars to be altered).
Instead, the password for the new account, user2, is set to an appropriate value: 0123456789abcdef. Also, the --prompt-password-change flag is used to force the user to change their password on next login.
# isi auth users create user2 --password 0123456789abcdef –prompt-password-change 1
When the user logs in to the user2 account, OneFS immediately prompts for a new password. In the following example, a non-compliant password (012345678zyxw) is entered.
0123456789abcdef -> 012345678zyxw = Failure
This returns an unsuccessful change attempt failure because it does not meet the 15-character minimum:
# su user2 New password: Re-enter password: The specified password does not meet the configured password complexity requirements. Your password must meet the following requirements: * Must contain at least 15 characters. * Must change at least 8 characters. * Must change at least 50% of characters. New password:
Instead, a compliant password and successful change could be:
0123456789abcdef -> 0123456zyxwvuts = Success
The following command can also be used to change the password for a user. For example, to update user2’s password:
# isi auth users change-password user2 Current password (hit enter if none): New password: Confirm new password:
If a non-compliant password is entered, the following error is returned:
Password change failed: The specified password does not meet the configured password complexity or history requirements
When employed, OneFS hardening automatically enforces security-based configurations. The hardening engine is profile-based, and its STIG security profile is predicated on security mandates specified in the U.S. Department of Defense (DoD) Security Requirements Guides (SRGs) and Security Technical Implementation Guides (STIGs).
On applying the STIG hardening security profile to a cluster (isi hardening apply --profile=STIG), the password policy settings are automatically reconfigured to the following values:
Field | Normal value | STIG hardened |
---|---|---|
Lockout Duration | Now | Now |
Lockout Threshold | 0 | 3 |
Lockout Window | Now | 15m |
Min Password Age | Now | 1D |
Max Password Age | 4W | 8W4D |
Min Password Length | 0 | 15 |
Password Prompt Time | 2W | 2W |
Password Complexity | - | lowercase, numeric, repeat, symbol, uppercase |
Password History Length | 0 | 5 |
Password Chars Changed | 0 | 8 |
Password Percent Changed | 0 | 50 |
Password Hash Type | NTHash | SHA512 |
Max Inactivity Days | 0 | 35 |
For example:
# uname -or Isilon OneFS 9.5.0.0 # isi hardening list Name Description Status --------------------------------------------------- STIG Enable all STIG security settings Applied --------------------------------------------------- Total: 1 # isi auth local view system Name: System Status: active Authentication: Yes Create Home Directory: Yes Home Directory Template: /ifs/home/%U Lockout Duration: Now Lockout Threshold: 3 Lockout Window: 15m Login Shell: /bin/zsh Machine Name: Min Password Age: 1D Max Password Age: 8W4D Min Password Length: 15 Password Prompt Time: 2W Password Complexity: lowercase, numeric, repeat, symbol, uppercase Password History Length: 5 Password Chars Changed: 8 Password Percent Changed: 50 Password Hash Type: SHA512 Max Inactivity Days: 35
Note that Password Hash Type is changed from the default NTHash to the more secure SHA512 encoding, in addition to setting the various password criteria.
The OneFS 9.5 WebUI also sees several additions and alterations to the Password policy page. These include:
Operation | OneFS 9.5 change | Details |
---|---|---|
Policy page | Added | New Password policy page under Access > Membership and roles |
reset-password | Added | Generates a random password that meets current password policy for user to log in |
The most obvious change is the transfer of the policy configuration elements from the local provider page to a new dedicated Password policy page.
Here’s the OneFS 9.4 View a local provider page, under Access > Authentication providers > Local providers > System:
This is replaced and augmented in the OneFS 9.5 WebUI with the following page, located under Access > Membership and roles > Password policy:
New password policy configuration options are included to require uppercase, lowercase, numeric, or special characters and limit the number of contiguous repeats of a character, and so on.
When it comes to changing a password, only a permitted user can make their change. This can be performed from a couple of locations in the WebUI. First, the user options on the task bar at the top of each screen now provides a Change password option:
A pop-up warning message will also be displayed by the WebUI, informing the user when password expiration is imminent. This warning provides a Change Password link:
Clicking on the Change Password link displays the following page:
A new password complexity tool-tip message is also displayed, informing the user of safe password selection.
Note that re-login is required after a password change.
On the Users page under Access > Membership and roles > Users, the Action drop-down list on the now also contains a Reset Password option:
The successful reset confirmation pop-up offers both a show and copy option, while informing the cluster administrator to share the new password with the user, and for them to change their password during their next login:
The Create user page now provides an additional field that requires password confirmation. Additionally, the password complexity tool-tip message is also displayed:
The redesigned Edit user details page no longer provides a field to edit the password directly:
Instead, the Action drop-down list on the Users page now contains a Reset Password option.
Author: Nick Trimbee