What’s new – Event Monitoring v0.6

Some time ago, I wrote a blog post on checking for LDAP, LDAPS, LDAP GC, and LDAPS GC ports with PowerShell. It mostly works, but it requires a tad bit of effort, and it doesn’t cover the full scope that I wanted. Recently (well over 3 years ago), Chris Dent shared some code that verifies the LDAP certificate, and I thought this would be good to update my cmdlets to support just that with a bit of my own magic on top.

I’ve been testing Disaster Recovery scenario restoring Active Directory. One of the servers was restored, and it worked for a moment after restore. If you can regain your Primary DC, it’s best to do so. If you can’t, a standard thing to do during DR is to move all FSMO roles to the restored server so that it can become a master server. You can find out your FSMO holders by using those commands below:

Having Bitlocker and LAPS in modern Active Directory is a must. But just because you enable GPO and have a process that should say Bitlocker and LAPS are enabled doesn’t mean much. Now and then you should verify things yourself. One of the Facebook users on PowerShell group just had this idea of exporting Bitlocker keys and then giving that list to his colleagues for manual verification. He wanted to do it half PowerShell and half manually. While the idea was great, why not take full advantage of PowerShell and have a helpful report with all the necessary information?

I work a lot with Active Directory-related tasks. One of the tasks is to know the group membership of critical Active Directory Groups such as Domain Admins, Enterprise Admins, Schema Admins, Event Log Readers, and a few others that are a bit less known. As I did it, I got bored of typing the group names repeatedly and decided that enough was enough and there must be an easier way for me to do that.

PasswordSolution uses the DSInternals PowerShell module to gather Active Directory hashes and then combines that data into a prettified report. If you have ever used DSInternals, you know that while very powerful, it comes with raw data that is hard to process and requires some skills to get it into a state that can be shown to management or security.

I shouldn’t be telling you that, but Active Directory Backup is an essential part of your Active Directory setup. When a backup of Active Directory happens, AD is aware of it. Following PowerShell solution allows you to get Active Directory Last Backup Time for the whole forest or by domain.

When working with Active Directory one of the common tasks is to move FSMO roles between servers. Well, maybe not that common but it happens from time to time where you have to move all or just some of the FSMO roles. For that purposes, there is single PowerShell command Move-ADDirectoryServerOperationalMasterRole. Sure you can do this via GUI but if there’s one command available to fix it all why bother? To make the move one has to be a Domain Admin, Enterprise Admin and Schema Admin. Everything was going smoothly for some roles but wasn’t working for others.

I’ve been working on cleaning up Group Policies for a couple of months. While it may seem trivial, things get complicated when you’re tasked with managing 5000 GPOs created over 15 years by multiple teams without any best practices in mind. While working on GPOZaurr (my new PowerShell module), I’ve noticed that the more code I wrote to manage those GPOs, the more I knew passing this knowledge to admins who will be executing this on a weekly/monthly basis is going to be a challenge. That’s why I’ve decided to follow a similar approach as my other Active Directory testing module called Testimo. I’ve created a single command that analyses Group Policies using different methods and shows views from different angles to deliver the full picture. On top of that, it provides a solution (or it tries to) so that it’s fairly easy to fix – as long as you agree with what it proposes.

Working as a freelancer is a great thing if you can handle it. Each day, each week something new happens and a new problem shows up on my doorstep. It also means it’s almost never boring at your job and you get to play with new stuff. But there’s one drawback to this. You’re often thrown at the problem, told to fix it but often that’s about as much information as you get. It wasn’t very different today. I was told to switch Office 365 from ADFS to Password Synchronization. While reasons for this are not really important, the important question here is what is the name of AD Connect server that’s responsible for this configuration?

In the last weeks, I’m working on a PowerShell module that the main goal is to work on gathering and fixing GPOs. I’ve been testing my module a lot of times on my test environment, and it worked fine till the moment I run it on production, and it started to fail pretty quickly. The difference between my environment and production is 25 GPOs vs. 5000 GPOs. The error I was getting:

One of the common ways to connect to Active Directory is thru LDAP protocol. There are a lot of applications that talk to AD via LDAP. By default Active Directory has LDAP enabled but that’s a bit insecure in today’s world. That’s where LDAPS comes in. It’s not easy to set up, but when you get it done, it works. The problem I had recently is that while setting up LDAPS on DC’s I only did this on some of the DC’s, and not all of them as I should.