UPN Lookup failed (Intermittently)

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

Users connect from AVD host using FileZilla to OSSH server using AD authentication.

Expected behavior

All domain users in security group are authenticated

Actual behavior

This works for ALL USERS most of the time.

A few times a day however, NO USERS can connect for a period of 5-10 minutes. During this time UPN lookup errors are logged (as seen below). Microsoft reviewed the configuration and NSG rules and agreed everything is correct. (TrackingID#2211180040004104) Microsoft has requested that I look for help on GitHub.

Error details

This example shows the same user logged in at 10:21 successfully but could not at 16:19 on the same day.

13816 2022-12-07 10:21:35.710 debug3: lookup_principal_name: Successfully discovered explicit principal name: 'abc\rpervez'=>'rpervez@abc.com'
13816 2022-12-07 10:21:35.711 debug3: LsaLogonUser Succeeded (Impersonation: 0)

11372 2022-12-07 16:19:21.600 debug3: checking match for 'Group administrators' user mission-ag\rpervez host 172.16.4.7 addr 172.16.4.7 laddr 172.16.5.4 lport 22
11372 2022-12-07 16:19:21.621 error: lookup_principal_name: User principal name lookup failed for user 'abc\rpervez' (explicit: 1355, implicit: 1355)
11372 2022-12-07 16:19:21.621 debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'abc\rpervez' Status: 0xC0000062 SubStatus 0.
11372 2022-12-07 16:19:21.621 debug3: get_user_token - unable to generate token for user abc\rpervez

Environment data

DC1/DC2: On Subnet 1 with NSG1
OpenSSH Server: Domain joined Windows Server 2022 on Subnet 2 with NSG2
Host: Windows 10 AVD host on Subnet3 with NSG3
Client: FileZilla
Note: All subnets are on the same vnet

Version

8.9.1.0

Visuals

No response

No source files or tests are named. Start by comparing the successful and failed lookup_principal_name and LsaLogonUser log entries in the issue, then trace UPN lookup handling for AD-authenticated users on the Windows OpenSSH server. Done means the intermittent authentication failure is reproduced or explained and the stated AVD, subnet, and security-group scenario behaves consistently.