[Freeipa-users] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

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  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:
>> nesre...@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:
>> nesre...@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:
>> nesre...@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:
>> nesre...@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] nesre...@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 > > 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
>> 
>> 

[Freeipa-users] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

Here is the last user_show I did:
[Mon Oct 16 10:27:25.164027 2017] [:error] [pid 24937] ipa: INFO:
nesre...@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:
nesre...@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:
nesre...@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:
nesre...@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] nesre...@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.

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:
[image: 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  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 > 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
 > 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  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.

[Freeipa-users] Re: unexpected upgrade to 4.5

[Alexander Bokovoy via FreeIPA-users]

On ma, 16 loka 2017, Charles Hedrick via FreeIPA-users wrote:

I just installed a new replica on Centos 7.3. Our existing servers are
also on Centos 7.3, and use IPA 4.4, which comes with Centos 7.3. I was
somewhat surprised to find that my new replica was IPA 4.5 with a newer
version of sssd as well. It appears that the replica install process
did the Centos 7.4 upgrades for ipa and sssd, though the rest of the
system is still Cento 7.3. The resulting system works, with only minor
differences in behavior in sssd. But it was unexpected.

We’ll do a full Centos 7.4 upgrade at the next major break, but had
been holding off doing that during a semester.

It’s moderately important to me not to get unexpected versions of
software. I didn’t even notice the difference until the replica was in
production. In a sense that’s good, because it means 4.5 works fine.
But we could also have discovered it that hard way …

This is not related to FreeIPA but is how CentOS (and RHEL, to some
degree) maintain their repositories.

https://wiki.centos.org/FAQ/General#head-dcca41e9a3d5ac4c6d900a991990fd11930867d6
says:

CentOS Linux releases minor (point in time) versions of our major
branches. Two very important things about CentOS Linux branches are:

   The CentOS Project provides updates or other changes ONLY for the
   latest version of each major branch. Thus, if the latest minor
   version of CentOS-6 is version 6.6 then the CentOS Project only
   provides updated software for this minor version in the 6 branch. If
   you are using an older minor version than the latest in a given
   branch, then you are missing security and bugfix updates.

 Note: Any minor version is just a snapshot with previous
updates, plus the latest batch of new upstream updates, rolled
into a new [base] repo with an initially empty [updates] repo.

{i} Tip: There is a CentOS Vault containing older CentOS trees.
This vault is a picture of the older tree when it was removed
from the main tree, and does not receive updates. It should only
	be used for reference. 


   When setting up yum repositories on CentOS Linux you should ONLY use
   the single digit for the active branch, which corresponds to the
   CentOS Linux major branch. For example,
   http://mirror.centos.org/centos/5/ ,
   http://mirror.centos.org/centos/6/ , or
   http://mirror.centos.org/centos/7/ . This is because we move all
   older minor branches to http://vault.centos.org/ . Remember from the
   prior bullet point, no updates are ever added to minor versions of
   CentOS Linux once in the vault. 



--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: unexpected upgrade to 4.5

[Petr Vobornik via FreeIPA-users]

Hello,

to prevent such situation is to prevent installing new packages.
FreeIPA cannot prevent it but yum can.

You can use `yum version-lock` in package yum-plugin-versionlock

HTH

On Mon, Oct 16, 2017 at 5:15 PM, Charles Hedrick via FreeIPA-users
 wrote:
> I just installed a new replica on Centos 7.3. Our existing servers are also 
> on Centos 7.3, and use IPA 4.4, which comes with Centos 7.3. I was somewhat 
> surprised to find that my new replica was IPA 4.5 with a newer version of 
> sssd as well. It appears that the replica install process did the Centos 7.4 
> upgrades for ipa and sssd, though the rest of the system is still Cento 7.3. 
> The resulting system works, with only minor differences in behavior in sssd. 
> But it was unexpected.
>
> We’ll do a full Centos 7.4 upgrade at the next major break, but had been 
> holding off doing that during a semester.
>
> It’s moderately important to me not to get unexpected versions of software. I 
> didn’t even notice the difference until the replica was in production. In a 
> sense that’s good, because it means 4.5 works fine. But we could also have 
> discovered it that hard way …
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org



-- 
Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] unexpected upgrade to 4.5

[Charles Hedrick via FreeIPA-users]

I just installed a new replica on Centos 7.3. Our existing servers are also on 
Centos 7.3, and use IPA 4.4, which comes with Centos 7.3. I was somewhat 
surprised to find that my new replica was IPA 4.5 with a newer version of sssd 
as well. It appears that the replica install process did the Centos 7.4 
upgrades for ipa and sssd, though the rest of the system is still Cento 7.3. 
The resulting system works, with only minor differences in behavior in sssd. 
But it was unexpected.

We’ll do a full Centos 7.4 upgrade at the next major break, but had been 
holding off doing that during a semester.

It’s moderately important to me not to get unexpected versions of software. I 
didn’t even notice the difference until the replica was in production. In a 
sense that’s good, because it means 4.5 works fine. But we could also have 
discovered it that hard way …



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: several IPA CA certificate entries

[Rob Crittenden via FreeIPA-users]

