freeipa

#9124 Nightly test failure in test_smb.py::TestSMB::test_smb_service_s4u2self
Closed: fixed by frenaud. Opened by frenaud.

Closed: fixed
Reopen Issue

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

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
Edited by amore

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
Edited by sumedhs

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:

  • 5419864c7ef893abc4717847fa6ea272d0c659fe ipatests: mark test_smb as xfail

ipa-4-10:

  • b5f2b0b1b213149b5bfe2653c9e40de98249dc73 ipatests: mark test_smb as xfail

ipa-4-9:

  • 1bdd8147e7fa1032025dc6f6868e26f285744ee1 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:

  • e00f457f755e78d384beb8cc7ac312e9741b56af ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 4ef8258d58046ee905c929c0e889653a8b86d383 ipa-kdb: protect against context corruption
  • 03897d8a6899691b7218428b296f6d22ccadcfb2 ipa-kdb: postpone ticket checksum configuration
  • d551e853fc4e213cf384bc983d0e76d8568ee954 ipa-kdb: process out of realm server lookup during S4U
  • 9cdf010ca6c8b03d9f7cc338e8253219e0e877b0 ipa-kdb: skip verification of PAC full checksum
  • 18bf495ce88fbb032f23f7db7f941458ecf55c7a ipalib/x509.py: Add signature_algorithm_parameters

ipa-4-10:

  • 3d0decd9efc4883328e95f9ff89002aec32462ec ipa-kdb: hint KDC to use aes256-sha1 for forest trust TGT
  • 803a44777f901217d634f8fd7feed8b66ece352a ipa-kdb: protect against context corruption
  • fefa0248296413b6ee5ad2543d8feb1b31840aee ipa-kdb: postpone ticket checksum configuration
  • bd8fcd6f5bc62a4bfc544b69c0d960291be05d37 ipa-kdb: process out of realm server lookup during S4U
  • 1b55e9b1cb4f192635878b0b7242104d58a37d2b ipa-kdb: skip verification of PAC full checksum
  • 11ce2b2133364916de06f4c42d8a19ce438bd41c ipalib/x509.py: Add signature_algorithm_parameters

master:

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

master:

  • 107f5f2d81f18e17b11edba2a000de97688e8995 ipatest: remove xfail from test_smb

ipa-4-9:

  • 998bafee86a870ad1ea4d6bccf12f0fae64c398c ipatest: remove xfail from test_smb

ipa-4-10:

  • 283f5463f091ac9fcc733092fc6becff586ae97f ipatest: remove xfail from test_smb

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

test-failure

None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.