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
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.
We have FreeIPA running on Ubuntu 16.04 since about two years
now. For the last few day we see these messages in the log
Oct 22 17:32:14 ipasrv certmonger: 2018-10-22 17:32:14  Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the SSL CA cert (path? access rights?).
Oct 22 17:32:20 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding request to dogtag-ipa-renew-agent
Oct 22 17:32:20 ipasrv dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent returned 3
Where should I start looking to recover from this?
I am looking at using FreeIPA without CA, using external signed certificates, reading the documentations it looks possible using —dirsrv-certfile, —http-cert-file and —point-certfile. Should I just create a CSR for the hostname by by hand and get it signed? Also is there any good reason for having different certs for http, ldap and pkinit? Can I just use one certificate for all services and for all servers and replicas using Subject Alternative Names?
I have configured DNS forwarders in each of my FreeIPA servers. However I want to be able to go back and verify they are there. I can't remember how to get that information. I am running CentOS 7 latest with FreeIPA version 4.5.0. I want to say there is an LDAP command I found.
This is not for global forwarders.
As part of a larger IPA "health" checker and driven largely by necessity
I have the beginning of a certificate checking tool available at
It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+
There is not much of a user-friendly interface to it. There are only two
options, debug and verbose, which increase the amount of debug output
(and it is immense).
The UI is limited because I expect it to be rolled up into some larger
tool at some point and don't want to have to throw away a ton of
It needs to be run on an IPA master and checks the things I thought of
to check. I've only done limited testing on mostly brand new installs so
I'd appreciate feedback. Don't freak out of it spits out errors as it
could just be bugs on my part :-)
It is read-only so it shouldn't blow up anything.
So if you want to run it against your system and send me the any output
I can try to figure out if it is my tool that is the issue or your
system (it is supposed to help pro-actively diagnose issues after all).
To use just clone it from git (or download ipa-checkcerts.py from the repo)
Run it as root:
# kinit admin
# python ipa-checkcerts.py
IPA version 4.5.4-10.el7_5.3
Check CA status
Check NSS trust
Checking certificates in CS.cfg
Comparing certificates to requests in LDAP
Checking RA certificate
Checking host keytab
Checking renewal master
End-to-end cert API test
Checking permissions and ownership
All checks passed
It is not always clear the best way to create an account for a script or application to use. Generally this special type of account has no password expiration (or a very long expiration window). For example, some applications require a bind user to connect to LDAP. It seems there are a half a dozen ways to do it. When should each be used? Here are the options I'm aware of:
1. Create IPA Service (ipa service-add)
My understanding is an IPA Service cannot reveal the plaintext password (keytab only) and must be tied to a single host. This doesn't work when the bind user password plaintext must be known (unless I missed that somewhere). Also, you can't assign a service to the "admins" user group, which is a special user group - so if you want a "root-like" service you can't use an IPA service (maybe you could cobble together some roles that mostly did what admins members get).
2. Create IPA User (ipa user-add)
There are few ways to make a special password expiration (not clear which is best):
A. You can use a special password policy where the password doesn't expire for a very long time (must be done before setting password).
B. Use kadmin.local to set password expiration to never (or a very long time).
C. Use ldapmodify (dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com) to set expiration to a very long time
D. If you never set a password, but execute the ipa getkeytab command then there doesn't appear to be any expiration on the user account password (though web interface says there is no password so not sure if this is a bug or what)
3. Create LDAP System Account (ldapmodify - dn: uid=system,cn=sysaccounts,cn=etc,dc=example,dc=com)
This seems like a back door and only works if your "application account" needs LDAP, but not Kerberos. Account does not show up in the web interface anywhere.
4. Create Kerberos Service (kadmin.local addprinc)
Probably no need to ever use kadmin.local to create a service? Then again, maybe there is?
I am looking for a way of allowing users to reset their password
without going through the VPN. I usually send users notification when
the password are about to expire, but they don't follow up until
something stop working. At that point, they can't even VPN.
Have anyone else exposed IPA to the public and have it faired well?
Also, is there a way of changing one way trust (The default) to two
way trust without first removing the current trust?
FreeIPA allows disabling DNS Autodiscovery by explicitly listing the host names of FreeIPA servers. However, it isn't clear if the order of host names matters. For example:
ipa-client-install --server firsthostname.example.com --server secondhostname.example.com
Is the first host name I list the one that will always be consulted first? Or does SSSD attempt to use whichever one responds to a ping faster? I have not configured any DNS SRV records.
We are looking to develop several custom plugins for FreeIPA. Could anyone please advise on any documentation guidelines on FreeIPA plugin development?
LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies.