Account Management – CompTIA Security+ SY0-501 – 4.4

There are important security considerations when managing your user accounts. In this video, you’ll learn about on-boarding, auditing, account naming conventions, and more.

<< Previous Video: Account Types Next: Account Policy Enforcement >>


Setting a user’s account to have the least number of privileges is a foundation in IT security. If you’re configuring a user’s account, they should have the ability to perform their job and have no other rights and permissions beyond that. This applies to all users in the organization. You should configure all of the accounts to only run exactly what is required for the applications needed.

You never want to have users running with administrative privileges. An Administrator has access to all systems at all levels. If you’re running with a least privilege, then that user would have a limited scope, especially if there’s malicious software which tries to affect other parts of the organization.

Account management becomes very important when you are on-boarding new users. These could be new hires or transfers from other parts of the organization. There are usually internal IT agreements that need to be signed. These could be part of your employee handbook. Or they could be a formal acceptable use policy that everyone has to read and agree to.

The IT Department will then create the accounts, and they will confirm that the user is provided with exactly the right permissions and access by adding them to the proper groups. And the new user may be assigned a workstation, a laptop, a tablet, and any other hardware that may be required to perform their job.

While some people are joining the organization, other people may be leaving the organization. But this is not a process that should be a surprise. You should have pre-planned for this occasion and know exactly the steps you should follow during the off-boarding process. For example, there should be a formal process to turn in hardware and confirm that the hardware has been received. And the user’s data is also extremely important, especially for the people that will still be here working or the people that will be replacing this person.

In many organizations, the account information is usually deactivated instead of being deleted. Occasionally, there can be information lost during the deletion process. So by simply deactivating the account, you can be assured that all of the data remains in place.

You’ve spent a lot of time creating formal policies and making sure that people agree to use those formal policies when they’re part of the network. One way to be assured that they’re following those policies is to perform routine audits. Although you may have already set up all of these accounts and all of these permissions initially, it’s remarkable how things can change over time. So by performing audits, you can be assured that everything is exactly the way it was designed to run from the very beginning.

Many types of these scheduled audits can even be automated. So the process can be done without any type of user intervention. And you can simply receive a list of alerts or a list of logs that shows you issues that may need to be resolved.

One type of auditing is a permission auditing. You want to be sure that every user has exactly the correct permissions they need for their particular role. For example, there may be people that have been provided Administrator access that really do not need to have Administrator access on your network. And usually this is a process where you can schedule a recertification of this. This is where you will be continually auditing the users’ permissions to make sure that they’re only able to access the information they need.

You might also perform usage auditing to find out exactly how your resources are being used. How are people storing information? And where are they storing those files? Are the systems and applications that are in use configured to be secure?

You might also want to perform audits to check on what’s happening during the day. Implementing time-of-day restrictions can be a good way to provide security. For example, no one needs to be in a particular location in a lab at 3:00 in the morning performing any type of functions. And if someone is in the lab at 3:00 in the morning, that may be something that you need to be aware of.

Every user is generally assigned a standard username. This should be a unique name, something that doesn’t conflict with anyone else in the organization. And this person should use the same username across all of the systems that they would ever authenticate to. Your naming convention should also be consistent. If you use first name, middle initial, and last name for one person, it should be that way for everyone’s username. And to avoid any type of future conflicts, you want to be sure to avoid describing any role or status in a person’s username, because these could change over time.

The naming convention should also require a persistent username. The username that you get on your first day in the organization should be exactly the same username that you’re using at the end of the organization. You don’t want someone’s username changing sometime during the duration of employment.

And the username should be memorable. It should be something that the user can easily remember. This doesn’t necessarily mean that it is a recognizable username. Some organizations will use an employee ID number, which is something that’s very memorable for the user, but something that’s difficult to recognize if a third party was to see that username.

This would mean that the standard user account maintenance would start with the account creation, where your provisioning the user and their access, providing them with their password information, and assigning them to the proper groups. Then of course, you’re going to provide constant password updates to make sure that that password is always changed at a regular period. And you want to be sure to provide those audits to always check for the permissions. And when a person leaves the organization, there will need to be a deprovisioning of this account information. The account would probably be disabled, and all of the user documents and account information would be archived.

Another standard part of account maintenance is providing the right permissions for a user. And these permissions can change over time. Often users are added to a particular user group. That user group is assigned permissions, so it makes it easy. As you add users to the group, they naturally will use those particular permissions.

This often means that users are members of multiple groups. And the permissions of those multiple groups may overlap. It can become difficult to try to determine what the effective or combined permissions are for someone who is in these multiple groups. And you don’t want to run into problems with implicit permissions, where one particular group denies access to data and the other group allows access to data. You would need to make sure that that user was given the correct access for whatever job role they held.

An increasingly common policy to use for user permissions is the location where that user happens to be. GPS locations, for example, can provide very accurate information on where a user is. 802.11 wireless gives you a more regional view. And IP addresses can sometimes help you narrow down where a user is. But unfortunately, those can be wildly inaccurate and would show someone in a completely different country than where they happened to be.

You can use one or more of these location-based systems to determine what policies should be set. For example, someone may be able to access a particular application or particular data when they’re in the office. But if they are outside of the office, they should have no access to any of those systems.

You commonly see this type of location-based policy applied to firewalls. For example, many firewalls allow you to block entire countries based on an IP address block. So you can define firewall rules that will automatically block all traffic from certain parts of the globe, because you know there’s no one from that particular country that would ever need access to your application.