Why does the login page even require a "username"?

[danb35]

If one of them is malicious, it's a matter of who can change the root password first, or who can revoke access to the other three users first.

But if one of them is fired, or leaves of his own accord, his account can be terminated without affecting the others (and I think it's common practice, before firing someone, to revoke any access credentials first). And in principle (though I don't believe FreeNAS does this) the system can log who did what, so there's an audit trail (and it'd be implicit that anyone other than root wouldn't be able to clear it). So yes, I think there would be value in supporting multiple users, even if all had the same permissions once logged in.

Of course, the real goal would be multiple users with configurable permissions, but neither FreeNAS nor TrueCommand gives you that. TrueCommand does give you multiple users, as many as you like, but they all have the same permissions.

But none of that really addresses your question, which I understand to be "given that there's only one username that can possibly log in, why prompt for the username on the login screen?" The best answers I can think of are inertia and convention.

 

[winnielinnie]

But none of that really addresses your question, which I understand to be "given that there's only one username that can possibly log in, why prompt for the username on the login screen?" The best answers I can think of are inertia and convention.

And this is the crux of my issue. If the FreeNAS / TrueNAS appliance will only ever allow you to access the GUI as root (by design; admitted by iXsystems; no other username accepted), then the username field should be removed for the sake of streamlining and aesthetics, without any additional risks or costs to this improvement of the login page. It also removes the confusion to some newcomers as to "Oh, I can type in a different user? Maybe I'll make bob an admin too?" This is why I made the ticket on Jira.

 

[subhuman]

Heck, even Google essentially lets you know if you've entered a real account name before you can even attempt to enter a password.

Really? You're going there?
I don't expect a company that makes its money from harvesting user data will be making a serious effort to help people secure that data. The limit of my trust for just about any company is I trust them to put their own interests ahead of mine or yours.

Separate ack for both parts of a login is bad. Period. Just look at WPS, which effectively does that by breaking the first 4 and the last 3 digits of the PIN into separate acks, reducing the maximum brute-force attempts from ten million down to eleven thousand. As it sits, WPS is trivial to crack, but if it wasn't acked separately it would take over 900x longer.

No discussion of password strength and security puts emphasis on the username.

What I stated before is a mathematical certainty.
So, while security discussions may not cover it, but meanwhile University math departments continue to pump out paper after paper about exploiting weaknesses in security practices. Let's just keep on doing what we've been doing, and continue to be surprised when it's not secure.

The same reasoning can be used to justify a third, fourth, fifth, etc, input field.

Exactly. I've done that in the past, required a second password for a non-local admin login. Sorry, but this time your example fell flat on its face :)

This brings me back to the redundancy of a username field in the login page of FreeNAS / TrueNas: iXsystems explicitly designed the appliance to be administered by the root user, and only the root user.

And I still disagree with you. I still think the request should be to allow non-root logins, rather than requesting the user field be removed.

 

[danb35]

I still think the request should be to allow non-root logins

I more reasonable request IMO, but iX have repeatedly shot it down.

 

[Spearfoot]

I'm surprised to hear that it's ever been otherwise, to the point that I'm having trouble believing you. The question has come up here many times in the past, and the answer (including from folks at iX) has always been, "only root can log in". See:

Change GUI login User

I'm pretty new to FreeNAS and I want to be able to login to the FreeNAS 11.2 UI using a user rather than the default root user. I have added a user to the wheel group (which I thought was the needed group) but no luck. What settings do I need to change to allow for the different login user? Thanks

www.ixsystems.com

SOLVED - Is root user the only credentials that can access GUI?

Hi there, So, I would like to setup FreeNAS to be accessible from outside my local network by means of HTTPS: and port forwarding. My concern is, which users are able to access the GUI? I have tried my own user created accounts and see that they cannot login to the GUI. But, I would like to put...

www.ixsystems.com

LDAP for local account login

