If Extranet Lockout Protection (ESL) is enabled in ADFS, logins to ADFS with accounts in a trusted domain gives the error "Incorrect User ID or password"

Glenn 1 Reputation point
2022-09-19T17:48:48.697+00:00

I have an issue that when Extranet lockout protection is enabled and I try logging in via ADFS to a trusted domain (2 way domain trust) using DOMAIN\USER format the login fails. Logins to these same trusted domains work with ESL enabled if in USER@keyman format. If I disable ESL, logins in both formats work correctly with the trusted domains.

It seems that when ESL is enabled, it tries to look up the account first in the trusted domains to see if it exists and this appears to be where it's failing. The error we receive from ADFS is "Incorrect user ID or password."

I see this in the trace logs:
DS_NAME_ERROR_NOT_FOUND
ADNameTranslator.NameTranslateWithReferral: unable to resolve name tusteddomain\User

This is on Server 2022.

The simple fix is to not use ESL, but I was hoping to have that feature enabled.

Any ideas? Thanks

Active Directory Federation Services
Active Directory Federation Services
An Active Directory technology that provides single-sign-on functionality by securely sharing digital identity and entitlement rights across security and enterprise boundaries.
1,189 questions
0 comments

5 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee
    2022-09-22T01:06:55.837+00:00

    What is the full error message? You should see an error code at the very end. The format is usually:
    ADNameTranslator.NameTranslateWithReferral: unable to resolve name {0} , result code {1}

    0 comments
  2. Glenn 1 Reputation point
    2022-09-22T12:54:22.34+00:00

    Just ran another adfs trace log and reproduced the problem on our test server, I don't see an error code on any of the event log "errors".

    Here are the other associated errors that happen when I try and login to trusted domain with DOMAIN\user format with ESL enabled:

    Exception: System error.

    Sceurity token not valid.
    Exception details:
    System error.

    ThreatDetector.AnalyzePreAuthRequest returned Restricted. Failing request.

    ThreatDetectionFramework AnalyzePreAuthRequest normalization failed, returning Block

    ThreatDetectionFramework NormalizeIdentityIfNeeded: Failed with exception: System.IdentityModel.Tokens.SecurityTokenValidationException: id ---> Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8022: Unable to find the specified user account.

    MsisLocalCpUserNameSecurityTokenHandler::UpdateAuthenticationContext: Identity domain\user Failed with exception:
    Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: MSIS8022: Unable to find the specified user account.

    ActiveDirectoryAccountStore - Name domain\user could not be translated to DN. Account is likley non-existent

    ADNameTranslator.NameTranslateWithReferral: unable to resolve name domain\user , result code DS_NAME_ERROR_NOT_FOUND

    243839-image.png

  3. Glenn 1 Reputation point
    2022-09-23T13:09:54.687+00:00

    Hi, thank you for the support, it is greatly appreciated.

    I searched the trace logs from when the issue was reproduced for anything with "ADNameTranslator.NameTranslateWithReferral" and only have the one event from the screenshot posted earlier. I'm unsure why my trace logs don't have that additional info.

    I turned on Netlogon logging in verbose mode on the ADFS test sever and tested a "run-as" logon on the server to make sure logging was working correctly and it did log the "run-as" attempt. Then I reproduced the issue logging into ADFS with the trusted domain in trusteddomain\username format, and nothing at all gets logged in the netlogon.log file for that attempt. However, If I login to the trusted domain via ADFS with username@trusteddomain.com format it works as expected and logs me in to the trusted domain, and I see the DC location process for the trusted domain in the netlogon logs.

    So it appears to me if trying in trusteddomain\username format with ESL turned on it doesn't event attempt to find the DC in the trusted domain.

    Let me know your thoughts, please, and thanks again for the help.

  4. Glenn 1 Reputation point
    2022-09-23T13:38:42.243+00:00

    No worries at all.

    Here is the additional info for the log entry with the trace verbosity change:

    ADNameTranslator.NameTranslateWithReferral: InputName : trusteddomain\user InputDomainHint trusteddomain : Server : DefaultServer Result : DS_NAME_ERROR_NOT_FOUND Domain : <null> nName : <null>

    244338-image.png

    0 comments
  5. Glenn 1 Reputation point
    2022-09-28T13:16:02.043+00:00

    Another piece of information I learned from testing:

    If I use format "FQDN domain name\username" it works as expected and also gets logged as expected in netlogon.log file.

    If I use format "NetBIOS domain name\username" it fails and nothing logged in netlogon.log.

    So it appears the problem is with using the netbios name of the trusted domain with Extranet lockout turned on. If I turn Extranet lockout off, both formats work as expected.

    The domain in question is in another forest and we have a two way trust.