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
I consider to deploy FreeIPA in my home network.
In this network I run several servers and workstations with both Linux and Windows.
In addition I have setup some Webservices running in containers (LXC).
I have only one public IP and manage the (privately hosted) Webservices with a reverse proxy.
The network architecture includes several networks, e.g. LAN, DMZ, ...
All networks are secured by relevant iptables roules.
I want a central user management strong security management.
This is included in FreeIPA.
In addition FreeIPA includes some network related features, e.g. DNS.
And here starts my problem.
Currently I manage the DNS of my public domain with the domain provider.
If I install FreeIPA I need to shutdown the DNS management with the domain provider and manage this by myself.
Can I shutdown this DNS service before starting FreeIPA installation w/o impacting DNS resolution to my domain?
What happens if FreeIPA is down? Should there be any redundancy?
I have executed script setup.sh from package "freeipa-letsencrypt".
The installation finished with this error message:
ipaplatform.redhat.tasks: INFO: Systemwide CA database updated.
ipalib.backend: DEBUG: Destroyed connection context.rpcclient_140228802354200
ipapython.admintool: INFO: The ipa-certupdate command was successful
certutil: could not authenticate to token NSS Certificate DB.: SEC_ERROR_IO: An I/O error occurred during security authorization.
certutil: Server-Cert is neither a key-type nor a nickname nor a key-id: SEC_ERROR_IO: An I/O error occurred during security authorization.
What's causing this error?
And how can I fix this?
The file "httpd-csr.der" in working directory (in my case /etc/ssl/ipa-le/) is 0 bytes. Therefore I conclude that the installation was not successful.
[root@ipa freeipa-letsencrypt]# ls -lR /etc/ssl/ipa-le/
drwxr-xr-x. 2 root root 187 3. Nov 19:49 ca
-rw-r-----. 1 root root 0 3. Nov 20:19 httpd-csr.der
-rw-r--r--. 1 root root 1220 3. Nov 19:49 DSTRootCAX3.pem
-rw-r--r--. 1 root root 1967 3. Nov 19:49 isrgrootx1.pem
-rw-r--r--. 1 root root 1702 3. Nov 19:49 LetsEncryptAuthorityX1.pem
-rw-r--r--. 1 root root 1675 3. Nov 19:49 LetsEncryptAuthorityX2.pem
-rw-r--r--. 1 root root 1647 3. Nov 19:49 LetsEncryptAuthorityX3.pem
-rw-r--r--. 1 root root 1647 3. Nov 19:49 LetsEncryptAuthorityX4.pem