#9124 Nightly test failure in test_smb.py::TestSMB::test_smb_service_s4u2self
Closed: fixed 10 months ago by frenaud. Opened 2 years ago by frenaud.

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).

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

test failure seen in testing_master_latest PR 1578 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 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.

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

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_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

Reproducible in testing_master_latest PR 2043 Report

Reproducible in testing_master_latest PR 2053 Report

master:

  • 5419864 ipatests: mark test_smb as xfail

ipa-4-10:

  • b5f2b0b ipatests: mark test_smb as xfail

ipa-4-9:

  • 1bdd814 ipatests: mark test_smb as xfail

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.

@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

master:

  • e00f457 ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 4ef8258 ipa-kdb: protect against context corruption
  • 03897d8 ipa-kdb: postpone ticket checksum configuration
  • d551e85 ipa-kdb: process out of realm server lookup during S4U
  • 9cdf010 ipa-kdb: skip verification of PAC full checksum
  • 18bf495 ipalib/x509.py: Add signature_algorithm_parameters

ipa-4-10:

  • 3d0decd ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 803a447 ipa-kdb: protect against context corruption
  • fefa024 ipa-kdb: postpone ticket checksum configuration
  • bd8fcd6 ipa-kdb: process out of realm server lookup during S4U
  • 1b55e9b ipa-kdb: skip verification of PAC full checksum
  • 11ce2b2 ipalib/x509.py: Add signature_algorithm_parameters

master:

  • 3a706e8 ipa-kdb: be compatible with krb5 1.19 when checking for server referral

master:

  • 107f5f2 ipatest: remove xfail from test_smb

ipa-4-9:

  • 998bafe ipatest: remove xfail from test_smb

ipa-4-10:

  • 283f546 ipatest: remove xfail from test_smb

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

10 months ago

Login to comment on this ticket.

Metadata