* switch to Python 3.7 (UsePythonVersion@0 task)
* use "pip install --user"
Fixes: https://pagure.io/freeipa/issue/8030
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Move common and error messages to class scope to be reused again.
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Add interactive configuration tests for
ipa-server-install and ipa-client-install
FreeIPA server as it is now is unable to
configure NTP interactively for replica
installations.
Resolves: https://pagure.io/freeipa/issue/7908
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When moving a preserved user to the stage area, check that the
custom attributes are not lost ( = the attr for which there is
no specific user_stage option).
Test scenario:
- add a stage user with --setattr "businesscategory=value"
- activate the user, check that businesscategory is still present
- delete (preserve) the user, check that attr is still present
- stage the user, check that attr is still present
Related: https://pagure.io/freeipa/issue/7597
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The user-stage command is internally implemented as:
- user_show(all=True) in order to read the user attributes
- loop on the attributes defined as possible to add using stageuser-add and
transform them into new options for stageuser_add (for instance stageuser-add
provides the option --shell for the attribute loginshell, but there is no
option for the attribute businesscategory).
- call stageuser_add in order to create a new entry in the active users subtree
- user-del to remove the previous entry in the staged users subtree
The issue is in the 2nd step. Only the attributes with a stageuser-add option
are processed.
The logic of the code should be slightly modified, so that all the attributes
read in the first step are processed:
- if they correspond to an option of stageuser-add, process them like it's
currently done. For instance if the entry contains displayname, then it
should be processed as --displayName=value in the stageuser-add cmd
- if they do not correspond to an option of stageuser-add, add them with
--setattr=<attrname>=<attrvalue>
Note that some attributes may need to be filtered, for instance user-show
returns has_password or has_keytab, which do not correspond to attributes
in the LDAP entry.
Fixes: https://pagure.io/freeipa/issue/7597
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
test_nfs.py historically used master_2repl_1client.
Now that master_3client exists, switch to that as it allows removal
of custom install/cleanup steps.
Fixes: https://pagure.io/freeipa/issue/8027
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
config_replica_resolvconf_with_master_data() is not replica specific.
Rename to config_host_resolvconf_with_master_data() as it is not tied
to any role (master, replica, client).
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Previously test_nfs.py would implement its own method to configure
resolv.conf leading to cleanup failures in some cases.
Use tasks.config_replica_resolvconf_with_master_data() instead.
Also simplify and fix client uninstall.
Fixes: https://pagure.io/freeipa/issue/7949
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Some tests would benefit from using a multi-client topology.
As PR-CI now supports master_3client, use it.
Fixes: https://pagure.io/freeipa/issue/8026
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
Commit 9182917280a5c2590fa677729db54b38a9ac4d1f introduced
SUCCESS, SERVER_INSTALL_ERROR and SERVER_NOT_CONFIGURED to
deal with cases when server is not configured.
Actually use SERVER_NOT_CONFIGURED in log_failure instead of 2.
Related-to: https://pagure.io/freeipa/issue/6843
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Test scenario:
- create a hostgroup
- create a host
- create an automember rule for the hostgroup with a condition fulfilled
by the host
- delete the hostgroup
- call automember-rebuild (1)
- call automember-find-orphans to remove the orphan automember group
- call automember-rebuild(2)
The test was expecting the first rebuild command to fail but this
assumption is not true if the DS version is >= 1.4.0.22 because of the
fix for https://pagure.io/389-ds-base/issue/50077
Modify the test so that it expects failure only when DS is older.
Fixes: https://pagure.io/freeipa/issue/7902
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Because of intergration with AD server response can take time more then 1 minute.
So request_timeout is increased to 120s.
Ticket: https://pagure.io/freeipa/issue/8024
Signed-off-by: Serhii Tsymbaliuk <stsymbal@redhat.com>
Reviewed-By: Tibor Dudlak <tdudlak@redhat.com>
- Add 'Server Options' section to the page
- Add 'IPA master capable of PKINIT' field to the 'Server Options'
Ticket: https://pagure.io/freeipa/issue/7305
Signed-off-by: Serhii Tsymbaliuk <stsymbal@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Problem: After adding ldap_deref_threshold=0 setting for sssd on master for
performance enhancement ssh from ipa client was failing
Test Procedure:
1. setup a master
2. add ldap_deref_threshold=0 to sssd.conf on master
3. add an ipa user
4. ssh from controller to master using the user created in step 3
Signed-off-by: Sumedh Sidhaye <ssidhaye@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The "domain_member" state was not removed at uninstall time.
Remove it so that future invocations of ipa-client-samba work.
Fixes: https://pagure.io/freeipa/issue/8021
Signed-off-by: François Cami <fcami@redhat.com>
https://pagure.io/freeipa/issue/8021
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Related-to: https://pagure.io/freeipa/issue/8021
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Fixes: https://pagure.io/freeipa/issue/8019
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Related-to: https://pagure.io/freeipa/issue/8019
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
The azure pipeline defines a "prepare build" step that
installs the FreeIPA development dependencies but the
step does not report failures of the dnf builddep command.
As a consequence, subsequent steps may fail (for instance
because of components not installed such as tox) but are
hard to diagnose.
The fix reports the command failure.
Fixes: https://pagure.io/freeipa/issue/8022
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Problem:
If a replica installation fails before all the services have been enabled then
it could leave things in a bad state.
ipa-replica-manage del <replica> --cleanup --force
invalid 'PKINIT enabled server': all masters must have IPA master role enabled
Test Steps:
1. Setup server
2. Setup replica
3. modify the replica entry on Master:
dn: cn=KDC,cn=<replica hostname>,cn=masters,cn=ipa,cn=etc,dc=<test>,dc=<realm>
changetype: modify
delete: ipaconfigstring
ipaconfigstring: enabledService
dn: cn=KDC,cn=<replica hostname>,cn=masters,cn=ipa,cn=etc,dc=<test>,dc=<realm>
add: ipaconfigstring
ipaconfigstring: configuredService
4. On master,
run ipa-replica-manage del <replicaFQDN> --cleanup --force
Related Ticket: https://pagure.io/freeipa/issue/7929
Signed-off-by: Sumedh Sidhaye <ssidhaye@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The p11helper module now includes the name of the PKCS#11 shared library
in error messages.
Fixes: https://pagure.io/freeipa/issue/8015
Co-Authored-By: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
- Increase wait timeout after password reset
- Wait for server response after login in TestLoginScreen.test_reset_password_and_login_view
Ticket: https://pagure.io/freeipa/issue/8012
Signed-off-by: Serhii Tsymbaliuk <stsymbal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When the DS certificate gets untracked then tracked again (via
dsinstance.start_tracking_certificate()), it loses its profile
configuration. Although it is the default profile, we want to
retain the explicit reference. Ensure we add the profile when
re-tracking the DS certificate.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When the HTTP certificate gets untracked then tracked again, it
loses its pin file. Ensure we add the pin file when (re-)tracking
the HTTP certificate.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Replace renewal CA and profile name literals with corresponding
symbols from ipalib.constants.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Profile-based renewal means we should always explicitly specify the
profile in tracking requests that use the dogtag-ipa-ca-renew-agent
renewal helper. This includes the IPA RA agent certificate. Update
CAInstance.configure_agent_renewal() to add the profile to the
tracking request. This also covers the upgrade scenario (because
the same method gets invoked).
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The search for the HTTP Certmonger tracking request uses an
incorrect parameter ('key-storage'), triggering removal and
recreation of tracking requests on every upgrade. Replace
'key-storage' with the correct parameter, 'key-file'.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For better diagnostics during upgrade, log the Certmonger tracking
requests that were not found (either because they do not exist, or
do not have the expected configuration).
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The upgrade routine checks tracking requests for CA system
certificates, IPA RA and HTTP/LDAP/KDC service certificates. If a
tracking request matching our expectations is not found, we stop
tracking all certificates, then create new tracking requests with
the correct configuration.
But the KRA was left out. Add checks for KRA certificates, and
remove/recreate KRA tracking requests when appropriate.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The profile for every Dogtag system cert tracking request is now
explicitly specified. So remove the code that handled unspecified
profiles.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The Dogtag "Server-Cert cert-pki-ca" certificate is treated
specially, with its own track_servercert() method and other special
casing. But there is no real need for this - the only (potential)
difference is the token name. Account for the token name difference
with a lookup method and treat all Dogtag system certs equally
w.r.t. tracking request creation and removal.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Update the renewal helper to always request a new certificate
("enrollment request") instead of using "renewal request". The
latter is brittle in the face of:
- missing certificate record in database
- missing original request record in database (pointed to by
certificate record)
- "mismatched" certificate or request records (there have been many
cases of this; it is suspected that request/serial range conflicts,
or something similar, may be the cause)
The Dogtag tracking request must know what profile to use, except
where the certificate uses the default profile ("caServerCert" per
'dogtag-ipa-renew-agent' implementation in Certmonger itself).
This part of the puzzle was dealt with in previous commits.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
To aid reader comprehension, use long options instead of short
options when invoking dogtag-ipa-renew-agent.
-N -> --force-new
-O -> --approval-option
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
To use profile-based renewal (rather than "renewal existing cert"
renewal which is brittle against database corruption or deleted
certificate / request objects), Certmonger tracking requests for
Dogtag system certs must record the profile to be used.
Update the upgrade method that checks tracking requests to look for
the profile. Tracking requests will be recreated if the expected
data are not found. The code that actually adds the tracking
requests was updated in a previous commit.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Enabling "fresh" renewals (c.f. "renewal"-based renewals that
reference the expired certificate and its associated request object)
will improve renewal robustness.
To use fresh renewals the tracking request must record the profile
to be used. Make dogtaginstance record the profile when creating
tracking requests for both CA and KRA.
Note that 'Server-Cert cert-pki-ca' and the 'IPA RA' both use
profile 'caServerCert', which is the default (according to
dogtag-ipa-renew-agent which is part of Certmonger). So we do not
need any special handling for those certificates.
This commit does not handle upgrade. It will be handled in a
subsequent commit.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
This will allow cifs principals to be found. They were suppressed
because they include objectclass=posixAccount.
This is a bit of a historical anomaly. This was included in the
filter from the initial commit (though it was person, not
posixAccount). I believe it was a mistake from the beginning but
it wasn't noticed because it didn't cause any obvious issues.
https://pagure.io/freeipa/issue/8013
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Add tests for remaining untested scenarios of --external-ca-profile
handling in ipa-server-install.
ipa-ca-install and ipa-cacert-manage remain untested at present.
Fixes: https://pagure.io/freeipa/issue/7548
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Commit dd47cfc75a removed the ability
to set pki_req_ext_oid and pki_req_ext_data in the pkispawn config.
This results in the --external-ca-profile option never setting the
requested values in the CSR (the default V1 template type specifying
"SubCA" is always used).
Remove relevant fields from both ipaca_default.ini and
ipaca_customize.ini. This allows the IPA framework to set the
values (i.e. when --external-ca-type=ms-cs and
--external-ca-profile=... demand it). It also allows users to
override the pki_req_ext_* settings.
Part of: https://pagure.io/freeipa/issue/7548
Related: https://pagure.io/freeipa/issue/5608
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
As we expand the integration tests for external CA functionality, it
is helpful (and avoids duplication) to use the MSCSTemplate*
classes. These currently live in ipaserver.install.cainstance, but
ipatests is no longer permitted to import from ipaserver (see commit
81714976e5e13131654c78eb734746a20237c933). So move these classes to
ipalib.
Part of: https://pagure.io/freeipa/issue/7548
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Try to create a certmap rule that mentiones altSecurityIdentities in its
mapping rule but uses IPA domain to apply to. It should fail with
ValidationError.
Related: https://pagure.io/freeipa/issue/7932
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
IPA LDAP has no altSecurityIdentities in use, it only should apply to
identities in trusted Active Directory domains.
Add checks to enforce proper certmap rule attribution for specific
Active Directory domains.
Related: https://pagure.io/freeipa/issue/7932
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
During an investigation into filter optimisation in 389DS it was
discovered that two attributes of the certmap query are unindexed.
Due to the nature of LDAP filters, if any member of an OR query is
unindexed, the entire OR becomes unindexed.
This is then basically a full-table scan, which applies the filter test
to the contained members.
Fixes: https://pagure.io/freeipa/issue/7932
Fixes: https://pagure.io/freeipa/issue/7933
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Active Directory schema includes altSecurityIdentities attribute
which presents alternative security identities for a bindable object in
Active Directory.
FreeIPA doesn't currently use this attribute. However, SSSD certmap
library may generate searches referencing the attribute if it is
specified in the certificate mapping rule. Such search might be
considered unindexed in 389-ds.
Define altSecurityIdentities attribute to allow specifying indexing
rules for it.
Fixes: https://pagure.io/freeipa/issue/7932
Related: https://pagure.io/freeipa/issue/7933
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
