Visual Studio Code and Azure DevOps (formerly VisualStudio.com) Integration Step-by-Step

My previous video walked through the process of using the old Visual Studio Team Services VS Code extension. That extension has now been deprecated. With the latest version or VS Code (I installed v 1.28.1) you should see the Azure Repos extension baked into VS Code. The only other requirement is a local Git repo (I installed 2.19.1). Once you have all the software installed it’s much easier to get this going, all the steps are below as well as in the video.

Step 1: Download and install VS Code (Download Link: https://code.visualstudio.com/download). The default install should work fine.

Step 2: Download and install Git (Download Link: https://git-scm.com/download). Choose all the defaults except change VS Code to the default editor. That’s actually optional but I did it.

Step 3: Access your VisualStudio.com / Azure Repos repo and click the “Clone to VS Code” link… see the video for details. You’ll be asked where in the file structure to clone the repo and prompted for your VisualStudio.com / Azure Repos credentials.

At this point you should be all set. Make sure you test changing a file and committing it to the cloud just to make sure. It’s a much easier process than before but I wasn’t able to find instructions on the interweb thus, this video and writeup.

Thanks for watching / reading.

Enterprise Security: How to configure and use Group Managed Service Accounts

I routinely see organizations big and small still using “regular” Active Directory user accounts as service accounts. Typically, they have the password for those service accounts set to never expire or an alternate password policy that only requires the password is changed yearly. If your organization is managing service accounts like this you are only increasing the potential for exploitation when a nefarious actor gets inside your enterprise. It’s a matter of WHEN not if.

With the introduction of Windows Server 2012, Microsoft introduced Group Managed Service Accounts to address this specific situation. Group Managed Service accounts (gMSA) are an upgrade from the Managed Service accounts that were available in Windows Server 2008 in that gMSA can be used on multiple servers. There is no need to create a specific service account for each server although, your internal policies may dictate otherwise.

Why use gMSA?

  • The Password is managed in Active Directory (AD) and is changed every 30 days by default.
  • Because the password is managed by AD, no human will ever know the password.
  • gMSA passwords are 240 bytes long so they are complex.
  • gMSAs are not permitted to logon interactively.

How do I configure and use a gMSA?

The code below is everything you need to get started with gMSAs. Also, take a look at the video below for a more in-depth walk-through of the process.

Do yourself a favor… get rid of legacy service accounts. It’s one of those things you can do to incrementally harden your enterprise.

Quickly deploy LAB Virtual Machines with the AutomatedLab PowerShell Framework

My Requirements:

  • Use PowerShell to minimize the time spent on creating VMs.
  • Install ADDS along with the VM creation.
  • Use a differencing disk for all the VMs to save disk space.

In the spirit of kickstarting this channel again, I needed to spin up a few Virtual Machines to facilitate PowerShelling. I was going to go through the process of using the Hyper-V management Cmdlets when I stumbled upon the AutomatedLab framework on GitHub (https://github.com/AutomatedLab/AutomatedLab). I had never used this framework before, so a little trial and error was in order.

Kudos to the developers, they have included an assortment of sample Lab scripts that you can easily modify to suit your needs and get going fairly quickly without a lot of hassle. The framework also includes the ability to install some applications like Exchange, SQL and a few others. There are many more features included that I haven’t started playing with yet. It’s worth having a look, particularly if you find yourself doing things like demoing applications or testing GPO settings on a regular basis.

 

The code I used to spin out my lab is below.

 

Enjoy

I’m resurrecting the YouTube channel.

I’m going to resurrect the YouTube channel and start making videos as time allows. That said if you have something specific you would like to see contact me using one of the methods below and I’ll see if I can work it in at some point.

More to follow…

 

Advanced Auditing with PowerShell Desired State Configuration Manager (DSC)

Greetings interweb. It’s been a while but I’m back with a new video finally.

This video focuses on Desired State Configuration Manager (DSC) and how to configure Advanced Auditing using DSC. You can certainly configure DSC using a group policy object (GPO). My use case for this is if you have a public facing web server that is in a DMZ outside the trusted side of your network. In that case, you probably don’t want that public facing Server on your domain but you also what to audit it and patch it and all of those other security processes you might run on any other server on the trusted side of the network.

For this exercise we will install DSC on a domain joined server (Pull Server) and configure that public facing server that’s in the DMZ to pull configuration from the Pull server.

Part 1: The Pull Server

All of this code is executed on the domain-joined Pull server.

Step 1: Install the required DSC modules, we need the 3 below. You can get all of them from powershellgallery.com

These 2 are for DSC itself

Install-Module -Name PSDscResources

Install-Module -Name xPSDesiredStateConfiguration

 

This module allows us to configure Advanced Auditing with DSC

Install-Module -Name AuditPolicyDsc

Step 2: You need a certificate on the Pull Server and any client that will connect to the pull server. This is the mechanism used to authenticate the client since it’s not in the domain.

In my case, I just installed certificate Services on my Pull Server. It’s literally the default installation, all you need is a Root CA. You could also manually create a certificate without installing certificate services but I found this more problematic than it was worth. Certificate services was the path of least resistance for me.

Certificate Services Step by Step: https://technet.microsoft.com/en-us/library/cc772393(v=ws.10).aspx

Step 3: Now we need to export the certificate so we can import it on the DSC client side. You’ll need to import the certificate on any non-domain DSC client. All of this code is from http://duffney.io/Configure-HTTPS-DSC-PullServerPSv5, I changed some of the information to fit my naming scheme, other than that it’s almost identical.

Step 4: Now we can install Desired State Configuration Manager on the Pull Server. Almost all of this code is identical to what you will find on MSDN with a few modifications to match my naming scheme. See the video above for a more detailed explanation of what’s going on here.

Once the DSC installation is complete, check the web address for the Pull Server. It should be, https://<your server name>dc:8080/PSDSCPullServer.svc/. If you get some XML output your pull server is good to go… theoretically.

Step 5: Create the MOF files for the DSC client. This code is pretty much the same code as is in the example on the module github repo. https://github.com/PowerShell/AuditPolicyDsc

Step 6: We need to package the MOFs and DSC resources and put them in the correct file structure on the Pull Server in order for the clients to pull what’s needed. The $MOFPath in this script is where you created the MOF files in the script above, you may need to change this if you used a different file location.

DSC Pull Server Mission complete!

Part 2: The DSC Client

Step 1: Configure the Local Configuration Manager on the client. Before you run the code below, it’s worth testing the connectivity to the Pull server website. In my case, this is my site to the Pull Server https://10.0.10.1:8080/PsDscPullserver.svc. I use the IP address for the Pull server because the client is not on the Domain so DNS is not going to work unless you add a manual entry in the Host file on the client.

Step 2: If you run Get-DscConfiguration and it comes back ok, the client should be properly registered with the Pull server.

Step 3: Now that the Pull server and the client are working, we need to figure out what the format for the CSV file is that we want to use to configure Advanced Auditing. See the video to understand how I figured out the format. My CSV is linked below.

Step 4: Once you have the CSV file complete and in the correct file location run the flowing to refresh the DSC config.

Run this to verify the Audit Policy is exactly the way you had it configured in the CSV.

Hope you enjoyed that tutorial… may the PowerShell force be with you all. 🙂