What’s new – Event Monitoring v0.7

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.

If you ever encounter an error while trying to create a new domain within a forest saying, „The replication operation encountered a database error,” it makes you sweat a bit. Your brain tells you it will be a nightmare to fix, do I have proper backups to make it happen, and the question „why now” shows up.

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’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.

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.

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.

If you’re paying attention to what’s happening around the world now you probably know Have I Been Pwned service by now. You probably know that it has huge lists of hashes of passwords that leaked out over the years from different services (LinkedIn, Adobe, and so on). This means those passwords are now in possession of good guys, but also bad guys. With Active Directory being often a central place to store your password that allows you to access your Office 365 account, ADFS, Microsoft Exchange it’s important that your AD passwords is both secure and safe. Bad guys may want to try and access your email accounts or other data that’s available online. And having a list of passwords you or other people may have used before doesn’t help you in protecting your own data.

While the title of this blog may be a bit exaggeration, the command I’m trying to show here does it’s best to deliver on the promise. What you’re about to witness here is something I’ve worked on for a while now, and it meets my basic needs. If you don’t have SIEM product or products that monitor who does what in Active Directory this command makes it very easy, even for people who don’t have much experience in reading Event Logs. If you’d like to learn about working with Windows Event Logs here’s a great article I wrote recently – PowerShell – Everything you wanted to know about Event Logs and then some.

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.

Today I saw an article on how to get Windows Version Report from Active Directory and thought that this is a cool idea. Something handy for migration scenarios or information on how up to date is your infrastructure. Since there are many ways to do the same thing I decided to tackle this myself and further include it into PSWinDocumentation.AD project. By default Active Directory stores Operating System and Operating System Version but it doesn’t really show versions one may expect.

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.