Bhavin Vaidya via FreeIPA-users wrote:

Thank you. your help is appreciated. We are still out of luck and this
is becoming very critical for us.


Please help.


We did remove all but 1 certificate, restarted master (ds01) but
clientinstallation, connection check and replica installation still fails.


certutil -D -d /etc/pki/nssdb -n 'ARTERIS.COM IPA CA'


the log messages are,


/var/log/ipaclient-install.log

2017-10-13T06:25:31Z DEBUG Starting external process
2017-10-13T06:25:31Z DEBUG args=/usr/bin/certutil -d /etc/ipa/nssdb -A
-n ARTERIS.COM IPA CA -t CT,C,C -f /etc/ipa/nssdb/pwdfile.txt
2017-10-13T06:25:31Z DEBUG Process finished, return code=255
2017-10-13T06:25:31Z DEBUG stdout=
2017-10-13T06:25:31Z DEBUG stderr=certutil: could not add certificate to
token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to
database.

2017-10-13T06:25:31Z ERROR Installation failed. Rolling back changes.

/var/log/ipareplica-conncheck.log

2017-10-13T01:56:19Z DEBUG Starting external process
2017-10-13T01:56:19Z DEBUG args=/usr/bin/certutil -d /tmp/tmpbrAYYO -A
-n CN=Certificate Authority,O=ARTERIS.COM -t C,, -f
/tmp/tmpbrAYYO/pwdfile.txt
2017-10-13T01:56:19Z DEBUG Process finished, return code=0
2017-10-13T01:56:19Z DEBUG stdout=
2017-10-13T01:56:19Z DEBUG stderr=
2017-10-13T01:56:19Z DEBUG Starting external process
2017-10-13T01:56:19Z DEBUG args=/usr/bin/certutil -d /tmp/tmpbrAYYO -A
-n CN=Certificate Authority,O=ARTERIS.COM -t C,, -f
/tmp/tmpbrAYYO/pwdfile.txt
2017-10-13T01:56:19Z DEBUG Process finished, return code=255
2017-10-13T01:56:19Z DEBUG stdout=
2017-10-13T01:56:19Z DEBUG stderr=certutil: could not add certificate to
token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to
database.

Here is the Red Hat thread https://access.redhat.com/solutions/1143193.


This issue is unrelated.

IPA pulls the list of CA's to add from LDAP so pre-deleting the entries 
locally won't do anything: they will be re-added by ipa-client-install.


You'll need to look in ARTERIS.COM IPA 
CA,cn=cn=certificates,cn=ipa,cn=etc,dc=ateris,dc=com for 
userCertificate. It is a multi-valued attribute. I'm guessing it occurs 
5 times. It seems only one of them is problematic, you'll need to figure 
out which one is the "bad" one, or figure out which is the most recent 
and remove the others. I'd be sure to save a copy of whatever is there 
at the moment to be on the safe side.


rob



regards,
Bhavin


*From:* Rob Crittenden 
*Sent:* Friday, October 13, 2017 5:38 AM
*To:* FreeIPA users list; Bhavin Vaidya
*Cc:* John Dennis
*Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries

John Dennis via FreeIPA-users wrote:

On 10/12/2017 05:06 PM, Bhavin Vaidya wrote:

Hello Jon,


thank you for your help. responded to main thread, and just sending
you the actual output for certutil.


[root@ds01 log]#  certutil -d /etc/pki/nssdb -L

Certificate Nickname Trust
Attributes

  SSL,S/MIME,JAR/XPI

ARTERIS.COM IPA CA   CT,C,C
ARTERIS.COM IPA CA   CT,C,C
ARTERIS.COM IPA CA   CT,C,C
ARTERIS.COM IPA CA   CT,C,C


These nicknames do not look unique to me, I'm assuming you're still
editing them for inclusion in this email.

But irregardless here is where I'm going with this. Your goal is to
identify the correct cert to use and which to discard. The only way you
can do that is to examine each individual cert. To examine an individual
cert you must have it's *unique* nickname to pass to "certutil -L -a -n
xxx" where xxx is the unique nickname.

Only you can identify the correct cert once you list them. At the
absolute minimum they should each have a unique (issuer,serial_number)
pair. The one you want to use will probably select based on the issuer
and validity dates.


This is how NSS handles multiple copies of the same certificate subject
in a given database.

My assumption is that the CA was renewed multiple times.

This should get you the PEM-encoded copies of the certs:

# certutil -D -d /etc/pki/nssdb -n "ARTERIS.COM IPA CA" -a

rob






*From:* John Dennis 
*Sent:* Thursday, October 12, 2017 6:10 AM
*To:* FreeIPA users list
*Cc:* Bhavin Vaidya; Rob Crittenden
*Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
On 10/12/2017 03:29 AM, Rob Crittenden via FreeIPA-users wrote:

Bhavin Vaidya via FreeIPA-users wrote:

Hello,


I'm having various problem on our FreeIPA setup, like can not establish
new replica server or add a client anymore. Initially we had
certificate
issue, then we upgraded the Master FreeIPA server (CentOS 7.0.146) to
FreeIPA v4.4.0) few months back.


On master server it shows up 4 entries for