Encrypting and decrypting PGP using PowerShell

Recently I got a simple task to implement LAPS for the newly created local user instead of using the built-in local administrator account. It seemed easy at first. Go to Group Policies, create a new user, add it to an administrators group, and then follow standard steps to implement LAPS. That is until you find out it’s actually not possible anymore due to password encryption key being available in the wild, which made Microsoft block that Group Policy Preference. While that road is blocked, I still need to get my user-created somehow. Let’s do it with PowerShell. It’s quite simple – use New-LocalUser a few parameters, some random password that I don’t need to save as LAPS will overwrite it. Except it’s not available on PowerShell 2.0, which is the default for Windows 7 that I have to support. Things get even more complicated if you consider that Administrators group is called differently in different countries. While I stopped supporting anything below PowerShell 5.1, I can’t say if it’s the project requirement.

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.

It’s no secret that nobody likes creating documentation. I don’t like it, and you don’t like it, even documentation lovers don’t like it. But while you can live without documentation, you really shouldn’t. And I am not talking here only about documentation that is only useful in the onboarding process of new employees or documentation concerning introducing someone to some concepts to get them easily start. I’m talking about documentation for your live environment where you know what you have, how you have set it up, but is still the same after one week, one month, or one year? Usually, not so much. And one of the worst mistakes admin can do is assume that his environment doesn’t change, things are as they were when they were set 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 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.

A few weeks ago, I posted a concept migration diagram for Office 365 to Twitter and Facebook. Today I thought I would show you how you can do it yourself using PowerShell and PSWriteHTML PowerShell module. When I started working on this, I’ve thought I want to create before and after infrastructure to see how it will look when migration ends. I’ve initially planned to assign myself an Office 365 Visio Plan 2 license and do something manually, thinking it may be just much easier. Unfortunately for me, there were no free Visio licenses in my tenant, and my laziness took over, so I’ve decided to give it a go using PowerShell only.

I have to admit – executing the same command three times and expecting different results is dumb, but I still do it anyway. Fortunately, after trying three times I usually resort to other methods and try to solve the problem I have. Today while trying to trust PowerShellGallery I was greeted with an error.

I must admit that it was a bit embarrassing to see my Administrator password expired when I tried to log in as Domain Admin to Domain Controller. I got this little message saying This user account’s password has expired. The password must change to logon. Please update the password or contact your system administrator or technical support.

A new branch of PSWinReporting is slowly coming, and I thought it would be the best time to have a final article about it with all configuration options available for those that will want to stay using PSWinReporting from Legacy branch. The idea is that you may have it working in your systems and it’s good enough for you. You may not want to change it, and with New Hope, the changes are so big it’s a rewrite.

A few days ago, I was asked to take a look at PowerShell Malware. While I don’t know much about malware, my curiosity didn’t let me skip on this occasion, and I was handed over WindowsPowerShell.evtx file. Ok, that’s not what I expected! I wanted PowerShell .ps1 files that I can read and assess? Well, you play with the cards you were dealt with. What I was handed over was PowerShell Event Log. PowerShell writes whatever you execute, and it thinks it is risky, to Windows PowerShell Operation Event Log.

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.

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.