Setting up an O.MG cable for keystroke injection attacks, and then forensically dumping the firmware for analysis.
Sometime a company just doesn’t document their network or active directory or anything for that matter- This is a point that makes me very grumpy and will no doubt be the point of quite a few future blogs!
There are design choices, that we as System Admins make that will need us to confirm or know certain things about out ADDS domain before we do stuff like roll out a new AD Site or Child Domain.
For example, where the hell are the FSMO role stored!
There are lots of ways, but I have a snippet of PS (That I shamelessly stolen from PowerShell magazine a few years ago that) that still works and is very useful – if you drop off the | Select-Object *owner – it will give you more information such as the current functional levels of both Domain and Forest. Kinda useful and cut and pasting is so much faster than clicking! After all Grumpy Admin is a lazy admin!
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() | Select-Object *owner
[System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest() | Select-Object *owner
I expect you will only ever need to run this once, and be able to remember after all us Administrators like to take ownership and know everything about our networks right???? But when you are new into a company with an existing infrastructure, the above is a fast and easy way to determine which naughty DCs holds the roles, rather than ask someone who fails to document a network they designed, planned, configured and run, as that would just make me super grumpy! But it means, I do have chance to at some point – start fresh and document the network I’m now on to the level I would expect, but then i’m a lazy admin so why would I create work for myself… that right because i’m a professional and if it makes me grumpy it will make the next guy in my seat grumpy and I expect his Blog will be better than mine!!!! lol