FreeIPA 4.8.9 released
by Alexander Bokovoy
The FreeIPA team would like to announce FreeIPA 4.8.9 release!
It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora distributions will be available from the official repository
soon.
== Highlights in 4.8.9
* 5011: [RFE] Forward CA requests to dogtag or helper by GSSAPI
* 7137: [RFE]: Able to browse different links from IPA web gui in new
tabs
* 8129: Tests: Replace paramiko with OpenSSH
Paramiko is not compatible with FIPS mode, therefore convert most
tests to using ssh directly. The only non-converted test is the
2-prompt OTP test because sshpass does not support 2-prompt password
authentication ( https://pagure.io/freeipa/issue/8431 ).
* 8151: test_commands timing-out
Re-enable test_sss_ssh_authorizedkeys ; add -v to ssh in order to
get debug information if this test fails or stalls again. The test
was run 16 times without a failure before re-enabling it.
* 8189: NIghtly test failure in test_integration/test_nfs.py::TestIpaClientAutomountFileRestore::test_nsswitch_backup_restore_sssd
Previously, ipa-client-installation saved the pre-install state
using "authselect current" command and the uninstallation reverted
to the same authselect state. In cases where the system was
installed using authconfig instead of authselect, the uninstallation
was unable to revert to the same state and picked "sssd"'s
authselect profile instead. Now, the client installation relies on
the backup functionality of authselect and is able to revert to the
exact pre-install state
* 8304: [fed32] client-install does not properly set
ChallengeResponseAuthentication yes in sshd conf
ipa-client-installation now writes the sshd configuration to the
drop-in directory /etc/ssh/sshd_config.d/, in the 04-ipa.conf
snippet, thus ensuring that the setting
"ChallengeResponseAuthentication yes" take precedence.
* 8335: [WebUI] manage IPA resources as a user from a trusted Active
Directory domain
When users from trusted Active Directory domains have permissions to
manage IPA resources, they can do so through a Web UI management
console.
* 8374: EPN does not ship its default configuration ( /etc/ipa/epn.conf) in freeipa-client-epn
EPN did not ship any configuration file. This was an oversight, but
the tool itself would work fine as it had sane defaults ; moreover,
the man page for the configuration file was present.
* 8391: Remove dnf workaround from test_epn.y
The new PR-CI images are cleaner and do not need the *epn* packages
to be uninstalled/reinstalled.
* 8401: Create platform definitions for freeipa-container
ipaplatform now provides container platform flavors for
freeipa/freeipa-container
* 8432: test failure in test_commands.py::TestIPACommand::test_login_wrong_password:
AssertionError
Sometimes test_login_wrong_password fails because the log window the
string message is searched in is too narrow. Broaden the window by
looking at the past 10 seconds.
* 8444: EPN: enhance input validation
Various input validation checks were added to EPN.
* 8445: EPN: '[Errno 111] Connection refused' when the SMTP is down
EPN now displays a proper message if the configured SMTP server
cannot be contacted.
* 8449: EPN: enhance CLI option tests
EPN: enhance existing tests for --dry-run, --from-nbdays and
--to-nbdays.
=== Enhancements
=== Known Issues
=== Bug fixes
FreeIPA 4.8.9 is a stabilization release for the features delivered as a
part of 4.8 version series.
There are more than 50 bug-fixes details of which can be seen in the
list of resolved tickets below.
== Upgrading
Upgrade instructions are available on Upgrade page.
== Feedback
Please provide comments, bugs and other feedback via the freeipa-users
mailing list (https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...)
or #freeipa channel on Freenode.
== Resolved tickets
* https://pagure.io/freeipa/issue/5011[#5011]
(https://bugzilla.redhat.com/show_bug.cgi?id=1527185[rhbz#1527185])
[RFE] Forward CA requests to dogtag or helper by GSSAPI
* https://pagure.io/freeipa/issue/5628[#5628] webui: Unclear(UX) purpose
of OTP field in password reset form on login
* https://pagure.io/freeipa/issue/7137[#7137]
(https://bugzilla.redhat.com/show_bug.cgi?id=1484088[rhbz#1484088])
[RFE]: Able to browse different links from IPA web gui in new tabs
* https://pagure.io/freeipa/issue/8129[#8129] Tests: Replace paramiko
with OpenSSH
* https://pagure.io/freeipa/issue/8151[#8151] test_commands timing-out
* https://pagure.io/freeipa/issue/8189[#8189]
(https://bugzilla.redhat.com/show_bug.cgi?id=1810179[rhbz#1810179])
Nightly test failure in
test_integration/test_nfs.py::TestIpaClientAutomountFileRestore::test_nsswitch_backup_restore_sssd
* https://pagure.io/freeipa/issue/8300[#8300] Replace uglify-js with
python3-rjsmin
* https://pagure.io/freeipa/issue/8304[#8304] [fed32] client-install
does not properly set ChallengeResponseAuthentication yes in sshd conf
* https://pagure.io/freeipa/issue/8326[#8326] CVE-2020-10747
* https://pagure.io/freeipa/issue/8335[#8335] [WebUI] manage IPA
resources as a user from a trusted Active Directory domain
* https://pagure.io/freeipa/issue/8336[#8336] [WebUI] "User attributes
for SMB services" section always shown
* https://pagure.io/freeipa/issue/8364[#8364] Nightly test failure while
establishing trust: Cannot find specified domain or server name
* https://pagure.io/freeipa/issue/8366[#8366] CA-less replica deployment
fails with --setup-ca
* https://pagure.io/freeipa/issue/8367[#8367] IPA-EPN fails to build in
ONLY_CLIENT mode
* https://pagure.io/freeipa/issue/8368[#8368]
(https://bugzilla.redhat.com/show_bug.cgi?id=1846349[rhbz#1846349])
cannot issue certs with multiple IP addresses corresponding to different
hosts
* https://pagure.io/freeipa/issue/8369[#8369] cert_find returns "CA not
configured" in CA-less install
* https://pagure.io/freeipa/issue/8370[#8370] ipa-join does not set
nshardwareplatform and nsosversion
* https://pagure.io/freeipa/issue/8371[#8371] Nightly test failure
[testing_master_testing] in
test_integration/test_idviews.py::TestCertsInIDOverrides
* https://pagure.io/freeipa/issue/8372[#8372]
(https://bugzilla.redhat.com/show_bug.cgi?id=1849914[rhbz#1849914])
FreeIPA - Utilize 256-bit AJP connector passwords
* https://pagure.io/freeipa/issue/8374[#8374]
(https://bugzilla.redhat.com/show_bug.cgi?id=1847999[rhbz#1847999]) EPN
does not ship its default configuration ( /etc/ipa/epn.conf ) in
freeipa-client-epn
* https://pagure.io/freeipa/issue/8377[#8377] Nightly test failure
(timeout) in test_caless_TestReplicaInstall
* https://pagure.io/freeipa/issue/8379[#8379] Nightly test failure
[testing_master_pki] while installing CA replica
* https://pagure.io/freeipa/issue/8381[#8381] Nightly test failure in
test_webui/test_loginscreen.py::TestLoginScreen::test_login_view
* https://pagure.io/freeipa/issue/8384[#8384] Provide reliable way to
know if a server installation is complete
* https://pagure.io/freeipa/issue/8388[#8388] Make help() on plugins
more useful
* https://pagure.io/freeipa/issue/8391[#8391] Remove dnf workaround from
test_epn.py
* https://pagure.io/freeipa/issue/8395[#8395] selinux don't audit rules
deny fetching trust topology
* https://pagure.io/freeipa/issue/8396[#8396] [WebUI] Font type of
"Enabled" column in user search facet wrong
* https://pagure.io/freeipa/issue/8399[#8399] certmonger attempts to add
LWCA tracking requests on non-CA server.
* https://pagure.io/freeipa/issue/8400[#8400] sshd template file is
installed in a wrong (server) location while used by the client side
* https://pagure.io/freeipa/issue/8401[#8401] Create platform
definitions for freeipa-container
* https://pagure.io/freeipa/issue/8403[#8403] Add option to add ipaapi
user as an allowed uid for ifp in /etc/sssd/sssd.conf when running
ipa-replica-install
* https://pagure.io/freeipa/issue/8407[#8407] Support changelog
integrated into main database
* https://pagure.io/freeipa/issue/8412[#8412]
(https://bugzilla.redhat.com/show_bug.cgi?id=1857157[rhbz#1857157]) AVC:
httpd cannot connect to ipa-custodia.sock
* https://pagure.io/freeipa/issue/8413[#8413] Nightly test failure in
test_integration/test_replica_promotion.py::TestUnprivilegedUserPermissions::test_sssd_config_allows_ipaapi_access_to_ifp
* https://pagure.io/freeipa/issue/8414[#8414] Nightly test failure in
test_integration/test_replica_promotion.py::TestReplicaPromotionLevel1::test_sssd_config_allows_ipaapi_access_to_ifp
* https://pagure.io/freeipa/issue/8416[#8416] [WebUI] Error while adding
user ID overrides to group
* https://pagure.io/freeipa/issue/8419[#8419] Azure is reporting a slew
of new no-member lint errors
* https://pagure.io/freeipa/issue/8425[#8425] Nightly test failure in
test_cert.test_cert.TestInstallMasterClient (certmonger timeout)
* https://pagure.io/freeipa/issue/8428[#8428] [ipatests] fails due to
new python-cryptography 3.0
* https://pagure.io/freeipa/issue/8429[#8429] Add fips-mode-setup to
ipaplatform.paths
* https://pagure.io/freeipa/issue/8432[#8432] test failure in
test_commands.py::TestIPACommand::test_login_wrong_password:
AssertionError
* https://pagure.io/freeipa/issue/8435[#8435] [ipatests] failures due to
new Pytest6.0 (pypi part)
* https://pagure.io/freeipa/issue/8437[#8437] unit tests for
ipa-extdom-extop are failing in Fedora 33
* https://pagure.io/freeipa/issue/8439[#8439] Nightly test failure in
test_integration/test_ipahealthcheck.py::TestIpaHealthCheck::test_ipa_healthcheck_expiring
* https://pagure.io/freeipa/issue/8440[#8440]
(https://bugzilla.redhat.com/show_bug.cgi?id=1863616[rhbz#1863616])
CA-less install does not set required permissions on KDC certificate
* https://pagure.io/freeipa/issue/8441[#8441]
(https://bugzilla.redhat.com/show_bug.cgi?id=1870202[rhbz#1870202]) File
permissions of /etc/ipa/ca.crt differ between CA-ful and CA-less
* https://pagure.io/freeipa/issue/8442[#8442] [pylint] warnings/errors
against pylint 2.5.3
* https://pagure.io/freeipa/issue/8444[#8444]
(https://bugzilla.redhat.com/show_bug.cgi?id=1866291[rhbz#1866291]) EPN:
enhance input validation
* https://pagure.io/freeipa/issue/8445[#8445]
(https://bugzilla.redhat.com/show_bug.cgi?id=1863079[rhbz#1863079]) EPN:
'[Errno 111] Connection refused' when the SMTP is down
* https://pagure.io/freeipa/issue/8447[#8447] Nightly test failure in
test_integration/test_ipahealthcheck/TestIpaHealthCheckWithoutDNS
* https://pagure.io/freeipa/issue/8449[#8449]
(https://bugzilla.redhat.com/show_bug.cgi?id=1866291[rhbz#1866291]) EPN:
enhance CLI option tests
* https://pagure.io/freeipa/issue/8456[#8456] Need new aci's for the new
replication changelog entries
* https://pagure.io/freeipa/issue/8459[#8459] [upgrade] handle missing
openssh-clients
* https://pagure.io/freeipa/issue/8461[#8461] [ALTLinux] server
uninstall error on missing /var/lib/samba
* https://pagure.io/freeipa/issue/8463[#8463] Nightly test failure in
test_ipahealthcheck.py::TestIpaHealthCheck::test_ipa_healthcheck_expiring
* https://pagure.io/freeipa/issue/8464[#8464] Increase replication
changelog trimming interval
== Detailed changelog since 4.8.8
Detailed changelog is available at https://www.freeipa.org/page/Releases/4.8.9#Detailed_changelog_since_4.8.8
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3 years, 8 months
Installation with external CA - signed cert 'Not a CA'
by John Spooner
Hello,
I have been tasked with installing FreeIPA in our environment to help manage certificates for Postgres, NGINX and RabbitMQ. I am completely new to the administrative side of certificates, so I may have made some incorrect assumptions. We have decided to use LetsEncrypt as our external CA, so I ran the FreeIPA install:
sudo ipa-server-install --realm MYDOMAIN.COM --domain mydomain.com --setup-dns --auto-forwarders --allow-zone-overlap --external-ca --ca-subject "CN=mydomain.com"
This produced a CSR which I have had signed by LetsEncrypt (I also tried to sign the CSR with with gethttpsforfree, but got the same results):
sudo certbot --csr /root/ipa.csr --preferred-challenges dns certonly
As I understand it, it should be as simple at this point to rerun ipa-server-install with external-cert-file arguments for the signed CSR file and the existing trust chain.
sudo ipa-server-install --external-cert-file=/path/to/file/signed_csr.pem --external-cert-file=/etc/letsencrypt/live/mydomain.com/fullchain.pem
This results in an error I can't wrap my head around:
ERROR: CA Certificate CN=mydomain.com in <signed CSR file>, <trust chain file> is not valid: not a CA certificate.
After getting this certificate chain in FreeIPA I plan on creating a couple more layers of intermediate certificates and, eventually, create root certificates for the individual services. What assumption am I making that is causing this process to go sideways? I could not really find anything in the volumes of documentation I have gone through so far.
3 years, 8 months
[ipa_pam_access_handler_done] (0x0020): No HBAC rules find, denying access
by David McDaniel
Joined new ipa-client
RHEL 7.8
IPA VERSION: 4.6.6
Have many ipa joined hosts on same vers, using same sssd.conf/krb5.conf configs and member of same HBAC group associated with same HBAC rule with no issues; only this one host
Same issue for both IPA & AD users for this host
id & getent will pull IPA & AD users group memberships without issue from said host
Kinit works for IPA & AD users without issue from said host
Testing with `ipa hbactest` outputs desired results for sshd & login services for this host
SSH is a no go for both IPA & AD users, with the below logged each time an SSH attempt is made.
[sssd[be[ipa.domain.com]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [ad-user(a)example.com]
[sssd[be[ipa.domain.com]]] [sdap_account_expired_rhds] (0x4000): Account for user [ad-user(a)example.com] is not locked.
[sssd[be[ipa.domain.com]]] [sdap_account_expired] (0x0400): IPA access control succeeded, checking AD access control
[sssd[be[ipa.domain.com]]] [sdap_account_expired_ad] (0x0400): Performing AD access check for user [ad-user(a)example.com]
[sssd[be[ipa.domain.com]]] [sdap_account_expired_ad] (0x4000): User account control for user [ad-user(a)example.com] is [200].
[sssd[be[ipa.domain.com]]] [sdap_account_expired_ad] (0x4000): Expiration time for user [ad-user(a)example.com] is [9223372036854775807].
[sssd[be[ipa.domain.com]]] [ipa_fetch_hbac_send] (0x4000): Connection status is [online].
[sssd[be[ipa.domain.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
[sssd[be[ipa.domain.com]]] [sdap_print_server] (0x2000): Searching <freeipa-master-ip-address>:389
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=freeipa-client.ipa.domain.com))][cn=accounts,dc=ipa,dc=domain,dc=com].
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostname]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSshPubKey]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 14
[sssd[be[ipa.domain.com]]] [sdap_op_add] (0x2000): New operation 14 timeout 60
[sssd[be[ipa.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55fcd97b0b90], connected[1], ops[0x55fcd979c7e0], ldap[0x55fcd9781e30]
[sssd[be[ipa.domain.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
[sssd[be[ipa.domain.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
[sssd[be[ipa.domain.com]]] [sdap_get_generic_op_finished] (0x2000): Total count [0]
[sssd[be[ipa.domain.com]]] [sdap_op_destructor] (0x2000): Operation 14 finished
[sssd[be[ipa.domain.com]]] [sdap_id_op_done] (0x4000): releasing operation connection
[sssd[be[ipa.domain.com]]] [ipa_pam_access_handler_done] (0x0020): No HBAC rules find, denying access
[sssd[be[ipa.domain.com]]] [dp_req_done] (0x0400): DP Request [PAM Account #11]: Request handler finished [0]: Success
[sssd[be[ipa.domain.com]]] [_dp_req_recv] (0x0400): DP Request [PAM Account #11]: Receiving request data.
[sssd[be[ipa.domain.com]]] [dp_req_destructor] (0x0400): DP Request [PAM Account #11]: Request removed.
[sssd[be[ipa.domain.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
[sssd[be[ipa.domain.com]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #11]: Sending result [6][example.com]
[sssd[be[ipa.domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x55fcd97b0b90], connected[1], ops[(nil)], ldap[0x55fcd9781e30]
[sssd[be[ipa.domain.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
sshd[2750]: pam_sss(sshd:account): Access denied for user ad-user(a)example.com: 6 (Permission denied)
$ ipa hbactest
User name: ad-user(a)example.com
Target host: freeipa-client.ipa.domain.com
Service: sshd
--------------------
Access granted: True
--------------------
Matched rules: allow_admin_all
Any help is much appreciated...stuck
3 years, 8 months
Re: pki-tomcatd not starting
by Scott Z.
... and just to show that I am a man of my word...
[cid:e4d4f3fa-c56a-4e3a-b5af-12ed7a7d90ab]
Thanks again for all the help guys!
Scott
________________________________
From: Scott Z. <sudz28(a)hotmail.com>
Sent: Thursday, August 13, 2020 9:58 AM
To: Fraser Tweedale <ftweedal(a)redhat.com>; FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Rob Crittenden <rcritten(a)redhat.com>; Florence Blanc-Renaud <flo(a)redhat.com>; Alexander Scheel <ascheel(a)redhat.com>
Subject: Re: [Freeipa-users] Re: pki-tomcatd not starting
Taking it from the top again this morning 🙂
1) Stopped NTPD
2) Checked status of certmonger (running, several "Error 60 connecting to <server>: Peer certificate cannot be authenticated with given CA certificates)
3) Checked that debug.level=0 in CS.cfg (it was already set there)
4) Checked the 'not after' dates for auditSigningCert, ocspSigningCert, subsystemSigningCert, and Server-Cert... all are still valid except for Server-Cert (Not After Sep. 26 2019), so I set the system date back to Sept. 25, 2019.
5) Stopped all ipa services (ipactl stop)
6) Restated IPA services manually in the specified order (dirsrv@domain, krb5kdc, kadmin, named-pkcs11, httpd, pki-tomcatd@pki-tomcat)
7) Checked the status of all those services to make sure they were showing the new, older date of Sept. 25, 2019.
8) Ran the curl command to make sure it would work (curl --cacert /etc/ipa/ca.crt -v https://`hostname`:8443/ca/ee/ca/getCertChain)
9) Ran "ipa-getcert resubmi -i <reqID>" for the Server-Cert cert-pki-ca cert I was trying to renew.
10) Ran "getcert list" a couple of times; first saw that it was showing "SUBMITTING", the it switched after several seconds to "POST_SAVED_CERT" - WOW!!! SOMETHING NEW! Then, a few seconds later still, it's showing as "MONITORING". Checking the "expires" date, it's FINALLY updated to Sept. 14, 2021!!!!!!
I cannot tell you how exciting this is for me. What a journey. Now, I assume I just need to "ipactl stop" and then "ipactl start", and all should be well I guess. I'm afraid to do it though, I'm scared of the cert reverting or something funky 🙁
________________________________
From: Fraser Tweedale <ftweedal(a)redhat.com>
Sent: Wednesday, August 12, 2020 6:02 PM
To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
Cc: Rob Crittenden <rcritten(a)redhat.com>; Florence Blanc-Renaud <flo(a)redhat.com>; Alexander Scheel <ascheel(a)redhat.com>; Scott Z. <sudz28(a)hotmail.com>
Subject: Re: [Freeipa-users] Re: pki-tomcatd not starting
On Thu, Aug 13, 2020 at 02:43:33AM +0000, Scott Z. via FreeIPA-users wrote:
> Just in case it helps to narrow things down a bit or answers questions...
> 1) The problem IdM server is the CA Master as far as I can tell (ran the command "ipa config-show", saw that the IPA CA renewal master: was the same server with the bad cert.
>
In any case, the CA renewal master setting shouldn't affect renewal
of the Dogtag "Server-Cert cert-pki-ca" certificate. This is
because the TLS server certificates are not shared; each server
needs their own certificate.
> 2) Followed the steps in the Red Hat knowledge article at https://access.redhat.com/solutions/3357261
> 3) As noted at the bottom of that page, I had pretty good success up until the end.
>
> My current status is that I've done an ipactl restart --ignore-service-failure, my timedate value is once again current, and when I do a "getcert list" I see the offending cert (Server-Cert cert-pki-ca) listed as CA_UNREACHABLE, with a ca-error value of Internal Error and of course still showing an expiration date of Sep. 26, 2019.
>
> If I do a status check on the certmonger service I see lots of "Internal Error" messages along with "Unspecified GSS failure. Minor code may provide more information, Minor (2529639068): Cannot contact any KDC for realm '<domain>'."
>
Was the KDC running at the time those certmonger GSS errors were
produced? That could explain this error.
It would help to see the /etc/pki/pki-tomcat/ca/debug log:
- for the startup failures, that may indicate why Dogtag does not
start up properly
- and for the time period during which renewal of the problematic
certificate is attempted
Ensure PKI debug logging is at a verbose level. In
/etc/pki/pki-tomcat/ca/CS.cfg, change the config:
debug.level=0
It is counterintuitive but /lower/ number = higher verbosity.
It would help to see certmonger journal output (`journalctl -u
certmonger') covering the time period of the renewal attempt.
Also, just seeing the all the certificates in the various location
(especially Dogtag and dirsrv NSSDBs, including the CA certificates)
would be helpful.
I understand that you have security policies that may prevent you
share all this in a public list (or making extra work for you to
redact sensitive data). If it would allow you to share more
logs/data, perhaps you could consider a commercial support
subscription with Red Hat.
Thanks,
Fraser
3 years, 8 months
Issues with SSO from AD Clients
by Hannes Eberhardt
Hi,
I am currently evaluating FreeIPA for a deployment in our department and I am running into problems with GSSAPI authentication from AD managed Windows clients to IPA managed servers.
The situation:
We do want to build an IPA domain for our departments' Linux infrastructure. Our plan is to create a trust between our IPA domain to the existing Active Directory so that we can continue to use our regular office workstations for managing our systems.
So far so good, we got the trust set up together with our IT department and username/password authentication works as expected.
The only issue I am facing right now is that we can't do a GSSAPI based authentication to a FreeIPA client system.
We are running FreeIPA under CentOS 8 from the official repositories. Version 4.8.4.
Active Directory runs on Server 2016 (Forest Functional Level and Domain Functional Level are both 2012R2).
We (our department and the rest of the company) do have completely separated DNS domains. Let's say the AD is running within the domain example.int and realm EXAMPLE.INT, our primary DNS domain is example.com and our Kerberos Realm is IDM.EXAMPLE.COM. FreeIPA is of course also running the authoritative nameserver for idm.example.com.
As to the IPA clients:
We currently do not plan to enroll our IPA clients directly underneath the idm.example.com domain, but under serveral (sub-)domains under example.com (e.g. dc.example.com / site1.example.com / staging.example.com).
And here comes the pitfall: If I enroll a FreeIPA client directly the subdomain idm.example.com (e.g ipaclient.idm.example.com) we are able to do a proper GSSAPI authentication from our AD managed workstation. If we do enroll them in any other subdomain. The AD clients or AD DCs are not able to map the domains to the right kerberos realms.
We checked the suffix routing at the AD side of the trust and noticed, that there is only a route with the domain *.idm.example.com.
So what I did and still are trying to do are basically two things:
First thing:
In my opiniont it would be the cleanest solution to just get the whole example.com domain routed to our FreeIPA system. So what I did was:
I deleted the trust again and added the entry example.com to the 'Realm Domains' tab in the Web UI. I am not sure if this is the right place to put it, because after this I was not able to establish a new trust, it just failed with the following in the httpd error_log.
[Wed Aug 12 09:32:40.973936 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] ipa: ERROR: non-public: NTSTATUSError: (3221225485, 'An invalid parameter was passed to a service or function.')
[Wed Aug 12 09:32:40.973975 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] Traceback (most recent call last):
[Wed Aug 12 09:32:40.973977 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/rpcserver.py", line 368, in wsgi_execute
[Wed Aug 12 09:32:40.973979 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] result = command(*args, **options)
[Wed Aug 12 09:32:40.973981 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 450, in __call__
[Wed Aug 12 09:32:40.973983 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] return self.__do_call(*args, **options)
[Wed Aug 12 09:32:40.973985 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 478, in __do_call
[Wed Aug 12 09:32:40.973987 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] ret = self.run(*args, **options)
[Wed Aug 12 09:32:40.973989 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipalib/frontend.py", line 800, in run
[Wed Aug 12 09:32:40.973991 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] return self.execute(*args, **options)
[Wed Aug 12 09:32:40.973992 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 758, in execute
[Wed Aug 12 09:32:40.974009 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] result = self.execute_ad(full_join, *keys, **options)
[Wed Aug 12 09:32:40.974011 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/plugins/trust.py", line 1019, in execute_ad
[Wed Aug 12 09:32:40.974013 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] trust_type
[Wed Aug 12 09:32:40.974014 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1732, in join_ad_full_credentials
[Wed Aug 12 09:32:40.974016 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] trust_type, trust_external)
[Wed Aug 12 09:32:40.974018 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1415, in establish_trust
[Wed Aug 12 09:32:40.974020 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] self.update_ftinfo(another_domain)
[Wed Aug 12 09:32:40.974022 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] File "/usr/lib/python3.6/site-packages/ipaserver/dcerpc.py", line 1286, in update_ftinfo
[Wed Aug 12 09:32:40.974024 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] ftinfo, 0)
[Wed Aug 12 09:32:40.974027 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760] samba.NTSTATUSError: (3221225485, 'An invalid parameter was passed to a service or function.')
[Wed Aug 12 09:32:40.974032 2020] [wsgi:error] [pid 2877:tid 140320305358592] [remote 10.100.7.223:59760]
The second thing:
I found an older thread that stated one could configure domain-to-realm maps on each client (via GPO).
This is something I am still troublshooting because I first tried to put the mapping in my local registry, but this seems to not work. I have to check this again together with a colleague of our IT department.
But this solution is definitly not my first choice as it forces the clients to do the mapping, as we are going to deliver services to the complete company this would mean our IT must roll out this GPO to all systems. I would rather try to get our whole domain mapped to our realm on DC side.
To get to the actual question:
Is Realm Domains the right place to put our complete domain or is this a bug in FreeIPA?
An if it is not the right place: Where can I put it then?
Thanks for your help,
Hannes
3 years, 8 months
Re: pki-tomcatd not starting
by Fraser Tweedale
On Thu, Aug 13, 2020 at 02:43:33AM +0000, Scott Z. via FreeIPA-users wrote:
> Just in case it helps to narrow things down a bit or answers questions...
> 1) The problem IdM server is the CA Master as far as I can tell (ran the command "ipa config-show", saw that the IPA CA renewal master: was the same server with the bad cert.
>
In any case, the CA renewal master setting shouldn't affect renewal
of the Dogtag "Server-Cert cert-pki-ca" certificate. This is
because the TLS server certificates are not shared; each server
needs their own certificate.
> 2) Followed the steps in the Red Hat knowledge article at https://access.redhat.com/solutions/3357261
> 3) As noted at the bottom of that page, I had pretty good success up until the end.
>
> My current status is that I've done an ipactl restart --ignore-service-failure, my timedate value is once again current, and when I do a "getcert list" I see the offending cert (Server-Cert cert-pki-ca) listed as CA_UNREACHABLE, with a ca-error value of Internal Error and of course still showing an expiration date of Sep. 26, 2019.
>
> If I do a status check on the certmonger service I see lots of "Internal Error" messages along with "Unspecified GSS failure. Minor code may provide more information, Minor (2529639068): Cannot contact any KDC for realm '<domain>'."
>
Was the KDC running at the time those certmonger GSS errors were
produced? That could explain this error.
It would help to see the /etc/pki/pki-tomcat/ca/debug log:
- for the startup failures, that may indicate why Dogtag does not
start up properly
- and for the time period during which renewal of the problematic
certificate is attempted
Ensure PKI debug logging is at a verbose level. In
/etc/pki/pki-tomcat/ca/CS.cfg, change the config:
debug.level=0
It is counterintuitive but /lower/ number = higher verbosity.
It would help to see certmonger journal output (`journalctl -u
certmonger') covering the time period of the renewal attempt.
Also, just seeing the all the certificates in the various location
(especially Dogtag and dirsrv NSSDBs, including the CA certificates)
would be helpful.
I understand that you have security policies that may prevent you
share all this in a public list (or making extra work for you to
redact sensitive data). If it would allow you to share more
logs/data, perhaps you could consider a commercial support
subscription with Red Hat.
Thanks,
Fraser
3 years, 8 months
Re: pki-tomcatd not starting
by Jochen Kellner
"Scott Z. via FreeIPA-users" <freeipa-users(a)lists.fedorahosted.org>
writes:
> My current status is that I've done an ipactl restart
> --ignore-service-failure, my timedate value is once again current,
Your IDM server has the ntp role enables, so you can't go back in time
and user "ipactl start", because that is setting the time to current
again. So do the following:
- ipctl stop
- stop ntp if it is still running
- go back in time
- start each service manually that ipactl would do but skip ntp.
See if the CA is running. Then restart certmonger or resubmit the
requests. That should work.
Jochen
--
This space is intentionally left blank.
3 years, 8 months
Re: pki-tomcatd not starting
by Rob Crittenden
Scott Z. via FreeIPA-users wrote:
> Just so I'm not confusing the various servers and roles they play in
> case it impacts what I'm doing (also, in case it matters, these are
> VMs), so I ran the command "ipa config-show" and here is what I got back:
> IPA masters: <all 4 of my IdM servers in this environment>
> IPA CA servers: <all 4 of my IdM servers in this environment>
> IPA NTP servers: <all 4 of my IdM servers in this environment>
> IPA CA renewal master: <problemserver.domain>
>
> To take things 'from the top' I went ahead and did a full-on "ipactl
> stop" and then "ipactl start --ignore-service-failure". This of course
> resets the date to present time. After it started (minus pki-tomcat
> that is) I did a "kinit admin" and then "getcert list". This list now
> shows the 'bad' cert with the expired date from last September and the
> status now is MONITORING. Hopeful, I ran "ipa-getcert resubmit -i
> <reqid>" but this didn't seem to have any affect.
>
> Is there any particular place to look log-wise to see what is happening
> when I try to do a 'getcert resubmit' or 'ipa-getcert resubmit'
> command? They seem to go through, but there's no change in status to
> the certificate (well, it changes from MONITORING to SUBMITTING but then
> right back to MONITORING with no change to the expiration) so I'm
> wondering if I can see where the request is either dying or being
> rejected or what.
>
> If I read things correctly, the bad server with the expired cert *is*
> the CA renewal server, correct? So it needs to make a request to itself
> to renew the expired cert... which I'm assuming it's having a problem
> doing because its own cert is already expired?
Exactly. The tomcat TLS cert is expired so the CA is likely not starting
at all. When you go back in time I'm assuming there is no time overlap
between the tomcat Server-Cert and the other CA subsystem certs so you
can either have tomcat work with TLS or the CA but not both.
If you have the ipa-cert-fix command try that. It can do offline renewals.
I'm cc'ing a CA developer, maybe he'll have some additional ideas.
rob
> Scott
>
> ------------------------------------------------------------------------
> *From:* Rob Crittenden <rcritten(a)redhat.com>
> *Sent:* Tuesday, August 11, 2020 9:07 AM
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>;
> Florence Blanc-Renaud <flo(a)redhat.com>
> *Cc:* Scott Z. <sudz28(a)hotmail.com>
> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>
> Scott Z. via FreeIPA-users wrote:
>> Adding the "NSSEnforceValidCerts off" definitely got me past the HTTPD
>> error. It started up and then I ran the systemctl start
>> pki-tomcatd@pki-tomcat which seemed to start up without any errors (it
>> didn't throw any on the command line), but checking the debug log I see
>> I'm still getting the same, original "Peer's Certificate has expired"
>> message for "Server-Cert cert-pki-ca". I just can't win 🙂
>> It's expired, I know it's expired, why does FreeIPA fight me so hard on
>> just trying to renew it?! LOL!
>>
>> Just for fun I then ran the "getcert renew -i <reqid>" command. But per
>> "getcert list", it's still showing as CA_UNREACHABLE and Internal Error.
>
> The CA is a servlet so tomcat can start without the CA starting. I'd
> look in the CA logs under /var/log/pki-tomcat/
>
> certmonger logs to syslog so use journalctl to see if it provided any
> more details on the failure, but it sounds like an issue with the CA.
>
> rob
>
>> Scott
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Rob Crittenden <rcritten(a)redhat.com>
>> *Sent:* Tuesday, August 11, 2020 8:07 AM
>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>;
>> Florence Blanc-Renaud <flo(a)redhat.com>
>> *Cc:* Scott Z. <sudz28(a)hotmail.com>
>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>
>> Scott Z. via FreeIPA-users wrote:
>>> Forgot to reply again - ugh!
>>> Hmmmm, so my domain is actually "idm.project.its.srv2", so I was
>>> literally typing "systemctl start dirsrv(a)idm.project.its.srv2"Â I see
>>> what you're saying, I need to put in dashes instead of periods! DOH!Â
>>> Done. Moving on...
>>> 4) Ran systemctl start krb5kdc
>>> 5) Ran systemctl start kadmin
>>> 6) Ran systemctl start named-pkcs11
>>> 7) Ran systemctl start httpd - got an error here, nothing really
>>> useful in the logs or journalctl, it says it's starting the Apache HTTP
>>> server, then throws "httpd.service: main process exited, code=exited,
>>> status=1/FAILURE", and "Failed to start The Apache HTTP Server".Â
>>> Finally there is a mention of 'too much time skew'. I assume the
>>> problem is that I'm trying to start HTTPD on a system where the date is
>>> almost a year old.Â
>>> Although now that I'm looking at /var/log/httpd/error_log, I see mention
>>> of "SSL Library Error: -8181 Certificate has expired". CERTIFICATES!!!
>>> "Unable to verify certificate 'Server-Cert'. Add "NSSEnfroceValideCerts
>>> off" to nss.conf so the server can start until the problem can be
>>> resolved", so maybe I'll try that.
>>
>> That can work, just remember to revert it, but it just bypasses the
>> start up check. Clients will still require cert validity.
>>
>> I don't think it will matter either way as the CA certs renew directly
>> against the CA so Apache not running shouldn't be an issue.
>>
>> rob
>>
>>> Scott
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>> *Sent:* Tuesday, August 11, 2020 6:55 AM
>>> *To:* Scott Z. <sudz28(a)hotmail.com>; FreeIPA users list
>>> <freeipa-users(a)lists.fedorahosted.org>; Rob Crittenden <rcritten(a)redhat.com>
>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>> Â
>>> On 8/11/20 6:39 PM, Scott Z. wrote:
>>>> First thing I did when I logged in this morning (I'm on Hawaii Standard
>>>> Time) was run "ipactl status". The return was "Directory Services:
>>>> STOPPED", and "Directory Service must running in order to obtain status
>>>> of other services".
>>>> 1) Ran "getcert list", and it shows the 9 certs being tracked (all the
>>>> previous 8 plus the 1 expired guy I added yesterday). All look good
>>>> except of course my problem child, who's status is CA_UNREACHABLE and
>>>> ca-error is Internal error.
>>>> 2) Ran "ipa stop", looks like all service stopped successfully.
>>>> 2) Changed date back to Sept. 1, 2019.
>>>> 3) Ran the "systemctl start dirsrv@<domain> and got back "Job for
>>>> dirsrv@<domain> failed because a configured resource limit was exceeded."
>>>> Â Â Â Â a. when I looked at "journalctl -xe", I just see a couple of
>>>> messages that don't tell me much... "Registered Authentication Agent for
>>>> unix-process:<blahblah>", followed by "Failed to load environment files:
>>>> no such files or directory". Then, "dirsrv@<domain> filed to run
>>>> 'start-pre' task: No such files or directory" and finally "Failed to
>>>> start 389 Directory Server <domain>".
>>>>
>>> If your domain is domain.com, you need to run
>>> systemctl start dirsrv@DOMAIN-COM
>>>
>>> I suspect that you ran instead systemctl start dirsrv@slapd-DOMAIN-COM
>>> which would produce the error you're seeing.
>>>
>>> flo
>>>
>>>> Not sure now how to proceed at this point.
>>>>
>>>> BTW, I have decided that once I get through this slog and have a working
>>>> server again, I'm going to donate $50 to the Hawaiian Food Bank or the
>>>> charity of your choice in appreciation.
>>>> Scott
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>> *Sent:* Monday, August 10, 2020 8:55 PM
>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; Rob
>>>> Crittenden <rcritten(a)redhat.com>
>>>> *Cc:* Scott Z. <sudz28(a)hotmail.com>
>>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>>> On 8/10/20 11:46 PM, Scott Z. via FreeIPA-users wrote:
>>>>> I stopped the ntp service with the command "timedatectl set_ntp 0"
>>>>> I set the new date to be Sept. 1st, 2019 with "timedatectl set-time
>>>>> 2019-09-01"
>>>>> I waiting a minute and then checked with the "date" command; the problem
>>>>> server believes it is Sept. 1st, 2019.
>>>>>
>>>>> Now when you say 'restart services', I assume you're only referring to
>>>>> the ipactl services? In that case I ran "ipactl start
>>>>> --ignore-service-failures". Interestingly, when I ran this command it
>>>>> not only failed to start pki-tomcatd (which I expected), but actually
>>>>> reset the date back to the present/correct time and date. Thus, I
>>>>> re-ran the command to set it back to Sept. 1st, 2019.
>>>>>
>>>> If the server was configured with ntp, "ipactl start" will also restart
>>>> ntpd. You need to do the following:
>>>> ipactl stop
>>>> change date in the past
>>>> systemctl start dirsrv@DOMAIN-COM (replace with your domain name)
>>>> systemctl start krb5kdc
>>>> systemctl start kadmin
>>>> systemctl start named-pkcs11 (if IPA is hosting the DNS server)
>>>> systemctl start httpd
>>>> systemctl start pki-tomcatd@pki-tomcat
>>>>
>>>> Then try getcert resubmit.
>>>>
>>>>> I then ran the "getcert resubmit -i <reqID> command. I just now went
>>>>> through these steps again, and it's showing "status: CA_UNREACHABLE" and
>>>>> "ca-error: Internal Error". Stuck now shows 'no'.
>>>>> Re-running "certutil -L -d /etc/pki/pki-tomcat/alias -n 'ServerCert
>>>>> cert-pki-ca' now yields a new error message, "certutil: could not find
>>>>> cert: ServerCert cert-pki-ca", and ": PR_FILE_NOT_FOUND_ERROR: File not
>>>>> found"
>>>> The cert nickname should contain a dash: "Server-Cert cert-pki-ca"
>>>>
>>>> HTH,
>>>> flo
>>>>>
>>>>> Many Mahalos for your continued support and patience!
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Rob Crittenden <rcritten(a)redhat.com>
>>>>> *Sent:* Monday, August 10, 2020 11:36 AM
>>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>;
>>>>> Florence Blanc-Renaud <flo(a)redhat.com>
>>>>> *Cc:* Scott Z. <sudz28(a)hotmail.com>
>>>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>>>> Scott Z. via FreeIPA-users wrote:
>>>>>> Whoops! Using the additional command to start tracking this paritcular
>>>>>> cert that you included in a different message, I got it in the "getcert"
>>>>>> list (with the "getcert start-tracking -n 'Server-Cert cert-pki-ca' -d
>>>>>> /etc/pki/pki-tomcat/alias -c dogtag-ipa-ca-renew-agent -B
>>>>>> /usr/libexec/ipa/certmonger/stop_pkicad -C
>>>>>> '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -P
>>>>>> <pin>" command).
>>>>>>
>>>>>> I have the date rolled back to Sept. 1st, 2019. I guess I have 'some'
>>>>>> progress now at least, but still have an issue; checking on the cert
>>>>>> with "getcert list -i <requestID>", it shows "status: CA_REJECTED", and
>>>>>> "stuck: yes".
>>>>>
>>>>> How did you roll the date back? Did you restart services? What date did
>>>>> you pick and does it overlap so that all certs are valid?
>>>>>
>>>>> rob
>>>>>
>>>>>>
>>>>>> Any additional thoughts or help would be greatly appreciated! And
>>>>>> thanks for the help so far.
>>>>>> Scott
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* Scott Z. via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
>>>>>> *Sent:* Monday, August 10, 2020 10:37 AM
>>>>>> *To:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>>>> *Cc:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>; Scott
>>>>>> Z. <sudz28(a)hotmail.com>
>>>>>> *Subject:* [Freeipa-users] Re: pki-tomcatd not starting
>>>>>> Â
>>>>>> Sorry, I didn't realize I had dropped the mailing list - my mistake!
>>>>>>
>>>>>> I backed up the files/directories you mentioned below, then I checked on
>>>>>> the ra-agent.pem to see if it was still valid (openssl x509 -in
>>>>>> /path/to/ra-agent.pem -text -noout), and the ra-agent.pem cert is indeed
>>>>>> currently valid (Not before: Aug 21 17:20:41 2019 GMT, Not After: Aug
>>>>>> 10 17:20:41 2021 GMT).
>>>>>>
>>>>>> Based on that information, and knowing that the bad cert is valid from
>>>>>> Oct. 6th 2017 to Sep. 26 2019, I'm going with Sept. 1st of this 2019
>>>>>> since all certs will see that date as valid.
>>>>>>
>>>>>> The only issue I have now is getting the request ID for the expired
>>>>>> cert; it doesn't show up in the list of certs when I do "getcert -list",
>>>>>> I can only see it by running "certutil -L -d
>>>>>> /var/lib/pki/pki-tomcat/ca/alias -n 'ServerCert cert-pki-ca'", and when
>>>>>> I run that it does not show any Request ID associated for it?
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>>>> *Sent:* Monday, August 10, 2020 8:45 AM
>>>>>> *To:* Scott Z. <sudz28(a)hotmail.com>
>>>>>> *Cc:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>>>>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>>>>> Â
>>>>>> Hi,
>>>>>>
>>>>>> re-adding the mailing list as the conversation could also help others.
>>>>>>
>>>>>> On 8/8/20 12:06 AM, Scott Z. wrote:
>>>>>>> I did notice when I compare it to another IdM server in the environment,
>>>>>>> if I do a "certutil -L -d /etc.httdp/alias" the non-working server has a
>>>>>>> <DOMAIN> IPA CA certificate and a Server-Cert, but the other one that
>>>>>>> I'm comparing against has a "Signing-Cert" certificate in addition. Is
>>>>>>> this because it's the 'Master' or whatever? Should my 'bad' server have
>>>>>>> this same Signing-Cert listed?
>>>>>>
>>>>>> /etc/httpd/alias only needs its own Server-Cert + IPA CA.
>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> *From:* Scott Z. <sudz28(a)hotmail.com>
>>>>>>> *Sent:* Friday, August 7, 2020 10:44 AM
>>>>>>> *To:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>>>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>>>>>> /"The interesting part is the list of expired certs on the failing node
>>>>>>> (is the RA cert /var/lib/ipa/ra-agent.pem expired?). Detailed
>>>>>>> instructions are available here:
>>>>>>> https://access.redhat.com/solutions/3357331 How do I manually renew
>>>>>>> Identity Management (IPA) certificates on RHEL7 after they have expired?
>>>>>>> (Replica IPA Server)"/
>>>>>>
>>>>>> Start by making a backup of /etc/dirsrv/slapd-*/*.db, /etc/httpd/alias,
>>>>>> /etc/pki/pki-tomcat/alias and /var/lib/ipa/ra-agent.* (the places where
>>>>>> the certificates are stored).
>>>>>>
>>>>>> If the RA cert is valid, you need to find a time window during which the
>>>>>> RA cert is already valid (date > notbefore) and the other certs are not
>>>>>> expired yet (date < notafter). When you have identified a proper date,
>>>>>> stop ntpd (or chronyd, depending on which service is used for time
>>>>>> synchronization), move the date back in time to the identified date,
>>>>>> start all the services except ntpd, then call "getcert resubmit -i
>>>>>> <request id>" for the expired cert(s).
>>>>>>
>>>>>> Check that the cert has been renewed with "getcert list -i <request
>>>>>> id>", the state should display MONITORING. When all the certs are good,
>>>>>> you can restart ntpd and the clock will go back to the current date.
>>>>>>
>>>>>> It's really important to find a date where all the certs are valid
>>>>>> because this ensures that the services are able to start and the RA cert
>>>>>> allows the authentication that is mandatory for certificate renewal.
>>>>>>
>>>>>> HTH,
>>>>>> flo
>>>>>>>
>>>>>>> Sadly, after I log in, it's only telling me that it's "Subscriber
>>>>>>> Exclusive Content". Not sure what happened with my account, I used to
>>>>>>> be able to access these docs with no problem but since I took a RHEL
>>>>>>> class a couple of weeks back now it's not working any more. I guess
>>>>>>> they did something to screw up my account when I took the class. Grrrrr!!!
>>>>>>> Scott
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>>>>> *Sent:* Thursday, August 6, 2020 2:46 AM
>>>>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>>>>>>> *Cc:* Scott Z. <sudz28(a)hotmail.com>
>>>>>>> *Subject:* Re: [Freeipa-users] Re: pki-tomcatd not starting
>>>>>>> On 8/6/20 12:53 AM, Scott Z. via FreeIPA-users wrote:
>>>>>>>> Thanks much for the assistance. Here is where I am with your suggestions:
>>>>>>>> 1) Checked on the cert with "certutil -L -d /etc/pki/pki-tomcat/alias -n
>>>>>>>> 'Server-Cert cert-pki-ca' and I see that the Validity is indeed old
>>>>>>>> (almost a year old actually, I assume IPA only checks it when it first
>>>>>>>> starts up so it didn't care that it was expired until the server was
>>>>>>>> rebooted?)
>>>>>>>
>>>>>>> certmonger checks the certificate validity periodically (configurable in
>>>>>>> certmonger.conf) and tries multiple times to renew soon-to-expire certs.
>>>>>>> The system probably had an issue that was not detected and the cert
>>>>>>> reached its expiration date.
>>>>>>>
>>>>>>>>
>>>>>>>> 2) ran ipactl start --ignore-service-failures
>>>>>>>> Â Â Â Â Â Â a. most services started, obviously pki-tomcatd did not
>>>>>>>> 3) ran "kinit admin"
>>>>>>>> Â Â Â Â Â Â a. was forced to change the password, but otherwise nothing happened
>>>>>>>> 4) Ran "ipa config-show |grep -i master
>>>>>>>> Â Â Â Â Â a. I see that the IPA CA renewal master is a different idm machine.
>>>>>>>> 5) Ran "getcert list | grep -E "Request|certificate:|expires:"
>>>>>>>> Â Â Â Â Â a.I see all certs are currently valid (none expired)
>>>>>>>> 6) Ran the command "getcert list" on the problem server, but I cannot
>>>>>>>> paste the output here because it's on an airgaped environment so while I
>>>>>>>> apologize for this and realize it makes things more difficult, perhaps
>>>>>>>> if you tell me what I should be looking for or more specifically what
>>>>>>>> you're interested in I can pluck that out and manually include it here?
>>>>>>>> So in summary, it is indeed an expired "Server-Cert cert-pki-ca'
>>>>>>>> certificate on the problem server, and it can theoretically be renew by
>>>>>>>> the Master at this time.
>>>>>>> The interesting part is the list of expired certs on the failing node
>>>>>>> (is the RA cert /var/lib/ipa/ra-agent.pem expired?). Detailed
>>>>>>> instructions are available here:
>>>>>>> https://access.redhat.com/solutions/3357331 How do I manually renew
>>>>>>> Identity Management (IPA) certificates on RHEL7 after they have expired?
>>>>>>> (Replica IPA Server)
>>>>>>>
>>>>>>> flo
>>>>>>>
>>>>>>>> Many thanks!
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> *From:* Florence Blanc-Renaud <flo(a)redhat.com>
>>>>>>>> *Sent:* Monday, August 3, 2020 9:34 PM
>>>>>>>> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>>>>>>>> *Cc:* Scott Z. <sudz28(a)hotmail.com>
>>>>>>>> *Subject:* Re: [Freeipa-users] pki-tomcatd not starting
>>>>>>>> On 8/3/20 10:14 PM, Scott Z. via FreeIPA-users wrote:
>>>>>>>>> Not sure I'm sending this to the right place, but here it goes. I
>>>>>>>>> inherited a FreeIPA/Identity Manager setup in an enclave (no internet
>>>>>>>>> access) environment that is running into problems. There are at least 3
>>>>>>>>> different IdM servers running in the environment spread out across
>>>>>>>>> different geographical areas. One of those areas suffered an unschedule
>>>>>>>>> power outage recently, and ever since we brought everything back up, the
>>>>>>>>> IdM server for this region is having an issue. Please bear with me as I
>>>>>>>>> have zero formal experience, training, or real knowledge with IdM.
>>>>>>>>>
>>>>>>>>> Logging in to the serverv (it's a VM server, running Centos 7.5), I run
>>>>>>>>> "ipactl status" and it shows "Directory Service: STOPPED". I then run
>>>>>>>>> "ipactl restart", and things go fine until it gets to "Starting
>>>>>>>>> pki-tomcatd Service", where it hangs for quite some time before failing
>>>>>>>>> to start and killing all the other services. I check the log at
>>>>>>>>> /var/log/pki/pki-tomcat/ca/debug and I see various errors such as
>>>>>>>>> (forgive any mistypings, I have to manually type these in as I can't
>>>>>>>>> import or screen capure the logs and put them in this message):
>>>>>>>>> "/java.lang.Exception: Certificate Server-Cert cert-pki-ca is invalid:
>>>>>>>>> Invalid certificate: (-8181) Peer's Certificate has expired/"
>>>>>>>>> And slightly further down in the same log:
>>>>>>>>> "/Cannot reset factory: connections not all returned/"
>>>>>>>>> "/CertificateAuthority.shutdown: failed to reset dbFactory: Cannot reset
>>>>>>>>> LDAP connection factory because some connections are still outstanding/"
>>>>>>>>> ... still further down"
>>>>>>>>> "/returnConn:mNumConns now 3 Invalid class name repositorytop/"
>>>>>>>>>
>>>>>>>>> Assuming I have some weird certificate issue with this server in
>>>>>>>>> particular, I try to run a few more commands:
>>>>>>>>> "certutil -L -d /etc/httpd/alias" --> returns a Server-Cert listing
>>>>>>>>> with u,u,u as it's trust attributes, and <IDM.domain> IPA CA with CT,C,C
>>>>>>>>> for it's attributes. Comparing to a second IdM server in this
>>>>>>>>> environment, it seems to be missing a "Signing-Cert"?
>>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> PKI is using the NSSDB in /etc/pki/pki-tomcat/alias, and its server cert
>>>>>>>> has the nickname 'Server-Cert cert-pki-ca'. You should check that this
>>>>>>>> one is not expired with:
>>>>>>>> # certutil -L -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca'
>>>>>>>> | grep 'Not '
>>>>>>>>
>>>>>>>> If the certificate is indeed expired, it will have to be renewed but you
>>>>>>>> need first to find which IPA server is the CA renewal master. On your
>>>>>>>> server, force a service start and check the CA renewal master:
>>>>>>>> # ipactl start --ignore-service-failures
>>>>>>>> # kinit admin
>>>>>>>> # ipa config-show | grep "renewal master"
>>>>>>>> Â Â IPA CA renewal master: server.domain.com
>>>>>>>>
>>>>>>>> You need to make sure that all the certificates are valid on the CA
>>>>>>>> renewal master:
>>>>>>>> (on the CA renewal master)# getcert list | grep -E
>>>>>>>> "Request|certificate:|expires:"
>>>>>>>>
>>>>>>>> - if the CA renewal master is not OK, please post the output of "#
>>>>>>>> getcert list" (without the grep) on the CA renewal master. This node
>>>>>>>> will have to be repaired first.
>>>>>>>> - if the CA renewal master is OK, please post the output of "# getcert
>>>>>>>> list" (also without the grep) on the failing node.
>>>>>>>>
>>>>>>>> We'll be able to help based on this information.
>>>>>>>> flo
>>>>>>>>
>>>>>>>>> I also did a "getcert list", and all certs it has show that they expire
>>>>>>>>> in the future (nothing shows as bein currently expired).
>>>>>>>>>
>>>>>>>>> I'm confused; it seems to that it is seeing an expired cert *somewhere*,
>>>>>>>>> but how do I track down which 'peer' the log file is talking about that
>>>>>>>>> has an expired cert? Meanwhile none of the linux clients that point to
>>>>>>>>> this IdM server are allowing people to log in/authenticate.
>>>>>>>>> Many thanks for any help!
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
3 years, 8 months
