tasks.create_active_user can fail in a subtle way when there
are two IPA servers due to replication delays.
Using the debug-enabled version of create_active_user helps
determine whether there is another underlying issue and, in
general, prevents the above problem.
Fixes: https://pagure.io/freeipa/issue/8944
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Anuja More <amore@redhat.com>
During interactive session of `ipa-adtrust-install` the user needs to
answer several questions. This was done by sending all answers to
the processes stdin without analyzing the questions.
If the installation scenario changes at some point we can get on of the
following results:
* the test fails in the end and the root cause is not obvious
* if a new question was added
* test does not fail but answers are provided for wrong questions -
in this case scope of test case changes without being noticed
If we use `pexpect` for controlling the session, the test will fail
immediately when it encounters unexpected question.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The test test_adtrust_install.py::TestIpaAdTrustInstall::test_add_agent_not_allowed
sometimes fails at kinit in create_active_user:
```
kinit: Password has expired while getting initial credentials
```
krb5_strace shows that this happens when kinit changes servers
between password change and TGT requests.
Display SSSD's kdcinfo to see if kinit should be pinned to one
server.
Related-to: https://pagure.io/freeipa/issue/8353
Related-to: https://pagure.io/freeipa/issue/8271
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Sumit Bose <sbose@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
The test test_adtrust_install.py::TestIpaAdTrustInstall::test_add_agent_not_allowed
sometimes fails at kinit in create_active_user:
```
kinit: Password has expired while getting initial credentials
```
Use krb5_trace to catch the required debug information.
Related-to: https://pagure.io/freeipa/issue/8353
Related-to: https://pagure.io/freeipa/issue/8271
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
When ipa-adtrust-install is used, IPA KDC will be configured to issue
tickets with MS-PAC record in them for users and services that have
ipaNTSecurityIdentifier (SID) attribute in the LDAP record.
Test that a newly added user can kinit and obtain a ticket that has
a PAC structure.
Test that a service can impersonate a user and the resulting S4U2Self
requested service ticket also has PAC structure.
Related: https://pagure.io/freeipa/issue/8319
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Isaac Boukris <iboukris@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is to ensure if said entry is set after installation with AD.
related: https://pagure.io/freeipa/issue/8193
Signed-off-by: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Kaleemullah Siddiqui <ksiddiqu@redhat.com>
Add tests checking the behavior of ipa-adtrust-install when
adding trust agents:
- try calling the remote method trust_enable_agent with
a principal missing the required privilege.
- try adding a trust agent when the remote node is stopped.
The installer must detect that he's not able to run the remote
commands and print a WARNING.
- try adding a trust agent when the remote node is running.
The WARNING must not be printed as the remote configuration is done.
- try adding a trust agent with --enable-compat.
The WARNING must not be printed and the Schema Compatibility plugin
must be enabled (the entries
cn=users/groups,cn=Schema Compatibility,cn=plugins,cn=config
must contain a new attribute schema-compat-lookup-nsswitch
(=user/group).
Thanks to sorlov for the nightly test definitions and new test.
Related: https://pagure.io/freeipa/issue/7600
Co-authored-by: Sergey Orlov <sorlov@redhat.com>
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>