Inherited the TestACME class by overriding install()
to install the ipa master with external CA. It will
setup the External-CA and will call all the test
method from TestACME class.
related: https://pagure.io/freeipa/issue/4751
Signed-off-by: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
I noticed from draft release notes that some commits with a
different email address slipped in. Add myself to mailmap so that I
do not have doppelganger.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The basic idea is:
* add a user with a password
* kinit with a bad password for the user until lockout
* on another server administratively reset the password
* wait for replication to finish
* kinit on the original server again and the user should
be able to kinit again meaning the lockout was removed
https://pagure.io/freeipa/issue/8551
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This fixes the case where an account is locked on one or more servers
and the password is reset by an administrator. The account would
remain locked on those servers for the duration of the lockout.
This is done by setting krbLastAdminUnlock to the current date and
time. The lockout plugin will see this and unlock the account. Since
the value should be replicated along with the password any server
that has the new password will also be unlocked.
This does incur an additional attribute that must be replicated,
whether it is needed or not, but since lockout is computed
per-server this is the only guaranteed way to be sure that the
account will be unlocked everywhere.
My original thought was to grab password replication events and detect
whether the user was locked out and unlock them. On any given server
you can only know if the user is locked out on that server by
computing it. Doing this would require generalizing the lockout code
so it could be computed on password change. krbLastFailedAuth could
be wiped which would unlock the account on that master (the attribute
is not replicated by default).
So it is complexity vs additional replication. Assuming that admin
reset is relatively rare let's start with that. This doesn't lock
us into this solution for the future.
We could set this attribute on user-driven password changes as
well but the original ask and my thinking are that if you forgot
your password and got locked out, how can you change it yourself?
Upon reflection I guess a user could fat-finger it a bunch of times
against one IPA server then have a revelation and log in against a
different server. So they would still be locked out for the duration
on the first one. I'm not sure the extra replication is worth it for
user-generated password changes or that users would be saavy enough
to try another server for the change.
https://pagure.io/freeipa/issue/8551
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
PTR records in zones other than in-addr.arpa and in6.arpa are legal,
e.g. DNS-SD [RFC6763] uses such records. If in a reverse zone
proceed with the existing checks, otherwise just accept the record.
Fixes: https://pagure.io/freeipa/issue/5566
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Currently translated at 6.8% (321 of 4676 strings)
Translated using Weblate (Indonesian)
Currently translated at 2.9% (136 of 4676 strings)
Co-authored-by: Andika Triwidada <andika@gmail.com>
Translate-URL: https://translate.fedoraproject.org/projects/freeipa/master/id/
Translation: freeipa/master
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
test_acme.py::TestACMECALess::test_enable_caless_to_cafull_replica is
running ipa-acme-manage status on a CA-less server and wrongly
expects retcode =1. According to the man page, the command returns 3
when executed on a server where the CA is not installed.
Fixes: https://pagure.io/freeipa/issue/8572
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
With commit 02c3b27 that has been included in ipa-healthcheck 0.7,
IPADNSSystemRecordsCheck also checks the presence of an AAAA record
for ipa-ca.
The test needs to handle this case and expect an error message for
missing ipa-ca AAAA record.
Fixes: https://pagure.io/freeipa/issue/8573
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
In ipa-healthcheck ds-related tests i.e
test_ipahealthcheck.py::TestIpaHealthCheck::test_ipahealthcheck_ds_configcheck
there exists a scenario of modifying the "nsslapd-logging-hr-timestamps-enabled" attribute to off
The tests are failing with the below error
"ipalib.errors.MidairCollision: change collided with another change"
The test audit log displays that the attribute is deleted first and then added.
changetype: modify
delete: nsslapd-logging-hr-timestamps-enabled
nsslapd-logging-hr-timestamps-enabled: on
-
add: nsslapd-logging-hr-timestamps-enabled
nsslapd-logging-hr-timestamps-enabled: off
Adding the nsslapd-logging-hr-timestamps-enabled attribute in _SINGLE_VALUE_OVERRIDE table
to check if we generate a replace instead of add and delete.
Signed-off-by: Sudhir Menon <sumenon@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
1. test_ipahealthcheck_ds_configcheck
checks ensures that warning message is displayed by ConfigCheck
when high resolution timestamp is disabled
2. test_ipahealthcheck_ds_fschecks
Test has been now moved under Class TestIpaHealthCheckFileCheck
This testcase checks that when permission of pwdfile.txt is changed
to other than 400, FSCheck returns CRITICAL status
3. test_ds_configcheck_passwordstorage
This test checks that critical status is displayed by
ConfigCheck when rootpwstoragescheme is set to MD5 instead
of the required PBKDF2_SHA256
4. test_ipahealthcheck_topology_with_ipactl_stop
This testcase ensures that ipahealthcheck.ipa.topology check
doesnot display 'source not found' on a system when ipactl
stop is run
5. Modified testcase name
the testcase name and description have been modified to match
the actual testcase executed
Signed-off-by: Sudhir Menon <sumenon@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Dynamic plugin registry returns as a plugin any folder within the
plugins directory. Web UI then attempts to load for each plugin 'foo' a
JavaScript file named 'foo/foo.js'. The problem is that if 'foo/foo.js'
does not exist, Web UI breaks and it is impossible to recover until the
empty folder is removed or 'foo/foo.js' (even empty) is created at the
server side.
Check that 'foo/foo.js' actual exists when including a plugin into the
registry.
Test the registry generator by creating fake plugins and removing them
during the test.
Fixes: https://pagure.io/freeipa/issue/8567
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
When initializing UPN suffixes, we calculate their sizes and didn't use
the right variable to allocate their size. This affects us if there are
more than one UPN suffix available for a trust due to memory corruption
while filling in sizes.
Add unit test for multiple UPN suffixes.
Fixes: https://pagure.io/freeipa/issue/8566
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
If no results are returned then find_entries will raise
EmptyResult and not NotFound. NotFound is returned if
the search base doesn't exist.
The test for not entries can be removed as well since this
is the EmptyResult case. In case of a NotFound this will
be handled by the ExecutionError clause.
Found with https://pagure.io/freeipa/issue/8555
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Use ldapmodify to remove the objectclass from the default
global policy then run ipa-server-upgrade to confirm
that it is properly added.
https://pagure.io/freeipa/issue/8555
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
ipapwdpolicy is the objectclass which defines the libpwquality
attributes. For older sytems it isn't strictly necessary (or
visible) but not having it included will result in policies
not being visible with pwpolicy-find.
https://pagure.io/freeipa/issue/8555
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The integration test test_trust.py::TestTrust::test_password_login_as_aduser
is expecting curl to output the cookie obtained after password login
in stdout but should use stderr instead.
Fixes: https://pagure.io/freeipa/issue/8559
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Test that:
1. With ACME enabled, SAN is required
2. With ACME disabled, SAN is not required
Also verify the ipa-acme-manage status command.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Traditionally in IPA 0 = success, 1 = error and then
specific error messages follow from that. Shift the
ipa-acme-manage return codes for "not installed" and
"not a CA" up by one.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
ACME requires an ipa-ca SAN to have a fixed URL to connect to.
If the Apache certificate is replaced by a 3rd party cert then
it must provide this SAN otherwise it will break ACME.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
New validation efforts in 389-ds-base require that the backend entry for
a database be created before the mapping tree entry. This enforces that
the mapping tree entry (the suffix) actually belongs to an existing backend.
For IPA we simply need to reverse the order of the backend vs mapping tree
creation in cainstance.py -> __create_ds_db()
Fixes: https://pagure.io/freeipa/issue/8558
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Nightly test failure was seen for test_ipahealthcheck_ds_encryption
The test was failing since @pytest.fixture was not specified before
the function modify_tls
Ref: https://pagure.io/freeipa/issue/8560
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Collect the let's encrypt client log for any potential
debug purposes.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Test if ACME service is enabled on replica if eabled on
server. This is to check the centralize enable/disable
from single host.
ipatests: Test if ACME is enabled on replica when converted from CA-less to CA-full
Deployment where one server is deployed as CA-less and acme is enabled, when converted
to CA full, should have ACME enabled by default.
ipatests: Test ACME with CA-less replica when converted to CA-full
Deployment have one ca-less replica and ACME is not enabled.
After converting ca-less replica to ca-full, ACME can be
enabled or disabled.
related:
https://pagure.io/freeipa/issue/8524
Signed-off-by: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
It's handy in general and good for testing to be able to
detect the current ACME status without having to revert
to using curl.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
The initial ACME support required that each server individually
enable/disable the service. PKI 10.10.0 stores this state in LDAP
so global enable/disable is available and the IPA code relies on
this.
Parse the VERSION file shipped with PKI to determine the version.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
This allows non-plugin components to import the RestClient
classes.
Removed code that only imported pki if in_server was True. This
was legacy code from when the plugins were also loaded in the
client.
Left the ra_plugin stanza for now. This is part of the old
abstraction that allowed for different CA plugins.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
This is to be able to import ACME schema provided by dogtag.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
This testcase modifies the update value set on RI Plugin
to -1 as a result checks that RIPluginCheck reports warning message
Signed-off-by: Sudhir Menon <sumenon@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
This testcase checks that EncryptionCheck reports ERROR status when DS tls version is
modified to TLS1.0
Signed-off-by: Sudhir Menon <sumenon@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
This testcase checks that the BackendsCheck reports
the CRITICAL status when dse.ldif present in the
DS instance directory is renamed/moved.
Signed-off-by: Sudhir Menon <sumenon@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
MIT Kerberos implements FAST negotiation as specified in RFC 6806
section 11. The implementation relies on the caller to provide a hint
whether FAST armoring must be used.
FAST armor can only be used when both client and KDC have a shared
secret. When KDC is from a trusted domain, there is no way to have a
shared secret between a generic Kerberos client and that KDC.
[MS-KILE] section 3.2.5.4 'Using FAST When the Realm Supports FAST'
allows KILE clients (Kerberos clients) to have local settings that
direct it to enforce use of FAST. This is equal to the current
implementation of 'kinit' utility in MIT Kerberos requiring to use FAST
if armor cache (option '-T') is provided.
[MS-KILE] section 3.3.5.7.4 defines a way for a computer from a
different realm to use compound identity TGS-REQ to create FAST TGS-REQ
explicitly armored with the computer's TGT. However, this method is not
available to IPA framework as we don't have access to the IPA server's
host key. In addition, 'kinit' utility does not support this method.
Active Directory has a policy to force use of FAST when client
advertizes its use. Since we cannot know in advance whether a principal
to obtain initial credentials for belongs to our realm or to a trusted
one due to enterprise principal canonicalization, we have to try to
kinit. Right now we fail unconditionally if FAST couldn't be used and
libkrb5 communication with a KDC from the user realm (e.g. from a
trusted forest) causes enforcement of a FAST.
In the latter case, as we cannot use FAST anyway, try to kinit again
without advertizing FAST. This works even in the situations when FAST
enforcement is enabled on Active Directory side: if client doesn't
advertize FAST capability, it is not required. Additionally, FAST cannot
be used for any practical need for a trusted domain's users yet.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When applying update files to 389 the listeners are disabled.
There is a large try/except around this so that if a failure
happens then the configuration should be automatically
restored.
We've seen multiple cases where this doesn't occur. Best guess
is that users are killing or ^C breaking out of the script.
What happens in that case is that when the next upgrade is run
the configuration is backed up again overwriting the original
values. This leaves dirsrv with no listener on 389.
Add a new state, upgrade-in-progress, so that the backup of the
config information can be skipped when the upgrader is executed
again after a failure.
The idea behind using a new state value is that if additional
attributes are ever backed up we don't need to remember to update
the list of possible saved values to check to decide if the
upgrade is in progress.
https://pagure.io/freeipa/issue/7534
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
[MS-ADTS] 6.1.6.9.3.2 requires msDS-TrustForestTrustInfo attribute of
trusted domain information in Active Directory to conform certain rules.
One side-effect of those rules is that list of UPN suffixes reported
through the netr_DsRGetForestTrustInformation function is dynamically
filtered to deduplicate subordinate suffixes.
It means that if list of UPN suffixes contains the following top level
names (TLNs):
fabrikam.com
sub.fabrikam.com
then netr_DsRGetForestTrustInformation would only return 'fabrikam.com'
as the TLN, fully filtering 'sub.fabrikam.com'.
IPA KDB driver used exact comparison of the UPN suffixes so any
subordinate had to be specified exactly.
Modify logic so that if exact check does not succeed, we validate a
realm to test being a subordinate of the known UPN suffixes. The
subordinate check is done by making sure UPN suffix is at the end of the
test realm and is immediately preceded with a dot.
Because the function to check suffixes potentially called for every
Kerberos principal, precalculate and cache length for each UPN suffix at
the time we retrieve the list of them.
Fixes: https://pagure.io/freeipa/issue/8554
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
ipa_sam was modifying the buffer returned by ipa_gethostfqdn().
Subsequent calls to ipa_gethostfqdn() returned the corrupt data,
causing other operations to fail.
Update ipa_sam to copy the string and modify the copy. Also
document this characteristic of ipa_gethostfqdn() and explain that
callers must not modify the returned data.
Part of: https://pagure.io/freeipa/issue/8501
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
ipa_gethostfqdn() now returns a pointer to a statically allocated buffer
or NULL in case of an error. The caller no longer has to supply a
correctly allocated buffer.
Rename IPA_HOST_HOST to_LEN IPA_HOST_FQDN_LEN and use IPA_HOST_FQDN_LEN
wherever code copies a hostname supplied from ipa_gethostfqdn().
Clarify that MAXHOSTNAMELEN and MAXHOSTFQDNLEN are different things.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
ipa_kdb and ipa-join now use ipa_gethostfqdn() instead of uname()'s nodename.
The code for hostname in ipa-join is simplified. Now the hostname is
auto-detected and verified in main(). All sub functions can now use the
hostname without additional checks. This removes a bunch of strdup(),
NULL checks, and free() calls.
Fixes: https://pagure.io/freeipa/issue/8501
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
FreeIPA's Python and C code used different approaches to get the FQDN of
the host. Some places assumed that gethostname() returns a FQDN. Other
code paths used glibc's resolver to resolve the current node name to a
FQDN.
Python code now uses the ipalib.constants.FQDN where a fully qualified
domain name is expected. The variable is initialized only once and avoids
potential DNS lookups.
C code uses a new helper function ipa_gethostfqdn() in util package. The
function implements similar logic as gethostfqdn() except it uses more
modern getaddrinfo(). The result is cached as well.
Fixes: https://pagure.io/freeipa/issue/8501
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>