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.
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.
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.
I’ve been in IT for a longer time now. I’ve made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.
Recently I was testing renaming the NETBIOS name of an Active Directory domain. While this process is fairly easy, there are a few gotcha’s, and before one would like to rename their domain or NETBIOS name, serious testing is required to be sure everything works after rename. In the end, if something goes wrong, the rollback will not be a walk in a park. It will hurt, and it will eat your time. So there was I going thru the usual steps.
We need to deal with a group names through SID’s rather than names because each group name is different in different languages. The second problem is to distinguish whether a user is a local or domain user. Finally, I need to connect to Active Directory to verify if the user I am about to remove has ExtensionAttribute10 (or any other field in AD) filled in or not.
Setting up a new Active Directory is an easy task. You download and install Windows Server, install required roles and in 4 hours or less have a basic Active Directory setup. In an ideal world that would be all and your only task would be to manage users, computers, and groups occasionally creating some Group Policies. Unfortunately, things with Active Directory aren’t as easy as I’ve pictured it. Active Directory is a whole ecosystem and works well ranging from small companies with ten users to 500k users or more (haven’t seen one myself – but so they say!). When you scale Active Directory adding more servers, more domains things tend to get complicated, and while things on top may look like they work correctly, in practice, they may not. That’s why, as an Administrator, you need to manage Active Directory in terms of its Health and Security. Seems easy right? Not quite. While you may think you have done everything, checked everything, there’s always something missing. Unless you have instructions for everything and can guarantee that things stay the same way as you left them forever, it’s a bit more complicated. That’s why Microsoft delivers you tools to the troubleshoot your Active Directory, such as dcdiag, repadmin and some others. They also sell monitoring solutions such as Microsoft SCOM which can help and detect when some things happen in your AD while you were gone. Surely there are some 3rd party companies give you some tools that can help with a lot of that as well. Finally, there is lo of folks within the community creating PowerShell scripts or functions that help with some Health Checks of your Active Directory.