Can't ssh using GSSAPI delegation from one freeipa client to another consistently
by Ranbir
Hello,
I have a Fedora 26 desktop joined to a freeipa domain running two ipa
4.5.4-10 servers on CentOS 7.5.1804. I have an odd "problem" I hope
someone here can help me fix.
I can ssh from my desktop to any server in the domain using my password
(i.e. interactive) or GSSAPI. Once on a server, I can ssh to some hosts
in the domain using GSSAPI delegation, but not to others.
When GSSAPI delegation doesn't work, I see this error:
debug1: Unspecified GSS failure. Minor code may provide more information
Server host/ipa01(a)THEINSIDE.RNR not found in Kerberos database
I think I solved this once before, but it was a very, very long time
ago and I don't have any notes to refer to.
What am I messing up?
--
Ranbir
5 years, 6 months
freeipa server install fails - ipa-ca DNS record will be incomplete
by Kees Bakker
Hi,
Installing FreeIPA server fails on Ubuntu 18.04 with the following
messages. (( I should say: still failing. I haven't had much luck with
it. ))
---------------------8X-----------------8X------------------
Restarting named
Updating DNS system records
ipapython.dnsutil: ERROR DNS query for usrv1.ijtest.nl. 1 failed: The DNS operation timed out after 30.0004618168 seconds
ipaserver.dns_data_management: ERROR unable to resolve host name usrv1.ijtest.nl. to IP address, ipa-ca DNS record will be incomplete
---------------------8X-----------------8X------------------
Notice, I should say that the installation process reports that all
went well. It completes the whole installation, ending with
---------------------8X-----------------8X------------------
...
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
trying https://usrv1.ijtest.nl/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://usrv1.ijtest.nl/ipa/json'
trying https://usrv1.ijtest.nl/ipa/session/json
[try 1]: Forwarding 'ping' to json server 'https://usrv1.ijtest.nl/ipa/session/json'
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://usrv1.ijtest.nl/ipa/session/json'
Systemwide CA database updated.
[try 1]: Forwarding 'host_mod' to json server 'https://usrv1.ijtest.nl/ipa/session/json'
Could not update DNS SSHFP records.
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
/etc/ssh/sshd_config not found, skipping configuration
Configuring ijtest.nl as NIS domain.
Client configuration complete.
The ipa-client-install command was successful
==============================================================================
Setup complete
---------------------8X-----------------8X------------------
However, bind (named) is not running.
---------------------8X-----------------8X------------------
root@usrv1:~# netstat -tulpen | grep -w 53
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 127902 88/systemd-resolved
udp 35328 0 127.0.0.53:53 0.0.0.0:* 101 127901 88/systemd-resolved
---------------------8X-----------------8X------------------
Also, when I access the IPA server using a browser it fails with
Login failed due to an unknown reason.
In /var/log/apache2/error.log there is this:
---------------------8X-----------------8X------------------
[Thu Sep 06 12:00:28.720410 2018] [wsgi:error] [pid 6137:tid 140075658061568] [remote 10.83.0.11:38596] ipa: INFO: [jsonserver_kerb] host/usrv1.ijtest.nl(a)IJTEST.NL: schema(version=u'2.170'): SUCCESS
[Thu Sep 06 12:01:00.010427 2018] [:warn] [pid 6140:tid 140076243191552] [client 10.83.0.11:38608] failed to set perms (3140) on file (/var/run/ipa/ccaches/host~usrv1.ijtest.nl(a)IJTEST.NL)!, referer: https://usrv1.ijtest.nl/ipa/xml
[Thu Sep 06 12:01:00.099271 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 10.83.0.11:38608] ipa: INFO: [jsonserver_session] host/usrv1.ijtest.nl(a)IJTEST.NL: ping(): SUCCESS
[Thu Sep 06 12:01:00.101695 2018] [:warn] [pid 6140:tid 140076130498304] [client 10.83.0.11:38608] failed to set perms (3140) on file (/var/run/ipa/ccaches/host~usrv1.ijtest.nl(a)IJTEST.NL)!, referer: https://usrv1.ijtest.nl/ipa/xml
[Thu Sep 06 12:01:00.273013 2018] [wsgi:error] [pid 6137:tid 140075658061568] [remote 10.83.0.11:38608] ipa: INFO: [jsonserver_session] host/usrv1.ijtest.nl(a)IJTEST.NL: ca_is_enabled(version=u'2.107'): SUCCESS
[Thu Sep 06 12:01:02.805635 2018] [:warn] [pid 6140:tid 140076234798848] [client 10.83.0.11:38608] failed to set perms (3140) on file (/var/run/ipa/ccaches/host~usrv1.ijtest.nl(a)IJTEST.NL)!, referer: https://usrv1.ijtest.nl/ipa/xml
[Thu Sep 06 12:01:02.999541 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 10.83.0.11:38608] ipa: INFO: [jsonserver_session] host/usrv1.ijtest.nl(a)IJTEST.NL: host_mod(u'usrv1.ijtest.nl', ipasshpubkey=(), updatedns=False, version=u'2.26'): EmptyModlist
[Thu Sep 06 13:02:22.125841 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] mod_wsgi (pid=6138): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
[Thu Sep 06 13:02:22.125877 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] Traceback (most recent call last):
[Thu Sep 06 13:02:22.125898 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/share/ipa/wsgi.py", line 57, in application
[Thu Sep 06 13:02:22.125961 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] return api.Backend.wsgi_dispatch(environ, start_response)
[Thu Sep 06 13:02:22.125972 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipaserver/rpcserver.py", line 265, in __call__
[Thu Sep 06 13:02:22.128833 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] return self.route(environ, start_response)
[Thu Sep 06 13:02:22.128846 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipaserver/rpcserver.py", line 277, in route
[Thu Sep 06 13:02:22.128860 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] return app(environ, start_response)
[Thu Sep 06 13:02:22.128872 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipaserver/rpcserver.py", line 935, in __call__
[Thu Sep 06 13:02:22.128881 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] self.kinit(user_principal, password, ipa_ccache_name)
[Thu Sep 06 13:02:22.128886 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipaserver/rpcserver.py", line 971, in kinit
[Thu Sep 06 13:02:22.128892 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] pkinit_anchors=[paths.KDC_CERT, paths.KDC_CA_BUNDLE_PEM],
[Thu Sep 06 13:02:22.128898 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipalib/install/kinit.py", line 125, in kinit_armor
[Thu Sep 06 13:02:22.133878 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] run(args, env=env, raiseonerr=True, capture_error=True)
[Thu Sep 06 13:02:22.133892 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 572, in run
[Thu Sep 06 13:02:22.138435 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] p.returncode, arg_string, output_log, error_log
[Thu Sep 06 13:02:22.138488 2018] [wsgi:error] [pid 6138:tid 140075658061568] [remote 172.16.16.30:38014] CalledProcessError: CalledProcessError(Command ['/usr/bin/kinit', '-n', '-c', '/var/run/ipa/ccaches/armor_6138', '-X', 'X509_anchors=FILE:/var/lib/krb5kdc/kdc.crt', '-X', 'X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem'] returned non-zero exit status 1: "kinit: Pre-authentication failed: Cannot open file '/var/lib/krb5kdc/kdc.crt': Permission denied while getting initial credentials\\n")
---------------------8X-----------------8X------------------
--
Kees
5 years, 6 months
shortname in trusted ad domain
by Pieter Baele
Hi,
I've one more application that doesn't behave very properly with FQDN users.
For LDAP, this is no longer a problem as we use AD directly for
applications now.
But this application uses PAM, so somehow I do need to present it a
shortname as described in
https://docs.pagure.org/sssd.sssd/design_pages/subdomain_configuration.ht...
and https://docs.pagure.org/sssd.sssd/design_pages/shortnames.html
Adding use_fully_qualified_names = False indeed results in the possibility
of using <user> instead of <user>@<domain>
But the returned/displayed values are still <user>@<ad domain> or
<user>@<IPA domain>
I could resolve that with full_name_format = %1$s, but this breaks logon
for trusted AD users....
Which is confirmed on the sssd mailing by Jakub Hrozek
"Keep in mind that by default, the names will still come back qualified
from the child domains because that’s the only way to distinguish users
from different domains during a multi-step authentication process (e.g.
application receives a name to authenticate as, then calls getpwnam on that
input and uses the output of getpwnam from then on..). You /can/ tune the
full_name_format to only include the user name, but please be aware of the
consequences."
Or is there a configuration which is a solution for this issue?
5 years, 6 months
Python 3 support
by Kristian Petersen
What version of FreeIPA was the one that gave us API support in Python3? I
am currently running Redhat IdM v4.5.4 and am curious what version to be
looking out for.
--
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
5 years, 6 months
Fwd: Fedora 30 System-Wide Change Proposal: FreeIPA Python 2 Removal
by Christian Heimes
For your information,
The upcoming FreeIPA 4.8.0 release will no longer support Python 2.7 or
3.5. Python 3.6 or newer will be required. In case you have any Python
script, tool, or application that import a FreeIPA package like ipalib
or ipaclient, now is the time to port them to Python 3!
FreeIPA 4.8 is scheduled to be released in December 2018 or early
January 2019.
Regards,
Christian
-------- Forwarded Message --------
Subject: Fedora 30 System-Wide Change Proposal: FreeIPA Python 2 Removal
Date: Wed, 5 Sep 2018 13:05:31 -0400
From: Ben Cotton <bcotton(a)redhat.com>
Reply-To: devel(a)lists.fedoraproject.org
To: devel-announce(a)lists.fedoraproject.org, devel(a)lists.fedoraproject.org
https://fedoraproject.org/wiki/Changes/FreeIPA_Python_2_Removal
== Summary ==
FreeIPA 4.8 will require Python 3.6+ and therefore no longer provide
Python 2 packages on Fedora 30.
== Owner ==
* Name: Christian Heimes (cheimes)
* Email: cheimes(a)redhat.com
== Detailed Description ==
On Fedora 27 to 29, FreeIPA client and server packages use Python 3
default. Additionally FreeIPA provides Python 2 packages. The Python 2
packages are not used by FreeIPA, but are merely provided for
backwards compatibility, e.g. Python 2 applications that utilize
python2-ipaclient to communicate with a FreeIPA server.
The FreeIPA upstream project is going to drop support for Python 2.7
in the upcoming FreeIPA release 4.8.0. Python 2 support is not only
causing development and testing overhead. It's also blocking
improvements like using new python-based 389-DS installer, use of new
Python features, and more. The removal of Python 2 support was
[https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorah...
announced] on the FreeIPA development on 2018-09-03.
=== Removed packages ===
* python2-ipalib
* python2-ipaclient
* python2-ipaserver
* python2-ipatests
* python2-ipa-desktop-profile-client (dependency)
== Benefit to Fedora ==
The removal of Python 2 support is in alignment with Mass Python 2
Package Removal proposal. FreeIPA depends has a large list of
dependencies. The change makes it possible to drop more Python 2
packages.
== Scope ==
* Proposal owners:
** Release FreeIPA 4.8.0 until mid January 2019
** Build and deliver FreeIPA 4.8.0 packages before 2019-01-29
** Add removed packages to ''fedora-obsolete-packages''.
* Other developers:
** Port Fleet Commander's fc-admin to Python 3 and no longer depend on
FreeIPA's Python 2 packages.
** Drop Fleet Command's Python 2 desktop profile package
** Port Ipsilion Project to Python 3 and no longer depend on FreeIPA's
Python 2 packages.
FreeIPA team is willing to help to aforementioned projects with their
port to use Python 3 FreeIPA libraries.
* Release engineering: [https://pagure.io/releng/issue/7760 #7760]
There is no releng work needed for this change.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The removal of Python 2 support will not affect FreeIPA server or
client systems. However 3rd party applications and scripts may be
affected. These applications and scripts must be ported to Python 3.
On upgrade from Fedora 29, previously installed ''python2-ipa*''
packages cannot be retained. All ''python[23]-ipa*'' packages have a
hard version dependency on common files with a requires line like
''Requires: freeipa-common = %{version}-%{release}''. This requires
cannot be satisfied for existing ''python2-ipa*''. Therefore
''python2-ipa*'' packages have to added to
''fedora-obsolete-packages'' package. This will ensure that the Python
2 packages are uninstalled on system upgrade.
== How To Test ==
* A fresh Fedora 30 installation will no longer have python2-ipa*
packages available.
* On upgrade from Fedora 29, all python2-ipa* packages are uninstalled.
== User Experience ==
N/A
== Dependencies ==
* fedora-obsolete-packages
* ipsilon-tools-ipa
* python2-ipa-desktop-profile-client
* fleet-commander-admin
== Contingency Plan ==
* Contingency mechanism: Keep shipping FreeIPA 4.7
* Contingency deadline: 2019-01-31
* Blocks release? No
* Blocks product? N/A
== Documentation ==
This page is the main documentation.
Also see https://pythonclock.org/ and
https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal .
== Release Notes ==
FreeIPA no longer supports Python 2. All ''python2-ipa*'' packages and
''python-ipa*'' aliases are discontinued.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
5 years, 6 months
Hiding User Groups from WebUI
by Heather A. Selbe
This is going to be a strange one. I have a new instance of IPA I am standing up, and did an migrate of users and groups from a prior IPA instance. In the old instance, all of the user private groups were hidden in the WebUI, but do still exist in the server, since I can find them with ipa group_show and group_find. I've done some digging, but I'm still unsure how to replicate this behavior on the new IPA master. The new IPA is on 4.5.4-10 for reference. Any help will be appreciated.
5 years, 6 months
Re: Help with FreeIPA startup problem
by Stuart McRobert
Hi,
> Yes, this looks correct. Make sure that 17 is the serial of your new
> certificate (it may differ from my example), and don't forget to replace
> O=XXX with the correct domain for your deployment.
Thanks, yes 17 was indeed the new serial and XXX was replaced.
The update was first tested with the -n and verbose option -v, then run.
Appeared to be okay, rebooted, and everything appears to have restarted.
> When the PKI instance on your system is able to start, please closely
> monitor its renewal or keep the mailing list in the loop if it does not
> renew automatically.
It has already been renewed on restart
expires: 2020-09-04 17:46:56 BST
One final question. We have three FreeIPA servers and correctly receive a
warning via the web interface when visiting IPA Servers / Topology page
that:
"Only One CA server detected"
which is how the system was initially deployed a couple of years' ago,
probably not intentionally.
I am looking for a guide on the correct way to add CA servers on the other
two FreeIPA servers. Any ideas?
Thanks
Best wishes
Stuart
5 years, 6 months
pwm
by Andrew Meyer
Hello,I am working on getting pwm setup with FreeIPA. However I'm running into some issues. I have it pretty much configured but I am getting error in the logs for pwm.
Sep 4 11:09:21 pwm01 server: 2018-09-04T11:09:21Z, ERROR, cluster.ClusterMachine, 5093 ERROR_CLUSTER_SERVICE_ERROR (error writing database cluster heartbeat: 5079 ERROR_LDAP_DATA_ERROR (error writing cluster data: javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - attribute "pwmresponseset" not allowed
I was also getting this:Sep 4 09:54:47 pwm01 server: 2018-09-04T09:54:47Z, ERROR, ldap.LdapOperationsHelper, {#,health} error adding objectclass 'pwmUser' to user uid=pwmtest,cn=users,cn=accounts,dc=example,dc=net: com.novell.ldapchai.exception.ChaiOperationException: javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - unknown object class "pwmUser"
To resolve the above error I removed the pwmUser from the config in pwm. Not sure if that was wise or not.
I have not extended the schema as suggested:https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e...
When I did this dirsrv threw an error on my dev environment.
However in my single server at home this worked fine.
What I want to know is, once I restart dirsrv and ipa service is there a way to validate the attribute and objectClasses are showing up in FreeIPA?
Also if anyone has set this up in the past and has any recommendations I will gladly take them.
Thank you,Andrew
5 years, 6 months
Re: Help with FreeIPA startup problem
by Stuart McRobert
Hi,
> I'm cc'ing the users mailing list, you may get more help there.
Thanks.
> As the output of certutil -K correctly displays an entry for
> subsystemCert cert-pki-ca, we can assume that the password is OK.
Okay, good.
> I would try to check the next steps detailed in
> https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom...
> and ensure that uid=pkidbuser,ou=people,o=ipaca contains the same
> certificate as /etc/pki/pki-tomcat/alias, as it is one of the most
> frequent root causes for authentication issues between PKI and the LDAP
> server after an upgrade.
That does indeed look very likely to be the problem, although the last
upgrade was I think about a year ago and we have only recently seen
issues. However a Fedora release upgrade to F28 is now overdue and on our
list to perform.
Comparing the certificate strings (removed below) from:
ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
Enter LDAP Password:
dn: uid=pkidbuser,ou=people,o=ipaca
userCertificate::
...
and
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
-----BEGIN CERTIFICATE-----
they do appear to look different.
Next to checking the serial numbers to confirm:
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial
Serial Number: 17 (0x11)
and from
ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso
description: 2;4;CN=Certificate Authority
which if I have understood correctly gives us the value 4 which clearly
doesn't match with 17.
I believe I should now take the "new" certificate as the one provided by:
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a
and save that into an update file with it appearing as a very long single
line certificate, a minus, then update the serial number in the
description:
dn: uid=pkidbuser,ou=people,o=ipaca
changetype: modify
replace: usercertificate
usercertificate::MIIDhjCC.............
-
replace: description
description: 2;17;CN=Certificate Authority,O=XXX;CN=CA Subsystem,O=XXX
Then I update with:
ldapmodify -D "cn=directory manager" -W -f my_update_file
If this all looks fine to everybody I will go ahead and try this update.
I also note your end comment:
> This could be described in another blog post (for the impatients, the
> automatic renewal of the certificate failed to update the LDAP server
> entry…)
I suspect this may well be the case, I note
ipa-getcert list
reports one that expires: 2018-09-09 18:00:20 BST which I would have
thought all being well would have been automatically renewed by now?
Hopefully it will just happen once back up and running?
Best wishes
Stuart
5 years, 6 months
Re: Help with FreeIPA startup problem
by Florence Blanc-Renaud
On 09/04/2018 11:27 AM, Stuart McRobert wrote:
> Hi,
>
> I wonder if you might be able to help me with hopefully a quick FreeIPA
> startup problem that I've not been able to work out how to fix, or point
> me to further information to help get this resolved? Many thanks.
>
> I found your useful guide "Troubleshooting FreeIPA: pki-tomcatd fails to
> start" and reach:
>
> + Then make sure that the private key can be read using the password found
> in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag internal=…)
>
> There is a value stored in /tmp/pwdfile.txt
>
> # certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'NSS
> Certificate DB: subsystemCert cert-pki-ca'
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
> Object Identifier.
>
> I thought better see what is in there (and Xed out the hex values):
>
> # certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt certutil:
> Checking token "NSS Certificate DB" in slot "NSS User Private Key and
> Certificate Services"
> < 0> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX caSigningCert
> cert-pki-ca
> < 1> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (orphan)
> < 2> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX NSS Certificate
> DB:subsystemCert cert-pki-ca
> < 3> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX NSS Certificate
> DB:auditSigningCert cert-pki-ca
> < 4> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX NSS Certificate
> DB:Server-Cert cert-pki-ca
> < 5> rsa XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX NSS Certificate
> DB:ocspSigningCert cert-pki-ca
>
> Try without the space:
>
> # certutil -K -d /etc/pki/pki-tomcat/alias -f /tmp/pwdfile.txt -n 'NSS
> Certificate DB:subsystemCert cert-pki-ca'
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
> Object Identifier.
>
> But not sure of the next step. Looking at the directory
>
> ls -la /etc/pki/pki-tomcat/alias
> total 100
> drwxrwx---. 2 pkiuser pkiuser 4096 Sep 8 2016 .
> drwxrwx---. 5 pkiuser pkiuser 4096 Aug 21 2017 ..
> -rw-------. 1 pkiuser pkiuser 65536 Sep 3 15:06 cert8.db
> -rw-------. 1 pkiuser pkiuser 28672 Sep 3 15:06 key3.db
> -rw-------. 1 pkiuser pkiuser 16384 Sep 8 2016 secmod.db
>
> the modification time could relate to my reboot yesterday and manual
> attempts to restart ipa.
>
> In short I know something has gone wrong but struggling to work out how
> to recover and without causing disruption to the department. Kerberos
> logins are thankfully currently working.
>
> Thanks
>
> Best wishes
>
> Stuart
Hi,
I'm cc'ing the users mailing list, you may get more help there.
As the output of certutil -K correctly displays an entry for
subsystemCert cert-pki-ca, we can assume that the password is OK. I
would try to check the next steps detailed in
https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tom...
and ensure that uid=pkidbuser,ou=people,o=ipaca contains the same
certificate as /etc/pki/pki-tomcat/alias, as it is one of the most
frequent root causes for authentication issues between PKI and the LDAP
server after an upgrade.
HTH,
flo
5 years, 6 months