Results 1 to 7 of 7
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Dec 2012
Having an admin account in Debian and Ubuntu
I'm working in a research center that has no IT expert, so I'm trying to help out researchers with their computer problems, as I know a bit more about computers.
Every member of this organization is receiving a laptop with Windows preinstalled on it, and some of them asked me to help them installing a linux distro, mostly Debian or Ubuntu.
As per this center policy, there must always be a Tech account with all privileges for the occasional technician that has to solve problems / install stuff.
How do I solve this?
What I did is creating two account: the one during the install, and another one after the install named "Tech".
I added both to sudoers, so they can both use the sudo command. I then proceeded to lower Tech's id under 1000 so it wouldn't show in the login screen.
I am now wondering if I did well or if there is a more elegant and efficient way of doing that, especially because the Tech user remains hidden until you use it, and then pops back from the first time you log into it forward.
Thanks for your time!
What you want to do is disable displaying usernames at the login screen.
Disable Login Screen User List Ubuntu
Tech's UID is in the administrative range so it's hidden from the available logins, but it's still a valid account. It sounds like your problem is the systems are configured to display the username of whoever logged in last.
The link may not apply to all of your distros, but you should get the picture.
Additionally, you were not wrong in changing the Tech UID to something below 1000, as UID's are grouped into privileged and unprivileged ranges. Assigning administrative users a UID in the privileged range is a best practice.
UIDs 1 through 99 are traditionally reserved for special system users (sometimes called pseudo-users), such as wheel, daemon, lp, operator, news, mail, etc. These users are administrators who do not need total root powers, but who perform some administrative tasks and thus need more privileges than those given to ordinary users.
Some Linux distributions (i.e., versions) begin UIDs for non-privileged users at 100. Others, such as Red Hat, begin them at 500, and still others, such Debian, start them at 1000. Because of the differences among distributions, manual intervention can be necessary if multiple distributions are used in a network in an organization.
Also, it can be convenient to reserve a block of UIDs for local users, such as 1000 through 9999, and another block for remote users (i.e., users elsewhere on the network), such as 10000 to 65534. The important thing is to decide on a scheme and adhere to it.
Among the advantages of this practice of reserving blocks of numbers for particular types of users is that it makes it more convenient to search through system logs for suspicious user activity.
Contrary to popular belief, it is not necessary that each entry in the UID field be unique. However, non-unique UIDs can cause security problems, and thus UIDs should be kept unique across the entire organization. Likewise, recycling of UIDs from former users should be avoided for as long as possible.
- Join Date
- Jun 2012
- SF Bay area
UID's below a certain number are hidden by default on Ubuntu so I think that's a reasonable way to handle hiding the "tech" user. Getting rid of all the username on the login screen is appealing to me personally, so thanks for posting that link [b]awc[/c]! But if you don't need to hide the normal users I think just tweaking the UID of the "tech" user is sufficient.
I don't remember low UID users popping up in the login screen after you've used them. That seems really odd to me. Maybe it will show only if the low UID users was the last one you logged into? I might have to test that...
I'm OCD-lite enough that I'd also change the GID of the "tech" user to match the new UID, but it's definitely not necessary!
- Join Date
- Dec 2012
Thank you both for your time. I edited the greeter config file and it solved it.
Also thank you for that guide. I may become the tech guy in this center soon, and I'll need every piece of help.
Just another question:
is there a way to block the passwd command?
I mean, everyone who has sudo priviledges can change not only theirs, but everyone's passwords: I already imagine the tech guy trying to login only to find his password changed by some researcher who didn't want anyone to access the laptop but him.
Last edited by awc; 12-14-2012 at 04:55 PM. Reason: Updated syntax for compatibility with older versions of sudo
- Join Date
- Dec 2012
Thank you, I'm learning a lot.
I tried that, but it didn't work. Then I saw the line "%sudo ALL=(ALL) ALL" and I figured out that everyone in the sudo group could execute every command. I added the "!/usr/bin/passwd" part to that and removed the "ALL" and it worked!
Now users in the sudo group can use sudo, but can't use "sudo passwd" anymore.
New question: my tech user was in the sudo group, and has also an entry in the sudoers file:
techuser ALL=(ALL) ALL
I thought that this line would be enough for it to give the ability to change password to other accounts using sudo, but it's not.
So I thought that maybe removing the tech user from the sudo group would solve the problem, but it didn't.
Is there a way to do that?
Last edited by Viandante; 12-14-2012 at 09:58 AM.
Come to find out, older versions of sudo (1.7.4p4-2) read command exclusions differently. The third ALL must be present otherwise all commands will be blocked. The correct syntax is
user ALL=(ALL) ALL, !/cmd/to/exclude
Now with that out of the way, you want to verify techuser is not a member of the sudo group and edit /etc/sudoers
verify group membership
$ id techuser
%sudo ALL=(ALL) ALL, !/bin/usr/passwd techuser ALL=(ALL) ALL
Last edited by awc; 12-14-2012 at 06:22 PM.