so im trying to learn Open LDAP and have the server set up. I can authenticate a linux client and pfsense fine. and can even gain sudo in linux and can manage my pfsense box with my user as if I logged in as admin. I am trying to do the same for freenas but can't get it to work. if I go to...

www.ixsystems.com

FreeNas GUI Query, Automate Installation, Configuration Backup

Hi All, We are using FreeNAS for our Serverpack35 devices. We need your help and support to clarify some doubts. Can we configure GUI for multiple users and give respective role and permission to them? How to automate the FreeNAS installation and Configuration? How to take a backup of FreeNAS...

www.ixsystems.com

In this last thread, neither Dru (whose account has apparently been deleted) nor the TC project lead indicate that there's any way to use different users other than using TrueCommand.

The manual concurs. 11.3, "the password for the root user is requested.":

3. Booting — FreeNAS®11.3-U3.2 User Guide Table of Contents

www.ixsystems.com

11.2-U6 (the last 11.2 series manual available), "Enter the password for the root user":

3. Booting — FreeNAS®11.2-U6 User Guide Table of Contents

www.ixsystems.com

11.1-U7, "The password for the root user is requested":

3. Booting — FreeNAS®11.1-U7 User Guide Table of Contents

www.ixsystems.com

Your post is the first suggestion I've seen in nine years here that anyone other than root can, or has ever been able to, log in to the web GUI under any circumstances. This may call for some testing.

Edit: so I've done some testing. Did a fresh install of 11.2-U8 in a VM, logged into the new (default) GUI, and created a new user called "fred." Gave him sudo access (checked that box), added him to the wheel group, and gave him a password. Logged out as root and tried to log in as fred. "Your username or password is incorrect."

Yep, I tried it too and only the superuser can log on to the GUI. I flubbed the dub.

 

[Tsaukpaetra]

I could see the ability to log in as non-root useful in the context of, perhaps, changing your password in the system, starting a shell, and (if it were ever developed) permission-based access to specific areas (i.e. allowed to view VMs and turn them on/off but not create or edit them).

As it stands, I doubt there will be any effort into creating such a permission system and there's no way for a user to self-service their account in this manner, so I kinda agree that removing or pre-filling root into the username field could be a simple ask.

But, in my opinion, if you have ne'er do wells trying to hack into your system via the FreeNAS GUI, they'd probably be better off using more mundane methods anyways... Also why are randos being allowed to access your GUI?

 

[mistermanko]

I'd like to share a positive example to @winnielinnies point. pi-hole
It needs root privileges and requires you to only type in a password to gain access to the GUI - simple and sufficient.

 

[HoneyBadger]

There was a ticket open in the old system for implementing RBAC in the middleware layer.

https://redmine.ixsystems.com/issues/25071

Unfortunately it looks like while it started as a priority, it was lowered and then closed.

Implementing RBAC may seem like a minor change but it will require the creation of an auth framework and then shimming basically every action in the middleware with a call to "auth_framework" to see if the user in question is permitted to read/write the data. Picture a kiddie pool the size of the Atlantic Ocean; it's easy to touch the bottom, but it'll take a long time to wade across.

 

[winnielinnie]

I'd like to share a positive example to @winnielinnies point. pi-hole
It needs root privileges and requires you to only type in a password to gain access to the GUI - simple and sufficient.

Clean, easy to implement, and removes any ambiguity of "Who else can I login as? Can I create another admin account? Are there differences in permissions based on the username I enter?" The Pi-Hole team did it right, and it looks simple, yet polished.

@mistermanko you're not worried someone can easily break into your Pi-Hole setup because they don't need to guess a username? They only need to correctly guess your passphrase? Aren't you worried? /s

Also why are randos being allowed to access your GUI?

Exactly. If you find yourself in a situation where random, malicious people (who have local access to your system somehow), have the luxury to keep attempting guesses at the username/password combination, well... you have other, more serious problems you need to address. Don't worry about calculating passphrase strength and the extra security of guessing a six-character username. Let's also assume you don't have the GUI portal exposed to the internet, either.

