OCSP responses for an external CA
by Andrew C Dingman
Hi, all
I'm not sure the following is feasible, but IHAC who may want to use
IPA in an air-gapped network while relying on smart card authentication
using certificates from a very large, external CA. Can anyone give me
an idea of whether the following scenario is feasible, and if so,
supportable?
External certificate authority E issues user certificates and
provisions smart card tokens. (It runs RHCS, if that matters.) Inside
the isolated network, users are separately maintained in IPA domain P.
When each user is created in P, a certificate issued by E is added to
the user's entry. That certificate is used for pkinit and ssl/tls
client authentication to services in P.
So far, my understanding is that this should be feasible provided that
E is added as a trusted authority in various places, but I'm a little
fuzzy on the pkinit piece. Where it gets really problematic is dealing
with CRLs.
Because P and its relying parties are isolated, they can't use OCSP to
check current validity of a certificate. To avoid the hassles of
distributing CRLs to all relying systems and services manually, would
it be possible to add those CRLs to the set served by the OCSP
responder in P? Obviously the responses would be signed by P rather
than E, but if P has verified the CRL on which they were based it seems
at least potentially viable.
As currently envisioned, E would be completely unaware of the existence
of P, but P would trust certificates issued by E. If that isn't
feasible, would it make any difference if P's CA were subordinate to E?
Thanks in advance for any guidance you can offer.
-Andrew
2 years, 4 months
OCSP responses for an external CA
by Andrew C Dingman
Hi, all
I'm not sure the following is feasible, but IHAC who may want to use
IPA in an air-gapped network while relying on smart card authentication
using certificates from a very large, external CA. Can anyone give me
an idea of whether the following scenario is feasible, and if so,
supportable?
External certificate authority E issues user certificates and
provisions smart card tokens. (It runs RHCS, if that matters.) Inside
the isolated network, users are separately maintained in IPA domain P.
When each user is created in P, a certificate issued by E is added to
the user's entry. That certificate is used for pkinit and ssl/tls
client authentication to services in P.
So far, my understanding is that this should be feasible provided that
E is added as a trusted authority in various places, but I'm a little
fuzzy on the pkinit piece. Where it gets really problematic is dealing
with CRLs.
Because P and its relying parties are isolated, they can't use OCSP to
check current validity of a certificate. To avoid the hassles of
distributing CRLs to all relying systems and services manually, would
it be possible to add those CRLs to the set served by the OCSP
responder in P? Obviously the responses would be signed by P rather
than E, but if P has verified the CRL on which they were based it seems
at least potentially viable.
As currently envisioned, E would be completely unaware of the existence
of P, but P would trust certificates issued by E. If that isn't
feasible, would it make any difference if P's CA were subordinate to E?
Thanks in advance for any guidance you can offer.
-Andrew
2 years, 4 months
replica unable to communicate
by Andrew Meyer
I need some help with this. I am working with FreeIPA runnning on CentOS 7.4 verssion 4.5.0-22. I have 2 servers in my AWS VPC and 2 servers at my local office.
For some reason I am not seeing replication happen (over ldaps?) from 1 server in my local office to the two servers up there.
AWS servers:
[centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[centos@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[centos@freeipa03 ~]$
[root@freeipa04 log]# ipa-replica-manage list -v freeipa03.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00freeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[root@freeipa04 log]# ipa-replica-manage list -v freeipa01.stl1.gatewayblend.netfreeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:25:31+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:30:31+00:00[root@freeipa04 log]#
Local office:server 1
[gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:41+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:24:32+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 13:30:53+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa01 ~]$
[gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa04.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:08:00+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:07:54+00:00freeipa03.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$ sudo vim /etc/resolv.conf[gatewayblend@freeipa03 ~]$ sudo ipa-replica-manage list -v freeipa03.east.gatewayblend.netfreeipa01.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa03.stl1.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2018-03-21 02:40:35+00:00freeipa04.east.gatewayblend.net: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) last update ended: 1970-01-01 00:00:00+00:00[gatewayblend@freeipa03 ~]$
The topologysegment shows we have 2-way connectivity all the way around:[root@freeipa04 log]# ipa topologysegment-find --allSuffix name: domain------------------6 segments matched------------------ dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa03.stl1.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa03.stl1.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top
dn: cn=freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa01.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa01.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa01.stl1.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa01.stl1.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.east.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.east.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both iparepltoposegmentstatus: autogen objectclass: iparepltoposegment, top
dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa03.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa03.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top
dn: cn=freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net,cn=domain,cn=topology,cn=ipa,cn=etc,dc=gatewayblend,dc=net Segment name: freeipa03.stl1.gatewayblend.net-to-freeipa04.east.gatewayblend.net Left node: freeipa03.stl1.gatewayblend.net Right node: freeipa04.east.gatewayblend.net Connectivity: both objectclass: iparepltoposegment, top----------------------------Number of entries returned 6----------------------------[root@freeipa04 log]#
When I add a user everything gets sync'ed. When I add a DNS entry its gets sync'ed all the way around.
Is the error i'm getting a false positive? It seems like it is.
This is the error I'm getting in /var/log/messages. However I think this pertains to DNSSEC and can be ignored, correct?
Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:35:25 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:35:25 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:36:25 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:36:25 freeipa01 systemd: Started IPA key daemon.Mar 21 13:36:25 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:36:28 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:36:29 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:36:32 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:36:32 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:36:33 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:36:33 freeipa01 systemd: ipa-dnskeysyncd.service failed.Mar 21 13:37:33 freeipa01 systemd: ipa-dnskeysyncd.service holdoff time over, scheduling restart.Mar 21 13:37:33 freeipa01 systemd: Started IPA key daemon.Mar 21 13:37:33 freeipa01 systemd: Starting IPA key daemon...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind...Mar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync processMar 21 13:37:36 freeipa01 ipa-dnskeysyncd: ipa.ipaserver.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BINDMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: Traceback (most recent call last):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_pollMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.syncrepl_refreshdone()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 115, in syncrepl_refreshdoneMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: self.hsm_replica_sync()Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipaserver/dnssec/keysyncer.py", line 181, in hsm_replica_syncMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in runMar 21 13:37:40 freeipa01 ipa-dnskeysyncd: raise CalledProcessError(p.returncode, arg_string, str(output))Mar 21 13:37:40 freeipa01 ipa-dnskeysyncd: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILUREMar 21 13:37:40 freeipa01 systemd: Unit ipa-dnskeysyncd.service entered failed state.Mar 21 13:37:40 freeipa01 systemd: ipa-dnskeysyncd.service failed.[gatewayblend@freeipa01 ~]$
I'm not sure what the issue is.
Any help is appreciated.
Thank you,Andrew Meyer
2 years, 4 months
Force TLS connection
by Peter Tselios
Hello,
My understanding is that FreeIPA is configured to accept connections on port 389 and the StartTLS is configured.
I managed to connect to the IPA server by using ldapsearch -x and without -ZZ so, I suppose the TLS is not enforced.
Is there any option force TLS connections only? Obviously, I would prefer something that can be replicated and not to manually edit the configuration files, but I can live with that :)
2 years, 4 months
LDAP Group Membership puzzle
by Peter Tselios
Hello,
I have an non-IPA aware application to succssfuly login users from IPA's LDAP.
However, I cannot make it work with group membership. It seems that the LDAP filter is not working and using LDAP search proves that the app is not wrong.
So, what I have:
myself (ptselios) member of the group grafana-adms.
The group is stored as:
ldapsearch -x -W -D "uid=nonipaapps,cn=sysaccounts,cn=etc,dc=example,dc=com" -b "cn=groups,cn=accounts,dc=example,dc=com" "(&(objectClass=groupOfNames)(cn=grafana-adms))" -h localhost -p 389 -s sub
dn: cn=grafana-adms,cn=groups,cn=accounts,dc=example,dc=com
member: uid=ptselios,cn=users,cn=accounts,dc=example,dc=com
member: uid=anotheruser,cn=users,cn=accounts,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-120251393-583861438-3385547448-1050
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
cn: grafana-adms
description:: blabla
ipaUniqueID: ccc54368-ce1d-11e8-b523-06db1b82a33a
gidNumber: 690200050
Now, when I search with the memberuid I get an empty response:
ldapsearch -x -W -D "uid=nonipaapps,cn=sysaccounts,cn=etc,dc=example,dc=com" -b "cn=groups,cn=accounts,dc=example,dc=com" "(&(objectClass=groupOfNames)(memberuid=ptselios))" -h localhost -p 389 -s sub
# search result
search: 2
result: 0 Success
# numResponses: 1
Obviously, the filter is wrong, but what is the correct one?
2 years, 4 months
Export service keytab as Active Directory user
by Michael Gusek
Hi,
we are running FreeIPA 4.5.4 on Centos 7 with a one way trust to an
Active Directory. We want to allow AD users to retrieve service keytab
on FreeIPA managed hosts. AD users are linked to a external group, and
these group to a FreeIPA group. We've created a service and allowed
FreeIPA group (for testing external group too) to retrieve keytab. Now
we logged in with AD credentials to a FreeIPA managed host, got an
ticket with kinit user@AD-domain and tried to retrieve keytab for
service, which runs in an error "Failed to parse result: Insufficient
access rights". With an FreeIPA user, added to FreeIPA group above, it
works.
So what we are missing here ? Is it possible to retrieve service keytabs
as a trusted AD user ?
Thanks.
2 years, 4 months
tomcatd - Could not connect to LDAP server host
by Jack Henschel
Hello,
we ran into an issue after an upgrade to FreeIPA 4.6.4, API_VERSION:
2.229 (using the current Docker Image Fedora 27)
The ipa-upgrade ran without issues, but pki-tomcatd is causing trouble
after the upgrade.
The tomcatd system log:
0.localhost-startStop-1 - [05/Nov/2018:08:44:41 UTC] [8] [3] In Ldap
(bound) connection pool to host ipa port 636, Cannot connect to LDAP
server. Error: netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Tomcat Debug log:
java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
Could not connect to LDAP server host ipa port 636 Error
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
Internal Database Error encountered: Could not connect to LDAP
server host ipa port 636 Error netscape.ldap.LDAPException: Unable to
create socket: java.net.ConnectException: Connection refused (Connection
refused) (-1)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:689)
However, the dirsrv starts just seconds afterwards:
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.159306972
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 08:44:45 ipa ns-slapd[90]: [05/Nov/2018:08:44:45.162543716
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 08:44:45 ipa systemd[1]: Started 389 Directory Server
Then, certmonger fails to start (probably trying to reach tomcatd, I
assume):
Nov 05 08:45:41 ipa systemd[1]: certmonger.service: Start-post
operation timed out. Stopping.
Nov 05 08:45:50 ipa server[231]: WARNING: Exception processing
realm com.netscape.cms.tomcat.ProxyRealm@3b86a3a1 background process
Nov 05 08:45:50 ipa server[231]:
javax.ws.rs.ServiceUnavailableException: Subsystem unavailable
Nov 05 08:45:50 ipa server[231]: at
com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:130)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1156)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5740)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1379)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:
1383)
Nov 05 08:45:50 ipa server[231]: at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1351)
Nov 05 08:45:50 ipa server[231]: at
java.lang.Thread.run(Thread.java:748)
Nov 05 08:45:56 ipa systemd[1]: Failed to start Certificate
monitoring and PKI enrollment.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Unit entered
failed state.
Nov 05 08:45:56 ipa systemd[1]: certmonger.service: Failed with
result 'timeout'.
After that, IPA shuts down after 300 sec.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5 KDC...
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5 KDC.
Nov 05 08:50:01 ipa systemd[1]: Stopping Kerberos 5
Password-changing and Administration...
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Main process
exited, code=exited, status=2/INVALIDARGUMENT
Nov 05 08:50:01 ipa systemd[1]: Stopped Kerberos 5
Password-changing and Administration.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Unit entered failed
state.
Nov 05 08:50:01 ipa systemd[1]: kadmin.service: Failed with result
'exit-code'.
Nov 05 08:50:02 ipa systemd[1]: Stopping The Apache HTTP Server...
Nov 05 08:50:03 ipa systemd[1]: Stopped The Apache HTTP Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping IPA Custodia Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped IPA Custodia Service.
Nov 05 08:50:03 ipa ntpd[73]: ntpd exiting on signal 15 (Terminated)
Nov 05 08:50:03 ipa ntpd[73]: 127.127.1.0 local addr 127.0.0.1 ->
Nov 05 08:50:03 ipa systemd[1]: Stopping Network Time Service...
Nov 05 08:50:03 ipa systemd[1]: Stopped Network Time Service.
Nov 05 08:50:03 ipa systemd[1]: Stopped target PKI Tomcat Server.
Nov 05 08:50:03 ipa systemd[1]: Stopping PKI Tomcat Server
pki-tomcat...
The error is consistent enough, it seems LDAP only comes up seconds
after tomcat tries to reach it.
Nov 05 09:34:57 ipa server[231]: Internal Database Error
encountered: Could not connect to LDAP server host ipa port 636 E rror
netscape.ldap.LDAPException: Unable to create socket:
java.net.ConnectException: Connection refused (Connection refused) (-1)
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.793590657
+0000] - INFO - slapd_daemon - slapd started. Listening on All
Interfaces port 389 for LDAP requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.812565603
+0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for
LDAPS requests
Nov 05 09:34:59 ipa ns-slapd[83]: [05/Nov/2018:09:34:59.814451330
+0000] - INFO - slapd_daemon - Listening on
/var/run/slapd-VISION-FHG-DE.socket for LDAPI requests
Since it's not an Authentication Error, as described here:
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom...
I don't think this is an issue with the certificates. Nonetheless, I
checked them and it seems fine.
When starting FreeIPA via ipactl start, however, the system starts -
certmonger remains failed though. The system isn't fully functional though.
This is how we start the Container:
/usr/bin/docker run \
-h 'ipa' --net bridge -m 0b -e IPA_SERVER_IP=192.168.2.15 \
-e IPA_SERVER_HOSTNAME=ipa \
-p 80:80 \
-p 443:443 \
-p 88:88/tcp \
-p 88:88/udp \
-p 389:389 \
-p 636:636 \
-p 7389:7389 \
-p 464:464/tcp \
-p 464:464/udp \
-p 123:123 \
-p 9443:9443 \
-p 9444:9444 \
-p 9445:9445 \
-v /data/ipa:/data:Z \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
--tmpfs /tmp --tmpfs /run --sysctl net.ipv6.conf.all.disable_ipv6=0
--cap-add=SYS_ADMIN --cap-add SYS_TIME \
--name freeipa \
freeipa/freeipa-server:fedora-27 \
Any idea what might cause this, or how we can futher debug it?
2 years, 4 months
IPA server upgrade fails with KDC error
by Johannes Brandstetter
Hi,
I'm trying to upgrade FreeIPA through ipa-server-upgrade from 4.4 to 4.5. The command fails with an "ACIError: Insufficient access:" . I find in the kdc log that it complains about " Database module does not match KDC version - while initializing database for realm..."
Does anybody know how to fix this?
Some more info:
$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
$ tail /var/log/krb5kdc.log
krb5kdc: Server error - while fetching master key K/M for realm XXX
krb5kdc: Database module does not match KDC version - while initializing database for realm XXX
$ sudo less /var/log/ipaupgrade.log
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2017-10-16T13:04:13Z DEBUG duration: 0 seconds
2017-10-16T13:04:13Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2017-10-16T13:04:14Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run
server.upgrade()
File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1896, in upgrade
data_upgrade.create_instance()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 124, in create_instance
runtime=90)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 504, in start_creation
run_step(full_msg, method)
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 494, in run_step
method()
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 96, in __start
api.Backend.ldap2.connect()
File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect
conn = self.create_connection(*args, **kw)
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 190, in create_connection
client_controls=clientctrls)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1111, in external_bind
'', auth_tokens, server_controls, client_controls)
File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
self.gen.throw(type, value, traceback)
File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler
raise errors.ACIError(info=info)
2017-10-16T13:04:14Z DEBUG The ipa-server-upgrade command failed, exception: ACIError: Insufficient access:
2017-10-16T13:04:14Z ERROR Insufficient access:
2017-10-16T13:04:14Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information
$ sudo less /var/log/yum.log
Oct 16 05:36:02 Updated: ipa-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:02 Updated: ipa-client-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:25 Updated: libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:53 Updated: python-libipa_hbac-1.15.2-50.el7_4.2.x86_64
Oct 16 05:36:55 Updated: python2-ipalib-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:36:55 Updated: python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:37:23 Updated: ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:43 Updated: ipa-server-common-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch
Oct 16 05:38:44 Updated: sssd-ipa-1.15.2-50.el7_4.2.x86_64
Oct 16 05:39:01 Installed: ipa-client-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:39:28 Updated: ipsilon-tools-ipa-2.0.2-5.el7.centos.noarch
Oct 16 05:39:29 Updated: ipa-server-4.5.0-21.el7.centos.1.2.x86_64
Oct 16 05:40:48 Erased: ipa-admintools-4.4.0-14.el7.centos.7.noarch
Oct 16 05:19:30 Updated: krb5-libs-1.15.1-8.el7.x86_64
Oct 16 05:19:30 Updated: krb5-workstation-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-server-1.15.1-8.el7.x86_64
Oct 16 05:19:31 Updated: krb5-pkinit-1.15.1-8.el7.x86_64
Oct 16 05:38:22 Updated: sssd-krb5-common-1.15.2-50.el7_4.2.x86_64
Oct 16 05:38:57 Updated: sssd-krb5-1.15.2-50.el7_4.2.x86_64
Cheers,
Johannes
2 years, 4 months
