The given key was not present in the dictionary.  System.Collections.Generic.KeyNotFoundException Managed Account Issue

Restore read access from the SharePoint farm account to the affected managed-account object in Active Directory, because this stack fails while Central Administration is retrieving that account’s AD properties—not while reading the server registry.

Correct the AD permissions

The call chain GetUserPropertyFromAD → GetUserAccountControl shows that SharePoint is attempting to read AD attributes such as account-control information. The same exception has been resolved by restoring read permissions on the service-account object after AD permissions were hardened ^1^.

1. Identify the exact managed account that produces the error.
2. On a domain controller, open Active Directory Users and Computers.
3. Select View → Advanced Features.
4. Open the affected service account: Properties → Security → Advanced → Effective Access.
5. Check effective access for the SharePoint farm service account. Central Administration and the SharePoint Timer Service run as this account ^2^.
6. Look for:
   • A missing inherited Read permission.
   • An explicit Deny applied directly or through a hardened security group.
   • Protected ACLs that stopped normal permissions from inheriting.
7. Remove the unintended explicit deny or restore inheritance. If the security baseline requires a narrow exception, grant the farm account—or a dedicated group containing it—Read and Read all properties on only the affected service-account object.
8. Allow AD replication to complete, then reopen: Central Administration → Security → Configure managed accounts → Edit.

Avoid granting broad write permissions, Domain Admin membership, or local administrator rights to application-pool accounts. SharePoint service and web application pool accounts normally remain ordinary domain users, with SharePoint assigning the required farm-side permissions ^2^.

Confirm the blocked directory lookup

If the ACL correction is not immediately conclusive, reproduce the error once and collect the matching ULS entries. SharePoint 2019 supports filtering ULS events with PowerShell ^3^.

From the SharePoint Management Shell on APP01:

$start = (Get-Date).AddMinutes(-10)
$end   = Get-Date

Merge-SPLogFile `
  -Path "C:\Logs\ManagedAccountError.log" `
  -StartTime $start -EndTime $end `
  -Message "*GetUserPropertyFromAD*" `
  -Overwrite

Merge-SPLogFile gathers matching ULS records across the farm; filtering by start and end time is recommended for performance ^4^.

Check the resulting log for:

• The affected DOMAIN\account.
• Access denied, LDAP, or AD lookup failures.
• The Central Administration correlation ID.
• The domain controller contacted.

This also helps determine whether cross-domain firewall, DNS, trust, or replication behavior is involved rather than an object ACL.

Conditional multi-domain check

Your multi-domain topology matters only if accounts were migrated and an active source account shares SID history with an active destination account. Microsoft documents that configuration as unsupported because SharePoint’s AD lookup can resolve either account unpredictably ^5^.

If that condition exists, either:

• Disable the active source account, or
• Remove the source objectSid from the destination account’s sidHistory.

Do not change SID history unless the duplicate-active-account condition has been verified.

Use credential repair only for a different symptom

Repair-SPManagedAccountDeployment is not the primary fix for this Central Administration AD lookup exception. Use it only if credentials are already registered correctly but services fail to start on one farm server while working on others. It redeploys local service and web-application credentials and checks the local farm passphrase ^6^.

Run it locally on each affected server:

Repair-SPManagedAccountDeployment

If the AD password was changed outside SharePoint and the ULS log instead confirms a password mismatch, synchronize SharePoint with the existing AD password using Set-SPManagedAccount -UseExistingPassword; Microsoft documents the required SQL, database, local administrator, and SharePoint PowerShell permissions for that operation ^7^.

References

1. SharePoint 2010: PSConfiguration issues with GetUserPropertyFromAD call
2. Account permissions and security settings in SharePoint Servers
3. View diagnostic logs in SharePoint Server
4. Merge-SPLogFile-Description
5. SharePoint identity and permission issues in two-way domain trust
6. Repair-SPManagedAccountDeployment-Syntax
7. Configure automatic password change in SharePoint Server