Changing default group on automember rules page is too easy.
Add a confirmation dialog to avoid misclick in the case.
Ticket: https://pagure.io/freeipa/issue/8322
Signed-off-by: Serhii Tsymbaliuk <stsymbal@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The ``--setup-dns`` knob and interactive installer now check for
presence of freeipa-server-dns early and stop the installer with an
error.
```
$ ipa-server-install
...
Do you want to configure integrated DNS (BIND)? [no]: yes
Integrated DNS requires 'freeipa-server-dns' package
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
```
```
$ ipa-server-install --setup-dns
Usage: ipa-server-install [options]
ipa-server-install: error: option setup-dns: Integrated DNS requires 'freeipa-server-dns' package
The ipa-server-install command failed.
```
Fixes: https://pagure.io/freeipa/issue/7577
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Service delegation rules and targets deal with Kerberos principals.
As FreeIPA has separate service objects for hosts and Kerberos services,
it is not possible to specify host principal in the service delegation
rule or a target because the code assumes it always operates on Kerberos
service objects.
Simplify the code to add and remove members from delegation rules and
targets. New code looks up a name of the principal in cn=accounts,$BASEDN
as a krbPrincipalName attribute of an object with krbPrincipalAux object
class. This search path is optimized already for Kerberos KDC driver.
To support host principals, the specified principal name is checked to
have only one component (a host name). Service principals have more than
one component, typically service name and a host name, separated by '/'
sign. If the principal name has only one component, the name is
prepended with 'host/' to be able to find a host principal.
The logic described above allows to capture also aliases of both
Kerberos service and host principals. Additional check was added to
allow specifying single-component aliases ending with '$' sign. These
are typically used for Active Directory-related services like databases
or file services.
RN: service delegation rules and targets now allow to specify hosts as
RN: a rule or a target's member principal.
Fixes: https://pagure.io/freeipa/issue/8289
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Fix is to display the proper principal in error message
while attempting to delete required principal.
related: https://pagure.io/freeipa/issue/7695
Signed-off-by: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
when ipa-advise generates a script to configure a client for smart card
auth, the script calls python3 to configure SSSD. The issue happens
if the server (when ipa-advise is run) and the client do not have
the same path for python3 command.
By default, try to use python3 but if the command is not found, fallback
to /usr/libexec/platform-python (which is the python3 path on RHEL8).
Fixes: https://pagure.io/freeipa/issue/8311
Reviewed-By: Christian Heimes <cheimes@redhat.com>
service-del deletes services by DN and LDAP DNs are compared
case-insensitive. Make check_required_principal() compare the
service name case insensitive.
Fixes: https://pagure.io/freeipa/issue/8308
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Refactor code to use api.env.container_sysaccounts instead of
('cn', 'sysaccounts'), ('cn', 'etc')
Related: https://pagure.io/freeipa/issue/8276
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The definition of servrole.takes_params was missing a comma.
Related: https://pagure.io/freeipa/issue/8290
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-backup does not check whether the IPA master it is running on has
all used roles installed. This can lead into situations where backups
are done on a CAless or KRAless host while these roles are used in the
IPA cluster. These backups cannot be used to restore a complete cluster.
With this change, ipa-backup refuses to execute if the roles installed
on the current host do not match the list of roles used in the cluster.
A --disable-role-check knob is provided to restore the previous behavior.
Fixes: https://pagure.io/freeipa/issue/8217
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
RN: host groups can now be renamed with IPA CLI:
RN: 'ipa hostgroup-mod group-name --rename new-name'.
RN: Protected hostgroups ('ipaservers') cannot be renamed.
Fixes: https://pagure.io/freeipa/issue/6783
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~3`.
If the HTTP certificate does not have the ipa-ca.$DOMAIN dNSName,
resubmit the certificate request to add the name. This action is
performed after the tracking request has already been updated.
Note: due to https://pagure.io/certmonger/issue/143, the resubmitted
request, if it does not immediately succeed (fairly likely during
ipa-server-upgrade) and if the notAfter date of the current cert is
still far off (also likely), then Certmonger will wait 7 days before
trying again (unless restarted). There is not much we can do about
that in the middle of ipa-server-upgrade.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~2`.
For new server/replica installation, issue the HTTP server
certificate with the 'ipa-ca.$DOMAIN' SAN dNSName. This is
accomplished by adding the name to the Certmonger tracking request.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~1`.
ACME support requires TLS and we want ACME clients to access the
service via the ipa-ca.$DOMAIN DNS name. So we need to add the
ipa-ca.$DOMAIN dNSName to IPA servers' HTTP certificates. To
facilitiate this, add a special case to the cert-request command
processing. The rule is:
- if the dnsName being validated is "ipa-ca.$DOMAIN"
- and the subject principal is an "HTTP/..." service
- and the subject principal's hostname is an IPA server
Then that name (i.e. "ipa-ca.$DOMAIN") is immediately allowed.
Otherwise continue with the usual dnsName validation.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
BACKGROUND:
We are implementing ACME support in FreeIPA (umbrella ticket:
https://pagure.io/freeipa/issue/4751). ACME is defined in RFC 8555.
HTTPS is REQUIRED (https://tools.ietf.org/html/rfc8555#section-6.1).
Therefore, every FreeIPA server that provides the ACME service
capability must be reachable by HTTPS.
RFC 8555 does not say anything about which port to use for ACME.
The default HTTPS port of 443 is implied. Therefore, the FreeIPA
ACME service will be reached via the Apache httpd server, which will
be the TLS server endpoint.
As a usability affordance for ACME clients, and as a maintainability
consideration i.e. to allow the topology to change without having to
reconfigure ACME clients, there should be a a single DNS name used
to reach the IPA ACME service.
The question then, is which DNS name to use.
REQUIREMENTS:
Each FreeIPA server that is also an ACME server must:
1. Be reachable via a common DNS name
2. Have an HTTP service certificate with that DNS name as a SAN
dNSName value
DESIGN CONSIDERATION - WHAT DNS NAME TO USE?:
Some unrelated FreeIPA ACME design decisions provide important
context for the DNS name decision:
- The ACME service will be automatically and unconditionally
deployed (but not necessarily *enabled*) on all CA servers.
- Enabling or disabling the ACME service will have topology-wide
effect, i.e. the ACME service is either enabled on all CA
servers, or disabled on all CA servers.
In a CA-ful FreeIPA deployment there is already a DNS name that
resolves to all CA servers: ``ipa-ca.$DOMAIN``, e.g.
``ipa-ca.example.com``. It is expected to point to all CA servers
in the deployment, and *only* to CA servers. If internal DNS is
deployed, the DNS records for ``ipa-ca.$DOMAIN`` are created and
updated automatically. If internal DNS is not deployed,
administrators are required to maintain these DNS records
themselves.
The ``ipa-ca.$DOMAIN`` alias is currently used for OCSP and CRL
access. TLS is not required for these applications (and it can
actually be problematic for OCSP). Enabling TLS for this name
presents some risk of confusion for operators. For example, if they
see that TLS is available and alter the certificate profiles to
include an HTTPS OCSP URL in the Authority Information Access (AIA)
extension, OCSP-using clients may fail to validate such
certificates. But it is possible for administrators to make such a
change to the profile, whether or not HTTPS is available.
One big advantage to using the ``ipa-ca.$DOMAIN`` DNS name is that
there are no new DNS records to manage, either in the FreeIPA
implementation or for administrators in external DNS systems.
The alternative approach is to define a new DNS name, e.g.
``ipa-acme.$DOMAIN``, that ACME clients would use. For internal
DNS, this means the FreeIPA implementation must manage the DNS
records. This is straightforward; whenever we add or remove an
``ipa-ca.$DOMAIN`` record, also add/remove the ``ipa-acme.$DOMAIN``
record. But for CA-ful deployments using external DNS, it is
additional work for adminstrators and, unless automated, additional
room for error.
An advantage of using a different DNS name is ``ipa-ca.$DOMAIN`` can
remain inaccessible over HTTPS. This possibly reduces the risk of
administrator confusion or creation of invalid AIA configuration in
certificate profiles.
Weighing up the advantages and disadvantages, I decided to use the
``ipa-ca.$DOMAIN`` DNS name.
DESIGN CONSIDERATION - CA SERVERS, OR ALL SERVERS?:
A separate decision from which name to use is whether to include it
on the HTTP service certificate for ACME servers (i.e. CA servers)
only, or on all IPA servers.
Combined with the assumption that the chosen DNS name points to CA
servers *only*, there does not seem to be any harm in adding it to
the certificates on all IPA servers.
The alternative is to only include the chosen DNS name on the HTTP
service certificates of CA servers. This approach entails some
additional complexity:
- If a non-CA replica gets promoted to CA replica (i.e. via
``ipa-ca-install``), its HTTP certificate must be re-issued with
the relevant name.
- ipa-server-upgrade code must consider whether the server is a CA
replica when validating (and if necessary re-creating) Certmonger
tracking requests
- IPA Health Check must be made aware of this factor when checking
certificates and Certmonger tracking requests.
Weighing up the options, I decided to add the common DNS name to the
HTTP service certificate on all IPA servers. This avoids the
implementation complexity discussed above.
CHANGES IN THIS COMMIT
When (re-)tracking the HTTP certificate, explicitly add the server
FQDN and ipa-ca.$DOMAIN DNS names to the Certmonger tracking request.
Related changes follow in subsequent commits.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The purpose of external groups in FreeIPA is to be able to reference
objects only existing in trusted domains. These members get resolved
through SSSD interfaces but there is nothing that prevents SSSD from
resolving any IPA user or group if they have security identifiers
associated.
Enforce a check that a SID returned by SSSD does not belong to IPA
domain and raise a validation error if this is the case. This would
prevent adding IPA users or groups as external members of an external
group.
RN: Command 'ipa group-add-member' allowed to specify any user or group
RN: for '--external' option. A stricter check is added to verify that
RN: a group or user to be added as an external member does not come
RN: from IPA domain.
Fixes: https://pagure.io/freeipa/issue/8236
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Custom IDViews should not be applied to IPA master nodes. Add a
check enforcing this rule in idview_apply command.
Fixes: https://pagure.io/freeipa/issue/5662
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
This partially restores the pre-ec73de969f state of `http_proxy`,
which fails to restart the apache service during master
installation. The failure happens because of apache is not
configured yet on 'pki-tomcatd' installation phase. The mentioned
code and proposed one relies on the installer which bootstraps the
master.
Fixes: https://pagure.io/freeipa/issue/8233
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When IPA was not installed on the restore target host, and
when httpd was already running, "ipactl stop" does not stop
httpd. "ipactl start" at the end of the restore tool will
therefore not restart httpd either.
Calling "ipactl restart" at the end of the restore fixes the
issue, and as an added bonus, makes sure IPA can restart itself
properly.
Fixes: https://pagure.io/freeipa/issue/8226
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Move all the routines run_ods* from tasks to _ods14 or _ods21 module
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When migrating the DNSSec Master to a replica, the setup of
opendnssec is re-using the database and needs to call zonelist
export.
With opendnssec 1.4 this call is done with ods-ksmutil while
opendnssec 2.1 uses ods-enforcer that communicates with
odsenforcerd that is not started yet.
Move the call after ods-enforcerd is started.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The communication between ods-signer and the socket-activated process
has changed with OpenDNSSEC 2.1. Adapt ipa-ods-exporter to support also
the new protocol.
The internal database was also modified. Add a wrapper calling the
right code (table names hab=ve changed, as well as table columns).
With OpenDNSSEC the policy also needs to be explicitely loaded after
ods-enforcer-db-setup has been run, with
ods-enforcer policy import
The command ods-ksmutil notify must be replace with ods-enforce flush.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
With OpenDNSSEC 1.4, the code was using the command
$ ods-ksmutil zonelist export
which printed the zonelist as XML in its output.
With OpenDNSSEC 2, the code is using the command
$ ods-enforcer zonelist export
which prints a message instead:
"Exported zonelist to /etc/opendnssec/zonelist.xml successfully"
The code needs to extract the zonelist file name and read the XML
from the file.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
In opendnssec 2.1.6, the <Interval> element is not supported in the
configuration file.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
AJP implementation in Tomcat is vulnerable to CVE-2020-1938 if used
without shared secret. Set up a shared secret between localhost
connector and Apache mod_proxy_ajp pass-through.
For existing secured AJP pass-through make sure the option used for
configuration on the tomcat side is up to date. Tomcat 9.0.31.0
deprecated 'requiredSecret' option name in favor of 'secret'. Details
can be found at https://tomcat.apache.org/migration-9.html#Upgrading_9.0.x
Fixes: https://pagure.io/freeipa/issue/8221
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
As we need to store credentials for AJP protocol comminucation,
ensure only root can read the configuration file.
Related: https://pagure.io/freeipa/issue/8221
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When the command ipa-adtrust-install --add-agents is run, it executes
remotely the command trust_enable_agent. This command does not require
the package ipa-server-trust-ad to be installed on the remote node, but
fails if it's not the case because dbus is not imported.
Need to move the "import dbus" outside of the try/except related to
dcerpc import.
Related: https://pagure.io/freeipa/issue/7600
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When ipa-adtrust-install is run, the tool detects masters that are
not enabled as trust agents and propose to configure them. With the
current code, the Schema Compat plugin is not enabled on these new
trust agents and a manual restart of LDAP server + SSSD is required.
With this commit, ipa-adtrust-install now calls remote code on the new
agents through JSON RPC api, in order to configure the missing parts.
On the remote agent, the command is using DBus and oddjob to launch
a new command,
/usr/libexec/ipa/oddjob/org.freeipa.server.trust-enable-agent [--enable-compat]
This command configures the Schema Compat plugin if --enable-compat is
provided, then restarts LDAP server and SSSD.
If the remote agent is an older version and does not support remote
enablement, or if the remote server is not responding, the tool
ipa-adtrust-install prints a WARNING explaining the steps that need
to be manually executed in order to complete the installation, and
exits successfully (keeping the current behavior).
Fixes: https://pagure.io/freeipa/issue/7600
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
server_conncheck is ensuring that the caller has the expected privilege.
Move the code to a common place in ipaserver/plugins/privilege.py
Related: https://pagure.io/freeipa/issue/7600
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
The relative service weight output tries to show the relative
chance that any given master in a locaiton will be picked. This
didn't account for all masters having a weight of 0 which would
result in a divide-by-zero error.
Implement the following rules:
1. If all masters have weight == 0 then all are equally
weighted.
2. If any masters have weight == 0 then they have an
extremely small chance of being chosen, percentage is
0.1.
3. Otherwise it's percentage change is based on the sum of
the weights of non-zero masters.
https://pagure.io/freeipa/issue/8135
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The web page ssbrowser.html is displayed when the browser doesn't
enable javascript. When js is enabled, the content is taken from
ipaserver/plugins/internal.py.
The commit e4966f9 fixed a string in ssbrowser.html but did not
fix the corresponding string in ipaserver/plugins/internal.py,
resulting in a different page depending on javascript enabled/not
enabled.
This commit makes both contents consistent.
Fixes: https://pagure.io/freeipa/issue/8201
Reviewed-By: Kaleemullah Siddiqui <ksiddiqu@redhat.com>
The labels for memberservice_hbacsvc and memberservice_hbacsvcgroup are
only "Services" and "Service Groups" but they should be "HBAC Services"
and "HBAC Service Groups".
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
dnsrecord_del fails when one of the record arguments is an empty list:
AttrValueNotFound("AAAA record does not contain 'None'",)
The problem is caused by the fact that LDAPEntry.__getitem__ returns None
for empty lists. The code in the plugin considers None as a single entry
and maps it to vals = [None].
The patch maps None to empty list.
Fixes: https://pagure.io/freeipa/issue/8196
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
We cannot gather information about required DNS records before "ADTrust
Controller" role is enabled on this server. As result, we need to call
the step to add DNS records after the role was enabled.
Fixes: https://pagure.io/freeipa/issue/8192
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This is the first time running Pylint-2.4 over the whole IPA codebase.
```
Pylint on /usr/bin/python is running, please wait ...
internal error with sending report for module ['ipaserver/plugins/serverroles.py']
maximum recursion depth exceeded while calling a Python object
************* Module ipatests.test_integration.base
ipatests/test_integration/base.py:84: [W0125(using-constant-test), IntegrationTest.install] Using a conditional statement with a constant value)
************* Module ipaserver.install.ipa_cacert_manage
ipaserver/install/ipa_cacert_manage.py:522: [R1724(no-else-continue), CACertManage.delete] Unnecessary "elif" after "continue")
```
The latest Pylint (via the Tox task) checks only:
```
{envsitepackagesdir}/ipaclient \
{envsitepackagesdir}/ipalib \
{envsitepackagesdir}/ipapython
```
, while the distro-Pylint runs over all project but it is not fresh.
That's why these warnings/errors weren't exposed before now.
Concerning `internal error`: a fix was accepted by upstream:
https://github.com/PyCQA/pylint/issues/3245, but wasn't released yet.
Until that is done, Pylint just warns.
Related: https://pagure.io/freeipa/issue/8116
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Previously in order to enable the LDAP profile subsystem
the ca_enable_ldap_profile_subsystem() would check the
current value of the profile subsystem class parameter in
CS.cfg. If the parameter was still set to the default value
(i.e. ProfileSubsystem), the code would change it to
LDAPProfileSubsystem.
There is a effort in PKI to clean up the profile subsystem
classes which may require changing the default value for
this parameter. However, this improvement is blocked since
the ca_enable_ldap_profile_subsystem() is implicitly assuming
that the default value will always be ProfileSubsystem.
This patch modifies the code such that instead of checking
for a specific value that needs to be changed, it will check
whether it has the desired value already. This mechanism
will reduce potential conflicts with future PKI improvements.
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Commit 49cf5ec64b fixed a bug that
prevented migration from externally-signed to self-signed IPA CA.
But it introduced a subtle new issue: certmonger-initiated renewal
renews an externally-signed IPA CA as a self-signed CA.
To resolve this issue, introduce the `--force-self-signed' flag for
the dogtag-ipa-ca-renew-agent script. Add another certmonger CA
definition that calls this script with the `--force-self-signed'
flag. Update dogtag-ipa-ca-renew-agent to only issue a self-signed
CA certificate if the existing certificate is self-signed or if
`--force-self-signed' was given. Update `ipa-cacert-manage renew'
to supply `--force-self-signed' when appropriate.
As a result of these changes, certmonger-initiated renewal of an
externally-signed IPA CA certificate will not issue a self-signed
certificate.
Fixes: https://pagure.io/freeipa/issue/8176
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Before removing a CA re-verify all the other CAs to ensure that
the chain is not broken. Provide a force option to handle cases
where the CA is expired or verification fails for some other
reason, or you really just want them gone.
https://pagure.io/freeipa/issue/8124
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
When ipa commands are used by an Active Directory user that
does not have any idoverride-user set, they return the
following error message which can be misleading:
$ kinit aduser@ADDOMAIN.COM
$ ipa ping
ipa: ERROR: cannot connect to 'https://master.ipa.com/ipa/json': Internal Server Error
The fix properly handles ACIError exception received when
creating the context, and now the following message can be seen:
$ kinit aduser@ADDOMAIN.COM
$ ipa ping
ipa: ERROR: cannot connect to 'https://master.ipa.com/ipa/json': Unauthorized
with the following log in /var/log/httpd/error_log:
ipa: INFO: 401 Unauthorized: Insufficient access: Invalid credentials
Fixes: https://pagure.io/freeipa/issue/8163
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Displaying "Dynamic Update" and "Bind update policy" by default
when 'ipa dnszone-show/find' are used would make client dns update
failures easier to diagnose, so display them.
Fixes: https://pagure.io/freeipa/issue/7938
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When 'ipa krbtpolicy-reset' is called, we need to reset all policy
settings, including per-indicator ones. Per-indicator policy uses
subtyped attributes (foo;bar), the current krbtpolicy-reset code does
not deal with those.
Add support for per-indicator policy reset. It is a bit tricky, as we
need to drop the values to defaults but avoid adding non-per-indicator
variants of the same attributes.
Add test to check that policy has been resetted by observing a new
Kerberos TGT for the user after its policy reset.
Fixes: https://pagure.io/freeipa/issue/8153
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The change to allow overlapping zone to be from the master itself has
introduced two issues: The check for the master itself should only executed
if options.force and options.allow_zone_overlap are both false and the
reverse zone check later on was still handling ValueError instead of
dnsutil.DNSZoneAlreadyExists.
Both issues have been fixed and the deployment with existing name servers
is properly working again.
Fixes: https://pagure.io/freeipa/issue/8150
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
When re-running `ipa-server-install --setup-dns` on already installed
server, we do not get to the check of being already installed because
DNS zone overlap forces us to fail earlier.
Change exception returned for this case from check_zone_overlap() to
return structured information that allows to understand whether we are
finding a conflict with ourselves.
Use the returned information to only fail DNS check at this point if DNS
zone overlap is generated by a different name server than ourselves.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
