A Dockerfile (no file extension) is a definition file that will build and run a container. That container can be a simple Microsoft IIS web application or Python/Flask application or a simple build/reporting service. A definition file helps us with our operational tasks, especially when we are building services or scripts for the repeatable tasks we face on a daily basis.
Docker is an operating-system level virtualization technology that allows you to isolate applications in so-called containers without the overhead of conventional virtual machines. In this post, you’ll learn how to install Docker on Windows and run your first containers.
Docker allows developers building a specific functionality (and all of its dependencies) into a small reproducible environment. This has evolved over time by enabling the ability to create small microservices that do one thing and do it well. I like to think of containers as a Windows Service installed without the need for the entire operating system.
Whether you are a pro with PowerShell or a beginner, PowerShell ISE snippets can speed up your scripting and assist when you are unsure of formatting.
Most IT professionals who work with PowerShell to build tools, scripts, or modules use the built-in PowerShell ISE (Integrated Scripting Environment) to build and debug their code.
In this post, I explain how to create a PowerShell function to process CSV data. This allows you to reuse your code whenever you are working with CSV files in PowerShell.
CSV (Comma-Separated Values) is used by almost every technology platform that we encounter. Manipulating this data can be cumbersome if you’re NOT an Excel wizard, but PowerShell can simplify this job. For example,
Group Policy is nothing but flexible and extremely powerful when it comes to both configuration management and installation of software. In addition, Group Policy is one of your best tools for securing your endpoints. You can manage anything and everything from Firewall rules, account privileges, application white-listing, etc. You can also manage user rights as well.
Computers and Users in your environment have a lot of rights, by default, that they don’t need. Using Group Policy, we can manage these privileges and start to lock-down our environments without making it burdensome for our end users. One such privilege is the ability to Log on Locally.
Use Group Policy to define accounts or services that are allowed to log on locally
By default, anyone that has the correct username and password can log on locally to a system, but do you really need to log on to a server in your datacenter using a local account? Some of you might, in this case you should explicitly allow certain accounts to have this privilege. Instead of using the default setting of “if you have a local account you can log in to this system”, but instead restrict this at a global level. This ensures that your systems are properly managed and no one was being lazy or malicious by creating a one-time account they forgot about.
Use Group Policy to define accounts or services that are not allowed to log on locally
Let’s take the opposite approach. Do you have systems on your network(s) that should only be logged on by specific individuals, accounts, services, etc? Instead of relying on plainly on the security of your username and password, we should restrict this right to the specific accounts, computers, users, etc. that should have access. Only then, if they have the correct credentials are they allowed to login over the network.
Use Group Policy to allow access to computers from the network
By restricting this access to only the certain machines or users within a specific group, someone who has either found a set of credentials or has somehow infiltrated your network will only be able authorize a set of systems because others have been restricted.
Another example is to manage who has access to Log on Remote Desktop Services permissions. Does everyone need to access a set of systems (this goes for both workstations and servers)? I bet not, so why just enable RDP (Remote Desktop Protocol) for anyone who has valid credentials? We should tightly restrict who has access to our systems, especially when using RDP.
Use Group Policy to allow or deny access to Remote Desktop Services
For all situations regarding user rights and access to systems, we should always restrict access as much as possible. The key is to create these restrictions without being burdensome for your end-users. There is a fine line, but we should always attempt to be reasonable with this approach. Some systems just shouldn’t be accessed over RDP or locally, this will be up to the discretion of your organizations risk. Providing clear guidance and allowing your management to either enable these restrictions or to accept the risk is all that we as IT professionals can do.
