We have discovered that the DISA STIG Sites updates, with server subscriptions to these sites, are flooding our Domain Controllers with SAMR requests :
BigFix Compliance: Updated DISA STIG Checklist for Windows 2016, published 2024-03-06
BigFix Compliance: Updated DISA STIG Checklist for Windows 2022, published 2024-02-27
BigFix Compliance: Updated DISA STIG Checklist for Windows Server 2019, published 2024-02-22
The updates have modified some content that is generating SAMR requests to our Domain Controllers on every client evaluation cycle - this is basically creating a Denial of Service attack on my Domain Controllers. I have removed all server subscriptions from the above sites, and now my Domain Controllers are working normally.
I highly recommend you look at the changes made to the above sites and review the relevance checks because I am concerned that you will have other compliance customers that will be having this same issue.
I would like to know what check(s) in these versions of the DISA STIG sites are creating these SAMR requests.
Is there a way I can see what specific content was updated on these versions of the DISA STIG sites?
I recommend opening a support case with HCL. While posting on forums may lead to visibility by the product support team, personalized assistance and thorough investigation are best achieved through direct interaction via a support case. This ensures that your issue receives dedicated attention and allows for a deeper analysis of your specific circumstances.
I opened a case last Friday. The support engineer has sent it to engineering for evaluation. I thought it may be wise to let other bigfix compliance customers know there is an issue. I can try to determine what evaluation is causing the issue, but that is a lot of work. It would be nice to know what HCL updated specifically in the latest release of these sites since Bigfix Announcements does not provide that information. I thought maybe there was another place I could get that information that I am not aware of - hence this post.
There have been potential for overwhelming Domain Controllers with the Compliance checklists that goes back years. I’m not certain that a content change introduced the issue, I’ve seen similar reports going back years and it’s often a balance between how many clients are subscribed to checklist sites, and the number & scale of your Domain Controllers to handle the workload.
I’d start by disabling any of the Measured Values analyses, if you’re not using them, as those can more than double the evaluation workload & trigger more DC lookups.
I also agree with opening the case, but I’m not certain you should expect any kind of quick resolution on it.
We did not have a SMAR flood going on before the most recent update to windows DISA STIG Sites. We have had these site enabled for 10 years and never had any issue. I have identified the Fixlets and relevance that is triggering problem. I also added 2 additional domain controllers and guess what, it made very little difference. Every time this relevance runs, it makes a very expensive SAMR call to the DCs and when I have 1700 servers doing this, they get overwhelmed. So I can longer subscribe my servers to use your DISA STIG Content as a result. Maybe that’s bad practice anyway.
Here are the fixlets causing the samr flood – please pass to engineering.
141096 Windows Server 2019 must have the built-in guest account disabled.
123968 Windows Server 2016 built-in guest account must be disabled.
151155 Windows Server 2022 must have the built-in guest account disabled.
not exists 1 whose (((not exists (property “name” of it as string, property “disabled” of it as string, property “localaccount” of it as string ) of (select objects (“Name,SID, Disabled, LocalAccount from Win32_UserAccount”) whose ((exists string value whose (first 9 of it = “S-1-5-21-” and (last 4 of it = “-501”)) of property “SID” of it) and (exists string value whose (it as string contains “False”) of property “Disabled” of it)) of WMI)) and (product type of it = nt domain controller product type) of operating system) or ((not exists (property “name” of it as string, property “disabled” of it as string, property “localaccount” of it as string ) of (select objects (“Name,SID, Disabled, LocalAccount from Win32_UserAccount”) whose ((exists string value whose (first 9 of it = “S-1-5-21-” and (last 4 of it = “-501”)) of property “SID” of it) and (exists string value whose (it as string contains “True”) of property “LocalAccount” of it) and (exists string value whose (it as string contains “False”) of property “Disabled” of it)) of WMI)) and (product type of it != nt domain controller product type) of operating system))
For what it’s worth, I do see the change that introduces this problem, at least on Win2016 it does apply only to the latest site version where it switches to a WMI query to enumerate accounts. I’ve opened an internal discussion on it but a customer-submitted but report would get higher priority. Thanks for bringing this to our attention.
We have updated the relevance to use local users instead of WMI for the check “Windows Server 2016 built-in guest account must be disabled”. The customer who reported this issue has tested and confirmed that it is no longer generating load on the Domain Controller. We have production propagated the same for Windows 2016, 2019 and 2022.
I respectfully request that, in the future, when you provide the BigFix Announcement for Updates to the Compliance Sites, that you specify the ID and Name of the checks/fixlets that you have added/changed/updated (from the previous version) so that I can verify that new version of the site (content) will not do evil things to my network. I would find that very helpful.
I can confirm that the new relevance is NOT causing a SAMR storm with the updated checks for:
141096 Windows Server 2019 must have the built-in guest account disabled.
123968 Windows Server 2016 built-in guest account must be disabled.
151155 Windows Server 2022 must have the built-in guest account disabled.
not exists 1 whose (((product type of it = nt domain controller product type) of operating system) or (exists (concatenation ", " of (it as string) of (not account disabled flag of it = (it != “0” and it as lowercase != “false”) of (“0”)) of local users whose (exist matches (regex “^S-1-5-21-\d+-\d+-\d+-501$”) of component string of sid of it)) whose (number of substrings separated by ", " whose (it is not “”) of it > 0 and number of substrings separated by ", " whose (it is not “”) whose (it as boolean is False) of it = 0)))