 |
The issue has been further diagnosed with winbind log level 10. The original report mentioned NT_STATUS_WRONG_PASSWORD and SEC_CHAN_NULL. The current samba-4.22.4-18.el9_7 no longer shows NT_STATUS_WRONG_PASSWORD but the SEC_CHAN_NULL problem remains and causes a different failure path. Summary of findings: - NTLM challenge/response authentication SUCCEEDS (PAM_AUTH_CRAP returns NT_STATUS_OK with valid netr_SamInfo6 from the trusted domain DC) - The failure occurs AFTER auth during the idmap_ad SID-to-UID mapping - The idmap_ad backend returns NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND - This causes the user's SID to be unmapped (XID 0xffffffff) - Winbind then returns NT_STATUS_NO_SUCH_USER for the GETPWNAM call - The SMB session setup ultimately fails with NT_STATUS_LOGON_FAILURE Root cause from log.wb-DOMAIN-B: cm_connect_netlogon_transport: get_secure_channel_type gave SEC_CHAN_NULL for DOMAIN-B, fallback to noauth on NCACN_NP. Because the trust is transitive (forest trust, shown as "Routed (via DOMAIN-A)" in wbinfo --trusted-domains --verbose), the Samba server has no direct trust credentials with DOMAIN-B. The winbind child for DOMAIN-B gets SEC_CHAN_NULL and falls back to anonymous netlogon. After the CVE-2025-49716 hardening on the Windows DCs, this anonymous netlogon is rejected, causing DsGetDCName to return NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND, which causes the entire idmap_ad lookup to fail. LDAP connectivity to DOMAIN-B DCs is NOT the issue. Manual testing with "ldapsearch -Y GSSAPI" using the machine's Kerberos credentials via cross-realm referral successfully queries RFC2307 attributes (uidNumber, gidNumber) from the DOMAIN-B DCs. The idmap_ad backend should be able to do the same, but the connection manager's netlogon failure prevents it. Detailed log sequence (winbindd, log level 10): 1. Auth succeeds: winbindd_pam_auth_crap_send: pam auth crap domain: [DOMAIN-B] user: [testuser] result: NT_STATUS_OK 2. idmap_ad Sids2UnixIDs call fails: wbint_Sids2UnixIDs out: result: NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND 3. Retry after dsgetdcname (DC found successfully) also fails: NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND 4. SID cached as unmapped: gencache_set_data_blob: key=[IDMAP/SID2XID/S-1-5-21-...] (120 seconds) 5. User rejected: XID type is 0, should be ID_TYPE_UID or ID_TYPE_BOTH. Return status NT_STATUS_NO_SUCH_USER. process_request_done: [nss_winbind:GETPWNAM]: NT_STATUS_NO_SUCH_USER Comparison: Working: samba-4.21.3-14.el9_6 on same machine, same smb.conf Broken: samba-4.22.4-18.el9_7 on same machine, same smb.conf The fix released for RHEL 9.6 (RHBA-2025:10634, samba-4.21.3-7.el9_6) per Red Hat Solution 7127997 appears to address this for the 4.21 branch. The equivalent fix for the 4.22 branch on RHEL 9.7 is either missing or incomplete for the transitive forest trust case. Related: - Red Hat Solution 7127997 - Upstream Samba Bug 15876 - RHEL-101761 (Fix DC discovery after Windows netlogon hardening) - RHEL-102370 (Fix issue with unresponsive second DC when using idmap_ad) |
- Anonymous
