FreeIPA, OSX, DockerDesktop
by james liu
PREP
====
git clone https://github.com/freeipa/freeipa-container.git
cd freeipa-container
mkdir /tmp/ipa-data
docker run --name freeipa-server-container -ti -h ipa.example.test --read-only -v /tmp/ip-data :/data:Z freeipa-server --sysctl net.ipv6.conf.all.disable_ipv6=1
RESULT
======
tar: etc/sysconfig/selinux: Cannot utime: No such file or directory
tar: Exiting with failure status due to previous errors
QUESTION
=========
I'm running DockerDesktop 2.0.4, OSX 10.13.6.
Is there a set of commands that will work?
Thanks
2 weeks, 3 days
yum update problem
by Natxo Asenjo
hi,
after patching our centos 7 hosts to the latest version today, one of the
two replicas is having trouble.
[root@kdc2 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: STOPPED
kadmin Service: STOPPED
named Service: STOPPED
httpd Service: RUNNING
ipa-custodia Service: STOPPED
ntpd Service: STOPPED
pki-tomcatd Service: RUNNING
smb Service: STOPPED
winbind Service: STOPPED
ipa-otpd Service: STOPPED
ipa-dnskeysyncd Service: STOPPED
ipa: INFO: The ipactl command was successful
and after digging in the logs I come across this in /var/log/ipaupgrade.log:
2019-11-20T18:18:29Z DEBUG stderr=
2019-11-20T18:18:31Z INFO Certmonger certificate renewal configuration
already up-to-date
2019-11-20T18:18:31Z INFO [Enable PKIX certificate path discovery and
validation]
2019-11-20T18:18:31Z DEBUG Loading StateFile from
'/var/lib/ipa/sysupgrade/sysupgrade.state'
2019-11-20T18:18:31Z INFO PKIX already enabled
2019-11-20T18:18:31Z INFO [Authorizing RA Agent to modify profiles]
2019-11-20T18:18:31Z INFO [Authorizing RA Agent to manage lightweight CAs]
2019-11-20T18:18:31Z INFO [Ensuring Lightweight CAs container exists in
Dogtag database]
2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740162547472
2019-11-20T18:18:31Z DEBUG flushing
ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache
2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket
conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc24b638>
2019-11-20T18:18:31Z DEBUG Destroyed connection
context.ldap2_139740162547472
2019-11-20T18:18:31Z INFO [Adding default OCSP URI configuration]
2019-11-20T18:18:31Z INFO [Ensuring CA is using LDAPProfileSubsystem]
2019-11-20T18:18:31Z INFO [Migrating certificate profiles to LDAP]
2019-11-20T18:18:31Z DEBUG Created connection context.ldap2_139740160021648
2019-11-20T18:18:31Z DEBUG flushing
ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket from SchemaCache
2019-11-20T18:18:31Z DEBUG retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-L-DOMAIN-IT.socket
conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f17cc289b00>
2019-11-20T18:18:31Z DEBUG Destroyed connection
context.ldap2_139740160021648
2019-11-20T18:18:31Z DEBUG request GET
https://kdc2.l.domain.it:8443/ca/rest/account/login
2019-11-20T18:18:31Z DEBUG request body ''
2019-11-20T18:18:31Z DEBUG response status 401
2019-11-20T18:18:31Z DEBUG response headers Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 CET
WWW-Authenticate: Basic realm="Certificate Authority"
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 951
Date: Wed, 20 Nov 2019 18:18:31 GMT
2019-11-20T18:18:31Z DEBUG response body '<html><head><title>Apache
Tomcat/7.0.76 - Error report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 401 - </h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u></u></p><p><b>description</b> <u>This request requires HTTP
authentication.</u></p><HR size="1" noshade="noshade"><h3>Apache
Tomcat/7.0.76</h3></body></html>'
2019-11-20T18:18:31Z ERROR IPA server upgrade failed: Inspect
/var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
2019-11-20T18:18:31Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 54, in run
server.upgrade()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 2146, in upgrade
upgrade_configuration()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 2018, in upgrade_configuration
ca_enable_ldap_profile_subsystem(ca)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 406, in ca_enable_ldap_profile_subsystem
cainstance.migrate_profiles_to_ldap()
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 2027, in migrate_profiles_to_ldap
_create_dogtag_profile(profile_id, profile_data, overwrite=False)
File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
line 2033, in _create_dogtag_profile
with api.Backend.ra_certprofile as profile_api:
File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line
1315, in __enter__
raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA
REST API'))
2019-11-20T18:18:31Z DEBUG The ipa-server-upgrade command failed,
exception: RemoteRetrieveError: Failed to authenticate to CA REST API
2019-11-20T18:18:31Z ERROR Unexpected error - see /var/log/ipaupgrade.log
for details:
RemoteRetrieveError: Failed to authenticate to CA REST API
In this kdc I see these errors in getcert list:
Request ID '20190220182014':
status: MONITORING
ca-error: Invalid cookie: u''
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=L.DOMAIN.IT
subject: CN=CA Audit,O=L.DOMAIN.IT
expires: 2019-12-05 13:58:24 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20190220182015':
status: MONITORING
ca-error: Invalid cookie: u''
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=L.DOMAIN.IT
subject: CN=OCSP Subsystem,O=L.DOMAIN.IT
expires: 2019-12-05 13:58:24 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20190220182016':
status: MONITORING
ca-error: Invalid cookie: u''
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=L.DOMAIN.IT
subject: CN=CA Subsystem,O=L.DOMAIN.IT
expires: 2019-12-05 13:58:24 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
Request ID '20190220182018':
status: MONITORING
ca-error: Invalid cookie: u''
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=L.DOMAIN.IT
subject: CN=IPA RA,O=L.DOMAIN.IT
expires: 2019-12-05 13:58:44 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes
Request ID '20190220182019':
status: MONITORING
ca-error: Server at "
https://kdc2.l.domain.it:8443/ca/agent/ca/profileProcess" replied: 1:
Invalid Credential.
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=L.DOMAIN.IT
subject: CN=kdc2.l.domain.it,O=L.DOMAIN.IT
expires: 2019-12-10 10:57:52 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"Server-Cert cert-pki-ca"
track: yes
auto-renew: yes
I still have a working replica, so I could just reinstall and have a
working set in a couple of minutes, but I would like to find out what has
gone wrong.
The systems are running ipa-server-4.6.5-11.el7.centos.3.x86_64
Any help welcome ;-)
Thanks,
--
Groeten,
natxo
4 weeks, 1 day
Re: Renewing a failed to auto-renewal certificate
by Stuart McRobert
Dear flo,
Thanks for the helpful links.
To check whether replication is possible between the three freeipa
servers, via the web interface on each, I have successfully created three
new users:
+ On server 1 create a new user 1 and check they appear on servers 2 & 3 - yes
+ On server 2 create a new user 2 and check they appear on servers 1 & 3 - yes
+ On server 3 create a new user 3 and check they appear on servers 1 & 2 - yes
Then for each user remove them from a different server to where they were
created. This worked as expected.
However I do appear to have one user whose information failed to
correctly replicate some time ago, causing an inconsistency that I am
uncertain on the best way to fix.
On server 1 via web attempt to view this specific user:
Operations Error
Some operations failed.
XXX: user not found
which should be displayed as a preserved user entry but lacks any details
shown other than the "user login".
On server 2 this user appears as an active user, with details, status
disabled.
On server 3 this user appears as a preserved user, with full details, and
a note I added to the Class field a few days ago to see whether it would
then just replicate but failed.
In logs, searching for the user in question on server 1
./httpd/error_log:[Sun Sep 20 10:34:14.256333 2020] [wsgi:error] [pid 29637] [remote IP_ADDRESS:56930] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: user_find(u'USER_XXX', sizelimit=0, version=u'2.215', pkey_only=True): SUCCESS
./httpd/error_log:[Sun Sep 20 10:34:28.721951 2020] [wsgi:error] [pid 29637] [remote IP_ADDRESS:56932] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: user_find(u'USER_XXX', preserved=True, sizelimit=0, version=u'2.215', pkey_only=True): SUCCESS
./httpd/error_log:[Sun Sep 20 10:34:28.738772 2020] [wsgi:error] [pid 29636] [remote IP_ADDRESS:56932] ipa: INFO: sm@OUR_DOMAIN: batch: user_show(u'USER_XXX', no_members=True): NotFound
./httpd/error_log:[Sun Sep 20 10:34:28.738952 2020] [wsgi:error] [pid 29636] [remote IP_ADDRESS:56932] ipa: INFO: [jsonserver_session] sm@OUR_DOMAIN: batch(({u'params': ((u'USER_XXX',), {u'no_members': True}), u'method': u'user_show'},), version=u'2.215'): SUCCESS
Which just confirms what was seen via the web interface.
Next go looking in /var/log/dirsrv/slapd-OUR-DOMAIN/errors and find lots
of these messages:
[20/Sep/2020:11:18:12.449932996 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToserver2" (server2:389): CSN 5bb473ef000000070000 not found, we aren't as up to date, or we purged
[20/Sep/2020:11:18:12.452051936 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToserver2" (server2:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized.
[20/Sep/2020:11:18:15.479226915 +0100] - ERR - agmt="cn=caToserver2" (server2:389) - clcache_load_buffer - Can't locate CSN 5bb473ef000000070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[20/Sep/2020:11:18:15.481677959 +0100] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=caToserver2" (server2:389): CSN 5bb473ef000000070000 not found, we aren't as up to date, or we purged
[20/Sep/2020:11:18:15.483458741 +0100] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=caToserver2" (server2:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized.
But is that the only CSN found to be missing, seems to be based on this
search:
grep -v 5bb473ef000000070000 ./dirsrv/slapd-OUR-DOMAIN/errors | grep -v "If the error persists"
389-Directory/1.3.6.6 B2017.145.2031
server1.OUR-DOMAIN:636 (/etc/dirsrv/slapd-OUR-DOMAIN)
[18/Sep/2020:05:57:26.038958649 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToserver3" (server3:389): Unable to parse the response to the endReplication extended operation.
[18/Sep/2020:17:45:55.236862951 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=caToserver2" (server2:389): Unable to parse the response to the endReplication extended operation.
Turning next to server 2 and the dirsrv logs there, lots of messages of the form:
[17/Sep/2020:19:33:24.075845464 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773158 (rc: 32)
[17/Sep/2020:19:33:24.076296207 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773159 (rc: 32)
[17/Sep/2020:19:33:24.077311010 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773160 (rc: 32)
[17/Sep/2020:19:33:24.077830624 +0100] - ERR - DSRetroclPlugin - delete_changerecord: could not delete change record 6773161 (rc: 32)
[19/Sep/2020:19:59:28.091654453 +0100] - ERR - NSMMReplicationPlugin - release_replica - agmt="cn=meToserver1" (server1:389): Unable to parse the response to the endReplication extended operation.
Finally for server 3, dirsrv logs appear to be more about getting started
after certificate problems the other day, rather than issues seen on the
other servers, but this server does appear to display the user fully as
would be desired everywhere.
Our old version appears to lack the 389 command dsconf so not been able to
use that to help.
Summary:
+ Replication appears to work for e.g. new users
+ I guess one entry has failed to be replicated correctly causing the
inconsistent state on the other two servers
+ This should ideally be corrected to avoid further issues???
+ Uncertain about the best way to do this, suggestions very welcome as
first time fixing such problems and I don't want to make it any worse,
after all replications seems to be working for everything else.
Thanks
Best wishes
Stuart
4 weeks, 1 day
Replica not renewing IPA certificates
by Roderick Johnstone
Hi
This is freeipa (ipa-server-4.6.5-11.el7_7.3.x86_64) on RHEL7 with
freeipa's own internal CA.
One of my ipa server replicas (host3) has not renewed its IPA system
certificates and is now showing
ca-error: Invalid cookie: u''
in the 'getcert list' output for certificates:
"auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca",
"subsystemCert cert-pki-ca", and the
certificate in the file /var/lib/ipa/ra-agent.pem
As far as I can see, the sequence of events has been as follows:
host3 noticed the certificates needed renewing at 30 Jan 2020 05:37 and
certmonger initiated a renewal.
The state of those certificates went from MONITORING to CA_WORKING but
the certificates were not renewed.
The CA renewal master (host1) noticed its same set of certificates (plus
"Server-Cert cert-pki-ca") needed renewing at 30 Jan 2020 07:28 and
renewed them successfully.
Another replica (host2) noticed that its certificates needed renewing at
30 Jan 2020 07:32 and renewed them successfully.
At 30 Jan 13:37 on host3 the certificates needing to be renewed went
from CA_WORKING back to MONITORING, but 'getcert list' now shows them with:
ca-error: Invalid cookie: u''
and they still haven't renewed.
I haven't seen certmonger attempt to try the renewal again on host3
(nothing from certmonger in /var/log/messages since 30 Jan 13:37).
While I could try a getcert resubmit on host3 to force it to try again,
I'd like to know if what I am seeing is the expected behaviour when a
replica tried to renew certificates before the renewal master.
How long should I have to wait till certmonger on host3 tries again? - I
couldn't find any reference to how often certmonger tries the renewal.
Rob Crittenden's freeipa-healthcheck script is now showing the following
for host3:
ERROR: ipahealthcheck.ipa.certs.IPARAAgent: RA agent description does
not match 2;16;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA
RA,O=EXAMPLE.COM in LDAP and 2;7;CN=Certificate
Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM expected
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040924:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040920:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040921:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040922:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040923:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040925:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040927:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180926040926:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.ipa.certs.IPACertRevocation.20180831064406:
Request for certificate failed, Certificate operation cannot be
completed: EXCEPTION (Invalid Credential.)
ERROR: ipahealthcheck.dogtag.ca.DogtagCertsConnectivityCheck: Request
for certificate failed, Certificate operation cannot be completed:
EXCEPTION (Invalid Credential.)
Each of host1, host2 and host3 are showing serial number 16 in ldap using:
ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca
description
At this stage I'm not sure whether this will resolve itself when
certmonger tries to renew certificates again or whether I need to be
more proactive.
I'm happy to supply more logs as necessary.
Thanks
Roderick
4 weeks, 1 day
Replication failure during replica setup
by William Muriithi
Evening,
I am attempting to setup a new replica this afternoon and it failed with an
error message that I haven't been able to decipher. Really haven't been
able to get past it as I can't figure out what really tripped the setup?
Have someone seen this in their logs and how did you go about fixing it?
The complete logs are on
https://pastebin.pl/view/85208dbb
2020-09-28T20:12:34Z DEBUG Successfully updated nsDS5ReplicaId.
2020-09-28T20:12:34Z DEBUG Add or update replica config
cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-09-28T20:12:34Z DEBUG Added replica config
cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-09-28T20:12:34Z DEBUG Add or update replica config
cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping tree,cn=config
2020-09-28T20:12:34Z DEBUG No update to
cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping tree,cn=config
necessary
2020-09-28T20:12:34Z DEBUG Waiting up to 300 seconds for replication
(ldapi://%2Fvar%2Frun%2Fslapd-EXTERNAL-EXAMPLE-COM.socket) cn=
meToneptune.external.example.com,cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping
tree,cn=config (objectclass=*)
2020-09-28T20:12:34Z DEBUG Entry found [LDAPEntry(ipapython.dn.DN('cn=
meToneptune.external.example.com,cn=replica,cn=dc\=external\,dc\=example\,dc\=com,cn=mapping
tree,cn=config'), {'objectClass': [b'nsds5replicationagreement', b'top'],
'cn': [b'meToneptune.external.example.com'], 'nsDS5ReplicaHost': [b'
neptune.external.example.com'], 'nsDS5ReplicaPort': [b'389'],
'nsds5replicaTimeout': [b'120'], 'nsDS5ReplicaRoot':
[b'dc=external,dc=example,dc=com'], 'description': [b'me to
neptune.external.example.com'], 'nsDS5ReplicatedAttributeList':
[b'(objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn
krblastsuccessfulauth krblastfailedauth krbloginfailedcount'],
'nsDS5ReplicaTransportInfo': [b'LDAP'], 'nsDS5ReplicaBindMethod':
[b'SASL/GSSAPI'], 'nsds5ReplicaStripAttrs': [b'modifiersName
modifyTimestamp internalModifiersName internalModifyTimestamp'],
'nsDS5ReplicatedAttributeListTotal': [b'(objectclass=*) $ EXCLUDE entryusn
krblastsuccessfulauth krblastfailedauth krbloginfailedcount'],
'nsds5replicareapactive': [b'0'], 'nsds5replicaLastUpdateStart':
[b'19700101000000Z'], 'nsds5replicaLastUpdateEnd': [b'19700101000000Z'],
'nsds5replicaChangesSentSinceStartup': [b''],
'nsds5replicaLastUpdateStatus': [b'Error (0) No replication sessions
started since server startup'], 'nsds5replicaLastUpdateStatusJSON':
[b'{"state": "green", "ldap_rc": "0", "ldap_rc_text": "success", "repl_rc":
"0", "repl_rc_text": "replica acquired", "date": "2020-09-28T20:12:34Z",
"message": "Error (0) No replication sessions started since server
startup"}'], 'nsds5replicaUpdateInProgress': [b'FALSE'],
'nsds5replicaLastInitStart': [b'19700101000000Z'],
'nsds5replicaLastInitEnd': [b'19700101000000Z']})]
2020-09-28T20:12:50Z DEBUG Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
line 603, in start_creation
run_step(full_msg, method)
File "/usr/lib/python3.6/site-packages/ipaserver/install/service.py",
line 589, in run_step
method()
File "/usr/lib/python3.6/site-packages/ipaserver/install/dsinstance.py",
line 427, in __setup_replica
cacert=self.ca_file
File "/usr/lib/python3.6/site-packages/ipaserver/install/replication.py",
line 1861, in setup_promote_replication
raise RuntimeError("Failed to start replication")
RuntimeError: Failed to start replication
Regards,
William
1 month
User account lock
by Pierre Labanowski
Hello,
Regularly, i have user accounts that are locked by the policy password.
following error message: "Client's credentials have been revoked"
It's possible to unlock the account when this happens. However, this
often happens when a third-party application misconfigured that made too
many wrong requests.
the account is locked sometimes 1 hour after it is unlocked ...
it is difficult to find the source of these connection errors. I don't
know which log file i can check to identify the source of the errors,
which could make it easier to understand the source of the problem.
Do you have a pointer on how to monitor and control in the log files the
various errors that lead to the locking of a user account ? thx
Regards,
Pierre
1 month
IPA CA request ID reuse issue
by Boris Sukhinin
I try to add a new replica to a cluster of 3 freeipa servers. ipa-replica-install --setup-ca fails with an error:
[5/28]: configuring certificate server instance
ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp_3KfOZ' returned non-zero exit status 1
ipaserver.install.dogtaginstance: CRITICAL See the installation logs and the following files/directories for more information:
ipaserver.install.dogtaginstance: CRITICAL /var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
/var/log/pki/pki-tomcat/ca/debug gives more info:
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: === Processing ocsp_signing cert ===
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: === Processing sslserver cert ===
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService.processKeyPair(sslserver)
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService: san_server_cert not found
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService: loading existing key pair from NSS database
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: loadKeyPair(Server-Cert cert-pki-ca, )
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService: storing key pair into CS.cfg
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: storeKeyPair(sslserver)
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService.processCert(sslserver)
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: SystemConfigService: checking sslserver cert in NSS database
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: configCert: caType is local
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: configCert: caType is remote (revised)
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: updateConfig() for certTag sslserver
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: updateConfig() done
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: configCert: remote CA
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: confgCert: tag: sslserver
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: CertRequestPanel: got public key
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: CertRequestPanel: got private key
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: For this Cloned CA, always use its Master CA to generate the 'sslserver' certificate to avoid any changes which may have been made to the X500Name directory string encoding order.
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: injectSAN: false
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: configRemoteCert: tag: sslserver : setting profileId to: caInternalAuthServerCert
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: configRemoteCert: tag: sslserver calculated profileId: caInternalAuthServerCert
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: CertUtil: content: {xmlOutput=[true], cert_request_type=[pkcs10], profileId=[caInternalAuthServerCert], cert_request=[...cut...], requestor_name=[CA-srvXXX.local.domain-8443], sessionID=[6184760106499759096]}
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: ConfigurationUtils: POST https://srvYYY.local.domain:443/ca/ee/ca/profileSubmit
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: CertUtil: status: 1
[15/Sep/2020:15:42:06][http-bio-8443-exec-3]: CertUtil: error: Request 19990005 - Server Internal Error
java.io.IOException: Request 19990005 - Server Internal Error
at com.netscape.cms.servlet.csadmin.CertUtil.createRemoteCert(CertUtil.java:103)
at com.netscape.cms.servlet.csadmin.ConfigurationUtils.configRemoteCert(ConfigurationUtils.java:2737)
at com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2593)
at org.dogtagpki.server.rest.SystemConfigService.processCert(SystemConfigService.java:484)
at org.dogtagpki.server.rest.SystemConfigService.processCerts(SystemConfigService.java:303)
at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:166)
at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:101)
<...long stacktrace...>
LDAP access logs on existing server show that certificate request ID was reused. ADD queries for request as well as for certificate have failed, but nevertheless the request was overwritten with a third query:
[15/Sep/2020:15:42:06.259655845 +0300] conn=2608 op=1804 ADD dn="cn=19990005,ou=ca,ou=requests,o=ipaca"
[15/Sep/2020:15:42:06.260525381 +0300] conn=2608 op=1804 RESULT err=68 tag=105 nentries=0 etime=0.0001251547
[15/Sep/2020:15:42:06.295774388 +0300] conn=2608 op=1805 ADD dn="cn=536805381,ou=certificateRepository,ou=ca,o=ipaca"
[15/Sep/2020:15:42:06.296210847 +0300] conn=2608 op=1805 RESULT err=68 tag=105 nentries=0 etime=0.0000755866
[15/Sep/2020:15:42:06.301651990 +0300] conn=2608 op=1806 MOD dn="cn=19990005,ou=ca,ou=requests,o=ipaca"
[15/Sep/2020:15:42:06.315983780 +0300] conn=2608 op=1806 RESULT err=0 tag=103 nentries=0 etime=0.0014827998 csn=5f60b69f000000110000
I can confirm that each server has its own request ID range configured in /etc/pki/pki-tomcat/ca/CS.cfg:
1. dbs.beginRequestNumber=19970001
dbs.endRequestNumber=19980000
2. dbs.beginRequestNumber=19980001
dbs.endRequestNumber=19990000
3. dbs.beginRequestNumber=19990001
dbs.endRequestNumber=20000000
So my questions are:
1. How does PKI track request IDs and prevent their reuse?
2. Does overwriting certificate request in LDAP affect certificate renewal or have any other negative consequences?
3. What's the best way to fix this problem? LDAP backups are available and restoring o=ipaca is an option. Domain database rollback is not an option though.
1 month
Anyone integrate FreeIPA 4.8.x with Okta LDAPS service recently?
by Chris Dagdigian
Hi folks,
Has anyone configured the LDAP service of Okta to push users into
FreeIPA recently? Looking for tips/tricks more recent than this page
https://www.freeipa.org/page/HowTo/Integrate_With_Okta which I think
dates back to 2014.
I can get the Okta agent running on the FreeIPA host and talking to Okta
but user provisioning fails with a DN parsing related error that makes
me think that something is now different about (a) telling Okta what
LDAP type/scheme is used on the other end or (b) setting up the
attribute mapping.
This is my Okta ldap agent error when a user is pushed into FreeIPA -- I
100% understand this is an Okta config and Okta agent config thing but
am just wondering if anyone has been down this road recently. If not
I'll try to write up my notes if I can get it working.
This is my error as of now. The RDN value is mapped to Okta 'uid'
attribute which always resolves to an email address like DN. I'm going
to blow everything away and restart fresh as I changed too many things
while debugging the current config:
[ 2020-09-25 21:39:14.859 ] [ Thread-15 ] [ INFO ] [LdapRestClient:478]
- GET
https://XXXX.okta.com/api/1/internal/app/agent/ldap_sun_one/0oa5o6gyetYbG...
[ 2020-09-25 21:39:14.859 ] [ pool-2-thread-3 ] [ ERROR ]
[UnboundIDLdapClient:531] - Error during ModifyRequest. ResultCode=34
(invalid DN syntax) exception=
com.unboundid.ldap.sdk.LDAPException: Unable to parse string
'dag(a)XXX.net' as a DN because it does not have an equal sign after RDN
attribute 'dag(a)XXX.net'.
at com.unboundid.ldap.sdk.DN.<init>(DN.java:434)
at com.unboundid.ldap.sdk.DN.<init>(DN.java:300)
at com.unboundid.ldap.sdk.DN.getParentString(DN.java:1055)
at
com.okta.ldap_agent.client.unboundid.UnboundIDLdapClient.moveEntry(UnboundIDLdapClient.java:902)
at
com.okta.ldap_agent.client.unboundid.UnboundIDLdapClient.modifyEntry(UnboundIDLdapClient.java:483)
at
com.okta.ldap_agent.connectors.ldap.LdapConnectorExecutorImpl.modifyEntry(LdapConnectorExecutorImpl.java:67)
at
com.okta.ldap_agent.adapters.LdapDirectoryAdapter.modifyEntry(LdapDirectoryAdapter.java:175)
at
com.okta.ldap_agent.handlers.WriteObjectActionHandler.performAction(WriteObjectActionHandler.java:43)
at
com.okta.ldap_agent.LdapAgent.lambda$dispatchAction$0(LdapAgent.java:253)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[ 2020-09-25 21:39:14.860 ] [ pool-2-thread-3 ] [ ERROR ]
[WriteObjectActionHandler:65] - Interchange error: 34, Unable to parse
string 'dag(a)XXX.net' as a DN because it does not have an equal sign
after RDN attribute 'dag(a)XXX.net'.
1 month
