SSSD accepts the account, but SSH rejects DOMAIN\user. What should I check?

First separate name parsing from SSH access control. Turn up SSSD logging temporarily, then check whether NSS can resolve the exact account form the client sends. For example, run getent passwd with the escaped DOMAIN\user name and inspect sssd_nss.log for sss_parse_name messages. If parsing fails, check the configured domain name and SSSD’s name-format expression before changing SSH settings.

If the user resolves correctly, look at the SSH and SSSD access logs next. That tells you whether the rejection happens during account lookup, the simple access-provider group check, or later in authentication. Avoid leaving maximum debug logging enabled longer than needed.

The Windows client’s default username format may be the mismatch, rather than a general Kerberos or SSH failure. A quick workaround is to set the username in the client’s SSH configuration for the relevant hosts, or explicitly provide the login name with ssh’s user option. That keeps users from having to type a longer command each time.

If the requirement is specifically to accept DOMAIN\user as typed, confirm SSSD recognizes that form on this version. Ubuntu 24 working does not by itself show whether the difference is in SSSD defaults, configuration, or the client’s submitted name.

One thing that stands out is the mix of domain values in the config. The SSSD domain section is named vafo.local, while the realm is domain.local and ad_domain is set to domain. Make sure those are intentional and consistently match the actual AD DNS domain and realm. A mismatch can make troubleshooting name handling much harder.

Also verify that the group name in simple_allow_groups is the form SSSD resolves on this host. I would check identity lookup and group membership first, then SSH authentication, rather than treating every permission-denied message as a password problem.