In many ways getting someone authenticated to the network
is the easy part.
Once they get here, we need to make
sure they have the right privileges
to access the resources that they
need to be able to do their job.
And it's a challenge to keep track of all of these things.
We have to figure out what rights a user
might have to a folder, to a file.
We need to make sure maybe they only
have read access to a certain part of the network, but read
and write access to another, and there's
all kinds of overlapping policies associated with this.
So we don't know if there's operating system changes,
things that are associated with their group
permissions, their permissions associated
with the user they might be using.
The individual file might have rights and permissions
associated with this, and all of those interact together.
To be able to set some of these privilege
we do a privilege management type
for user management, group management,
and role-based management.
User management is something that's very easy to do.
It's done on a user by user basis, very simple,
but it's also very unsophisticated.
There's not a lot of flexibility that we have with that.
We go to a specific user, we grant them specific rights,
and you're done.
You've now created the rights and permissions and privileges
for that user.
This is something we go to each individual user,
and we carve out exactly what rights and what privileges
they might have.
Obviously this becomes a little bit
difficult to manage, especially if you
need to make one tiny change, you
have to go into each individual user account
to make that change.
So obviously, this is not something
that's going to scale very well.
If you have a large environment, you
could be spending all day going into every single user account
and changing every privilege for every person
in the organization.
Group management is a little bit different.
For group management we're setting privileges
on what you as an individual are doing in the organization.
We may put many different people into a group.
Maybe we have an accounting group, a marketing group,
a shipping and receiving group, and we set privileges
for the entire group all at once.
And If we need to change or modify those privileges,
we're doing it for everyone who might
be in that particular group.
If somebody needs the privileges,
somebody joins the marketing department,
we put them in the marketing group,
and like magic they suddenly have access to everything
the marketing group needs access to.
So it makes a little bit more of that administrative process
much more streamlined for us.
Now users can, of course, be members of multiple groups.
You may be in the marketing group,
but you might also be in the Florida group,
or you might also be in the east coast group.
There's three groups right there,
and there may be different permissions
for the exact same resources in each one of those groups.
So now you have to figure out what
are those effective permissions.
If you're in the marketing department,
you need read and write access.
If you're in the east coast group maybe
you need read access.
Which one takes priority?
And what takes priority is really
dependent on the operating system and the methods
that you use for those operating systems to determine that.
So it's not quite as straightforward
as you might think, but as long as you understand what's
involved in trying to calculate or determine
those effective permissions, this
becomes a very nice way to be able to control
a lot of different rights and permissions
all at the same time.
Role-based management takes this idea
one step further where we're really
setting some very fine grain controls for what
people do in the organization.
So perhaps instead of having a big marketing group,
maybe I have a field marketing group,
maybe I have a technical marketing group.
Those two people are in the marketing department,
and they have the exact same rights and permissions
for marketing, but maybe I need to break them out and have
different controls for really their roles
within the organization.
We also might want to think about how
we're going to create these because you could end up
creating a lot of different roles.
Obviously a lot more administration
associated with this, because you could have HR managers,
you could have accounting analysts,
you could have IT project managers.
There's a lot of different ways to go
with the role-based management infrastructure,
but it makes it very easy if you need to move people
in and out of different permissions
and rights as their role changes.
And in some organizations you're required
to move from role to role to role
at different times of the year.
So from an administrative perspective,
we can simply add people to new roles,
and now all of the different privileges move with that user
as they move into the new role.
And of course, you need to keep in mind
in this particular role-based management,
you're only going to be a member of one specific role.
You can't be a member of multiples.
That's not the idea behind this.
This is something where we're recreating very fine grain
control, and therefore, you're only
going to be part of one role at a time.