September 2021 - FreeIPA-users - Fedora mailing-lists

New IPA server and unable to sudo from client
by Jeremy Tourville 20 Sep '21

20 Sep '21

After all the trouble with fixing a botched upgrade I decided it was easier to build a new IPA Server. Now that I have it up and running I am running into an issue with my ipa enrolled clients. I am unable to sudo. The client says: <user>@<host> is not allowed to run sudo on <host>. This incident will be reported. The HBAC test in the GUI tells me "ACCESS GRANTED" so my policy is setup correctly. I looked at /etc/nsswitch on the client and see a line: sudoers: files sss Shouldn't sss be listed first? Stopping, clearing sssd cache and restarting again doesn't fix it, I presume because the order is wrong. This is happening on two of my ipa clients so far and I hate to go any further until I figure put what the issue is. Is there something on the server side that controls the nsswitch config or do I need to change the config on the client?

2 3

sudo rules for local accounts
by iulian roman 20 Sep '21

20 Sep '21

Hello everybody, Does anybody know if it is possible to have sudo rules in FreeIPA for local accounts (accounts which are in /etc/passwd) ?

2 1

Signature verification
by Patrick Northon 18 Sep '21

18 Sep '21

Hi, I'm having a problem verifying the signature of the latest release (4.9.7), did something change with how it is signed? Previous releases work fine: gpg: Signature made mar 29 jun 2021 11:32:36 EDT gpg: using RSA key 840A1D1C7F3EC4B2FE5304354719E2B8ABBF621A gpg: Good signature from "FreeIPA Master Signing Key" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0E63 D716 D76A C080 A4A3 3513 F408 00B6 298E B963 Subkey fingerprint: 840A 1D1C 7F3E C4B2 FE53 0435 4719 E2B8 ABBF 621A Current release: gpg: Signature made jeu 19 aoû 2021 11:23:09 EDT gpg: using RSA key FAF42668FC4263CD83C365149F853DF24BC2DFE1 gpg: Can't check signature: No public key Was it signed with a different key?

2 1

IPA slapd parameter tuning
by Kathy Zhu 17 Sep '21

17 Sep '21

Hi List, One of my ipa server's database had issue and left many log entries like the following in messages and slapd errors log: *Sep 16 08*:34:28 ipa0 ns-slapd: [16/Sep/2021:08:34:28.886632992 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery *Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:28.987593487 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery *Sep 16 08*:34:29 ipa0 ns-slapd: [16/Sep/2021:08:34:29.035181321 -0700] - ERR - libdb - BDB0060 PANIC: fatal region error detected; run recovery Restart ipa fixed the issue. I googled for root cause and found the verified solution - https://access.redhat.com/solutions/3098131, which is to increase nsslapd-dncachememsize to a reasonable value (>150MB). This sounds like easy, however, all slapd cache parameters are related. Red Hat Directory Server performance tuning guide explain a bit: https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h… However, I wonder if there is a better guide. Thanks. Kathy.

3 5

CA errors after update, server.xml desync?
by D Trom 16 Sep '21

16 Sep '21

If the subject isn't vague enough, perhaps I can explain in some better detail. I have IPA setup with a couple of replicas and it's been running fine for a few months; perriodic runs of ipa-healthcheck didn't show any issues. During an update of the system packages, something went wrong and the CA is now unavailable from the webui and ipa tools. When accessing from the webui (Authentication->Certificates) I get th following error: "Certificate operation cannot be completed: Unable to communicate with CMS (403)" From some cli tools (ipa cert-show) I get this error: "ipa: ERROR: Certificate operation cannot be completed: Request failed with status 403: Non-2xx response from CA REST API: 403. (403)" It appears that dogtag is working, as I can use it's toolset to query "pki ca-cert-show 0x1 --pretty" for example returns the certificate as expected so I suspect the issue lies somewhere in the API. I compared the cert which I believe to be used for pki with the following: "grep internal /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt" "certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'" So from what I've read it seems pki-tomcat should be able to access it's private key and certificate. I also compared the cert with the one in LDAP and the two are the same. "ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate" In digging through some old backups, I found that entries in /etc/pki/pki-tomcat/server.xml had changed, so I reset the "requiredSecret" back to an earlier value, which seemed to allow the webui to work again, at least partially as I can now get a listing from the CA in the webui though I cannot see details of any particular certificate. Assuming I'm on the right path, is there a documented process to regenerate the server.xml file or am I chasing the wrong problem?

4 4

Disabling ssh hostkey generation/caching
by Dominik Vogt 16 Sep '21