EDIT: If the iXsystems team is putting their foot down in only ever allowing "root" to access the GUI, then any arguments for authentication and permissions based on different accounts becomes a moot point. I'm not saying they're bad ideas. In fact, they would only enhance TrueNAS overall. I'm just saying that it's a moot point since it appears iXsystems already made up their mind, for whatever reason. Hence, why I question the redundancy (and potential confusion) of the current login page.

 

[winnielinnie]

And this is the crux of my issue. If the FreeNAS / TrueNAS appliance will only ever allow you to access the GUI as root (by design; admitted by iXsystems; no other username accepted), then the username field should be removed for the sake of streamlining and aesthetics, without any additional risks or costs to this improvement of the login page. It also removes the confusion to some newcomers as to "Oh, I can type in a different user? Maybe I'll make bob an admin too?" This is why I made the ticket on Jira.

I felt I might as well quote and reply to myself. Bold emphasis added.

Can't log in after update

The first time I installed I set a username and password. I was never able to log into the web GUI. So I reinstalled and did not set a username or password. The first time I accessed the web GUI it forced me to set a password. I then proceeded to install updates. Now I can not log into the web...

www.truenas.com

Unashamedly asking for others to vote on this issue if they agree with the reasoning I laid out:

https://jira.ixsystems.com/browse/NAS-106603

• TrueNAS only allows "root" to be entered; now and the foreseeable future?
  • If true, then...
  • ...remove the username input field from the Web GUI login page
• TrueNAS will soon allow multiple users to access the Web GUI?
  • If true then...
  • ...leave the login page as it is, but implement a mechanism to allow non-root logins

As everything appears now, I still stand by this feature request in order to remain congruent with iXsystems's implementation. If they refuse to allow anything other than "root" to be used in the login page, they must be consistent like other appliances and remove the username input field. (See my above example with Pi-Hole.)

• This will yield a cleaner and more streamlined login page.

• Removes any confusion and/or hopes of multiuser logins or multiple "admin" accounts.

• For those who do not save their browser's passwords, they can quickly type in their password to login, rather than redundantly entering "root" before their password every single time they open the login page.

 

[danb35]

I don't believe they "must" do this. Many appliances work as you describe, and doubtless many others don't. iX doesn't have a whole lot to compare to, and there's no particular reason they need to be consistent with products from other vendors. But with that said, I think it would be a good change and have voted for the issue.

 

[winnielinnie]

Honestly, all else being equal, I too would have preferred (like others in this thread) for TrueNAS to support "admin" accounts and alternative "privileged" usernames for the login. As others have mentioned, it could be used for auditing reasons as well.

But it's a moot point now (and the foreseeable future). So in the spirit of a streamlined login screen and less confusion about "Oh, I can enter a username to login?", it's preferable to remove the username prompt, as it is redundant.

For the same reason we're not prompted to also input the server's IP address or hostname every time we login. There's no point to it. If a login screen is prompting for your username, it implies a feature of logging in with a particular username.

Welcome to TrueNAS! Please login.
[ enter the hostname ] <--- "Silly. How pointless!"
[ enter the IP address ] <--- "Silly. How pointless!"
[ enter your username] <--- "You mean always type in root? That's... not pointless at all...."
[ enter your password ]

 

[danb35]

less confusion about "Oh, I can enter a username to login?"

I have to admit that I don't have a lot of sympathy for the confusion--it's not like this isn't well documented. And the folks who complain most tend to be like the OP in the thread you just linked to, who thinks it's somehow TrueNAS' fault that his PC won't boot without a keyboard attached (but he's since moved to a "better server OS" because our resident grinch is mean).

Yes, I think the username field is redundant, and I agree that removing it would provide a better UX. But seriously, a little RTFM would solve most of these problems.