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
3 years, 5 months
ipa-replica-install failing
by Mitchell Smith
Hi list,
I wanted to repost this issue with a more appropriate subject line, in
case anyone has come across this issue before and has a work around.
To provide some context, I have two FreeIPA instances running FreeIPA
4.3.1 on Ubuntu 16.04 LTS.
I want to migrate to FreeIPA 4.5.4 running on CentOS 7.
I have a way to migrate by dumping all the users out with ldapsearch
and adding them to the new instance with ldapadd but it is a bit messy
and will result in all users having to reset their password, as it
won't let me add in already encrypted passwords.
My initial thought was to add the new instance as a replica and then
eventually retire the old one.
I ran in to some problems with the ‘ipa-replica-install’ command though.
I was able to join as a client no problem, but when I went to run
‘ipa-replica-install’ it failed while configuring the directory server
component.
[25/42]: restarting directory server
[26/42]: creating DS keytab
[27/42]: ignore time skew for initial replication
[28/42]: setting up initial replication
[error] DatabaseError: Server is unwilling to perform: modification
of attribute nsds5replicareleasetimeout is not allowed in replica
entry
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
I thought this might have something to do with differences between
4.3.1 and 4.5.4 but I wasn’t entirely sure.
If there is a work around for this issue, it would be a significantly
easier transition to the new FreeIPA instance.
Cheers,
Mitch
3 years, 7 months
IPA healthcheck for older versions
by Rob Crittenden
Over the summer we announced the freeipa-healthcheck project which is
designed to look at an IdM cluster and look for common problems so you
can have some level of assurance that the system is running as it should.
It was built against the IPA 4.8.x branch and originally released only
for Fedora 29+. It is also included in the newly released RHEL 8.1.0.
My curious nature led me to see if it would also work in in the IPA
4.6.x branch. It was a bit of a challenge backing down to Python 2 but I
was able to get something working. I tested primarily on Fedora 27 but
it should also work in RHEL/CentOS 7 (I smoke tested 7.8).
I made an EPEL 7 build in COPR,
https://copr.fedorainfracloud.org/coprs/rcritten/ipa-healthcheck/
Enable the repo and do: yum install freeipa-healthcheck
Then run: ipa-healthcheck --failures-only
Ideally there will be no output but an empty list []. Otherwise the
output is JSON and hopefully has enough information to point you in the
right direction. Feel free to ask if need help.
False positives are always a possibility and many of the checks run
independently so it's possible to get multiple issues from a single root
problem. It's hard to predict all possible installations so some
fine-tuning may be required.
I'd recommend running it every now and then at least, like prior to
updating IPA packages, creating a new master, etc, if not daily. It
will, for example, warn of impending cert expiration.
The more feedback I get on it the better and more useful I can make it.
This is my own personal backport and is not officially supported by
anyone but me. It's preferred to report issues on this mailing list.
I'll see them and others may be able to chime in as well.
rob
3 years, 7 months
kinit -n asking for password on clients
by John Ratliff
When trying to do pkinit, if I do kinit -n on one of the IdM servers, it
works fine. If I try on a client machine, it asks me for the password
for WELLKNOWN/ANONYMOUS@REALM.
I have the pkinit_anchors setup for the realm. As I'm trying to do
anonymous pkinit, I think I don't need a client certificate.
On the server, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[13061] 1518402857.924212: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[13061] 1518402857.929673: Sending request (200 bytes) to IDM.EXAMPLE.COM
[13061] 1518402857.931830: Initiating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.932241: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402857.939162: Received answer (359 bytes) from stream
10.77.9.101:88
[13061] 1518402857.939180: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.939284: Response was from master KDC
[13061] 1518402857.939380: Received error from KDC:
-1765328359/Additional pre-authentication required
[13061] 1518402857.939474: Processing preauth types: 16, 15, 14, 136,
19, 147, 2, 133
[13061] 1518402857.939499: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402857.939509: Received cookie: MIT
[13061] 1518402857.939563: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402857.940352: PKINIT client computed kdc-req-body checksum
9/D98A0144E7E4ACC66B63EBCA98379AB9F055D143
[13061] 1518402857.940369: PKINIT client making DH request
[13061] 1518402858.935: Preauth module pkinit (16) (real) returned:
0/Success
[13061] 1518402858.956: Produced preauth for next request: 133, 16
[13061] 1518402858.994: Sending request (1408 bytes) to IDM.EXAMPLE.COM
[13061] 1518402858.1091: Initiating TCP connection to stream 10.77.9.101:88
[13061] 1518402858.1187: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402858.43063: Received answer (2880 bytes) from stream
10.77.9.101:88
[13061] 1518402858.43088: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402858.43198: Response was from master KDC
[13061] 1518402858.43258: Processing preauth types: 17, 19, 147
[13061] 1518402858.43273: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402858.43300: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402858.44150: PKINIT client verified DH reply
[13061] 1518402858.44189: PKINIT client found id-pkinit-san in KDC cert:
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM
[13061] 1518402858.44199: PKINIT client matched KDC principal
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM against id-pkinit-san; no EKU
check required
[13061] 1518402858.62345: PKINIT client used KDF 2B06010502030602 to
compute reply key aes256-cts/00E0
[13061] 1518402858.62395: Preauth module pkinit (17) (real) returned:
0/Success
[13061] 1518402858.62402: Produced preauth for next request: (empty)
[13061] 1518402858.62414: AS key determined by preauth: aes256-cts/00E0
[13061] 1518402858.62547: Decrypted AS reply; session key is:
aes256-cts/96F0
[13061] 1518402858.62589: FAST negotiation: available
[13061] 1518402858.62692: Initializing
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 with default princ
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[13061] 1518402858.62770: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62846: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: fast_avail: yes
[13061] 1518402858.62878: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62933: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: pa_type: 16
[13061] 1518402858.62954: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/pa_type/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
But on the client, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[2941] 1518402820.155827: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[2941] 1518402820.156298: Sending request (200 bytes) to IDM.EXAMPLE.COM
[2941] 1518402820.158723: Resolving hostname paine.example.com.
[2941] 1518402820.159975: Resolving hostname phantom.example.com.
[2941] 1518402820.160757: Resolving hostname paine.example.com.
[2941] 1518402820.161411: Initiating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.162065: Sending TCP request to stream 204.89.253.101:88
[2941] 1518402820.168495: Received answer (359 bytes) from stream
204.89.253.101:88
[2941] 1518402820.168532: Terminating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.169917: Response was from master KDC
[2941] 1518402820.169974: Received error from KDC:
-1765328359/Additional pre-authentication required
[2941] 1518402820.170029: Processing preauth types: 16, 15, 14, 136, 19,
147, 2, 133
[2941] 1518402820.170051: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2941] 1518402820.170062: Received cookie: MIT
Password for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM:
[2941] 1518402833.34612: Preauth module encrypted_timestamp (2) (real)
returned: -1765328252/Password read interrupted
kinit: Pre-authentication failed: Password read interrupted while
getting initial credentials
Suggestions on what I'm missing?
Thanks.
3 years, 8 months
automember hostgroup by account?
by Amos
Is it possible to have an automember rule to add a host to a hostgroup
based on the account used with ipa-install-client?
Amos
3 years, 9 months
IPA and legacy systems
by Ronald Wimmer
What would be a good solution to add systems where the FQDN cannot be
changed?
Would it make sense to add a second DNS A Record in the IPA domain for
each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
Cheers,
Ronald
3 years, 10 months
IPA CA renewal and duplicate CA certs
by Sigbjorn Lie
Hi,
We recently renewed our IPA CA cert using the "ipa-cacert-manage renew” command. The renewal was successful, and our CA cert no longer expires in 2020, but in 2040.
Running “ipa-certupdate” on existing IPA clients and ipa-client-install on new IPA clients also works, however both the new and the old CA cert is pulled down to the IPA client and stored in /etc/ipa/ca.crt.
This creates some issues as most applications reading /etc/ipa/ca.crt only reads the first entry, which happens to be the old CA cert.
For the moment everything works OK as the old CA cert is still valid, however this will become a major issue in a few months time.
Is this expected? To continue to service both the old and the new CA certificate to old and new IPA clients?
Will the old certificate be automatically removed at some point?
If not, what is the safe steps to remove the old CA certificate from the IPA servers?
Thanks.
Regards,
Siggi
3 years, 10 months
Samba integration - access without Kerberos
by lejeczek
hi everybody.
I see this subject might have been poked around many times, a couple
times at least for sure. But, I thought I'll poke again and hopefully
get some latest comments & thoughts on - how to make IPA's Samba allow
password authentication to Win clients from outside of IPA/AD domains?
Would there, by now, possibly be a semi-official (by IPA team) way of
getting there, since the subject first came up a longer while ago?
many thanks, L.
3 years, 11 months
ipa-adtrust-install --unattended | did not quite work?
by lejeczek
hi everyone,
I did something pretty vanilla:
$ ipa-adtrust-install --unattended --admin-password=xxx
Process showed first some warning about "unattended" but then this:
Configuring CIFS
[1/24]: validate server hostname
[2/24]: stopping smbd
[3/24]: creating samba domain object
[4/24]: retrieve local idmap range
[5/24]: creating samba config registry
[6/24]: writing samba config file
[7/24]: adding cifs Kerberos principal
[8/24]: adding cifs and host Kerberos principals to the adtrust agents
group
[9/24]: check for cifs services defined on other replicas
[10/24]: adding cifs principal to S4U2Proxy targets
[11/24]: adding admin(group) SIDs
[12/24]: adding RID bases
[13/24]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
[14/24]: activating CLDAP plugin
[15/24]: activating sidgen task
[16/24]: map BUILTIN\Guests to nobody group
[17/24]: configuring smbd to start on boot
[18/24]: adding special DNS service records
[19/24]: restarting Directory Server to take MS PAC and LDAP plugins
changes into account
[20/24]: adding fallback group
[21/24]: adding Default Trust View
[22/24]: setting SELinux booleans
[23/24]: starting CIFS services
ipaserver.install.adtrustinstance: CRITICAL CIFS services failed to start
[24/24]: restarting smbd
Done configuring CIFS.
Now, Samba would not start and I wonder what that might have to do with
the above:
tarting Samba SMB Daemon...
[2020/02/14 11:21:34.801358, 0]
../../source3/passdb/pdb_interface.c:171(make_pdb_method_name)
No builtin nor plugin backend for ipasam found
smb.service: Main process exited, code=exited, status=1/FAILURE
smb.service: Failed with result 'exit-code'.
Failed to start Samba SMB Daemon.
Or is is it unrelated? Hot to troubleshoot & fix it?
I'm on Centos 8 with ipa-server-4.8.0-13.module_el8.1.0+265+e1e65be4.x86_64
many thanks, L.
3 years, 11 months
ipa: ERROR: CIFS server communication error: code "3221225506", message "{Access Denied} A process has requested access to an object but has not been granted those access rights." (both may be "None")
by Bernard Lheureux
Hi all,
After a fresh install of FreeIPA 4.6.5-11.el7.centos.x86_64, fully updated from update repo on a CentOS7 x64 server, it appears that it is totally impossible to establish a trust with an AD running on local AD servers, we did it a few times ago with exactly the same distribution and had really no problem, we tried to completely reinstall the machine and the IPA wit always the same results,
ipa: ERROR: CIFS server communication error: code "3221225506", message "{Access Denied} A process has requested access to an object but has not been granted those access rights." (both may be "None")
Could someone point me to the direction to look for, because we are going nuts on this ?
We found some tips in the /var/log/httpd/errors, but nothing seems to provide sufficient infos...
[Wed Oct 02 12:54:57.868830 2019] [:error] [pid 2036] ipa: INFO: [jsonserver_session] admin(a)DOMAIN.INTRA: trust_add/1(u'domain.intra', trust_type=u'ad', realm_admin=u'admin', realm_passwd=u'********', bidirectional=True, version=u'2.231'): RemoteRetrieveError
The IPA server and the AD servers are in the same VLan with no firewall between them
samba version on the IPA server is the latest available: 4.9.1-6.el7.noarch
Thanks for your help...
3 years, 11 months