16 Sep '21

I have a problem with ssh host keys being automatically generated(?). Our installation process looks like this: 1) Install IdM server and clients. 2) Generate ssh host keys for all machines in a special way because of a requirement about available entropy that is not 3) Distribute the new keys to all machines but do not install them. (Any required known_hosts files are also generated and distributed). and known_hosts files 4) Reboot all machines at the same time. 5) During reboot, a script installs the new keys and deletes the old ones (rsa and ecdsa format). However, host key files in rsa and ecdsa format keep reappearing. I'm not exactly sure when this happens. Does it have something to do with sssd? -- So, we need to disable * automatic generation of ssh keys, * restoring them from backups (in case some component does that). Caching the keys in sssd would be in order if we can make sure that sssd does not cache the old keys at any time. Running "sss_cache -H" does not seem to affect the cached known_hosts file in /var/lib though. I understand that IdM can manage host keys, but we don't want to use that feature because of the underlying system requirements, and we'll never add new machines anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 3

ipa-cert-fix failing
by Marc Boorshtein 16 Sep '21

16 Sep '21

I'm trying to fix a freeipa 4.6 cluster running on centos 7 that has expired directory and http certificates. I turned back the clock so that the certs would be valid and am trying to run ipa-cert-fix but its failing with: INFO: Loading password config: /etc/pki/pki-tomcat/password.conf INFO: Fixing the following system certs: ['sslserver'] INFO: Renewing the following additional certs: ['21'] SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Stopping the instance to proceed with system cert renewal INFO: Configuring LDAP password authentication INFO: Setting pkidbuser password via ldappasswd SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Selftests disabled for subsystems: ca INFO: Resetting password for uid=ipara,ou=people,o=ipaca SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 INFO: Creating a temporary sslserver cert INFO: Getting sslserver cert info for ca INFO: Trying to create a new temp cert for sslserver. INFO: Generate temp SSL certificate INFO: Getting sslserver cert info for ca INFO: Selftests enabled for subsystems: ca INFO: Restoring previous LDAP configuration ERROR: Unable to find CSR for sslserver cert AFter doing some searching I found https://access.redhat.com/solutions/4852721 but the instructions aren't applying to me because there's no CSR in the request: Request ID '20210601131820': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=RHELENT.LAN subject: CN=CA Subsystem,O=RHELENT.LAN expires: 2023-05-01 18:04:11 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes then look for a csr: [root@freeipa ~]# grep -A 19 csr /var/lib/certmonger/requests/20210601131820 [root@freeipa ~]# Is there something i can do to get the ca subsystem cert re-issued? Thanks Marc Boorshtein

3 7

Re: [BUG?] Host Alias DNS
by Florence Renaud 16 Sep '21

16 Sep '21

Hi, re-adding the mailing list On Wed, Sep 15, 2021 at 6:31 PM Buckley Ross <buckleyross42(a)gmail.com> wrote: > Hi Flo, > > I think you misread my question. > Indeed. I interpreted "I found that on DNS records were provisioned..." as "I found that on <the> DNS <server>, records were provisioned" instead of "I found that *no* DNS records were provisioned". Sorry about that... I am not running `ipa host-add`. I am running `ipa host-add-principal`. I > would expect that if I am adding a new principal to a host, that > principal's DNS name would be added with either a CNAME or an A record, > pointing back to the original host. Is there a reason that this does not > happen? I cannot understand the utility of being able to add a new > principal to a host if that principal is not routable via DNS. > In your case you expect myhost and myalias to resolve to the same IP address, but that's not the general use case. Consider for instance a host with 2 different IP addresses, myhost resolving to the 1st one and myalias to the 2nd one. Adding the principal alias is de-coupled from the DNS records. Hope this clarifies, flo > Thanks, > Buckley Ross > > On Tue, Sep 14, 2021 at 7:17 AM Florence Renaud <flo(a)redhat.com> wrote: > >> Hi, >> I was not able to reproduce this issue: >> >> # ipa host-add myhost.ipa.test --ip-address $IP >> # ipa dnsrecord-find ipa.test >> >> shows myhost.ipa.test has been added >> >> # ipa host-add-principal myhost host/myalias.ipa.test >> # ipa dnsrecord-find ipa.test >> >> no new record added >> >> DNS records are added when the command "ipa host-add --ip-address" is >> used, when a host is joined with ipa-client-install, or when "ipa >> dnsrecord-add" is called. You can check in /var/log/httpd/error_log if you >> find trace of such a command. >> >> flo >> >> On Mon, Sep 13, 2021 at 1:46 PM Buckley Ross via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: >> >>> Hello, >>> >>> I'm trying to provision an HTTP service principal for a containerized >>> service. The host on which the container is running also has a kerberized >>> HTTP service running on it with a separate service principal (both services >>> are highly critical, but for different systems, and thus should probably >>> have separate keytabs). >>> >>> Since both services share an IP address (but are serving HTTP on >>> different ports), this seemed like a perfect application of kerberos host >>> aliases. However, when I provisioned a host alias with `ipa >>> host-add-principal myHost host/myAlias.domain.com`, I found that on DNS >>> records were provisioned for `myAlias.domain.com`, thus making the >>> alias completely useless for resolving to the container. Is this a bug in >>> the host-alias system, or am I missing something? >>> >>> Thank you for your time. >>> >>> Thank you, >>> Buckley Ross >>> _______________________________________________ >>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> To unsubscribe send an email to >>> freeipa-users-leave(a)lists.fedorahosted.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… >>> Do not reply to spam on the list, report it: >>> https://pagure.io/fedora-infrastructure >>> >>

