I have to clean up lot of useless certificate in dirsrv database.
Because of resubmit loop on Certmonger client, i have 99,9% of certificate in dirsrv database that are useless and not obsolete (expiration in 2020) (it represent ~85 000 certificates).
These useless certificates produce some issues on FreeIPA:
- decrease FreeIPA performances on CLI and GUI
- increase the LDAP size
- increase size and time of FreeIPA backup
Is it possible to purge these certificates in dirsrv database and how?
I found two branches in LDAP directory about these certificates:
I can remove all requests and certificates entry from dirsrv database but how it is supported by PKI manager Dogtag (CRL, certificate generation, OCSP)?
(This topic has already been discuss on https://email@example.com...)
Thank you for you help
IT Operations service
Tel : +33 (0)5 32 09 09 74 | Poste : 574
So I solved my LXC problems (thanks Rob, again), but now:
ipa-replica-install -U --setup-ca -N
fails when rebuilding my replica from scratch, see:
, where I think I've copied the relevant logs. I think I saw someone
recommending revoking the replica certs, which makes sense as I'm using the
same hostname that I used on the previous replica, but that doesn't seem to
(I'm removing the previous replica via the admin interface, IPA Server ->
Topology -> IPA Servers, select my replica and "Delete Server". This
removes it too from the host list).
( Y )
()~*~() mail: alex at corcoles dot net
I followed these instructions to enable kerberos within my realm/domain.
My FreeIPA, NFS server and my NFS client is CentOS 7.4
I’m completely stuck in that when I mount the NFS share I get
Sudo mount -o sec=krb5p share.example.com:/data/shared /mnt/shared
“mount.nfs: access denied by server while mounting share.example.com:/data/shared”
My /etc/exports file
/data/shared 172.16.0.0/24(sec=krb5p, rw, ...)
On my nfs server /var/log/messages all i see is
rpc.mountd: authenticated mount request from 172.16.0.23:819 for /data/shared (/data/shared)
If i remove the “sec=krb5p” from the mount and the exports file it mounts just fine.
I'm having an issue with OTP when logging into a vpn server that is a client of FreeIPA. I can login with no issues when OTP is disabled.
HBAC Service: openvpn
[root@ipa ~]# ipa hbacrule-show openvpn_access
Rule name: openvpn_access
Description: VPN users HBAC rule for accessing ,vpnhost> via openvpn service.
[root@ipa ~]# ipa user-show <omitted>
User login: <omitted>
First name: <omitted>
Last name: <omitted>
Home directory: /home/<omitted>
Login shell: /bin/bash
Principal name: <omitted>
Principal alias: <omitted>
Email address: <omitted>
User authentication types: otp
Account disabled: False
Member of groups: vpn_users
Member of HBAC rule: openvpn_access
Indirect Member of HBAC rule: user_ipa_access
Kerberos keys available: True
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
Any help would be greatly appreciated. Any other information that you may need, please feel free to ask. I've read multiple threads, some have gotten it to work without posting answers, some have not and has stated openvpn does not support multiple prompts.
We have noticed some behaviour that we are trying to work out if it is
expected or not (or if this is an SSSD thing). We have a pair of FreeIPA
replicas running on CentOS 7 (v4.5.x), with various CentOS 7 clients.
Most clients aren't actually enrolled in FreeIPA, but are configured with:
id_provider = ldap
auth_provider = krb5
Authentication works as expected, plus password changes etc. However, if
a user has added a public key to authorized_keys, the status of the
password is not considered and at no point is a user prompted to change
their password. More importantly, if a user is disabled in FreeIPA, they
are still permitted to login using their SSH key.
I have checked the behaviour on a client that is enrolled, and it is better
(disabling a user does prevent access), but it still does not give any
indication about failed passwords.
Under most circumstances this wouldn't be too much of an issue, but we make
use of one application for remote access that does not know what to do with
an expired password, and instead just presents 'authentication failed'.
> > What's the process for either removing or making it known?
> I'll add something to the program about this too but for now you can run:
> # getcert list -i 20170919231606
> That will tell us what it is. It is perfectly fine to have certmonger
> track other certs on the system. I display unexpected once as a
> It's supposed to display as just a warning. I'll fix that too since it
> is a little alarming.
This is the result I got on my end.:
Unable to find request for serial 268304424
Unable to find request for serial 268304426
Unable to find request for serial 268304425
Unable to find request for serial 268304423
Subject O=ENG.EXAMPLE.COM,CN=zinc.eng.example.com and template subject
CN=lithium.eng.example.com,O=ENG.EXAMPLE.COM do not match for serial
Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/key3.db are 0600 and
should be 0640
Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/cert8.db are 0600 and
should be 0640
Permissions of /etc/dirsrv/slapd-ENG-EXAMPLE-COM/secmod.db are 0600
and should be 0640
Unknown certmonger ids: 20170812234301
The system so far seem healthy. Did these file permission had a
stricter access that was relaxed later? I have never attempted to
change them, at least impicitly
Just because we can and a Rapsberry Pi 3 is cheap, I'm trying to
install a FreeIPA replica on Fedora 29 ARM. It looks like the Raspberry
is a bit too slow for default installation settings:
018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was garbage
collected before it was cleared.
password file contains no data
pkispawn : ERROR ........... server did not start after 60s
pkispawn : ERROR ....... server failed to restart
2018-11-03T12:27:12Z CRITICAL Failed to configure CA instance:
CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f',
'/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password
was garbage collected before it was cleared.\npassword file contains no
data\npkispawn : ERROR ........... server did not start after
60s\npkispawn : ERROR ....... server failed to restart\n')
2018-11-03T12:27:12Z CRITICAL See the installation logs and the
following files/directories for more information:
2018-11-03T12:27:12Z CRITICAL /var/log/pki/pki-tomcat
2018-11-03T12:27:12Z DEBUG Traceback (most recent call last):
packages/ipaserver/install/dogtaginstance.py", line 164, in
File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line
573, in run
p.returncode, arg_string, output_log, error_log
['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned
non-zero exit status 1: 'WARNING: Password was garbage collected before
it was cleared.\npassword file contains no data\npkispawn :
ERROR ........... server did not start after 60s\npkispawn :
ERROR ....... server failed to restart\n')
I did change the "startup_timeout" in /usr/lib/python3.7/site-
packages/ipalib/constants.py and /etc/ipa/default.conf but it doens't
seem to be enough.
About a year ago I did a really, really stupid thing. I updated IPA on one CentOS 7 host, then before being really sure things were working, I did the replica. Turned out the first upgrade only 'mostly' worked[*], meaning both hosts are now partially wrecked :S
The good news is, DNS and PKI seems mostly in-tact and functional (why I haven't done anything for a year). The bad news is, the web interface and API-access (ipa cmdline) is non-functional. Meaning I have no way to maintain the setup, add new replicas/hosts, etc. :(
Both kerberos and ldapsearch are working, so I'm wondering if there's a way I can "save" my DNS and user/group/kerberos records, to make a re-build/re-install less painful? I don't have anything worth saving PKI-wise.
[*] The damage was caused by running out of disk-space after the package install, while the upgrade or schema-update script was running. I'm not above trying to repair the API, but so far my attempts have all been fruitless. I tried 'yum reinstall' and manually running the upgrade scripts. The damage seems to be inside the databases, since restoring from backup also restores API-breakage.
So I had a running replica on CentOS 7 LXC which started giving me trouble,
so I decided to rebuild it.
Now, when running ipa-replica install I get:
2018-11-04T20:12:20Z DEBUG stderr=pkispawn : ERROR .......
subprocess.CalledProcessError: Command '['sysctl', 'crypto.fips_enabled',
'-bn']' returned non-zero exit status 255!
2018-11-04T20:12:20Z CRITICAL Failed to configure CA instance: Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpyZ34z1' returned non-zero exit status 1
, which seems to cause this to fail. Googling around, I find this thread:
, where apparently two bugs were filed to fix this- and they were fixed.
Are they supposed to land on CentOS 7?
( Y )
()~*~() mail: alex at corcoles dot net