I checked on the certificates as you suggested and none show they are expired.  Any other suggestions?
sudo getcert list | grep expires
       expires: 2019-08-25 20:51:47 UTC
       expires: 2019-08-25 20:50:38 UTC
       expires: 2019-08-25 20:50:58 UTC
       expires: 2035-10-13 20:50:26 UTC
       expires: 2019-08-26 20:50:37 UTC
       expires: 2019-08-25 20:50:37 UTC
       expires: 2019-09-17 20:50:47 UTC
       expires: 2019-09-17 20:50:37 UTC
       expires: 2018-08-14 19:29:31 UTC



On Mon, Oct 16, 2017 at 2:32 PM, Rob Crittenden <rcritten@redhat.com> wrote:
Kristian Petersen wrote:
Here is the last user_show I did:
[Mon Oct 16 10:27:25.164027 2017] [:error] [pid 24937] ipa: INFO:
nesretep@CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
user_show(u'aaburton', rights=True, all=True): SUCCESS
[Mon Oct 16 10:27:25.216336 2017] [:error] [pid 24937] ipa: INFO:
nesretep@CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
pwpolicy_show(None, rights=True, user=u'aaburton', all=True): SUCCESS
[Mon Oct 16 10:27:25.269772 2017] [:error] [pid 24937] ipa: INFO:
nesretep@CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
krbtpolicy_show(u'aaburton', rights=True, all=True): SUCCESS
[Mon Oct 16 10:27:25.277407 2017] [:error] [pid 24937] ipa: ERROR:
ra.find(): Unable to communicate with CMS ([Errno 111] Connection refused)
[Mon Oct 16 10:27:25.277553 2017] [:error] [pid 24937] ipa: INFO:
nesretep@CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
cert_find(None, sizelimit=0, all=True, user=(u'aaburton',)):
CertificateOperationError
[Mon Oct 16 10:27:25.277807 2017] [:error] [pid 24937] ipa: INFO:
[jsonserver_session] nesretep@CHEM.BYU.EDU
<mailto:nesretep@CHEM.BYU.EDU>: batch(({u'params': ([u'aaburton'],
{u'all': True, u'rights': True}), u'method': u'user_show'}, {u'params':
([], {u'all': True, u'user': u'aaburton', u'rights': True}), u'method':
u'pwpolicy_show'}, {u'params': ([u'aaburton'], {u'all': True, u'rights':
True}), u'method': u'krbtpolicy_show'}, {u'params': ([], {u'sizelimit':
0, u'all': True, u'user': (u'aaburton',)}), u'method': u'cert_find'}),
version=u'2.228'): SUCCESS

I think this supports my suspicion that the failure of pki-tomcatd to
start the last time I updated IPA is related somehow to his issue
(correct me if I am wrong).  I have been struggling to figure out why
that failed in the first place.

So there is a recently reported issue in the UI when cert-find fails, https://pagure.io/freeipa/issue/7202

As for why tomcat doesn't start I'd run getcert list first to check on the status of your certificates. My guess is one or more is expired.

rob


Pavel:
The issue with the menu showing all of the options shown in the image I
sent only lasts until I load another user.  The menu initially appears
(before a refresh) like this:
Inline image 1
This is how I would expect it to look for a disabled user.  It stays
like that until I refresh the page, then it looks like the other image I
sent.

