Have you ever looked at your Active Directory and wondered, “Why do I still have computers listed that haven’t been turned on since World Cup 2016?” Yeah, we’ve all been there. Keeping AD clean and up-to-date is like trying to organize your garage—it’s easy to put off until it becomes a total mess.
ad
I was scrolling X (aka Twitter) today and saw this blog post, “PowerShell: Report On-Premises Active Directory Accounts that are Synchronized with Azure AD Connect” by Kevin Trent. I like reading blog posts as I tend to learn some new things and see how people tend to solve their problems.
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 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.
Today’s blog post is about Active Directory-integrated DNS and how to find duplicate entries. By duplicate, I mean those where one DNS name matches multiple IP addresses. While some duplicate DNS entries are expected, in other cases, it may lead to problems. For example, having a static IP assigned to a hostname that later on is also updated with dynamic entries.
Duplicate SPNs aren’t very common but can happen in any Active Directory as there’s no built-in way that tracks and prevent duplicate SPN’s. One has to either know all SPN’s in the environment, track them or check each time whether it already exists or not. Things get more complicated with larger Active Directory environments as people change, new apps are added, old apps are forgotten, but SPNs prevail.
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.
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.
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.
In Active Directory when you change something, it’s replicated to other Domain Controllers regularly. It’s a standard procedure that happens automatically in the background for you. It’s a handy feature because you can have multiple DC’s all over the world and have your users data in sync. You can change almost anything on DC nearest to you and be sure it will be the same value all over the place. But is it always the same? Well, it should be unless it isn’t. Today I was given a new migration from Exchange to Office 365. I started with ADConnect installation and wanted to make sure that UserPrincipalNames have all UPNSuffixes in place.