The nightly test test_smb.py::TestSMB::test_smb_service_s4u2self is failing since March 9, 2022. Same issue is seen on the nightly tests for master-previous (using ipa master branch on fedora 34), master-testing (using ipa master branch on fedora 35 + updated packages from fedora updates-testing).
test_smb.py::TestSMB::test_smb_service_s4u2self
See for instance PR #1564 with the following logs and report:
self = <ipatests.test_integration.test_smb.TestSMB object at 0x7f734bfacf40> @pytest.mark.skipif( osinfo.id == 'fedora' and osinfo.version_number <= (31,), reason='Test requires krb 1.18') def test_smb_service_s4u2self(self): """Test S4U2Self operation by IPA service against both AD and IPA users """ script = textwrap.dedent("""export KRB5_TRACE=/dev/stderr kdestroy -A kinit -kt /etc/samba/samba.keytab {principal} klist -f {print_pac} -k /etc/samba/samba.keytab -E impersonate {user_princ} klist -f """) principal = 'cifs/{hostname}'.format( hostname=self.smbserver.hostname) # Copy ipa-print-pac to SMB server # We can do so because Samba and GSSAPI libraries # are present there print_pac = self.master.get_file_contents( os.path.join(paths.LIBEXEC_IPA_DIR, "ipa-print-pac")) result = self.smbserver.run_command(['mktemp']) tmpname = result.stdout_text.strip() self.smbserver.put_file_contents(tmpname, print_pac) self.smbserver.run_command(['chmod', 'a+x', tmpname]) for user in (self.ad_user, self.ipa_user1,): shell_script = script.format(principal=principal, user_princ=user, print_pac=tmpname) > self.smbserver.run_command(['/bin/bash', '-s', '-e'], stdin_text=shell_script)
The call to ipa-print-pac is failing with:
[31578] 1646841842.022178: Decoding FAST response [31578] 1646841842.022179: Decoding FAST response [31578] 1646841842.022180: Got cred; -1765328324/Generic error (see e-text) gss_acquire_cred_impersonate_name(): Unspecified GSS failure. Minor code may provide more information Generic error (see e-text)
The error looks similar to the issue described in https://bugzilla.redhat.com/show_bug.cgi?id=2060421 FAST processing over cross-realm fails against Active Directory in FIPS mode, but here the test in run in non-FIPS mode.
Reproduced in : testing_master_testing_selinux 1565 report
test failure seen in testing_master_latest PR 1569 Report
testing_master_latest
test failure seen in testing_master_latest PR 1578 Report
reproduced in testing_master_latest_selinux, report
failure observed at [testing_ipa-4.9_latest_selinux] Nightly PR #1568 , report
test failure seen in testing_master_latest PR 1584 Report
test failure seen in testing_master_latest PR 1592 Report
test failure seen in testing_master_latest PR 1600 Report
test failure seen in testing_master_latest PR 1608 Report
test failure seen in testing_master_latest_selinux PR 1608 Report
test failure seen in testing_master_latest PR 1614 Report
test failure seen in testing_master_latest PR 1622 Report
test failure seen in testing_master_latest PR 1629 Report
test failure seen in testing_master_latest PR 1637 Report
test failure seen in testing_master_testing_selinux PR 1637 Report
test failure seen in testing_master_latest PR 1644 Report
test failure seen in testing_master_latest PR 1653 Report
test failure seen in testing_master_latest_selinux PR 1651 Report
test failure seen in testing_master_latest PR 1660 Report
test failure seen in testing_master_latest PR 1668 Report
test failure seen in testing_master_latest PR 1691 Report
test failure seen in testing_master_latest PR 1699 Report
test failure seen in testing_master_latest_selinux , report
test failure seen in testing_master_latest PR 1708 Report
test failure seen in testing_master_latest PR 1716 Report
test failure seen in testing_master_latest PR 1734 Report
test failure seen in testing_master_latest PR 1743 Report
Reproducible in testing_master_latest PR 1752 Report
Looking at the Kerberos traffic, I see that the TGS-REQ to the AD DC contains both PA-FOR-USER and PA-S4U-X509-USER structures. This contradicts MS-SFU spec: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/def5e449-f5b1-44d1-acca-1abc83285533
What padata type Service 1 sends is determined by two factors. First, determine whether the TGT session key is of a newer type, defined here as ciphers that are not DES or RC4 based. Second, determine whether the client username was provided explicitly or was extracted from a certificate. Service 1 SHOULD populate and send a PA-FOR-USER structure when one of the following is true: No certificate was presented for the user. No user name was explicitly provided, and instead a certificate was provided that contained the user name in the Subject Alternate Name (SAN) field. Service 1 SHOULD populate and send a PA-S4U-X509-USER structure when one of the following is true: No PA-FOR-USER is being sent. The session key of the TGT being used is not a DES or RC4 key type.
What padata type Service 1 sends is determined by two factors. First, determine whether the TGT session key is of a newer type, defined here as ciphers that are not DES or RC4 based. Second, determine whether the client username was provided explicitly or was extracted from a certificate.
Service 1 SHOULD populate and send a PA-FOR-USER structure when one of the following is true:
No certificate was presented for the user.
No user name was explicitly provided, and instead a certificate was provided that contained the user name in the Subject Alternate Name (SAN) field.
Service 1 SHOULD populate and send a PA-S4U-X509-USER structure when one of the following is true:
I think this is a bug in krb5 client code. I am yet to figure out whether the same bug is present after S4U refactoring has happened for krb5 1.20.
Reproducible in testing_master_latest PR 1760 Report
Reproducible in testing_master_latest PR 1778 Report
Reproducible in testing_master_latest PR 1786 Report
reproduced in testing_master_latest_selinux report
Reproducible in testing_master_latest PR 1813 Report
Reproducible in testing_master_latest PR 1821 Report
Reproducible in testing_master_latest PR 1838 Report
Reproducible in testing_master_sssd PR 1851 Report
testing_master_sssd
Reproducible in testing_master_latest PR 1846 Report
Reproducible in testing_master_latest PR 1856 Report
Reproducible in testing_master_latest PR 1866 Report
Reproducible in testing_master_sssd PR 1892 Report
Reproducible in testing_master_latest PR 1887 Report
Reproducible in testing_master_latest PR Report
Reproducible in testing_master_latest PR 1906 Report
Reproducible in testing_master_testing_selinux report
Reproducible in testing_master_latest PR 1927 Report
Reproducible in testing_master_latest PR 1937 Report
Reproducible in testing_master_sssd PR 1970 Report
Reproducible in testing_master_latest PR 1965 Report
Reproducible in testing_master_latest PR 1975 Report
Reproducible in testing_master_sssd PR 1990 Report
Reproducible in testing_master_latest PR 1985 Report
Reproducible in testing_master_latest PR 1995 Report
Reproducible in testing_master_latest PR 2014 Report
Reproducible in testing_master_latest PR 2024 Report
Reproducible in testing_master_sssd PR 2029 Report
Reproducible in testing_master_latest PR 2034 Report
Reproducible in testing_master_ssssd PR 2048 Report
testing_master_ssssd
Reproducible in testing_master_latest PR 2043 Report
Reproducible in testing_master_latest PR 2053 Report
master:
ipa-4-10:
ipa-4-9:
Hello, @frenaud I checked test_smb.py::TestSMB::test_smb_service_s4u2self in LTE with AD server 2022 and 2019 and the test passed:
test_integration/test_smb.py::TestSMB::test_samba_uninstallation_without_installation PASSED [ 6%] test_integration/test_smb.py::TestSMB::test_install_samba PASSED [ 12%] test_integration/test_smb.py::TestSMB::test_authentication_with_smb_cifs_principal_alias PASSED [ 18%] test_integration/test_smb.py::TestSMB::test_samba_service_listed PASSED [ 25%] test_integration/test_smb.py::TestSMB::test_smb_access_for_ipa_user_at_ipa_client PASSED [ 31%] test_integration/test_smb.py::TestSMB::test_smb_access_for_ad_user_at_ipa_client PASSED [ 37%] test_integration/test_smb.py::TestSMB::test_smb_mount_and_access_by_different_users PASSED [ 43%] test_integration/test_smb.py::TestSMB::test_smb_service_s4u2self PASSED [ 50%] test_integration/test_smb.py::TestSMB::test_smb_mount_fails_without_kerberos_ticket PASSED [ 56%] test_integration/test_smb.py::TestSMB::test_ntlm_authentication_with_auto_domain PASSED [ 62%] test_integration/test_smb.py::TestSMB::test_ntlm_authentication_with_upn_with_lowercase_domain PASSED [ 68%] test_integration/test_smb.py::TestSMB::test_ntlm_authentication_with_upn_with_uppercase_domain PASSED [ 75%] test_integration/test_smb.py::TestSMB::test_uninstall_samba PASSED [ 81%] test_integration/test_smb.py::TestSMB::test_repeated_uninstall_samba PASSED [ 87%] test_integration/test_smb.py::TestSMB::test_samba_reinstall PASSED [ 93%] test_integration/test_smb.py::TestSMB::test_cleanup PASSED [100%]
I tried it again with AD2022 (updates KB5012170, KB5023705, KB5022507 were uninstalled from AD) and the test test_smb.py::TestSMB::test_smb_service_s4u2self failed. ... test_integration/test_smb.py::TestSMB::test_smb_mount_and_access_by_different_users PASSED [ 43%] test_integration/test_smb.py::TestSMB::test_smb_service_s4u2self FAILED [ 50%] test_integration/test_smb.py::TestSMB::test_smb_mount_fails_without_kerberos_ticket PASSED [ 56%] ....
It seems that the issue was fixed on AD side. IMO we could remove pytest xfall from this test (ipa-4-10). What do you think?
@fdvorak wonderful news, thank you. ICan you please say what distribution did you use on FreeIPA side? Was it with Fedora, CentOS Stream, RHEL? And what version?
@fdvorak we need to update our Windows images for the upstream PRCI in this case. And then we can remove the xfail. Let me check which version is in use currently...
The tests are using Vagrant templates from https://github.com/freeipa/freeipa-pr-ci/tree/master/templates/vagrantfiles (the templates names starting with Vagrantfile.ad-xxx) and they all use "freeipa/windows-server-2016-standard-x64-eval" box. We definitely need to update the Windows version to something more recent.
Vagrantfile.ad-xxx
@abbra I used "ipa-server-4.10.1-6.el9.x86_64" on RHEL9.2.
Thanks, so this is with krb5 1.20 but without the changes to introduce support for sha-1-based encryption type for cross-realm tgt. This means that MSFT indeed fixed this silently in their code after our report at https://lists.samba.org/archive/cifs-protocol/2022-September/003760.html
On FreeIPA side we need two parts: - update Windows vagrant images to make PR CI to use MSFT updates - add SHA-1 enctype hint as discussed in https://github.com/krb5/krb5/commit/5af907156f8f502bbe268f0c62274f88a61261e4
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.