-: Users and groups.
A lot of our access control systems
rely upon the concepts of subjects and objects.
Now, subjects can be users, those people.
But objects can be things like files and folders and devices,
but it can also be devices, computers
and even groups of users.
And each of those can have different
permission levels granted to them.
Now, computers can have multiple users and multiple groups.
A group can have lots of different users inside of it,
but a group can also contain other groups.
So, for instance, we might have the IT department
and then have subgroups under the IT department
of administrators and power users, right?
Going back to our role-based access control,
we always want to assign users to groups
and then assign the permissions to those groups.
It's a lot easier to put somebody into a group and get them
all the permissions they need when they get hired.
It's also easier to take somebody out of a group
and remove all the permissions at once
if you're using groups using that role-based access.
Now, here you have an example of ADUC.
ADUC is the Active Directory Users and Computers.
This is a program inside of Windows where you can explore
all the users, the groups, and the computers.
And you can see here all the lists
of the users on this particular system.
Now, as we go through, I want you to remember
that there's two different ways that you can create a user.
So, if you are a brand new person at our organization
and we need to create you an account,
we can do it one of two ways.
The first way is to right-click an empty space
in the users folder of the ADUC and select Create New User.
This is using the graphical user interface.
Now, the second way is to create a new user
within the organizational unit within active directory.
Each organizational unit is made
to mimic a department within a company.
If you're a small organization,
you're going to do it the first way.
If you're a really large organization,
you're going to be using organizational units
for each department or branch
and then having your users added there.
So, depending on which one you're going to use,
it's depending on how big your organization is.
Now, when you look at ADUC as you see in the example here,
you can see there's two organizational units.
The first one is called Org1
and the other one is called testersunit.
In your company, you may have one for sales,
another one for HR, another one for IT, you get the idea.
Organizational units match up to large departments.
Now, when we talk about that,
we also have to think about the concept of permissions
for these users that we're creating, right?
And that's known as user rights.
User rights are basically whatever permissions
you give to a particular user.
This includes more than just file access, though,
because it can be things like login hours,
when your account's going to expire,
how often you have to change your password,
what devices can they login to, what printers can they use,
and all sorts of those type of things.
This all falls into this user-rights bucket.
Now, when I look at a user, for instance,
here's one called Bob.
And you can see in this example that Bob has a login name
of bob.smith, up there towards the top of the screen.
Now, you could see his name is Bob Smith
and you can see his account is unlocked.
This is a local user account on a Windows 10 system.
If I was on a domain, I would have a lot more options
that I can do with Bob.
Now, let's go ahead and look at one of those.
One of those would be something like a login hours.
So, here I can configure for Bob
when he can log in to our domain.
Here, you can see I have it set up that between nine to five,
Monday through Friday, he can log in.
So, if Bob comes to the office on Saturday at 3:00 a.m.
Guess what, he can't log in to the network.
And that's okay, because we want to force Bob
to be there during working hours
so everybody else can see what Bob's doing
and make sure he's not stealing from us, right?
By preventing Bob from being able to come in at 3:00 a.m.,
it prevents him from coming in,
downloading the entire shared drive,
and walking out the front door
and giving it to your competitor.
Now again, I know I'm being kind of mean and sarcastic
and being pessimistic of people,
but if you ever been in security for a long time,
you'll see all this type of stuff happen.
So, you want to start preventing when people can log in
and make sure it matches up to normal business hours
that you would have other people in the office
cause people who come in on their own
usually are the ones you have to watch closely.
Now, the next thing we have is we take all these users,
we want to collect them together,
and we collect them into what's called a group.
Groups are simply a collection of users
based on common attributes.
Normally, we're going to group them together into work roles.
This way, we can say, okay, all the admins go together,
all the receptionist go together,
all the salespeople go together.
And I set permissions based on those groups.
Now, as we look at groups, you can see here
that Bob is a member of a couple of groups.
I have him inside of the users group, the accounting group,
the backup operators group,
and the remote desktop users group,
and each of those gives him different permissions.
As a user, he has access to log in to the domain, maybe.
As accounting, he has access
to get into our financial systems.
As a backup operator, he can back up his financial system
to our taped backup system.
And as remote desktop user, he can log in from home
during his login hours,
because maybe Bob was given permission to work at home.
All of these things are going to be set
based on the permissions of those groups,
and they're cumulative.
So, whichever one gives them permission out of those groups
is the permission he's going to be able to use.
Now, as we look at this,
you can also see how groups are used
for file and folder permissions.
So, here I have the accounting folder on the shared drive.
And when you look at the permissions here, you can see
that only members of administrators
or accounting have access.
Now, Bob was part of the accounting group, right?
So, he's going to be able to get access to this folder.
But Susan down in sales,
she won't have access to this folder
because she's not part of accounting
and she doesn't need access to that financial data.
That's the idea here why we have
users and groups and the permissions we set.
Now, permissions in Windows can be set into multiple ways.
You can have full control, you can have modify,
you can have read and execute, you can have
listing of the folder contents, reading or writing.
And depending on which permission you set,
is what actions that user is going to be able to do.
Now, when we look at our permissions,
they're usually broken down in Linux into three categories.
Read, write, and execute.
They're much simpler than what you saw there in Windows.
Now, when we look at this, though,
we actually have these assigned to our owners,
our groups, and all users.
And for some reason, owners is called U, groups is called G,
and all users is either symbolized by O or A.
Why are owners call U?
Because, really, think about it, as in user, right?
So, users, groups, and all users, that's the idea here.
Now, as we consider permissions in Linux,
there's a program you have to be familiar with
and it's called Change Mod, chmod.
This is a program in Linux that's used
to change the permissions or rights of a file or folder
by using a shorthand numbering system.
And for the Security+ exam, you do want to be aware
of this shorthand numbering system.
So, we're going to cover it right now.
Basically, it comes down to three numbers.
If you have read permissions, you're a four.
If you have write permissions, you're a two.
And if you have execute permissions, you're a one.
But just like Windows, you can combine these permissions.
So, if I combined read and write, I would get six.
If I had read, write, and execute, I'd have a seven.
Now, how do I use these digits?
Well, it looks something like this.
change mod 760 filename.
And that would be giving the 760 permissions
to the filename.
The seven is what the owner can do,
and they can read, write, or execute.
The six is what the group can do
cause it's a second position, they can read and write.
And then the third piece is the zero,
which is for all users, in this case, no access.
And so, based on those numbers there in the change mod,
I'm assigning those permissions to that filename.
So, if I ever 777 in Linux,
what that tells you is that the person
has read, write, and execute.
Both the owner, the group, and all users,
because the seven is in all three positions.
So, you can see how this change mod
and this numbering system works.
For the exam, you're probably going to see a question
that gives you something with a change mode command,
and you'll have to be able to figure out
what permissions each person has.
So, keep that in mind, as well.
Now, another thing you need to worry about
with users and groups permissions is called privilege creep.
This occurs when a user gets
additional permissions over time
as they rotate through different positions or roles.
So, I talked about in the last lesson
how job rotation was good.
And if I took you from sales to marketing,
what would happen?
The IT group would take you and add you
into the marketing distributions, right?
And the marketing permissions.
But the problem with that is if they forget
to take you out of the sales group,
you still now have the sales permissions
and the marketing permissions.
And then, if you went and did a tour inside the HR field,
now, you're going to have all three of those.
And if somebody's been with the organization for many years,
often, you'll see that they have
all of these different permissions
because they've creeped up over time.
Now, you always want to be checking people's permissions
to make sure that privilege creep isn't happening
because privilege creep is going to violate
all of the good principles
of the least privilege concepts that we've talked about.
Now, to do this, we use a thing called
user-access recertification.
This is a process where each user's rights and permissions
are revalidated to ensure that they're correct.
This may be done annually, once a year,
or it may be done whenever they switch permissions.
Or it may be done anytime they ask
for new permissions to be added.
So, for example, if I moved Jim from accounting over to HR.
Well, at that point, we want to take away
his permissions from accounting and add HR.
At the same time, we would go back and look and say
hey, what else does Jim have access to
and does he need access for all of that?
It's really important to always check these permissions
because they do end up getting overtime
just added and added an added,
and people forget to take them away.
Now, there are three times in every employee's career
where their permissions tend to either get
added or taken away.
Usually, it's when they're hired, when they're fired,
or when they're promoted.
So, any of those three things should automatically trigger
a user-access recertification
to make sure that they have the right permissions
and they don't have excessive permissions.
Remember, least permission and least privilege
is the name of the game here.