test_integration/test_trust.py::TestTrust::test_ipa_commands_run_as_aduser fails:
def test_ipa_commands_run_as_aduser(self): """Test if proper error thrown when AD user tries to run IPA commands Before fix the error used to implies that the ipa setup is broken. Fix is to throw the proper error. This test is to check that the error with 'Invalid credentials' thrown when AD user tries to run IPA commands. related: https://pagure.io/freeipa/issue/8163 """ tasks.kdestroy_all(self.master) ad_admin = 'Administrator@%s' % self.ad_domain tasks.kinit_as_user(self.master, ad_admin, self.master.config.ad_admin_password) err_string = ('ipa: ERROR: Insufficient access: SASL(-14):' ' authorization failure: Invalid credentials') result = self.master.run_command(['ipa', 'ping'], raiseonerr=False) > assert err_string in result.stderr_text E AssertionError: assert 'ipa: ERROR: Insufficient access: SASL(-14): authorization failure: Invalid credentials' in 'ipa: ERROR: Insufficient access: Invalid credentials\n' E + where 'ipa: ERROR: Insufficient access: Invalid credentials\n' = <pytest_multihost.transport.SSHCommand object at 0x7f42ae325710>.stderr_text test_integration/test_trust.py:147: AssertionError -------------------------------Captured log call-------------------------------- INFO ipatests.pytest_ipa.integration.host.Host.master.IPAOpenSSHTransport:transport.py:391 RUN ['kdestroy', '-A'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd108:transport.py:513 RUN ['kdestroy', '-A'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd108:transport.py:217 Exit code: 0 INFO ipatests.pytest_ipa.integration.host.Host.master.IPAOpenSSHTransport:transport.py:391 RUN ['kinit', 'Administrator@ad.test'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd109:transport.py:513 RUN ['kinit', 'Administrator@ad.test'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd109:transport.py:558 Password for Administrator@ad.test: DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd109:transport.py:217 Exit code: 0 INFO ipatests.pytest_ipa.integration.host.Host.master.IPAOpenSSHTransport:transport.py:391 RUN ['ipa', 'ping'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd110:transport.py:513 RUN ['ipa', 'ping'] DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd110:transport.py:558 ipa: ERROR: Insufficient access: Invalid credentials DEBUG ipatests.pytest_ipa.integration.host.Host.master.cmd110:transport.py:217 Exit code: 1
PR, logs This is related to 8163
Metadata Update from @fcami: - Issue assigned to fcami
Metadata Update from @fcami: - Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/4508
The error message seems to vary in this case. logs with the originally expected error message.
Seen again in PR4513, logs
Metadata Update from @fcami: - Assignee reset
Metadata Update from @fcami: - Issue tagged with: Raven
Metadata Update from @fcami: - Custom field on_review reset (from https://github.com/freeipa/freeipa/pull/4508)
Also see this comment for an improvement.
Also in testing_master_previous Nightly PR #4579: logs
The original test failure (wrong message for ipa ping run as ad user) was happening on fedora 31. Now that PRCI has moved to fedora 32 the test failure is different:
RUN ['kinit', 'Administrator@ad.test'] kinit: KDC has no support for encryption type while getting initial credentials
Need to check what is different between fed31 and fed32 and could explain the problem.
Thanks to @abbra here is a pointer explaining what needs to be configured on AD side in our PR-CI: https://support.microsoft.com/en-ca/help/4492348/kerberos-unsupported-etype-error-when-authenticating-across-trust or https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/setting-up-samba-on-an-idm-domain-member_configuring-and-managing-idm#enabling-the-aes-encryption-type-in-active-directory-using-a-gpo_setting-up-samba-on-an-idm-domain-member
Fedora 32's default crypto policy does not support RC4 any more, and AES256 needs to be enabled on AD side.
I am looking into the issue and see strange behavior: kinit fails only for administrator but not for normal user:
[root@master1 vagrant]# kinit administrator@ad.test kinit: KDC has no support for encryption type while getting initial credentials [root@master1 vagrant]# kinit testuser@ad.test Password for testuser@ad.test: [root@master1 vagrant]# klist Ticket cache: KCM:0:71111 Default principal: testuser@AD.TEST Valid starting Expires Service principal 05/21/2020 13:50:48 05/21/2020 23:50:48 krbtgt/AD.TEST@AD.TEST renew until 05/22/2020 13:50:45
@frenaud Do you think it is expected or there could be a bug somewhere?
Update: applying instructions from both links does not change situation: kinit for administrator still fails and succeeds for normal user.
Yes, AD administrator created using only RC4 enctype. It needs a password reset before new encryption keys would be generated after a policy to allow AES would be applied.
PR: https://github.com/freeipa/freeipa-pr-ci/pull/366
Commit: https://github.com/freeipa/freeipa-pr-ci/pull/366/commits/873a9189afe6d739bfead28526f46198eccf0e49
Now waiting for deploy and next nightly run
Closing as https://github.com/freeipa/freeipa-pr-ci/pull/366 was merged.
Metadata Update from @fcami: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.