On Fri, Oct 13, 2017 at 8:24 AM, Rob Crittenden <rcritten@redhat.com
<mailto:rcritten@redhat.com>> wrote:

    Rob Crittenden wrote:

        Rob Crittenden via FreeIPA-users wrote:

            Kristian Petersen via FreeIPA-users wrote:

                Very possibly a bug if others are experiencing this as
                well.  I am
                running IPA v4.5.0 on RHEL 7.4 are you running in a
                similar environment?


            You might be able to figure out what is going on using
            something like
            the Firefox dev console. In it you could see the JSON
            returned by the
            IPA server, look for errors in the JS console, etc. to try
            to identify
            where the issue is.

            And/or file a bug, but since you have a reproducer the more
            data you can
            gather to narrow the cause the easier it will be to fix.

            rob


        Kirstian gave me some javascript errors. We've seen other
        oddness in the
        UI when cert_find() fails. Can you look in
        /var/log/httpd/error_log to
        see if there is a traceback or a failure when you load the user
        in the UI?


    And one more thing to check. I'm pretty sure under Network you can
    drill down into the details to see what data is returned by the
    server. Find the last user_show('youruser')

    In the result there should be a long blog for attributelevelrights.
    Find userpassword in there and ensure the rights contains w, like:

    u'userpassword': u'swo'


    rob



                On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins
                <givaldolins@gmail.com <mailto:givaldolins@gmail.com>
                <mailto:givaldolins@gmail.com
                <mailto:givaldolins@gmail.com>>> wrote:

                    I noticed the same thing weeks ago and I am using
                the same
                    workaround that Kristian. Might it be a bug on webui?

                    —
                    Givaldo Lins

                    On Oct 12, 2017, at 9:05 AM, Kristian Petersen via
                FreeIPA-users
                    <freeipa-users@lists.fedorahosted.org
                <mailto:freeipa-users@lists.fedorahosted.org>
                    <mailto:freeipa-users@lists.fedorahosted.org

                <mailto:freeipa-users@lists.fedorahosted.org>>> wrote:

                        When trying to reset a password for a user and I
                    pull up the page
                        for a specific user, it shows them as being
                    disabled even if they
                        aren't.  This causes the reset password option
                    to be grayed-out
                        among other things.  I verified the users
                    weren't actually
                        disabled by running ipa user-show <username> on
                    a few of them.  If
                        you do a user search in the WebUI or show all of
                    the users in the
                        system the status shows correctly on that page
                    of the Web UI.
                        This problem appears to happen across the
                    replicas as well.

                        After playing around with the Web UI for a bit I
                    found that a
                        refresh of the user's page gives back access to
                    the Reset Password
                        option, but just for that view.  If you go to
                    another user the
                        problem resurfaces.  I have confirmed this
                    happens in both chrome
                        and firefox running in both Windows or Linux.
                    The httpd logs show
                        nothing there, /var/log/ipa logs aren't helpful
                    either.

                        IPA got some updates recently (which also appear
                    to have broken
                        pki-tomcatd), but I'm not sure if the two
                    problems are related.

                        --
                        Kristian Petersen
                        System Administrator
                        Dept. of Chemistry and Biochemistry
                        _______________________________________________
                        FreeIPA-users mailing list --
                    freeipa-users@lists.fedorahosted.org
                    <mailto:freeipa-users@lists.fedorahosted.org>
                        <mailto:freeipa-users@lists.fedorahosted.org
                    <mailto:freeipa-users@lists.fedorahosted.org>>
                        To unsubscribe send an email to
                        freeipa-users-leave@lists.fedorahosted.org
                    <mailto:freeipa-users-leave@lists.fedorahosted.org>

                    <mailto:freeipa-users-leave@lists.fedorahosted.org
                    <mailto:freeipa-users-leave@lists.fedorahosted.org>>





                --
                Kristian Petersen
                System Administrator
                Dept. of Chemistry and Biochemistry


                _______________________________________________
                FreeIPA-users mailing list --
                freeipa-users@lists.fedorahosted.org
                <mailto:freeipa-users@lists.fedorahosted.org>
                To unsubscribe send an email to
                freeipa-users-leave@lists.fedorahosted.org
                <mailto:freeipa-users-leave@lists.fedorahosted.org>

            _______________________________________________
            FreeIPA-users mailing list --
            freeipa-users@lists.fedorahosted.org
            <mailto:freeipa-users@lists.fedorahosted.org>
            To unsubscribe send an email to
            freeipa-users-leave@lists.fedorahosted.org
            <mailto:freeipa-users-leave@lists.fedorahosted.org>






--
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry




--
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry