Feature Request or Enhancement

• Feature
• Enhancement

Summary of Request
Control 1.1.6 - Ensure Relax minimum password length limits is set to Enabled.
should be enabled by default and an alternative implementation done.

Describe Alternatives You've Considered
Updating the registry key

Suggested Code

- name: "1.1.6 | PATCH | Ensure Relax minimum password length limits is set to Enabled."
  ansible.windows.win_regedit:
      path: HKLM:\System\CurrentControlSet\Control\SAM
      name: RelaxMinimumPasswordLengthLimits
      data: 1
      type: dword
  when:
      - win22cis_rule_1_1_6
  tags:
      - level1-memberserver
      - rule_1.1.6
      - patch
      - password

Describe the Issue
CIS Control 18.6.4.3 is misconfigured. Multicast name resolution is enabled instead of disabled via the Ansible Lockdown module.

Expected Behavior
According to the GPO description the value of EnableMulticast should be '0':

If you enable this policy setting, LLMNR will be disabled on all available network adapters on the client computer. See admx.help.

Actual Behavior
Ansible Lockdown enables multicast name resolution by setting the value to '1'.

- name: "18.6.4.3 | PATCH | Ensure Turn off multicast name resolution is set to Enabled MS Only | Member Server"
  ansible.windows.win_regedit:
      path: HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient
      name: EnableMulticast
      data: 1
      type: dword

Control(s) Affected
18.6.4.3. (L1) Ensure 'Turn off multicast name resolution' is set to 'Enabled'

Environment (please complete the following information):

• branch being used: devel
• Ansible Version: 2.14.2
• Host Python Version: Python 3.11.5
• Ansible Server Python Version: Python 3.11.5
• Additional Details:

Additional Notes
N/A

Possible Solution
Change the data value:

- name: "18.6.4.3 | PATCH | Ensure Turn off multicast name resolution is set to Enabled MS Only | Member Server"
  ansible.windows.win_regedit:
      path: HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient
      name: EnableMulticast
      data: 0
      type: dword

Describe the Issue
The main tasks file Windows-2022-CIS/tasks/main.yml has import_tasks tasks and when statements for each CIS section. I noticed task related to importing section 18 tasks uses the when statement for section 17.

- name: Execute the section 18 tasks
  ansible.builtin.import_tasks:
      file: section18.yml
  when:
      - win22cis_section17
  tags:
      - section18

Expected Behavior
When the variable win22cis_section18 is set to false, section18.yml shouldn't be included in the play.

Actual Behavior
A clear and concise description of what's happening.

Control(s) Affected
What controls are being affected by the issue

Environment (please complete the following information):
Additional Notes
Anything additional goes here

Possible Solution

- name: Execute the section 18 tasks
  ansible.builtin.import_tasks:
      file: section18.yml
  when:
      - win22cis_section18
  tags:
      - section18

Describe the Issue
Section 18 controls are missing or have default values that do not match the CIS controls.

Expected Behavior
Pass on all controls

Actual Behavior
Some controls are failing

Control(s) Affected

• 18.6.4.3
• 18.10.81.2
• 18.10.81.3
• 18.10.93.4.1

Environment (please complete the following information):

• branch being used: devel
• Ansible Version: 2.15
• Host Python Version: n/a
• Ansible Server Python Version: 3.8.2
• Additional Details:

Additional Notes
Testing with CIS Assessor

Possible Solution
Will make a PR.

Issue
After applying cis principal from devel branch, I was not able to add extra volumes to my ec2 machine

Expected Behavior
It should automatically initialize and used by Local Disk Manager such that it can access it.

Actual Behavior
Not able to initialize automatically, need to initialize manually

Environment (please complete the following information):

• branch being used: devel
• Ansible Version: 2.16.3
• Host Python Version: Python 3.12.1
• Ansible Server Python Version: Python 3.12.1
  

Describe the Issue

The "Get Windows installation type" & "Set Windows installation type" tasks are missing the "always" tag in tasks/main.yml

Expected Behavior

Playbook completes successfully when using this role and specifying tags.

Actual Behavior**

Playbook fails due to "windows_installation_type" being undefined since these two tasks are untagged.

Control(s) Affected

Any task that depends on the "windows_installation_type" variable.

Environment (please complete the following information)

ansible [core 2.14.6]
config file = /home/j.cook3/ansible/ansible.cfg
configured module search path = ['/home/j.cook3/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /opt/ansible-python/lib64/python3.9/site-packages/ansible
ansible collection location = /home/j.cook3/ansible/collections:/home/j.cook3/ansible_collections
executable location = /opt/ansible-python/bin/ansible
python version = 3.9.16 (main, Dec 23 2022, 09:55:36) [GCC 8.5.0 20210514 (Red Hat 8.5.0-17)] (/opt/ansible-python/bin/python3.9)
jinja version = 3.1.2
libyaml = True

Target server: Windows 2022 Standard

Possible Solution

Add the "always" tag to the two tasks:

- name: Get Windows installation type
  ansible.windows.win_reg_stat:
      path: HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion
      name: InstallationType
  register: get_windows_installation_type
  tags:
    - always

- name: Set Windows installation type
  ansible.builtin.set_fact:
      windows_installation_type: "{{ get_windows_installation_type.value | default('') }}"
  tags:
    - always

Question

After applying for WINDOWS-2022-CIS roles, I cannot RDP after the reboot of Windows server 2022, what's needs to be done to fix the issue?

Environment :

• Ansible Version: [ 2.14.6 ]
• Host Python Version: [ Python 3.9.18 ]
• Ansible Server Python Version: [ Python 3.9.18 ]
• Additional Details: I am creating golden image AMI with the help of WINDOWS-2022-CIS roles, but as soon as all tasks are completed and I restart of machine, I am not able to login to my new machine.

Describe the Issue
Ordering of the applied controls makes it fails

Expected Behavior

TASK [Windows-2022-CIS : 1.2.2 | PATCH | Ensure Account lockout threshold is set to 5 or fewer invalid logon attempt(s), but not 0. | Set Variable.] ***
changed: [10.0.0.3]

TASK [Windows-2022-CIS : 1.2.3 | PATCH | Ensure Allow Administrator account lockout is set to Enabled] ***
changed: [10.0.0.3]

TASK [Windows-2022-CIS : 1.2.4 | PATCH | Ensure Reset account lockout counter after is set to 15 or more minutes. | Set Variable.] ***
changed: [10.0.0.3]

TASK [Windows-2022-CIS : 1.2.1 | PATCH | Ensure Account lockout duration is set to 15 or more minutes. | Set Variable] ***
changed: [10.0.0.3]

Actual Behavior
The current order fails

Control(s) Affected

• 1.2.1
• 1.2.2
• 1.2.3
• 1.2.4

Environment (please complete the following information):

• branch being used: devel
• Ansible Version: 2.15
• Host Python Version: does not apply (Windows)
• Ansible Server Python Version: 3.11.5
• Additional Details: None

Additional Notes
None

Possible Solution
Azure requires a different order, however AWS can use the standard order (same as local).
Setting win22cis_cloud_based_system in prelim.yml to false for AWS would fix the issue.

Describe the Issue
Under the following file... https://github.com/ansible-lockdown/Windows-2022-CIS/blob/devel/tasks/section18.yml you have the following code:

- name: "18.10.43.10.2 | PATCH | Ensure 'Turn off real-time protection' is set to 'Disabled'"
  ansible.windows.win_regedit:
      path: HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection
      name: DisableRealtimeMonitoring
      data: 1
      datatype: dword

I believe this is actually doing the opposite of what is intended. This was brought to my attention by an incident created in Microsoft Defender for Endpoint. It flagged a high severity incident that Ansible was disabling Defender protection.

Expected Behavior
I believe this should be setting the dword value to 0 as highlighted here...

https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsDefender::DisableRealtimeMonitoring

I can see the confusion with the use of Disabled/Enabled. But when Enabled (dword value 1) you are Enabling the Disabling of the setting. i.e. DisableRealtimeMonitoring = true.

Registry Hive | HKEY_LOCAL_MACHINE
Registry Path | Software\Policies\Microsoft\Windows Defender\Real-Time Protection
Value Name | DisableRealtimeMonitoring
Value Type | REG_DWORD
Enabled Value | 1
Disabled Value | 0

Control(s) Affected
18.10.43.10.2

Environment (please complete the following information):

Using git tag 2.0.0. Have checked latest devel and it is still the same.