Prerequisites
Related: #1787 (SSH with AAD/Entra ID credentials). The behaviour below comes from PowerShell/openssh-portable#744, which made ga_init() non-fatal when no user token can be generated.
Steps to reproduce
- Entra ID–joined Windows 11 device; an Entra ID user (SID
S-1-12-1-…) who is a member of the local Administrators group.
- Default
%ProgramData%\ssh\sshd_config, which contains:
Match Group administrators
AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
- Run
sshd.exe 10.0.0.0p2 as SYSTEM (as the service does). For the logs below: sshd.exe -ddd -p 2223 -E log.txt from a SYSTEM scheduled task.
- Put the user's public key in
C:\Users\<user>\.ssh\authorized_keys.
ssh -p 2223 -l 'azuread\<user>' <host>
Expected behavior
The Match Group administrators block applies to an administrator, so their keys are looked up only in administrators_authorized_keys, as documented in OpenSSH key management. If group membership can't be determined, sshd should say so clearly rather than silently treating the user as a non-administrator.
Actual behavior
sshd can't create an S4U token for the Entra ID user (see #1787), so since #744 ga_init() reports the user as being in no groups. The Match Group administrators block is skipped for an Entra ID administrator, and the key is read from the per-user authorized_keys:
checking match for 'Group administrators' user azuread\\<user> host <client> ... lport 2223 on line 87
lookup_principal_name: User principal name lookup failed for user 'azuread\\<user>' (explicit: 1355, implicit: 1355)
debug1: generate_s4u_user_token: LsaLogonUser() failed. User 'azuread\\<user>' Status: 0xC0000062 SubStatus 0.
get_user_token - unable to generate token on 2nd attempt for user azuread\\<user>
ga_init, unable to resolve user azuread\\<user>
debug1: Can't Match group because user azuread\\<user> not in any group at line 87
debug3: match not found on line 87
Accepted key ED25519 SHA256:... found at C:/Users/<user>/.ssh/authorized_keys:1
Accepted publickey for azuread\\<user> from <client> port ... ssh2: ED25519 SHA256:...
(The session then fails with fork of unprivileged child failed, the S4U limitation tracked in #1787.)
Any other Match Group block an admin relies on (e.g. ForceCommand, ChrootDirectory, AllowTcpForwarding) is silently skipped for Entra ID users in the same way, because their membership always reads as "no groups".
Suggestion: when the token can't be generated, resolve membership another way (e.g. the account SID against the local group, including Entra role SIDs nested in Administrators), or at least log a warning that Match Group rules could not be evaluated for that user.
Environment data
Windows 11 Pro 25H2, build 10.0.26200, Entra ID–joined (AzureAdJoined: YES, DomainJoined: NO)
Windows PowerShell 5.1.26100
Version
OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 4.2.0 (GitHub release 10.0.0.0p2-Preview, zip, run as SYSTEM)
Inbox OpenSSH_for_Windows_9.5 (sshd.exe 9.5.6.2) on the same machine fails earlier: ga_init() still calls fatal() there (pre-#744).
Prerequisites
Related: #1787 (SSH with AAD/Entra ID credentials). The behaviour below comes from PowerShell/openssh-portable#744, which made
ga_init()non-fatal when no user token can be generated.Steps to reproduce
S-1-12-1-…) who is a member of the local Administrators group.%ProgramData%\ssh\sshd_config, which contains:sshd.exe10.0.0.0p2 as SYSTEM (as the service does). For the logs below:sshd.exe -ddd -p 2223 -E log.txtfrom a SYSTEM scheduled task.C:\Users\<user>\.ssh\authorized_keys.ssh -p 2223 -l 'azuread\<user>' <host>Expected behavior
The
Match Group administratorsblock applies to an administrator, so their keys are looked up only inadministrators_authorized_keys, as documented in OpenSSH key management. If group membership can't be determined, sshd should say so clearly rather than silently treating the user as a non-administrator.Actual behavior
sshd can't create an S4U token for the Entra ID user (see #1787), so since #744
ga_init()reports the user as being in no groups. TheMatch Group administratorsblock is skipped for an Entra ID administrator, and the key is read from the per-userauthorized_keys:(The session then fails with
fork of unprivileged child failed, the S4U limitation tracked in #1787.)Any other
Match Groupblock an admin relies on (e.g.ForceCommand,ChrootDirectory,AllowTcpForwarding) is silently skipped for Entra ID users in the same way, because their membership always reads as "no groups".Suggestion: when the token can't be generated, resolve membership another way (e.g. the account SID against the local group, including Entra role SIDs nested in Administrators), or at least log a warning that
Match Grouprules could not be evaluated for that user.Environment data
Version