Ok, here is a real-world problem: My company decided to force users to use smartcards and Feitian FIDO-keys to logon on our domain computers with no option to use passwords. I will not mention all the other problems that came up, especially with IT-stuff who couldn’t help remotely any of the regular users without smartcards connected to accounts with local-admin privilege. But that’s another story. My company bought a couple of thousand Feitian FIDO2 compatible keys that are supposed to be used by our domain users for MFA. Nice. Nobody thought about how those keys are treated by Windows. They are NOT smart cards, if you remove the key nothing will happen, you're still logged on until the screensaver kicks and locks the screen, all depending on your group policy. The problem is that people who ordered this solution took for granted that Feitian FIDO-keys (or any other USB-based solution like YUBI-key) would lock the computer as soon as the user pulled

We're all so confident in putting all of our data in hands of trusted companies, many just do it because it's there, it's cheap, the suppliers are trustworthy, just put everything in the cloud. It should be safe because most of the world is using it and the company is from the USA. Well, " That's not entirely accurate " as someone in " Independence Day " said. When you run your own data  on-premise  it implies that you are THE ONE responsible for the security, how it works, when the patches will roll out, who is responsible, everything. The major advantage is that ransomware attackers need to be more specific if they really want to attack just YOUR company. If they attack your dearly  ?aaS then they might get access to all of your sensitive data, internal network, everything. So easy and beautiful, knock off one and you have thousands of victims to harvest bitcoins from. It's like " Ender's Game " (read the book, please) or "

I usually want some kind of ticket back when i send configurations to the clients. With Active Directory Group Policies you will never know if all those fancy scripts of yours actually did something. If you have SCCM in your environment you could/should do it with more accuracy, get the status and remediate clients that do not comply.That is why i made custom AOVPN deployment script in Powershell that can use versioning when you need to upgrade your clients, change some ip range or whatever. Microsoft has a standard procedure that you can read about here , i borrowed most of the code and added some lines that should work with other deployment software, SCCM , Zenworks , Altiris etc. Alt 1: You will need only one file, Powershell script with everything (XML) embedded Alt 2: You'll need 2 files: Powershell script and XML as a separate file with configuration parameters for your VPN network. In this case i used machine-certificate IKEv2 type of configuration because it should work ri