Should we disable “admin” account?

[glad silo]

My understanding is we cannot disable it or make any changes on it’s privileges, if that’s true,
Should we concern about it for any security reasons?

Any docs on the recommendation of if we should or shouldn’t disable ?

[night comet]

it is used to configure the system. basically the "root" (Linux) or "Administrator" (windows) equivalent. if you disable it, you need a new user with the same privileges, so you've basically just renamed the admin account. Some people claim this improves security but YMMV.

what you could do instead is give the admin a secret password that's only stored in a safe, and create multiple named admins for people to use. You probably still need at least one user with full privileges though as it is used for many things (application integration for example)

[glad silo]

Every one of cluster administrators has all “admin “ privileges, what are reasons we need this “admin” account?

[night comet]

yeah that's basically what I just said 🙂 you can have named admins with that permission. But it doesn't necessarily increase security, that continues to depend on your password strength

and since you cannot deactivate the account AFAIK, all you can do is give it a strong password and store that somewhere

[sinful pumice]

you can indeed deactivate the builtin admin-Account

we do on our systems after our named admin-Accounts are created

[night comet]

ah good to know. it probably checks whether you have at least one other account with the admin role

[sinful pumice]

yes that it does, once got the message that I can only deactivate after having another one, there is a security measure

[night comet]

yeah makes sense so you don't lock yourself out. But I'd still argue that from a security standpoint it's not much different than giving the admin user a long secure password and storing that in a safe somewhere (which is what our customers usually do)

[sinful pumice]

agreed, just was a KPI in our security evaluation to disable the default admin, wasn't in the mood to argue about security through obscurity

[glad silo]

The concern here is a hacker may somehow sneak in by using the “admin” account, then in this scenarios, the strong password may not matter. So, to satisfy those are worried about “admin”, I probably just go ahead with disabling it. Make sense?

Will it be re-enabled after an ONTAP upgrade?

[sly smelt]

no, it wont

you have to manually enable it again

if you deploy a system via BlueXP, it forces you to create an account with admin rights and the built in account is set to disabled by default

[glad silo]

ChatGPT said this: Yes, ONTAP reinstates the admin account post–upgrade/reboot.

[distant bolt]

I can confirm it does not reinstate the admin account. We've disabled ours long back and have gone through multiple upgrades.

[glad silo]

ChatGPT has been wrong on me multiple times. This is another one:

[night comet]

maybe don't use LLMs as replacement for a search engine? Just a suggestion

[night comet]

what do you mean by "sneak in"? What prevents the hacker from "sneaking in" by using another account?

and you can't really "sneak into" a system without knowing or guessing the password, so yeah, strong passwords absolutely do matter

[sly smelt]

probably meaning it's easier to use an account that is known, all you need to find is the password

[coral vault]

When we secure systems for government, the typical process includes:

1. Creating the ability for domain logins only
2. Local accounts are not to be used
3. Create a “break glass” account in case of emergencies (password kept in safe. No one is supposed to know the password)
4. After verifying access with the above, lock the admin account so it can not be used
5. Additionally, some customers remove methods from the admin login (like ssh/ontapi/http) so that it is truly a local account only, still locked though.

The point is to remove a known entity from brute force attacks. Many platforms have an “admin” or “administrator” account. Removing/renaming on ONTAP is not possible. You can only lock it

[coral vault]

And ChatGPT is never wrong…

[glad silo]

One thing is not clear to me: the brute force attacks can sneak in just due to the existence of “admin” account, in this scenarios, a strong password would not stop them, or they would have to figure out what the password is first, then to use it to get in?

[night comet]

that's why I was asking you what you mean by "sneak in"? You cannot get into the system without the password (obviously). So maybe I'm just lost in translation here but what exactly do you mean?

[sinful pumice]

Well this puts the security into the Active Directory which is notoriously the first thing hackers attack.
We use local personalized users with 2FA whereever possible in our storage systems and have no AD integration going for Admin Login.

[night comet]

yeah, we also suggest to our customers to not use domain login but instead local accounts for security reasons. But most of them do not have the large security task force teams that govt. installations have (I presume)

[coral vault]

Realize there is a lot more to the process including a lot more securing of Active Directory.
The beginning of this was about disabling admin.

That can be done. You just need other accounts to access as an admin. Be it local or be it remote or even remote with multi factor…that was the topic

The Fed’s require nearly everything with non local accounts I suspect mainly for logging and control purposes

With local accounts someone needs to manage potentially many local points. With AD you create one or more security groups with access to the Netapp and set your controls there. In large organizations, people come and go all the time. This minimizes user updates falling through cracks at the edge.