Choosing the identity source when adding a user: exists on the server, or only in the panel

The suffix at the end of a username is not decoration. It says where the account lives, and this choice cannot be moved later.

Two kinds of user

The first kind really exists on the server. They are the machine's own users, and their password is the machine's password. The root account you first sign in with is of this kind.

The second kind exists only inside Proxmox. They have no counterpart on the machine: no shell, no remote login, no place in the system. It sounds incomplete, but this is exactly what you want. Letting someone use the panel does not require opening the server to them.

The first classic mistake

A user is created on the server, and then the panel will not let them in. Creating a system account by itself grants nothing in the panel, because identity and permission are separate jobs. The account is recognised, but what it may see was never stated. This is the twin of the problem where permission is granted and still nothing appears.

The second classic mistake

A user is created in the panel, and then someone tries to connect to the server with it. It will not work, and it is good that it will not. An account that exists only in the panel exists precisely for this: its reach ends at the screen.

Which one to choose

If the person does not need to touch the server itself, choose the kind that exists only in the panel. Fewer doors open, and on the day it has to be closed it closes in one place. If someone really will do work on the server they need a system account anyway, but do not make that decision because of a panel requirement.

Disabling instead of deleting

An account can be disabled without being deleted, and an account can be given an end date. Deleting takes the history along with the record: the question of who had been given what is left unanswered. For someone who has left, disabling is usually the more correct answer than deleting.

Grant to a group, not to a person

Granting directly to a person is fast on the first day, starts the work over on the second person, and by the third it gets muddled who has what and why. Granting to a group and putting the person in it leaves seconds of work for every person after, and builds up no scattered entries behind you.

Second factor

A password on its own is one door. If the panel is reachable from outside, or if the account carries authority, turn on the second factor. For automation, generating a separate key is better than sharing a password, and that is its own subject.

What Atlas does

Atlas shows access as a chain rather than a list: the server, the scope, the identity source, the user, the group, the role and the path all sit connected on one map. So the question "which door does this person come through and what do they reach" is answered by looking, not by assembling entries in your head. Password, second factor and automation keys are managed per account, and because Atlas does not build its own role system, the authority you see on screen is the same authority as on the server.