Windows Server 2019 – General security best practices

How to Install Kubernetes cluster on Ubuntu 18.04

Sometimes we need only to rely on ourselves, and not necessarily functionality provided by the OS, to secure our systems. There are many common-sense approaches to administratorship (if that is a word) that are easy to accomplish but are rarely used in the field. The following are a few tips and tricks that I have learned over the years and have helped companies implement. Hopefully, you as the reader have even more to add to this list as to what works well for you, but if nothing else this section is intended to jog your thinking into finding creative ways with which you can limit administrative capability and vulnerability within your network.

Getting rid of perpetual administrators

Do all of your IT staff have domain admin rights the day they are hired? Do any of your IT staff have access to the built-in domain administrator account password? Do you have regular users whose logins have administrative privileges on their own computers? You know where I’m going with this—these are all terrible ideas!

Unfortunately, that was all the status quo for many years in almost every network, and the trend continues today. I still regularly watch engineers use the administrator domain account for many tasks when we set up new servers. This means they not only have access to potentially the most important account in your network and are using it for daily tasks, but it also means that anything being set up with this user account is not accountable. What do I mean by that? When I set up a new server or make changes to an existing server using the general administrator account, and I end up causing some kind of big problem, nobody can prove that I did it. Using generalized user accounts is a sure way to thwart responsibility in the event that something goes wrong. I’m not trying to imply that you are always on the lookout for who did that?, but if I mess something up on an application server that I don’t normally administer, it would be nice if the guys trying to fix it could easily figure out that it was me and come ask me what I did so that they can reverse it. There are many reasons that using the built in administrator account should be off limits for all of us.

To address the client side, do your users really need administrative rights on their computers? Really? I think you could probably find ways around it. Bringing regular users down to user or even power user rights on their systems can make a huge impact on the security of those computers. It gives viruses a much harder time installing themselves if the user needs to walk through a prompt asking for admin privileges before they can proceed with the install. It also keeps all of your machines in a much more consistent behavioral pattern, without new and unknown applications and settings being introduced by the user.

Using distinct accounts for administrative access

This idea piggy backs off the last one, and is something that I have started employing even on all of the home computers that I install for friends and family members. It really boils down to this: utilize two different user accounts. One with administrative access, and one without. When you are logged in for daily tasks and chores, make sure that you are logged in with your regular user account that does not have administrative privileges, either on the local computer or on the domain. That way, if you attempt to install anything, or if something attempts to install itself, you will be prompted by the User Account Control (UAC) box, asking you to enter an administrative username and password before the installer is allowed to do anything. I can tell you that this works, as I have stopped a number of viruses on my own computer from installing themselves as I’m browsing around the internet trying to do research for one project or another. If I get a UAC prompt asking me for an admin password and I haven’t clicked on an installer file, I know it’s something I don’t want. All I have to do is click on No, and that installer will not get a hold of my computer. On the other hand, if it is something that I am intending to install, then it is a minor inconvenience to simply enter the password of my administrative account, and allow the installer to continue.

Maintaining two separate accounts allows you to work your way through most daily tasks while putting your mind at ease that you do not have rights to inadvertently do something bad to your system. This mindset also limits the amount of activity that any administrative account needs to take on a computer or on the network, and makes those administrative accounts easier to track when admins are making changes in the environment.

Using a different computer to accomplish administrative tasks

If you want to progress even further on the idea of separate user accounts, you could make your computing experience even more secure by utilizing a separate computer altogether when accomplishing administrative-level tasks. One computer for regular knowledge worker tasks, and another computer for administration. This would certainly help to keep your administrative system secure, as well as the remote systems that it has access to. And while it does seem cumbersome to have two physical computers at your desk, remember that with most SKUs in Windows 10 we have the ability to run Hyper-V right on our desktop computers. I actually do exactly this with my own computer. I have my computer that is running Windows 10, and then inside that computer I am running a virtual machine via Hyper-V from which I do all administrative tasks on the sensitive servers. This way a compromise of my day-to-day OS doesn’t necessitate a compromise of the entire environment.