1 0

ipa_check_consistency alerts and ERR - slapd_poll - Timed out
by Kathy Zhu 15 Sep '21

15 Sep '21

Hi List, I use ipa_check_consistency <https://github.com/peterpakos/checkipaconsistency/tree/v1.3.0> as one of my Nagios monitors. It runs every 5 minutes on each ipa server. For example: [root@ipa0 ~]# /usr/local/sbin/ipa_check_consistency -d example.com -H ipa0 Directory Manager password: FreeIPA servers: ipa0 STATE ================================= Active Users 1422 OK Stage Users 0 OK Preserved Users 10 OK User Groups 75 OK Hosts 848 CRITICAL Host Groups 39 OK HBAC Rules 593 OK SUDO Rules 8 OK DNS Zones 16 OK Certificates 244 OK LDAP Conflicts NO OK Ghost Replicas NO OK Anonymous BIND YES OK Replication Status ipa2 0 OK ipa1 0 ipa3 0 ipa5 0 ================================= [root@ipa0 ~]# All ipa servers report OK for all components but there is one ipa server which alerts CRITICAL everyday multiple times. The inconsistency alers are in different components, for example, "Hosts", "Active Users", and so on, however, it never alerts for "Replication Status" and "LDAP Conflicts". This is also the only ipa server within the domain which I see "Timed out" like the following in its /var/log/dirsrv/slapd-EXAMPLE-COM/errors log: [14/Sep/2021:06:55:40.694662470 -0700] - ERR - slapd_poll - (429) - Timed out [14/Sep/2021:16:08:45.441598637 -0700] - ERR - slapd_poll - (1211) - Timed out [14/Sep/2021:16:08:55.452150573 -0700] - ERR - slapd_poll - (1211) - Timed out [14/Sep/2021:16:09:05.460069764 -0700] - ERR - slapd_poll - (1211) - Timed out However, the timestamps of the above may not match when ipa_check_consistency alerts. This ipa server's OS is Centos 7-8.2003.0 and IPA version is 4.6.8, API: 2.237. [root@ipa0 ~]# rpm -qa 389\* 389-ds-base-snmp-1.3.10.1-14.el7_8.x86_64 389-ds-base-libs-1.3.10.1-14.el7_8.x86_64 389-ds-base-1.3.10.1-14.el7_8.x86_64 [root@ipa0 ~]# rpm -qa slapi\* slapi-nis-0.56.0-13.el7.x86_64 [root@ipa0 ~]# This may not be the same issue or connected. However, I feel that something in its configuration is not correct with this ipa server but do not know what. Since I have other ipa servers which have the same OS, ipa version and so on but do not exhibit this behavior. Does anyone have any ideas for troubleshooting? Thanks! Kathy.

1 0

[BUG?] Host Alias DNS
by Buckley Ross 14 Sep '21

14 Sep '21

Hello, I'm trying to provision an HTTP service principal for a containerized service. The host on which the container is running also has a kerberized HTTP service running on it with a separate service principal (both services are highly critical, but for different systems, and thus should probably have separate keytabs). Since both services share an IP address (but are serving HTTP on different ports), this seemed like a perfect application of kerberos host aliases. However, when I provisioned a host alias with `ipa host-add-principal myHost host/myAlias.domain.com`, I found that on DNS records were provisioned for `myAlias.domain.com`, thus making the alias completely useless for resolving to the container. Is this a bug in the host-alias system, or am I missing something? Thank you for your time. Thank you, Buckley Ross

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2021