Having Bitlocker and LAPS in modern Active Directory is a must. But just because you enable GPO and have a process that should say Bitlocker and LAPS are enabled doesn’t mean much. Now and then you should verify things yourself. One of the Facebook users on PowerShell group just had this idea of exporting Bitlocker keys and then giving that list to his colleagues for manual verification. He wanted to do it half PowerShell and half manually. While the idea was great, why not take full advantage of PowerShell and have a helpful report with all the necessary information?
ad
There was I, deploying PSPasswordExpiryNotifications for one of my Clients when I started getting complaints that some users are not getting their Password Expiry Notifications. Well, that’s a new one. I’ve tested this script multiple times, and it worked just fine. So I dive into the details of my script to see what I did in there (I don’t even remember anymore – it just works) to find out this little line:
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.
I’ve been testing Disaster Recovery scenario restoring Active Directory. One of the servers was restored, and it worked for a moment after restore. If you can regain your Primary DC, it’s best to do so. If you can’t, a standard thing to do during DR is to move all FSMO roles to the restored server so that it can become a master server. You can find out your FSMO holders by using those commands below:
Working as a freelancer is a great thing if you can handle it. Each day, each week something new happens and a new problem shows up on my doorstep. It also means it’s almost never boring at your job and you get to play with new stuff. But there’s one drawback to this. You’re often thrown at the problem, told to fix it but often that’s about as much information as you get. It wasn’t very different today. I was told to switch Office 365 from ADFS to Password Synchronization. While reasons for this are not really important, the important question here is what is the name of AD Connect server that’s responsible for this configuration?
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.
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!
