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.
Active Directory
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.
Active Directory Trusts are useful to connect one or more domains. But as useful those are, they can be very dangerous. Also, keeping trusts working and in good shape should be a top priority for Active Directory Admins. While there is a couple of command in the Active Directory module Get-ADTrust, I thought I would try and write my own that checks a few more things. I want to thank Chris Dent for his input on the part of this command. His binary skills amaze me!
In the Active Directory PowerShell module, you have two commands to your disposal that help display group membership. Those are Get-ADGroup and Get-ADGroupMember. The first command contains property Members, which gives you DistinguishedName of all members, and Get-ADGroupMember can provide you either direct members or with Recursive switch all members recursively (skipping groups). Till a few weeks ago, I was a happy user of those commands until I noticed two things. Member property for Get-ADGroup sometimes misses elements for whatever reason.
I’m pretty addicted to reading blog posts. I saw this new blog post the other day, where the author created the DHCP HTML report, and he did it by manually building headers, footers, table borders, and finally, adding some coloring to the percentage of DHCP being in use. It’s the „standard” approach to build HTML in PowerShell, and I’ve seen a similar path before, but that got me thinking how much time it would take for me to replicate the very same functionality using PSWriteHTML module.
Some months ago, I created PowerShell Script to create local administrative users on workstations – Create a local user or administrator account in Windows using PowerShell. It’s a bit overcomplicated, but the goal was it should work for Windows 7 and up, and that means supporting PowerShell 2.0. As part of that exercise, I’ve been using Win32_UserAccount WMI based query to find local users and manage them to an extent. While Get-LocalUser exists, it’s not suitable for the PowerShell 2.0 scenario. I also use the same query in GPO for WMI filtering. You can say it’s been a good friend of mine.
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:
The security account manager (SAM) has determined that the security identifier (SID) for this computer is already in use in the Forest you want to join. This can happen when restoring an Active Directory Domain Controller with an improper backup. Reinstall the operating system on the local AD DC to obtain a new SID.
Azure AD Connect allows three ways to make sure the user password is the same in Active Directory and Office 365. Those are Password Hash Sync, Pass-Thru Authentication, and ADFS. While my preferred option to go with would be Pass-Thru Authentication, only Password Hash Synchronization is the easiest and least resource-intensive. It synchronizes user password to Office 365, and even if your Active Directory is down, you can still log in to Office 365. It’s perfect for small and even more significant companies that don’t have resources or can’t guarantee that their infrastructure will stay 100% time online so users can authenticate based on their Active Directory.
One of the critical parts of Active Directory is DFS. It allows you to share same NETLOGON/SYSVOL folders across all Domain Controllers in your Forest. Its health is vital to the functionality of your Active Directory. If it’s broken, a lot of things may not work, and it’s not that easy to tell the status of it. At first sight, everything may seem to work correctly, but if you take a closer look – not so much. It’s great if you find it out by yourself, but not fun if suddenly GPO’s don’t apply to some users, computers, and you find out a year later.