SSH Key auth with expired Kerberos password
by Nathan Harper
Hi all,
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'.
Any suggestions?
1 year, 6 months
Re: Testing requested - certificate checking tool
by William Muriithi
Morning Rob
> > 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
> just-in-case.
>
> 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.:
Failures:
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
77
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
Warnings:
Unknown certmonger ids: 20170812234301
[root@lithium bin]#
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
Regards,
William
1 year, 6 months
Replica install on RPI3
by Winfried de Heiden
Hi all,
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):
File "/usr/lib/python3.7/site-
packages/ipaserver/install/dogtaginstance.py", line 164, in
spawn_instance
ipautil.run(args, nolog=nolog_list)
File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line
573, in run
p.returncode, arg_string, output_log, error_log
ipapython.ipautil.CalledProcessError: 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')
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.
Any sugestion?
Winfried
1 year, 6 months
How to wreck your IPA environment
by Chris Evich
Hey all,
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.
Thoughts?
[*] 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.
1 year, 7 months
FreeIPA on CentOS 7 under LXC, replica installation problems
by Alex Corcoles
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:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
, where apparently two bugs were filed to fix this- and they were fixed.
Are they supposed to land on CentOS 7?
Cheers,
Alex
--
___
{~._.~}
( Y )
()~*~() mail: alex at corcoles dot net
(_)-(_) http://alex.corcoles.net/
1 year, 7 months
Contribute to a HowTO
by Peter Tselios
Hello,
I have a relatively easy HowTo for Integrating Grafana with FreeIPA as an Authentication Back-end.
So, can you please allow my account write access to the Wiki?
1 year, 7 months
FreeIPA - it it the right solution for me?
by 74cmonty
Hi,
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?
THX
1 year, 7 months
Error installation "freeipa-letsencrypt": certutil: could not authenticate to token NSS Certificate DB.: SEC_ERROR_IO: An I/O error occurred during security authorization.
by 74cmonty
Hi,
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/
/etc/ssl/ipa-le/:
insgesamt 0
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
/etc/ssl/ipa-le/ca:
insgesamt 24
-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
THX
1 year, 7 months
No httpd service listening on TCP4
by 74cmonty
Hi,
I just completed installation with Fedora 29 in KVM.
The installation finished w/o errors.
Setup complete
Next steps:
1. You must make sure these network ports are open:
TCP Ports:
* 80, 443: HTTP/HTTPS
* 389, 636: LDAP/LDAPS
* 88, 464: kerberos
* 53: bind
UDP Ports:
* 88, 464: kerberos
* 53: bind
* 123: ntp
Checking the open ports I cannot identify any TCP4 port 80,443.
[root@ipa ~]# netstat -tulpen | egrep "80|443"
tcp6 0 0 127.0.0.1:8005 :::* LISTEN 17 56422 3678/java
tcp6 0 0 127.0.0.1:8009 :::* LISTEN 17 53206 3678/java
tcp6 0 0 :::80 :::* LISTEN 0 60216 4570/httpd
tcp6 0 0 :::8080 :::* LISTEN 17 53200 3678/java
tcp6 0 0 :::443 :::* LISTEN 0 60224 4570/httpd
tcp6 0 0 :::8443 :::* LISTEN 17 53204 3678/java
Ports 80,443 are listening on TCP6 only.
How does this happen?
THX
1 year, 7 months
replication sync issues
by Grant Janssen
I have these errors in the syslog of the primary, the syslog on the secondary is clean.
Oct 30 09:41:59 ef-idm01 ns-slapd: [30/Oct/2018:09:41:59.104092627 -0700] agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" (ef-idm02:389) - Can't locate CSN 5afd9651000200600000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
Oct 30 09:41:59 ef-idm01 ns-slapd: [30/Oct/2018:09:41:59.105088278 -0700] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" (ef-idm02:389): CSN 5afd9651000200600000 not found, we aren't as up to date, or we purged
Oct 30 09:41:59 ef-idm01 ns-slapd: [30/Oct/2018:09:41:59.105750108 -0700] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ef-idm02.production.efilm.com-pki-tomcat" (ef-idm02:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized.
I initiated a resync, but the errors continue to pile up on the primary.
grant@ef-idm02:~[20181030-9:36][#115]$ ipa-replica-manage force-sync --from ef-idm01.production.efilm.com
Directory Manager password: ********
ipa: INFO: Setting agreement cn=meToef-idm02.production.efilm.com,cn=replica,cn=dc\=production\,dc\=efilm\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meToef-idm02.production.efilm.com,cn=replica,cn=dc\=production\,dc\=efilm\,dc\=com,cn=mapping tree,cn=config
grant@ef-idm02:~[20181030-9:37][#116]$
thanx
- grant
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
1 year, 7 months
