If you're watching this video on your computer,
then you're probably logged in with a user account.
A user account is one that is associated
with an individual, a specific person who
has been assigned this account.
Your account probably has a name associated with it.
For example, the username I log in with is Professor Messer.
There's also, behind the scenes, a specific identification
number that associates this account
with that particular name.
And the operating system usually refers
to the number associated with the account,
rather than referring to Professor
Messer as that account name.
If you have a computer where multiple users are logging
into that same computer, one thing you may notice
is that the files associated with your account
are not able to be seen by users of other accounts.
This, of course, is by design.
If you're creating and saving files under your username,
you would have to specifically allow those users access
to the files.
Otherwise, they won't be able to see them.
User accounts are specifically designed
not to have full access to the operating system.
This means that if malware or some other type
of malicious software was running as that user,
they would only have certain access to the operating system
and ideally would not be able to make any significant changes
to the underlying OS.
By default, this is the type of account
that every user should have.
Even if this is someone who is a system administrator
or they're doing some other type of work in IT,
they would still use a user account any time
they are not doing anything specific to that operating
system.
This limits the amount of damage that
could be done to the operating system
if something was to execute as this user account.
A shared account is an account type
used by more than one person.
If you have a guest log in or an anonymous log in,
this is an example of a shared account.
The problem with a shared account
is it's very difficult to know exactly who performed
a particular action on that operating system.
Since everyone's logging in as guest,
you aren't exactly sure who was logged in as guest when
a particular function occurred.
This also makes it difficult to assign the proper permissions
to an account, since so many different people could
be logging in with the same account name.
And if multiple people are using the same account,
imagine what happens if the password changes
on that account.
How do you inform all of those individuals sharing
the same account that this password has now been changed?
This makes it difficult for users
to keep up with all of the different changes.
And what they may end up doing is writing down the password
and storing it somewhere, which, of course, is a very bad habit
when it comes to passwords.
The best practice for shared and generic accounts
is to simply not use them at all.
Everyone should have their own personal account associated
with them as an individual.
And no one else shouldn't have access to their user account.
Guest accounts are a shared account
that, until most recently, were a normal part of an operating
systems installation.
A guest account allows users who don't have a normal user
account on that system to be able to log in and at least
have some rights and permissions to the operating system.
These accounts usually don't have
a password associated with them, and they're
highly restricted accounts.
They don't usually have access to run all of the applications
on that system.
They have very limited access to the operating system.
And you can't change or customize
many aspects of the user interface.
But even more concerning is that if someone does gain access
to your system, it might be possible
for them to run some type of privilege escalation
and gain full access to the system.
So an attacker could log in as guest,
which has very limited access to the operating system,
take advantage of a vulnerability in that operating
system, and now suddenly have full access to the system.
Although there is a convenience factor associated
with having a guest account, there
are so many disadvantages from a security perspective
that we've started to disable this and not
use it as a standard practice.
For example, in Windows 10, build 10159,
Microsoft completely removed the guest account.
And it's no longer a default part of the operating system.
A type of account that doesn't log in interactively and you
usually don't see it running on your desktop
is a service account.
As the name implies, a service account
is an account type that is only used by background services
in your operating system.
So things like a web server, a database server, a print
spooler, and the other services that you
have running on your system are using
some type of service account to gain access to the OS.
It's very common for different services
to have different service accounts.
This allows you to set specific rights and permissions
for a service that are just for the ability of that service
to operate.
For example, a web server can be assigned a certain set
of rights and permissions that allow people
to store and retrieve information from the web server
directories.
But a database server has a completely different set
of files and a completely different set of permissions
required for users to access the database server.
It makes sense, in that case, to have two separate service
accounts, one for the web server and one for the database
server.
Just like your normal user accounts,
these service accounts have a username and password.
The username is assigned to a particular service.
And the password is included along with that service
configuration.
That means that if there are any password updates on the system,
you will also have to change the password in the service.
Otherwise, it won't be able to log in and operate normally.
If you're a system administrator,
then you're probably very familiar
with a privileged account.
In Microsoft Windows, administrator
is the privileged account.
And in Linux, your privileged account is called root.
These privilege accounts have full access
to the operating system.
They can change core files.
They can modify the kernel of the system.
They can manage the hardware drivers
and anything else that may be required to run that system.
The privileged account has access
to the operating system the normal user account does not
have.
And it's usually a best practice to use your user account all
the time, unless you happen to be performing
a function that a user account simply doesn't have access to.
In those cases, you might switch over to the privileged account,
perform those functions required for that privileged account,
and then log out of that privileged account
and back to your user account once that's done.
A best practice for privileged accounts
is never to use it as your normal user account,
but instead, only use it in times when it's required.
Because this account has full access to the operating system,
it needs to be very secure.
So we need to provide at least strong passwords
and multifactor authentication.
We might also want to schedule password changes so that we
know that we always have a password that
has been updated recently for these privileged accounts.