Now that you’ve created your user accounts, how do you ensure that they are used securely? In this video, you’ll learn about credential management, Group Policy control, passwords, and more.
<< Previous Video: Account Management Next: Agreement Types >>
The credentials that you use when you log in are the only thing that stands between the rest of the world and your data. This means that you must protect those credentials, and you have to be sure that they are always secure. You have to make sure that the applications that you’re using are securing these credentials, that all of those credentials are always stored on the server, that they’re never stored on the client, and that nothing is ever sent across the network in the clear. That’s why IT security professionals often audit these applications to make sure that that authentication process is secure.
Creating a set of policies like this for a large organization can be difficult. For the Windows operating system, there are a number of built-in administrative tools that can help you do this. For example, the Windows Group Policy Management. This allows you to apply administrative settings and security rules across all of your systems globally.
These Group Policy rules are a bit different than the NTFS permissions or permissions that you might set to a Windows Share. These affect the operating system itself and some of the functions that people will use daily on their computers. This is linked to Windows Active Directory, so you can administer different sites, different users, different groups, or any combination of any of those Active Directory administrative boundaries.
Administrators often use Group Policy control to limit what people are able to do in an operating system. For example, you can allow someone to add or remove applications from their computer. Or you can restrict someone from performing those functions.
From a security perspective, we have a lot of control over what happens inside of a Windows domain and the operating system. You can limit what the maximum or minimum password links would be. You could require that someone use a smart card to authenticate. You can set the size of the security log, and you can enforce any user login restrictions across all systems on your network.
To limit the scope of a brute force attack, we want to make our passwords strong. We don’t want to use any single words or words that would be easily recognizable. We also don’t want to use any words that might be associated to you, such as the name of your dog. It’s important to use upper case and lower case characters along with special characters so that any brute force process would become that much more difficult. Many organizations will set a minimum password length of eight characters, but some applications will allow you to add entire phrases or sets of words as your password.
And as you’ve probably seen, it’s difficult to reuse a password. Most systems will remember the history of your password use and will require a unique password each time it’s changed. Many organizations will require a password change after a certain number of days. It might be 30 days or 60 days, or it may be a shorter amount of time depending on your security requirements. If your credentials for some reason were made available to someone else, changing your password constantly would limit the scope of someone’s access.
If you forget your password and need to have your password reset, this recovery process should not be something trivial. The password recovery process is an opportunity for social engineering. So you want to be sure the person who’s trying to recover the password is truly the person who owns that account.
Many operating systems will automatically disable account if too many incorrect attempts are made for a login. This is a normal part of most operating systems, and your audit and recovery process should take this into account. These lockouts could also occur for service accounts. But instead of disabling this functionality for service accounts, you may want to leave that on to make sure that no one’s trying to perform a brute force attack to your service accounts as well.
And as we mentioned earlier, it’s a best practice to simply disable accounts rather than deleting accounts. There’s often data and encryption keys associated with user’s accounts. So by simply disabling that account, you would still have access to all of the keys needed to decrypt all of the user’s data.