SOLVED TrueNAS-SCALE: How to create a user granted with a privilege of Local Administrator?

[winnielinnie]

We've updated the docs as well to explain this process in more detail.

Is this destined to land in Core as well, or is it only for SCALE?

 

[Patrick M. Hausen]

Actually, starting with Bluefin it is. If you disable password for root user, like you do, you will not be able to login with root user into UI. In Angelfish you can. People were complaining into forums they cannot login into UI anymore with root user. :)

I don't disable password. I disable password login for SSH. Everywhere in my data centre. I still need a root password to login at the console via IPMI in case of an emergency.

I will create the user and name it "admin" - let's see where this is going. Thanks for your hints.

 

[Daisuke]

@Patrick M. Hausen here the original discussion link.

 

[Patrick M. Hausen]

Arigatou gozaimasu.

 

[anodos]

I don't disable password. I disable password login for SSH. Everywhere in my data centre. I still need a root password to login at the console via IPMI in case of an emergency.

I will create the user and name it "admin" - let's see where this is going. Thanks for your hints.

Historically, disabling password for root in GUI (in general password authentication) did not prevent password login. Now since it's passing through pam and password is disabled in then shadow file, pam_authenticate() fails for root if you disable password auth there. I think this is more technically correct and really the only way to do this if you want to leverage pam for auth.

 

[Patrick M. Hausen]

Historically, disabling password for root in GUI (in general password authentication) did not prevent password login.

I disable password login for the SSH service. Everywhere. Public key only.

 

[anodos]

I disable password login for the SSH service. Everywhere. Public key only.

Right, that's the sensible way of doing SSH.

 

[Kris Moore]

Is this destined to land in Core as well, or is it only for SCALE?

This is a pretty large feature which still has a lot more improvements slated as others have hinted at (Being able to delegate specific admin permissions). Unlikely for a backport due to the amount of churn.

 

[Kris Moore]

As long as logging in as "admin" vs. as "root" leads to the exact same UI that is itself running with the exact same privileges, there really is no difference. As soon as we get role based granular administration, we are talking. Maybe this change is just a first step. Also: audit of administrative changes.

Stay tuned ;)

 

[jsclayton]

Not clear if this is a bug or working as designed...

I've added my normal user "foo" to the builtin_administrators group and can login to the web GUI. The alert has gone away, however I can still log in as root. The language made it sound like once you have another admin, logging in as root would be disabled. Do I need to explicitly disable root's password?

The other thing that was a bit odd was that the 2FA token that I used as root still works as "foo". I don't see any way to configure it per user, so I'm assuming that's correct?

 

[anodos]

Not clear if this is a bug or working as designed...

I've added my normal user "foo" to the builtin_administrators group and can login to the web GUI. The alert has gone away, however I can still log in as root. The language made it sound like once you have another admin, logging in as root would be disabled. Do I need to explicitly disable root's password?

The other thing that was a bit odd was that the 2FA token that I used as root still works as "foo". I don't see any way to configure it per user, so I'm assuming that's correct?

There is ongoing work for plumbing with PAM and directory services. See here: https://github.com/truenas/middleware/pull/10054
So this feature will become more refined as BlueFin progresses.

 

[Daisuke]

Do I need to explicitly disable root's password?

Yes.

 

[Capitol]

Yes.

A rewrite of the warning is definitely in order then. At the moment it's harmful since it strongly implies (or directly states) that access for root will be rescinded when another administrator is created.

 

[Daisuke]

Actually the correct way is how Bluefin has it implemented now. In Angelfish, the setting was ignored, since only root could've access the UI. We are doing things the right way now. But I agree, a warning would be useful.

 

[Gillis785]

Just upgraded to TrueNAS-SCALE-22.12.0

Saw a warning message:

Root user has their password disabled, but as there are no other users granted with a privilege of Local Administrator, they can still log in to the Web UI. Please create a separate user for the administrative purposes in order to forbid root from logging in to the Web UI.​

Question: how to create a user granted with a privilege of Local Administrator?

Select builtin_administrators and root groups on the Auxiliary Group dropdown list.

Auxiliary Groups should look like 41,90,91

It will add builtin_users once saved

 

[anodos]

Select builtin_administrators and root groups on the Auxiliary Group dropdown list.

Auxiliary Groups should look like 41,90,91

It will add builtin_users once saved

builtin_administrators as auxiliary group should be sufficient. The numbers are DB IDs and shouldn't have been exposed (bug being fixed in 22.12.1 - will be group names).

 

[FabrizioR8]

help please!
Managed to get "everything" working in this regard with my named user able to login to the UI and root disabled. Then I rebooted...

Now my named user can't login via the UI and neither can root.
I've attempted resetting the user's password from the system console to make sure I actually remembered it correctly. Did not help.

Code:

root@tndev[~]# passwd joeadmin
New password: Abc123!
Retype new password: Abc123!
passwd: password updated successfully

root@tndev[~]# id joeadmin
uid=500(joeadmin), gid=50(staff),groups=50(staff),544(builtin_administrators),545(builtin_users),1001(family),1003(homesvcs),1000(mediasvcs),20(sudo),6667(timemachine)

root@tndev[~]# service middlewared stop
root@tndev[~]# service middlewared start

Now I'm locked out of the webUI completely. neither joeadmin nor root can authenticate successfully, though ssh works fine.

Is there a way to re-enable the root access to the UI or otherwise re-validate/config my named user from the console CLI to fix whatever isn't set correctly after reboot?

 

[TensorVortex]

help please!
Managed to get "everything" working in this regard with my named user able to login to the UI and root disabled. Then I rebooted...

Now my named user can't login via the UI and neither can root.
I've attempted resetting the user's password from the system console to make sure I actually remembered it correctly. Did not help.

Code:

root@tndev[~]# passwd joeadmin
New password: Abc123!
Retype new password: Abc123!
passwd: password updated successfully

root@tndev[~]# id joeadmin
uid=500(joeadmin), gid=50(staff),groups=50(staff),544(builtin_administrators),545(builtin_users),1001(family),1003(homesvcs),1000(mediasvcs),20(sudo),6667(timemachine)

root@tndev[~]# service middlewared stop
root@tndev[~]# service middlewared start

Now I'm locked out of the webUI completely. neither joeadmin nor root can authenticate successfully, though ssh works fine.

Is there a way to re-enable the root access to the UI or otherwise re-validate/config my named user from the console CLI to fix whatever isn't set correctly after reboot?

I'm in the exactly same situation, cannot login to web ui at all, ssh is fine. My thread is here: https://www.truenas.com/community/t...th-a-privilege-of-local-administrator.106645/

Please help if anyone has any idea.

I have fixed my issue with midcli. Check my thread for how to fix it

 

[FabrizioR8]

I did as well... figured I'd just unlock my root user, get back into the ui, and re-reset my joeadmin user password again from there. This worked, and I can log-in as joeadmin now from the UI.

root@tndev[~]# cli
[tndev]> account user update password_disabled=false uid_or_username=root

 

[seb101]

Just posting here for reference as it caught me out for 10 minutes. Usernames are case-sensitive in the Web UI but not case-sensitive for Samba. I was copy/pasting credentials for my personal 'super-user' account after adding it to the builtin_administrators group and the first letter of the username was capitalized in my password manager (which works fine for Samba), this was generating the 'Username or Password is Incorrect' error and leading me down a path to think something deeper was wrong.

I've also noticed that some browsers are automatically capitalizing the first letter of the username on the WebUI (Safari on iPad for one). Which could be a best-practice issue with the field tags on the username field (autocapitalize="off"), but I haven't looked too far into it.