search

ansible-lockdown / Windows-2022-CIS

CIS Baseline Ansible Role for Windows 2022
MIT License
71 stars 30 forks source link

fix: adjusted execute order of 1.2.1, 1.2.2, 1.2.3 to prevent failure in AWS #13

Closed ChiefHolland closed 1 year ago

ChiefHolland commented 1 year ago

Overall Review of Changes

Using Packer to create hardened AMI for Windows Server 2022 was failing due to the lockoutduration being less than the lockoutcounter.

Issue Fixes

Changing the order of execution to satisfy lockoutduration value set prerequisites. See https://github.com/ansible/ansible/issues/62594#issuecomment-533455130

georgenalen commented 1 year ago

@ChiefHolland Thanks for the PR and good catch on the var in defaults/main. I'm trying to sort out the order change for 1.2.1, 1.2.2, and 1.2.3. The order they are in with the role are the only order that work for a physical box I have, VM's in vagrant, and our AWS accounts. It looks like that order change was something related to your packer build, can you add a bit more detail there?

-George

ChiefHolland commented 1 year ago

@georgenalen Absolutely! I'm pulling the Windows Server 2022 Full AMI from AWS and using that as the base to apply the patches. Every time I would hit 1.2.1 (which was already placed after 1.2.2), it would fail with an error that pointed to the value it was attempting to apply was rejected. That was what led me to the string value of that variable. Changing it to an int didn't fix the problem, but I left it in the PR to be consistent with the other variable values in that file.

From the research I did, it seems the Windows image I'm using as a base might be applying a higher default value (30 min ?) to the time it takes to reset the lockout counter after a failure (win22cis_resetlockoutcount). According to the link I posted in the original PR, the lockoutduration must be equal or greater than the resetlockoutcount, which is why I changed the order. That did work. My assumption was that the default value of resetlockoutcount, which I have not verified in the base AMI as of yet, was Microsoft's default across the board. That might be the issue we're having between our different builds. I'll dig a little more, and we might get by with just adding a comment to help others down the line.

EDIT: I checked into this, and the default value of the Account Lockout Counter in the AMI I'm using is None/null, as the control isn't enabled. That explains why the Lockout Duration cannot be applied in my situation. I will look at building a conditional for this issue and revisit with a different PR.