0X00002082: Active Directory attribute value out of range fix

Why you're seeing 0X00002082

What's actually happening here is that Active Directory has a strict range check on certain attributes. You're trying to write a value that falls outside what the schema defines as acceptable. The error code 0x2082 maps to ERROR_DS_RANGE_CONSTRAINT, and it means the directory service refused the operation because the attribute value you supplied isn't within the legal bounds.

This shows up most often with integer-based attributes like badPwdCount, lockoutThreshold, maxPwdAge, or msDS-User-Account-Control-Computed. For example, setting badPwdCount to -1 or to 100000 won't work - the schema expects a value between 0 and 65535. You'll see this error when running PowerShell scripts, using ADSI Edit, or when a third-party tool tries to sync attributes from another system.

Cause 1: Direct attribute modification with wrong integer value (most common)

This is the one I see constantly. Someone runs a PowerShell command like:

Set-ADUser jdoe -Replace @{badPwdCount=-1}

Or they try to clear lockoutTime by setting it to 0 (which is fine) but accidentally set it to an empty string or a huge number. The schema for lockoutTime uses a 64-bit integer that represents a file time. Setting it to 0 is valid (means "not locked"), but setting it to a negative number or anything beyond 2^63-1 will trigger 0x2082.

The real fix: Check the attribute's syntax and range using ADSI Edit or PowerShell. Here's how:

Get-ADObject -Identity "CN=User,CN=Schema,CN=Configuration,DC=yourdomain,DC=com" -Properties rangeLower, rangeUpper, attributeSyntax

But that's a pain to run. Easier: look at the attribute's definition in ADSI Edit under Schema > Attribute. Find rangeLower and rangeUpper. For badPwdCount, they're 0 and 65535. For lockoutTime, there's no upper range defined in schema, but the value must be a valid 64-bit integer (not negative, not a string).

If you're fixing a user account that got stuck with a bad value, use NTDSUTIL to do a metadata cleanup or simply re-set the attribute to a known good value:

Set-ADUser jdoe -Replace @{badPwdCount=0}

That works because 0 is within the range. The reason step 3 works is that AD validates the value against the schema's range boundaries before it writes to the database.

Cause 2: Replication conflict with a newer schema version

You've got a domain controller running Windows Server 2012 R2 and another on Server 2022. The newer schema might have updated range constraints for attributes like msDS-PasswordSettings or msDS-MinimumPasswordLength. If a write comes from a tool that expects the old range, replication can fail with 0x2082.

What's happening: The originating DC writes a value that passes its own schema check, but when it replicates to a DC with a newer schema, the validation there catches it. The replication fails with this error.

The fix: Update the forest schema to match the highest DC level. Run adprep /forestprep and adprep /domainprep from the newer DC. Then check if the attribute ranges changed. For example, in Windows Server 2019+, the msDS-PasswordLength attribute's range was narrowed. If you had an old value of 0 (allowed pre-2019), it now must be at least 8.

To find the offending attribute, turn on diagnostic logging for replication:

repadmin /showrepl * /csv > repl.csv

Then look for the error code 2082 in the Last Failure Status column. It'll tell you which attribute failed. Then fix the value on the source DC.

Cause 3: Application or sync tool feeding bad data

This one's sneaky. You've got an HR sync tool, a password manager, or an in-house script that pushes values into AD. The tool might be sending a string where an integer is expected, or a number that's too large. I've seen a custom onboarding script that set msDS-User-Account-Control-Computed to 8388608 (which is a valid flag value) but also set badPwdCount to 99999 - that's outside 0-65535, boom.

How to track it down:

1. Enable auditing of directory service changes on all DCs.
2. Look in the Security log for Event ID 4662 (An operation was performed on an object).
3. Filter for error code 0x2082 in the event details. The event will show the attribute GUID.
4. Convert the GUID to the attribute name using this PowerShell:

Get-ADObject -Filter * -Properties lDAPDisplayName, schemaIDGUID | Where-Object {$_.schemaIDGUID -eq [guid]'YOUR-GUID-HERE'}

Once you know the attribute, check what process is modifying it. Look at the caller in the event. Then go fix the source application's mapping logic.

Quick-reference summary

The key takeaway: 0x2082 is always about a value that violates schema constraints. It's not a corruption or a permissions issue. Don't waste time rebuilding the database or changing ACLs. Find the attribute, check its allowed range, and correct the value.