The domain and ca objects were unreadable which caused
the conneciton lines between nodes in the UI to not be
visible.
Also add a manual ACI to allow reading the min/max
domain level.
Fixes: https://pagure.io/freeipa/issue/9594
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
The name used to be "export_%Y_%m_%d_%H_%M_%S" so if the tasks
were added within the same second the second backend would fail.
Add the backend name to the task name to ensure uniqueness.
export_{backend}_%Y_%m_%d_%H_%M_%S
Fixes: https://pagure.io/freeipa/issue/9584
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mark Reynolds <mreynolds@redhat.com>
The initial design for ticket flags was implementing this logic:
* If a ticket policy is defined for the principal entry, use flags from
this policy if they are set. Otherwise, use default ticket flags.
* If no ticket policy is defined for the principal entry, but there is a
global one, use flags from the global ticket policy if they are set.
Otherwise, use default ticket flags.
* If no policy (principal nor global) is defined, use default ticket
flags.
However, this logic was broken by a1165ffb which introduced creation of
a principal-level ticket policy in case the ticket flag set is modified.
This was typically the case for the -allow_tix flag, which was set
virtually by the KDB driver when a user was locked until they initialize
their password on first kinit pre-authentication.
This was causing multiple issues, which are mitigated by the new
approach:
Now flags from each level are combined together. There flags like
+requires_preauth which are set systematically by the KDB diver, as
well as -allow_tix which is set based on the value of "nsAccountLock".
This commit also adds the implicit -allow_svr ticket flag for user
principals to protect users against Kerberoast-type attacks. None of
these flags are stored in the LDAP database, they are hard-coded in the
KDB driver.
In addition to these "virtual" ticket flags, flags from both global and
principal ticket policies are applied (if these policies exist).
Principal ticket policies are not supported for hosts and services, but
this is only an HTTP API limitation. The "krbTicketPolicyAux" object
class is supported for all account types. This is required for ticket
flags like +ok_to_auth_as_delegate. Such flags can be set using "ipa
host-mod" and "ipa serivce-mod", or using kadmin's "modprinc".
It is possible to ignore flags from the global ticket policy or default
flags like -allow_svr for a user principal by setting the
"final_user_tkt_flags" string attribute to "true" in kadmin. In this
case, any ticket flag can be configured in the principal ticket policy,
except requires_preauth and allow_tix.
When in IPA setup mode (using the "ipa-setup-override-restrictions" KDB
argument), all the system described above is disabled and ticket flags
are written in the principal ticket policy as they are provided. This is
required to initialize the Kerberos LDAP container during IPA server
installation.
This fixes CVE-2024-3183
Signed-off-by: Julien Rische <jrische@redhat.com>
The initial implementation of MS-SFU by MIT Kerberos was missing a
condition for granting the "forwardable" flag on S4U2Self tickets.
Fixing this mistake required adding special case for the
check_allowed_to_delegate() function: if the target service argument is
NULL, then it means the KDC is probing for general constrained
delegation rules, not actually checking a specific S4U2Proxy request.
In commit e86807b5, the behavior of ipadb_match_acl() was modified to
match the changes from upstream MIT Kerberos a441fbe3. However, a
mistake resulted in this mechanism to apply in cases where target
service argument is set AND unset. This results in S4U2Proxy requests to
be accepted regardless of the fact there is a matching service
delegation rule or not.
This vulnerability does not affect services having RBCD (resource-based
constrained delegation) rules.
This fixes CVE-2024-2698
Signed-off-by: Julien Rische <jrische@redhat.com>
The behavior of ipa-replica-manage list-ruv was modified with
the commit 544652a and now displays host short names instead
of FQDN:port.
Fix the regular expression in order to return the FQDN:port again.
Fixes: https://pagure.io/freeipa/issue/9598
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
By default, interactive console prints full traceback in case of an
error. This looks weird in the console when LDAP errors pop up.
Instead, process PublicError exceptions as if they are final ones and
only print their message.
As a result, calls like api.Command.user_show('unknown') would
result in a concise message:
>>> api.Command.user_show('unknown')
IPA public error exception: NotFound: unknown: user not found
>>>
rather than a two-screen long traceback.
Fixes: https://pagure.io/freeipa/issue/9590
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
jwcrypto has turned JWK object into a dict-like structure in 2020 and
marked data wrappers as deprecated. The only exception for direct
foo['bar'] access is a key ID -- some keys might have no 'kid' property,
thus it is best to use jwk.get('kid') instead for those.
Fixes: https://pagure.io/freeipa/issue/9597
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For each executed command in server context, send the information about
the command to the systemd journal. The resulting string is similar to
what is recored in httpd's error_log for API requests coming through the
RPC layer.
In server mode operations are performed directly on the server over
LDAPI unix domain socket, so httpd end-point is not used and therefore
operations aren't recorded in the error_log.
With this change any IPA API operation is sent as an audit event to the
journal, alog with additional information collected by the journald
itself.
To aid with identification of these messages, an application name is
replaced with IPA.API and the actual name from api.env.script is made a
part of the logged message. The actual application script name is
available as part of the journal metadata anyway.
If no Kerberos authentication was used but rather LDAPI autobind was in
use, the name of the authenticated principal will be replaced with
[autobind].
Messages sent with syslog NOTICE priority.
More information is available in the design document 'audit-ipa-api.md'
Fixes: https://pagure.io/freeipa/issue/9589
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Context changes cause linters to complain for older code formatting
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
To prevent cyclic imports, move JSON handling code to a separate file.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
batch(methods=Dict(), keeponly=list) will allow to execute batch of
commands and remove from the output everything but the attributes which
names were passed in the keeponly list.
This can be useful if you are only interested in getting names and
assigned random passwords, for example.
Fix batch API test in test_integration/test_idm_api.py and use it to
validate keeponly option.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Follow pylint recommendations (turned errors in recent pylint updates)
and use PEP-380 syntax for subgenerators. This is supported by all
Python 3 versions since ~2011.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In LDAP auto-bind situation we will not have a Kerberos principal
available, so we should be using a different mechanism to find the
object. Since we already have a valid bound LDAP DN, use it as a base DN
here and simply require presence of the POSIX account.
This will not match 'cn=Directory Manager' but none of the code we have
uses LDAP auto-bind as root when calling 'ipa user-find --whoami'.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
When processing certificate issuance requests a care has to be done to
match operations done as LDAP auto-bind to actual principals for
validation. This is a tough one as we have no principal to match for
cn=Directory Manager. Use fake principal to fail validation here and
rely on LDAP ACIs instead.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
We only get to this code path when running in the server context. At
that point _bindings_installed will be defined. Pylint cannot track this
and always fails with this check.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
Make sure to reject requests unless we are operating as a Directory
Manager in such cases.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
When batch runs under server context, we have no context.principal set
because we talk directly to LDAPI endpoint and authenticate using
auto-binding, not GSSAPI. Account to that in the logger.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In server-like context we use LDAPI connection with auto-binding to LDAP
object based on the UID of the process connecting to LDAPI UNIX domain
socket. This means context.principal is not set and we cannot use it.
In principal_has_privilege() we can take None principal object as a sign
that currently bound LDAP DN has to be checked for the privilege. This
allows to match any type of account to the privilege, with exception of
the cn=Directory Manager which is never added to privileges explicitly.
cn=Directory Manager will be allowed any privilege because it already
can write to any LDAP entry.
Fixes: https://pagure.io/freeipa/issue/9583
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
I don't know why these weren't added originally when the
topology plugin was created.
Add them all to the 'Replication Administrators' privilege
Fixes: https://pagure.io/freeipa/issue/9594
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
SID anchors are only resolvable on servers with DCERPC bindings
installed. On non agent replica these bindings are not installed and
therefore group and role management if there are AD user idoverride
members.
If there is an ipaUserOverride for the anchor, the ipaoriginaluid is
returned.
Fixes: https://pagure.io/freeipa/issue/9544
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
update after change in implementation of `krb_utils.get_principal()` now using GSSAPI
Related: https://pagure.io/freeipa/issue/9575
Signed-off-by: Erik Belko <ebelko@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Sometimes RUV's are missing the LDAP Url and max/min csns. This prevents
cleanallruv task from running. However, cleanallruv doesn't need to
know the LDAP URL or min/max csns. Added a new paramter to get_run()
called "strict", and when set to False it will still process and
include incomplete RUVs.
Fixes: https://pagure.io/freeipa/issue/9591
Signed-off-by: Mark Reynolds <mreynolds@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
If there is no token name it is safe to assume that an HSM
installation is not requested. The validator assumes that if
there is a token name then the library and password are also
provided.
Fixes: https://pagure.io/freeipa/issue/9593
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
sss_ssh_knownhostsproxy will be deprecated in favor of sss_ssh_knownhosts. This commit
implements a mechanism to apply the change when upgrading from older versions.
Fixes: https://pagure.io/freeipa/issue/9536
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
sss_ssh_knownhostsproxy will be deprecated in favor of sss_ssh_knownhosts.
With this update, if the file /usr/bin/sss_ssh_knownhosts is present,
KnownHostsCommand will be used instead of ProxyCommand. Also, GlobalKnownHostsFile
is disabled as it is no longer needed.
Fixes: https://pagure.io/freeipa/issue/9536
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Additional SELinux rules are necessary for the HSM to be
managed by IPA and certmonger. Given the infinite possible
naming combinations of library paths and modules this is
a best effort. A message is logged if a missing module
is detected.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Don't blow up if the expected module is not installed but warn
about it. Hopefully users will actually read the output and/or the
installation log.
This is done by looking for strings in the path. Not great but
it's at least something.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
hsm_validator was validating that the token was available but
not that the provided password worked. Add that capability.
Also call it early in the CA and KRA installation cycle so that
it errors out early. This is particularly important for the KRA
because there is no uninstaller.
Bump the minimum PKI release to 11.5.0 as that contains important
fixes for the HSM.
Remove an unused arguments to hsm_version and hsm_validator.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
* Switch to CA user when saving NSS certificates
* Add new certs to internal token, try harder to remove on renewal
* Don't restrict tokens to CKM_RSA_X_509
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
If a certificate on a token does not have NSS trust set then
it won't be visible in the softoken. This can be disconcerting
for those used to seeing all the certificates.
Loop through the possibilities and set no trust (or Peer) for
all the certificates on the token.
Also ensure that the CA certificate has the correct nickname.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Not all HSMs support PKCS#1 v1.5. The nShield nFast is one we know
of so force the KRA to use OAEP in this case..
This can be seen in HSMs where the device doesn't support the
PKCS#1 v1.5 mechanism. It will error out with either "invalid
algorithm" or CKR_FUNCTION_FAILED.
There is currently no good way to test for this capability in
advance of configuration. Testing for mechanisms alone is
insufficient. The only real way to test would be to attempt a
wrap/unwrap but it is very complex.
If the list of affected HSMs increases we can use a table
instead based on "best guess" of some sort of property but
looking for a unique string inside the library path is a
pretty straigthforward way.
Note that this doesn't preclude someone from wanting to require
OAEP directly by modifying the KRA CS.cfg and it won't impact
FIPs mode which requires OAEP.
Related: https://pagure.io/freeipa/issue/9191
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
If the password wasn't provided by --token-password then an empty
value would be passed into the CA installer which promptly failed.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
On a non-HSM, non-renewal-server replica we look in LDAP for
an updated certificate. If the certificates don't match then we
have a new one and write it out. If they match the assumption is
that it hasn't been renewed yet so go into CA_WORKING.
The problem is that for networked HSMs the cert will already be
visible in the database so certmonger will always be in CA_WORKING.
In this case we can assume that if the certs are the same then
that's just fine.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Arguments were added to the configuration file to allow specifying
the token option values. These needed to be included into the
defaults as well.
This should be merged into the tests prior to pushing.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Use SoftHSM2 to install an IPA CA to store the keys in an HSM.
Whenenver new keys are generated either in the initial install
or if a KRA is installed then the token needs to be synced
between all servers prior to installing a new CA or KRA.
Fixes: https://pagure.io/freeipa/issue/9273
Signed-off-by: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This is simple, a port needs to be available to certmonger
to communicate during renewals of CA subsystem certificats.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
A number of files that need to be managed by certmonger
have unconfined_u:object_r:pki_common_t:s0.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This certificate should not be renewed this way.
ipa-cacert-manage renew should be used.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
It would fail eventually with the output in the CA logs but it
wasn't always very obvious and you had to wait a while to find
out about a typo.
Scraping modutil output is a bit ugly but it is guaranteed
to be installed and this should work both with p11-kit and
without.
Related: https://pagure.io/freeipa/issue/9273
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This can be eventually squashed into the main "test" patch but
keeping it separate to make it easier to see what has happened.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Use SoftHSM2 to install an IPA CA to store the keys in an HSM.
Whenenver new keys are generated either in the initial install
or if a KRA is installed then the token needs to be synced
between all servers prior to installing a new CA or KRA.
Fixes: https://pagure.io/freeipa/issue/9273
Signed-off-by: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
