What’s new – Event Monitoring v0.7

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.

A few weeks ago I’ve released my first version of PSWinDocumentation. It was simple, one command module where you start it and get some basic AD stuff into Microsoft Word document. Today… I’m releasing a new version that has a bit bigger feature set. Are you ready for it? Let’s go!

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.

Having a modern, secure infrastructure in 2019 is a requirement. You should implement BitLocker to make sure that in the event of stolen laptop data is not readily extractable and implementing LAPS is a must in a fast changing IT world. But I’m not here to convince you to those two security features. I’m here to show you an easy way to backup LAPS and BitLocker. While having everything stored in Active Directory is excellent, things can get complicated when you don’t have access to your Active Directory, or you restore an older version of it. You see, LAPS, for example, keeps only last Administrator password. This is great and all but what happens if you restore the machine from backup from 6 months back? Your password has already changed multiple times. During our testing of DR scenarios, we wanted to access the computer via their local Administrator credentials and we just couldn’t because that password was already gone.

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.

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.

Azure AD Connect is an application responsible for synchronizing Active Directory with Azure AD allowing for a natural population of users, groups, and devices in Office 365. While for most companies standard setup is very easy and most of the time touch-free, there are companies which require greater customization. During installation of AD Connector, you choose what should be used for Azure AD Username from your AD. UserPrincipalName field is an obvious choice for this and also proposed by default for that purpose. This field is utilized further by your users to log in to your Exchange, SharePoint, Teams and so on.

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.

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:

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.

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.

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.

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.