This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(265.6, 49%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EID%3C/text%3E%3C/svg%3E)
I have two AD forests with two-way trust (selective authentication): prod.com and clients.com.
Schemas in both forests were updated to Windows 2019 by adprep.
There are ADFS and WAP servers with Windows 2019 in prod.com. (Upgraded from Windows 2012 R2 farm by https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server)
ADFS configured as:
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests prod.com,clients.com.
Permission "Allowed to authenticated" on ADFS.prod.com was granted for all users from clients.com.
When ExtranetLockout is enabled on ADFS, users from clients.com can't sing-in using CLIENTS\username format, but can sign-in by username@clients.com.
User receive errors 1210 and 516 in Security logs:
User:
clients\user1
nBad Password Count:
0
nLast Bad Password Attempt:
1/1/0001 12:00:00 AM
It seems that ADFS can't find user clients\user1 or his attributes badPwdCount and badPasswordTime.
When ExtranetLockout is disabled, users from clients.com can sing-in as CLIENTS\username and username@clients.com also.
Users from prod.com can always sing-in in any way regardless of ExtranetLockout setting.
When using the extranet lockout policy, the ADFS server is trying to lookup the user using LDAP before the authentication. Therefore, the ADFS service account will have to be able (authorized) to make that call.
ADFS service account (from prod.com domain) has permission "Read all properties" for user objects in clients.com
I meant that in that case the resource the ADFS service account is trying to access to is a DC (the LDAP component of the DC). So my guess is that is currently failing with the error KDC_ERR_POLICY. You can confirm that with a network trace (Kerberos error messages are in the clear on the wire), or by enabling Kerberos logs on the ADFS server and check the System event logs. And if so, then you'll need to add the "Allow to authenticate" permission on the DC objects (directly or via the OU inheritance). Also when it comes to Selective Authentication, it is a good practice to add both the service account and the servers on which the account is used to make it work regardless of the authentication protocol (Kerberos or NTLM).
I enabled Kerberos logs.
When I sing-in by user1@clients.com I see several Kerberos errors on ADFS server, and several successful messages on DC of clients.com. And user sign-in successfully.
But when I sing-in by clients\user1 I don't see any Kerberos messages on ADFS and on DC also.
It seems that ADFS just doesn't know what LDAP server must verify such user
I captured network traffic to domain controllers by Wireshark.
When I sing-in by Clients\username I see only one packet from ADFS to DC to port 3268 and one response from DC.
When I sing-in by username@clients.com I see a lot of packets from ADFS to DCs including search query to port 389.
And when I disable ExtranetLockout then I see a lot of packets in both cases. It seems as some bug on ADFS server.
But, has the ADFS service account the permission "Allow to authenticate" on the DC's object of the trusted domain? Because that's what matter to perform an LDAP call on the other side.
Granted permission "Allow to authenticate" for ADFS service account to all DCs, but unfortunately it didn't help