nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Component react.community-search had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.

System Manager uses Passkey for MFA when using local accounts

MarktheSpark

Hello All,

I've been investigating implementing MFA on our FAS/AFF systems. We took the active decision to use local accounts on these systems so that a compromise of our Active Directory didn't also result in access to our storage estate.

Generally, I logon via SSH and setting up TOTP MFA is pretty simple and works ok. But for HTTPS access, there is no documented way to add MFA to a local account logging in via HTTPS, at least not that I could find but I'm happy to be corrected. However, in System Manager, there the option to add MFA to the account is presented; so I tried on our test system. I was expecting to get a QR code to scan to add TOTP but instead my password manager prompted me to save a Passkey. I was a little surprise.

Now when I login, I always have to provide a password and passkey. So in principle, this meets the 2FA requirement. I just have to persuade our auditors that this is a Cyber Essentials compliant method.

Just wondering if anyone else has gone down this route and what success they've had with their auditors.

Regards,

Mark

Find more posts tagged with

Multifactor Authentication (MFA)

Comments

OGill

I don't know about security audit requirements (but FIDO2 is mentioned here and here).

In general FIDO2 (together with WebAuthn) is much more secure than utilizing TOTP for several reasons (the Internet is full of it). Yes, currently TOTP is not possible with System Manager but I would recommend using FIDO2 anyways.

We have tested it extensively and it works really well so far. We mainly used it with hardware tokens like YubiKey but generally you could use any authenticator that the operating system supports. It also works with Windows Hello and also with other password managers like Bitwarden. It even worked when saving the passkey to your phone. In the MFA dialogue of Windows you need to choose your phone (I think we only tested it with Android) and then make sure your phone and the machine where you're connected to the System Manager are close by because it is utilizing Bluetooth Low Energy to make sure your are not remotely connected.

It even works for Citrix and regular RDP since the MFA dialogues are redirected to your local device.

The most important part is using current operation system and browser versions. For Windows 11 you need at least 23H2 (but it's much better and more stable with 24H2+). We've tested it with Edge, Chrome, Firefox and Safari and it works well (earlier Firefox versions have issues, use the latest).

One caveat though: Currently you can only register one passkey per ONTAP user. So you can't configure a second hardware authenticator and keep it as backup. But this is no show stopper since other admins can reset your MFA token so next time you login you need to re-register it. Also always configure a break-glass user so you can still get in in case of emergency. (Also with SSH you can configure multiple MFA tokens per users so a user who lost his primary token can still login via SSH with his backup token.)

I hope NetApp changes that - no idea why they chose that implementation.

Another caveat: You can't really use System Manager with WebAuthn passwordless. It's configured in ONTAP that FIDO2 will always be the second factor only. When you're talking about passkeys you're often using a passwordless approach where you only need your authenticator plus the FIDO2 PIN (or any biometric). So there is no password to phish. That's currently not possible with the WebAuthn implementation of ONTAP since you always need to provide a password for the first authentication-method (you could switch that to "domain" but then you still need to password of the domain-user).

And lastely: There is a known vulnerability to bypass the second factor with WebAuthn.
https://security.netapp.com/advisory/NTAP-20260722-0001

It's fixed only in ONTAP 9.19.1. For 9.16.1-9.18.1 you need to set a bootargs as a workaround:

https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-Issues/CONTAP-597688

Generally beginning with 9.19.1 before you configure MFA via WebAuthn you need to first set the relying party (RP) domain. So usually the FQDN of the cert which System Manager is using. Otherwise the configuration will fail during MFA registration but the error message is not clear what is the issue.

MarktheSpark

Hi OGill,

Thank you so much for this comprehensive reply, I really appreciate it. I hadn't appreciated that passkeys are FIDO2 compliant, please excuse my ignorance. But every day is a school day :)

I did some testing on Friday and like you have been very impressed with how passkeys work as a second factor in System Manager. We use 1Password here and integration with that worked well. Even working with the 1Password app on my phone when logging into a browser without the extension and using my phone as to provide the passkey. I think that will keep our security team happy and hopefully our auditors too, although perhaps they will need a little education.

Noting you comments regarding TOTP, I'll investigate using DUO for our SSH logins. I already password protect my SSH key and encourage other users to do likewise but can't enforce that.

Regarding the break-glass account. Do you limit this to console access only? I'm thinking that enforces MFA for all remote accounts. I've not looked at service process access yet, but hope we can enforce MFA there too.

Thanks for the comments on the relying party; I had noted the need for a proper certificate. It's just a shame that the MAV requests include the node IP address, as users following those links get errors during login and have to replace the IP address with the FQDN.

Mark

OGill

DUO is one way for SSH but you can also use FIDO2 for SSH - it's public key encryption anyways.

This TR is a bit old but still works fine: https://www.netapp.com/pdf.html?item=/media/17055-tr4647.pdf

You either need a special PuTTY fork named PuTTY CAC ( https://github.com/nomorefood/putty-cac ) or simply OpenSSH which often is already included in newer versions of Windows. Since they are utilizing the same FIDO2 framework you will get the same FIDO2 popups from your operating system. Bonus: You can configure multiple MFA tokens (aka public keys) per user.

For the break-glass user we usually allow console and SP access. And make sure that the regular user accounts only include HTTP and SSH since imo SP is not needed for daily activities.

Console is the only access which does not support MFA. With newer hardware models you can also protect the SP with MFA. So in theory you could also add SP access for your regular users as long as it's also protected by MFA but I don't think it's necessary.
For the SP access of the break-glass user I would also not really use MFA but a long enough PW. It's break-glass anyways so with MFA you would also need to put the hardware token in the same safe together with the credentials… so not much use imo. Also in case of emergency you don't want to hassle with MFA.

Of course if you save everything in 1Password you could also put the passkey there - maybe even for the break-glass user. But then you're always dependent on your password manager which does not really satisfy the break-glass requirements (credentials privileged admins can use in case of emergency without any other dependencies).

It's just a shame that the MAV requests include the node IP address, as users following those links get errors during login and have to replace the IP address with the FQDN.

Oh I didn't know that, have to try.