Whether you choose to split up administrative access at the user account level or the computer level, remember this simple rule: never administer Active Directory from the same place that you browse Facebook. I think that pretty well sums this one up.

Never browse the internet from servers

Seems like a no brainer, but everyone does it. We spend all day working on servers, and very often have to reach out and check something from a web browser. Since Internet Explorer exists on Windows Servers, sometimes it is just quicker and easier to check whatever it is that we need to check from the server console where we are working, rather than walk back over to our desks. Resist the temptation! It is so easy to pick up bad things from the internet, especially on servers because if any machines in our network are running without antivirus protection, it is probably on the server side. The same is true for internet filters. We always make sure that the client traffic is flowing through our corporate proxy (if we have one), but we don’t always care whether or not the server traffic is moving outward the same way.

Don’t even do it for websites that you trust. A man-in-the-middle attack or a compromise of the website itself can easily corrupt your server. It’s much easier to rebuild a client computer than it is a server.

Role-Based Access Control (RBAC)

The phrase Role-Based Access Control (RBAC) is not one that is limited to Microsoft environments. It also is not a particular technology that can be utilized inside Windows Server 2019, but rather it is an ideology that is all about separating job roles and duties. When we think about separating our employees’ job roles from an IT perspective, we traditionally think in terms of Active Directory groups. While adding user accounts to groups does solve many problems about splitting up levels of permissions and access, it can be complicated to grow in this mentality, and ultimately AD groups still empower administrators with full access to the groups themselves. RBAC technologies divide up roles at a different level, caring about more than permissions. RBAC focuses more on employee job descriptions than access restrictions. There are a number of different technologies that take advantage of RBAC tools integrated into them, and there are even third-party RBAC solutions that ride on top of all your existing infrastructure, making it widely accessible across your entire organization, and not restricted to working in the confines of a single domain or forest.

Just Enough Administration (JEA)

A great example of an RBAC technology that is included in Windows Server 2019 is Just Enough Administration (JEA), which is part of PowerShell. JEA provides you with a way to grant special privileged access for people, without needing to give them administrative rights, which would have been required to accomplish the same duties in the past. The necessity to add someone to the administrators group on a server so that they can do their job is quite common, but JEA is a first step away from that necessity.

In our old way of thinking, it might be easy to think of JEA as doing something like allowing users to have administrative access within PowerShell even when they don’t have administrative access to the OS itself, but it’s even more powerful than that. The design of JEA is such that you can permit users to have access only to run particular PowerShell commands and cmdlets at an administrative level, leaving other commands that they do not need access to in the dark.

In fact, if a user is working within a JEA context of PowerShell and they try to invoke a cmdlet that is not part of their allowed cmdlets, PowerShell pretends as though it doesn’t even recognize that cmdlet. It doesn’t say, sorry, you can’t do this—it just ignores the command! This definitely helps to keep prying fingers out of the cookie jar, unless you want to let them in.

Let’s take it a step further. Maybe you are a DNS administrator, and you might occasionally need to restart the DNS services. Since we are adopting the JEA/RBAC mentality, you are not going to have administrative rights on the OS of that DNS server, but you will have JEA-based rights within PowerShell so that you can run the tools that you need in order to do your work. Restarting the DNS service requires access to use the Restart-Service cmdlet, right? But doesn’t that mean I would be able to restart any service on that server, and could potentially do all sorts of things that I don’t need to do? JEA is even powerful enough to deal with this scenario. When setting up the level of access that the user needs to get, you can even dive into particular cmdlets and divide up permissions. In our example, you could provide the user with access to the Restart-Service cmdlet, but only give permissions to restart particular services, such as those pertaining to DNS. If the user tried to Restart-Service on WINrm, they would be denied.

Comments are closed.