Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Alexander Bokovoy]

On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote:

I am new to FreeIPA and have inherited two IPA servers not sure if one
is a master/slave or how they are different.  I will try to give some
pertinent outputs below of some of the things I am seeing.  I know the
Server-Cert is expired but can't figure out how to renew it.  There
also appears to be Kerberos authentication issues going on as I'm
trying to fix it.

#getcert list -d /etc/httpd/alias -n ipaCert
Number of certificates and requests being tracked: 2.
Request ID '20150922143354':
   status: NEED_TO_SUBMIT
   stuck: no
   key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
   certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
   CA: dogtag-ipa-retrieve-agent-submit
   issuer: CN=Certificate Authority,O=.GOV
   subject: CN=IPA RA,O=.GOV
   expires: 2013-10-09 11:45:01 UTC
   key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
   eku: id-kp-serverAuth,id-kp-clientAuth
   pre-save command:
   post-save command: /usr/lib64/ipa/certmonger/restart_httpd
   track: yes
   auto-renew: yes

#certutil -V -u V -n Server-Cert -d /etc/httpd/alias
certutil: certificate is invalid: Peer's Certificate has expired.


#certutil -L -d /etc/httpd/alias -n Server-Cert
Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number: 166 (0xa6)
   Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
   Issuer: "CN=Certificate Authority,O=.GOV"
   Validity:
   Not Before: Sun Sep 22 17:46:26 2013
   Not After : Wed Sep 23 17:46:26 2015
   Subject: "CN=comipa02..gov,O=.GOV"
   Subject Public Key Info:
   Public Key Algorithm: PKCS #1 RSA Encryption
   RSA Public Key:
   Modulus:
   c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9:
   e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40:
   ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8:
   6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40:
   51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d:
   14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f:
   c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44:
   9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30:
   ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81:
   0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c:
   ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc:
   5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae:
   15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03:
   11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51:
   a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8:
   32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb
   Exponent: 65537 (0x10001)
   Signed Extensions:
   Name: Certificate Authority Key Identifier
   Key ID:
   ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50:
   c3:13:4b:16

   Name: Authority Information Access
   Method: PKIX Online Certificate Status Protocol
   Location:
   URI: "http://comipa01..gov:80/ca/ocsp"

   Name: Certificate Key Usage
   Critical: True
   Usages: Digital Signature
   Non-Repudiation
   Key Encipherment
   Data Encipherment

   Name: Extended Key Usage
   TLS Web Server Authentication Certificate
   TLS Web Client Authentication Certificate

   Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
   Signature:
   2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98:
   d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5:
   44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2:
   64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a:
   c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa:
   b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07:
   6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2:
   43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57:
   ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57:
   01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5:
   b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7:
   0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f:
   7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38:
   f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70:
   5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0:
   7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f
   Fingerprint (SHA-256):
   
DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C
   Fingerprint (SHA1):
   88:51:F1:8F:3A:BD:7E:24:0D:4D:4A:CE:94:FB:A9:75:14:82:58:FA

   

Re: [Freeipa-users] Slow SSH login for IPA users only

[Guillem Liarte]

Sumit,

Thanks for you reply.

Ues, I have debug enabled: With level 5 I see that here is where it spends
most of its time:

(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info]
(0x0200): Got request for [0x1][1][name=testuser]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info]
(0x0200): Got request for [0x1][1][name=testuser]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]] [be_get_account_info]
(0x0200): Got request for [0x3][1][name=testuser]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:17 2015) [sssd[be[#.com]]]
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)]
(Wed Oct  7 13:14:18 2015) [sssd[be[#.com]]] [acctinfo_callback] (0x0100):
Request processed. Returned 0,0,Success

Note that I removed the real domain name, also to make it a short line.


After  reading in this pots:

https://www.centos.org/forums/viewtopic.php?f=47=53652

I actually saw that setting selinux_provider = none improved things quite a
lot.

Still, what is this message:

[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
domain SID from [(null)

?

Regards,

Guillem

On 7 October 2015 at 12:35, Sumit Bose  wrote:

> On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote:
> > All,
> >
> > I have an IPA 4.1 installation that works perfectly. We just suffer from
> > slow logins ( this is also slow in other operations such invoking SUDO )
> >
> > IPA user:
> >
> > 1st. login: 30 seconds
> > 2nd login: 8 seconds
> > 3rd  login: 6.5 seconds
> > 4rth login: 20 seconds
> >
> > Local user:
> >
> > Consistently under 2  seconds
> >
> > In SSH have tried:
> >
> > Setting UseDNS to no
> > Setting GSSAPIAuthentication to no
> >
> > I have tried various things that would work on an slow SSH, with no
> effect.
> > In fact, local users have no problem.
> >
> > DNS both forward and reverse works well, works fast and gives consistent
> > results. That is no the issue.
> >
> > While trying to find out more about the issue, I see that after the
> client
> > has connected, it spends most of the time here:
> >
> > [...]
> > debug2: input_userauth_pk_ok: fp
> > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
> > debug3: sign_and_send_pubkey: RSA
> > e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
> > debug1: Authentication succeeded (publickey).
> > [...]
> >
> > At first I though it might be the key retrival from the IPA service, but
> it
> > is actually quite fast:
> >
> > time /usr/bin/sss_ssh_authorizedkeys testuser
> > real0m0.209s
> >
> > We have all the configration files just as they were after installing the
> > ipa-client. The only modification was made to sshd_config as  these two
> > lines:
> >
> > AuthorizedKeysCommand  /usr/bin/sss_ssh_authorizedkeys
> > AuthorizedKeysCommandUser nobody
> >
> > I also tried removing the _srv_ in the ipa server line in sssd.conf, but
> > that did not make any difference either.
> >
> > So, in brief:
> >
> > - SSH is fast for local users
> > - authorized keys get retrieved quickly
> > - no DNS issues.
> > - IPA users take from 6 to 30 seconds to login (and also to perform sudo
> > invocations)
> > - While watching ssh logins, for  ipa users, it takes a long time to pass
> > these two:
> >
> >- input_userauth_pk_ok
> >- sign_and_send_pubkey
> >
> > Could someone give me an idea of what to try next?
>
> Please check the SSSD logs especailly the ones for the domain. You might
> need to increase the debug_level, please see
> 

[Freeipa-users] Upgrade of schema has broken permissions and now no one can authenticate if they have certain permissions

[Alex Williams]

Hi folks,

this one is becoming a bit of a major issue now. We upgraded one of our 
IPA3.0.0 servers to use the new dogtag schema over the last few days, 
then created an IPA4 replica from it successfully, upgraded the schema 
on a few more of the IPA3.0.0 servers and joined them into the mix and 
everything appeared to go ok. Unfortunately, the IPA3 replica schemas 
did not appear to get updated automatically, as the redhat upgrade 
documentation suggests it will, so we had to do them manually. One last 
server needed doing this morning and it was manually updated earlier 
today, a force-sync from one of the other servers was done to ensure it 
was up to date and Immediately after the sync finished, everyone was 
then refused authentication for SSH, logging into the web UI for IPA and 
ultimately, our VPN, which is an OpenVPN server on the IPA realm, using 
PAM to authenticate users. We've narrowed this down to permission issues 
by tailing the /var/log/sssd/sssd_OUR_DOMAIN.log, after increasing 
sssd's debug level. We discovered lines like below on a server we were 
attempting to ssh into:


(Thu Oct 8 13:51:16 2015) [sssd[be[domain-replaced.com]]] 
[hbac_eval_user_element] (0x0080): Parse error on [cn=add 
krbprincipalname to a 
host+nsuniqueid=1e4b0d05-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]
(Thu Oct 8 14:01:45 2015) [sssd[be[domain-replaced.com]]] 
[hbac_eval_user_element] (0x0080): Parse error on [cn=add sudo 
command+nsuniqueid=1e4b0d0a-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]


If we remove all of a users roles, that user is able to authenticate and 
the SSH session continues unhindered. Of course a user with no roles, 
therefore no permissions, is not really able to do anything, so we have 
to add permissions back in. Unfortunately, there seems to be rather a 
lot of them that are broken.


Any help would be hugely appreciated, as this was a production upgrade, 
after much planning, which somehow seems to have ended up broken.


Kind Regards

Alex Williams

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Rob Crittenden]

Gronde, Christopher (Contractor) wrote:
> Now I am getting CA_UNREACHABLE
> 
> # ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt -K 
> HTTP/comipa02..gov -C /usr/lib64/ipa/certmonger/restart_httpd
> Resubmitting "20151007150853" to "IPA".
> 
> # ipa-getcert list
> Number of certificates and requests being tracked: 2.
> Request ID '20151007150853':
> status: CA_UNREACHABLE
> ca-error: Error setting up ccache for "host" service on client using 
> default keytab: Cannot contact any KDC for realm '.GOV'.
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=.GOV
> subject: CN=comipa02.itmodev.gov,O=.GOV
> expires: 2015-09-23 17:46:26 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes

What really baffles me is what happened to the original tracking for
these certificates. Based on the original e-mail only 2 of the 8 are
being tracked at all.

What version of IPA is this? rpm -q ipa-server

I'm guessing that the IPA services aren't running due to the expired
certificates. You'll need to roll back the time to before Sept 22, at
last, to get things up and running.

rob

> 
> 
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
> Sent: Thursday, October 08, 2015 9:00 AM
> To: Gronde, Christopher (Contractor) 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
> manually renewing Server-Cert
> 
> Hi,
> 
> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote:
>> Thank you for your response!
> Do not respond directly, send your emails to the mailing list, please.
> 
>> Yes "getent passwd admin" does work
>>
>> # getent passwd admin
>> admin:*:127820:127820:Administrator:/home/admin:/bin/bash
>>
>> The second not returned:
>>
>> # ipa-getcert resubmit -i 20151007150853 -p 
>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>>
>> ]# ipa-getcert resubmit -i 20151007150853 -p 
>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>> [root@comipa02 conf.d]# ipa-getcert list Number of certificates and 
>> requests being tracked: 2.
>> Request ID '20151007150853':
>>status: MONITORING
>>ca-error: Unable to determine principal name for signing request.
> So it doesn't know whom to map the cert to.
> 
> When re-submitting the request with ipa-getcert, add
>   -K HTTP/comipa02.itmodev.gov
> 
> While at it, I've looked at my test setup and I can see that your 
> configuration below lacks restart of httpd after certificate was
> rotated:
>   -C /usr/lib64/ipa/certmonger/restart_httpd
> 
> 
>>stuck: no
>>key pair storage: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>certificate: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB'
>>CA: IPA
>>issuer: CN=Certificate Authority,O=.GOV
>>subject: CN=comipa02.itmodev.gov,O=.GOV
>>expires: 2015-09-23 17:46:26 UTC
>>key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>eku: id-kp-serverAuth,id-kp-clientAuth
>>pre-save command:
>>post-save command:
>>track: yes
>>auto-renew: yes
>>
>> This Cert however still shows expired.  What do I need to do to go about 
>> renewing it?
>>
>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>> certutil: certificate is invalid: Peer's Certificate has expired.
>>
>>
>>
>> -Original Message-
>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>> Sent: Thursday, October 08, 2015 2:22 AM
>> To: Gronde, Christopher (Contractor) 
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Certmonger and dogtag not 
>> workingissues manually renewing Server-Cert
>>
>> On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote:
>>> I am new to FreeIPA and have inherited two IPA servers not sure if one 
>>> is a master/slave or how they are different.  I will try to give some 
>>> pertinent outputs below of some of the things I am seeing.  I know the 
>>> Server-Cert is expired but can't figure out how to renew it.  There 
>>> also appears to be Kerberos authentication issues going on as I'm 
>>> trying to fix it.
>>>
>>> #getcert list -d /etc/httpd/alias -n ipaCert 

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Alexander Bokovoy]

Hi,

On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote:

Thank you for your response!

Do not respond directly, send your emails to the mailing list, please.


Yes "getent passwd admin" does work

# getent passwd admin
admin:*:127820:127820:Administrator:/home/admin:/bin/bash

The second not returned:

# ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt
Resubmitting "20151007150853" to "IPA".

]# ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt
Resubmitting "20151007150853" to "IPA".
[root@comipa02 conf.d]# ipa-getcert list
Number of certificates and requests being tracked: 2.
Request ID '20151007150853':
   status: MONITORING
   ca-error: Unable to determine principal name for signing request.

So it doesn't know whom to map the cert to.

When re-submitting the request with ipa-getcert, add 
 -K HTTP/comipa02.itmodev.gov


While at it, I've looked at my test setup and I can see that your
configuration below lacks restart of httpd after certificate was
rotated:
 -C /usr/lib64/ipa/certmonger/restart_httpd



   stuck: no
   key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
   certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
   CA: IPA
   issuer: CN=Certificate Authority,O=.GOV
   subject: CN=comipa02.itmodev.gov,O=.GOV
   expires: 2015-09-23 17:46:26 UTC
   key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
   eku: id-kp-serverAuth,id-kp-clientAuth
   pre-save command:
   post-save command:
   track: yes
   auto-renew: yes

This Cert however still shows expired.  What do I need to do to go about 
renewing it?

# certutil -V -u V -n Server-Cert -d /etc/httpd/alias
certutil: certificate is invalid: Peer's Certificate has expired.



-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Thursday, October 08, 2015 2:22 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote:

I am new to FreeIPA and have inherited two IPA servers not sure if one
is a master/slave or how they are different.  I will try to give some
pertinent outputs below of some of the things I am seeing.  I know the
Server-Cert is expired but can't figure out how to renew it.  There
also appears to be Kerberos authentication issues going on as I'm
trying to fix it.

#getcert list -d /etc/httpd/alias -n ipaCert Number of certificates and
requests being tracked: 2.
Request ID '20150922143354':
   status: NEED_TO_SUBMIT
   stuck: no
   key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
   certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
   CA: dogtag-ipa-retrieve-agent-submit
   issuer: CN=Certificate Authority,O=.GOV
   subject: CN=IPA RA,O=.GOV
   expires: 2013-10-09 11:45:01 UTC
   key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
   eku: id-kp-serverAuth,id-kp-clientAuth
   pre-save command:
   post-save command: /usr/lib64/ipa/certmonger/restart_httpd
   track: yes
   auto-renew: yes

#certutil -V -u V -n Server-Cert -d /etc/httpd/alias
certutil: certificate is invalid: Peer's Certificate has expired.


#certutil -L -d /etc/httpd/alias -n Server-Cert
Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number: 166 (0xa6)
   Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
   Issuer: "CN=Certificate Authority,O=.GOV"
   Validity:
   Not Before: Sun Sep 22 17:46:26 2013
   Not After : Wed Sep 23 17:46:26 2015
   Subject: "CN=comipa02..gov,O=.GOV"
   Subject Public Key Info:
   Public Key Algorithm: PKCS #1 RSA Encryption
   RSA Public Key:
   Modulus:
   c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9:
   e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40:
   ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8:
   6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40:
   51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d:
   14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f:
   c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44:
   9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30:
   ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81:
   0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c:
   ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc:
   

Re: [Freeipa-users] Upgrade of schema has broken permissions and now no one can authenticate if they have certain permissions

[Martin Basti]

On 10/08/2015 03:23 PM, Alex Williams wrote:

Hi folks,

this one is becoming a bit of a major issue now. We upgraded one of 
our IPA3.0.0 servers to use the new dogtag schema over the last few 
days, then created an IPA4 replica from it successfully, upgraded the 
schema on a few more of the IPA3.0.0 servers and joined them into the 
mix and everything appeared to go ok. Unfortunately, the IPA3 replica 
schemas did not appear to get updated automatically, as the redhat 
upgrade documentation suggests it will, so we had to do them manually. 
One last server needed doing this morning and it was manually updated 
earlier today, a force-sync from one of the other servers was done to 
ensure it was up to date and Immediately after the sync finished, 
everyone was then refused authentication for SSH, logging into the web 
UI for IPA and ultimately, our VPN, which is an OpenVPN server on the 
IPA realm, using PAM to authenticate users. We've narrowed this down 
to permission issues by tailing the /var/log/sssd/sssd_OUR_DOMAIN.log, 
after increasing sssd's debug level. We discovered lines like below on 
a server we were attempting to ssh into:


(Thu Oct 8 13:51:16 2015) [sssd[be[domain-replaced.com]]] 
[hbac_eval_user_element] (0x0080): Parse error on [cn=add 
krbprincipalname to a 
host+nsuniqueid=1e4b0d05-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]
(Thu Oct 8 14:01:45 2015) [sssd[be[domain-replaced.com]]] 
[hbac_eval_user_element] (0x0080): Parse error on [cn=add sudo 
command+nsuniqueid=1e4b0d0a-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]

IMHO the entries above have replication conflict

Please follow: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


Martin



If we remove all of a users roles, that user is able to authenticate 
and the SSH session continues unhindered. Of course a user with no 
roles, therefore no permissions, is not really able to do anything, so 
we have to add permissions back in. Unfortunately, there seems to be 
rather a lot of them that are broken.


Any help would be hugely appreciated, as this was a production 
upgrade, after much planning, which somehow seems to have ended up 
broken.


Kind Regards

Alex Williams



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

Now I am getting CA_UNREACHABLE

# ipa-getcert resubmit -i 20151007150853 -p /etc/httpd/alias/pwdfile.txt -K 
HTTP/comipa02..gov -C /usr/lib64/ipa/certmonger/restart_httpd
Resubmitting "20151007150853" to "IPA".

# ipa-getcert list
Number of certificates and requests being tracked: 2.
Request ID '20151007150853':
status: CA_UNREACHABLE
ca-error: Error setting up ccache for "host" service on client using 
default keytab: Cannot contact any KDC for realm '.GOV'.
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=.GOV
subject: CN=comipa02.itmodev.gov,O=.GOV
expires: 2015-09-23 17:46:26 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes


-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: Thursday, October 08, 2015 9:00 AM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

Hi,

On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote:
>Thank you for your response!
Do not respond directly, send your emails to the mailing list, please.

>Yes "getent passwd admin" does work
>
># getent passwd admin
>admin:*:127820:127820:Administrator:/home/admin:/bin/bash
>
>The second not returned:
>
># ipa-getcert resubmit -i 20151007150853 -p 
>/etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>
>]# ipa-getcert resubmit -i 20151007150853 -p 
>/etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>[root@comipa02 conf.d]# ipa-getcert list Number of certificates and 
>requests being tracked: 2.
>Request ID '20151007150853':
>status: MONITORING
>ca-error: Unable to determine principal name for signing request.
So it doesn't know whom to map the cert to.

When re-submitting the request with ipa-getcert, add
  -K HTTP/comipa02.itmodev.gov

While at it, I've looked at my test setup and I can see that your configuration 
below lacks restart of httpd after certificate was
rotated:
  -C /usr/lib64/ipa/certmonger/restart_httpd


>stuck: no
>key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
>CA: IPA
>issuer: CN=Certificate Authority,O=.GOV
>subject: CN=comipa02.itmodev.gov,O=.GOV
>expires: 2015-09-23 17:46:26 UTC
>key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>eku: id-kp-serverAuth,id-kp-clientAuth
>pre-save command:
>post-save command:
>track: yes
>auto-renew: yes
>
>This Cert however still shows expired.  What do I need to do to go about 
>renewing it?
>
># certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>certutil: certificate is invalid: Peer's Certificate has expired.
>
>
>
>-Original Message-
>From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>Sent: Thursday, October 08, 2015 2:22 AM
>To: Gronde, Christopher (Contractor) 
>Cc: freeipa-users@redhat.com
>Subject: Re: [Freeipa-users] Certmonger and dogtag not 
>workingissues manually renewing Server-Cert
>
>On Wed, 07 Oct 2015, Gronde, Christopher (Contractor) wrote:
>>I am new to FreeIPA and have inherited two IPA servers not sure if one 
>>is a master/slave or how they are different.  I will try to give some 
>>pertinent outputs below of some of the things I am seeing.  I know the 
>>Server-Cert is expired but can't figure out how to renew it.  There 
>>also appears to be Kerberos authentication issues going on as I'm 
>>trying to fix it.
>>
>>#getcert list -d /etc/httpd/alias -n ipaCert Number of certificates 
>>and requests being tracked: 2.
>>Request ID '20150922143354':
>>status: NEED_TO_SUBMIT
>>stuck: no
>>key pair storage: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>certificate: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
>> Certificate DB'
>>CA: dogtag-ipa-retrieve-agent-submit
>>issuer: CN=Certificate Authority,O=.GOV
>>subject: CN=IPA RA,O=.GOV
>>expires: 2013-10-09 11:45:01 UTC
>>key usage: 
>> 

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

Currently running ipa-server-3.0.0-47.el6.x86_64

I have stopped ntpd and reset the date to Sept 21st.  Yes I agree this has been 
baffling me for days.


-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, October 08, 2015 9:49 AM
To: Gronde, Christopher (Contractor) ; Alexander 
Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

Gronde, Christopher (Contractor) wrote:
> Now I am getting CA_UNREACHABLE
> 
> # ipa-getcert resubmit -i 20151007150853 -p 
> /etc/httpd/alias/pwdfile.txt -K HTTP/comipa02..gov -C 
> /usr/lib64/ipa/certmonger/restart_httpd
> Resubmitting "20151007150853" to "IPA".
> 
> # ipa-getcert list
> Number of certificates and requests being tracked: 2.
> Request ID '20151007150853':
> status: CA_UNREACHABLE
> ca-error: Error setting up ccache for "host" service on client using 
> default keytab: Cannot contact any KDC for realm '.GOV'.
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=.GOV
> subject: CN=comipa02.itmodev.gov,O=.GOV
> expires: 2015-09-23 17:46:26 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes

What really baffles me is what happened to the original tracking for these 
certificates. Based on the original e-mail only 2 of the 8 are being tracked at 
all.

What version of IPA is this? rpm -q ipa-server

I'm guessing that the IPA services aren't running due to the expired 
certificates. You'll need to roll back the time to before Sept 22, at last, to 
get things up and running.

rob

> 
> 
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: Thursday, October 08, 2015 9:00 AM
> To: Gronde, Christopher (Contractor) 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Certmonger and dogtag not 
> workingissues manually renewing Server-Cert
> 
> Hi,
> 
> On Thu, 08 Oct 2015, Gronde, Christopher (Contractor) wrote:
>> Thank you for your response!
> Do not respond directly, send your emails to the mailing list, please.
> 
>> Yes "getent passwd admin" does work
>>
>> # getent passwd admin
>> admin:*:127820:127820:Administrator:/home/admin:/bin/bash
>>
>> The second not returned:
>>
>> # ipa-getcert resubmit -i 20151007150853 -p 
>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>>
>> ]# ipa-getcert resubmit -i 20151007150853 -p 
>> /etc/httpd/alias/pwdfile.txt Resubmitting "20151007150853" to "IPA".
>> [root@comipa02 conf.d]# ipa-getcert list Number of certificates and 
>> requests being tracked: 2.
>> Request ID '20151007150853':
>>status: MONITORING
>>ca-error: Unable to determine principal name for signing request.
> So it doesn't know whom to map the cert to.
> 
> When re-submitting the request with ipa-getcert, add
>   -K HTTP/comipa02.itmodev.gov
> 
> While at it, I've looked at my test setup and I can see that your 
> configuration below lacks restart of httpd after certificate was
> rotated:
>   -C /usr/lib64/ipa/certmonger/restart_httpd
> 
> 
>>stuck: no
>>key pair storage: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>certificate: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB'
>>CA: IPA
>>issuer: CN=Certificate Authority,O=.GOV
>>subject: CN=comipa02.itmodev.gov,O=.GOV
>>expires: 2015-09-23 17:46:26 UTC
>>key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>eku: id-kp-serverAuth,id-kp-clientAuth
>>pre-save command:
>>post-save command:
>>track: yes
>>auto-renew: yes
>>
>> This Cert however still shows expired.  What do I need to do to go about 
>> renewing it?
>>
>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>> certutil: certificate is invalid: Peer's Certificate has expired.
>>
>>
>>
>> -Original Message-
>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>> Sent: Thursday, October 08, 2015 2:22 AM
>> To: Gronde, Christopher (Contractor) 
>> Cc: freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] Certmonger and dogtag not 
>> workingissues manually renewing 

Re: [Freeipa-users] sudo rules do not seem to work

[Karl Forner]

Sorry I had disabled the emailing, just was your answers in the archives.


>> How can I debug this ?

>Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?

Where is it ? Do you mean the slide
"FreeIPA Training Series: Obtaining debugging information" from
https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
?

Thanks !
Karl

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

When I ran "getcert list" rather than "ipa-getcert list" I get the following:

# getcert list
Number of certificates and requests being tracked: 2.
Request ID '20150922143354':
status: NEED_TO_SUBMIT
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=ITMODEV.GOV
subject: CN=IPA RA,O=ITMODEV.GOV
expires: 2013-10-09 11:45:01 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
Request ID '20151007150853':
status: CA_UNREACHABLE
ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed 
request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. 
 Peer certificate cannot be authenticated with known CA certificates).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=ITMODEV.GOV
subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV
expires: 2015-09-23 17:46:26 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, October 08, 2015 10:33 AM
To: Gronde, Christopher (Contractor) ; Alexander 
Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

Gronde, Christopher (Contractor) wrote:
> Currently running ipa-server-3.0.0-47.el6.x86_64
> 
> I have stopped ntpd and reset the date to Sept 21st.  Yes I agree this has 
> been baffling me for days.

You should be tracking 8 certificates. The output of `getcert list` should look 
something like:

Number of certificates and requests being tracked: 8.
Request ID '20150102143352':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=CA Audit,O=EXAMPLE.COM
expires: 2016-12-22 14:33:08 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20150102143353':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=OCSP Subsystem,O=EXAMPLE.COM
expires: 2016-12-22 14:33:07 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20150102143354':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=CA Subsystem,O=EXAMPLE.COM
expires: 2016-12-22 14:33:07 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
   

[Freeipa-users] Announcing FreeIPA 4.2.2

[Petr Vobornik]

The FreeIPA team would like to announce FreeIPA v4.2.2 security release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds are available for Fedora 23 
 and 
rawhide. Builds for Fedora 22 are available in the official COPR 
repository .


This announcement is also available at 
.


== Highlights in 4.2.2 ==
FreeIPA 4.2.0 introduced Key Archival Agent (KRA) support. This release 
fixes CVE-2015-5284. The CVE affects IPA servers where ipa-kra-install 
was run. Read manual instructions if your system was affected 
.


=== Bug fixes ===
* CVE-2015-5284: ipa-kra-install included certificate and private key in 
world readable file.

* Firefox configuration steps were adjusted to new extension signing policy.
* ipa-restore does not overwrite files with local users/groups
* ipa-restore now works with KRA installed
* Fixed an integer underflow bug in libotp which prevented from syncing 
TOTP tokens under certain circumstances.
* winsync-migrate properly handles collisions in the names of external 
group

* Fixed regression where installation of CA failed on CA-less server #5288.
* Vault operations now works on a replica without KRA installed 
(assuming that at least one replica has KRA installed). #5302


=== Enhancements ===
* Improved performance of search in Web UI's dialog for adding e.g. 
users to e.g. sudo rules.
* Modified vault access control and  added commands for managing vault 
containers. #5250
* Added support for generating client referrals for trusted domain 
principals. Note that bug 
https://bugzilla.redhat.com/show_bug.cgi?id=1259844 has to be fixed in 
MIT Kerberos packages to allow client referrals from FreeIPA KDC to be 
processed.


== Upgrading ==
Upgrade instructions are available on upgrade page 
.


== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed Changelog since 4.2.1 ==

=== Abhijeet Kasurde (1) ===
* Updated number of legacy permission in ipatests

=== Alexander Bokovoy (1) ===
* client referral support for trusted domain principals

=== Christian Heimes (1) ===
* Handle timeout error in ipa-httpd-kdcproxy

=== Gabe Alford (4) ===
* Add Chromium configuration note to ssbrowser
* Standardize minvalue for ipasearchrecordlimit and ipasesarchsizelimit 
for unlimited minvalue

* dnssec option missing in ipa-dns-install man page
* Update FreeIPA package description

=== Jan Cholasta (16) ===
* config: allow user/host attributes with tagging options
* baseldap: make subtree deletion optional in LDAPDelete
* vault: set owner to current user on container creation
* vault: update access control
* vault: add permissions and administrator privilege
* install: support KRA update
* install: Support overriding knobs in subclasses
* install: Add common base class for server and replica install
* install: Move unattended option to the general help section
* install: create kdcproxy user during server install
* platform: add option to create home directory when adding user
* install: fix kdcproxy user home directory
* install: fix ipa-server-install fail on missing --forwarder
* install: fix KRA agent PEM file permissions
* install: always export KRA agent PEM file
* vault: select a server with KRA for vault operations

=== Martin Babinsky (5) ===
* load RA backend plugins during standalone CA install on CA-less IPA master
* destroy httpd ccache after stopping the service
* ipa-server-install: mark master_password Knob as deprecated
* re-kinit after ipa-restore in backup/restore CI tests
* do not overwrite files with local users/groups when restoring authconfig

=== Martin Bašti (11) ===
* FIX vault tests
* Server Upgrade: backup CS.cfg when dogtag is turned off
* IPA Restore: allows to specify files that should be removed
* DNSSEC: improve CI test
* DNSSEC CI: test master migration
* backup CI: test DNS/DNSSEC after backup and restore
* Limit max age of replication changelog
* Server Upgrade: addifnew should not create entry
* CI: backup and restore with KRA
* Replica inst. fix: do not require -r, -a, -p options in unattended mode
* Fix import get_reverse_zone_default in tasks

=== Milan Kubík (4) ===
* ipatests: Add Certprofile tracker class implementation
* ipatests: Add basic tests for certificate profile plugin
* ipatests: configure Network Manager not to manage resolv.conf
* Include ipatests/test_xmlrpc/data directory into distribution.

=== Nathaniel McCallum (1) ===
* Fix an integer underflow bug in libotp

=== Oleg Fayans (1) ===
* Added a proper workaround for dnssec test failures in Beaker environment

=== Petr Voborník (4) ===
* vault: add vault 

[Freeipa-users] (no subject)

[Karl Forner]

Hi,


> you are prompted for password because (ALL) ALL rule is applied because of 
> last-match rule. > > > See: 
> http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.

Ok. I updated the rules to use a sudoorder attribute of 100 for the
/usr/bin/less sudo rule.
Now, if I type in a terminal:
%sudo -l
Matching Defaults entries for karl on midgard:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
(ALL) ALL
(root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
(ALL) ALL
(ALL) NOPASSWD: /usr/bin/less

so my less rule is the last one. So far so good.

%sudo -l less
/usr/bin/less

but if I type in a new terminal:
%sudo less .bashrc
[sudo] password for karl:

I am prompted to type in a password.

So there seems to be a problem, right ?

Regards,
Karl

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Pavel Březina]

On 10/08/2015 04:09 PM, Karl Forner wrote:

Sorry I had disabled the emailing, just was your answers in the archives.



How can I debug this ?



Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?


Where is it ? Do you mean the slide
"FreeIPA Training Series: Obtaining debugging information" from
https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
?

Thanks !
Karl



It is not yet publicly available.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] (no subject)

[Pavel Březina]

On 10/08/2015 04:26 PM, Karl Forner wrote:

Hi,



you are prompted for password because (ALL) ALL rule is applied because of last-match 
rule. > > > See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.


Ok. I updated the rules to use a sudoorder attribute of 100 for the
/usr/bin/less sudo rule.
Now, if I type in a terminal:
%sudo -l
Matching Defaults entries for karl on midgard:
 env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User karl may run the following commands on :
 (ALL) ALL
 (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
 (ALL) ALL
 (ALL) NOPASSWD: /usr/bin/less

so my less rule is the last one. So far so good.

%sudo -l less
/usr/bin/less

but if I type in a new terminal:
%sudo less .bashrc
[sudo] password for karl:

I am prompted to type in a password.

So there seems to be a problem, right ?

Regards,
Karl



Hi,
we have a bug in sssd in versions prior 1.13.1:
https://fedorahosted.org/sssd/ticket/2682

where sudoOrder attribute is treated the other ways around. Please, try 
inverting the order. What version of sssd do you use?


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Rob Crittenden]

Gronde, Christopher (Contractor) wrote:
> When I ran "getcert list" rather than "ipa-getcert list" I get the following:
> 
> # getcert list
> Number of certificates and requests being tracked: 2.
> Request ID '20150922143354':
> status: NEED_TO_SUBMIT
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
> CA: dogtag-ipa-retrieve-agent-submit
> issuer: CN=Certificate Authority,O=ITMODEV.GOV
> subject: CN=IPA RA,O=ITMODEV.GOV
> expires: 2013-10-09 11:45:01 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
> Request ID '20151007150853':
> status: CA_UNREACHABLE
> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed 
> request, will retry: -504 (libcurl failed to execute the HTTP POST 
> transaction.  Peer certificate cannot be authenticated with known CA 
> certificates).
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=ITMODEV.GOV
> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV
> expires: 2015-09-23 17:46:26 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes

I don't know how the certificates became un-tracked but the result is
that the expiration date passed and I can only assume that they are all
expired now. What is really strange is that someone poked at ipaCert
last month, though that cert expired 2 years ago. The Apache cert is
equally confusing as it has probably been renewed at least once given
the date of ipaCert.

In any case, the first thing to do is to see what the state of the other
certs are. These will enable certmonger tracking of them.

NOTE: I haven't tested these commands on a live system but I think it is
right.

# grep internal= /var/lib/pki-ca/conf/password.conf

The series of numbers is the PIN you need next.

# for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert
cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
do
getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c
dogtag-ipa-renew-agent -P  -B
/usr/lib64/ipa/certmonger/stop_pkicad -C
'/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"'
done

The tracking is incorrect for ipaCert so you'll need to try to fix it with:

# getcert start-tracking -i 20150922143354 -C
/usr/lib64/ipa/certmonger/renew_ra_cert

And finally track the 389-ds certs:

# getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p
/etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C
'/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV'
# getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p
/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C
'/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA'

So now theoretically getcert list will show all 8 certificates as being
tracked.

Start with the 4 CA certificates and see when they expire. Stop ntpd if
running, go back to when those are valid and try restarting the CA. You
may have to go back *really* far given the expiration date of ipaCert.
In fact, to get things working you might have to go back, renew some of
the certs, move forward to when those would expire last month and renew
again.

# service pki-cad restart

Give it a minute to fully start then try the renewal either by
restarting certmonger or for each of the CA subsystem certs run getcert
resubmit -i .

Assuming that worked next try to renew ipaCert. If that gets renewed
then do the 3 remaining certs: Apache and the two 389-ds instances.

If that works run ipactl stop, bring time forward, ipactl start.

rob


> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com] 
> Sent: Thursday, October 08, 2015 10:33 AM
> To: Gronde, Christopher (Contractor) ; 
> Alexander Bokovoy 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
> manually renewing Server-Cert
> 
> Gronde, Christopher (Contractor) wrote:
>> Currently running ipa-server-3.0.0-47.el6.x86_64
>>
>> I have stopped ntpd and 

[Freeipa-users] Cleanly removing replication agreement

[Dominik Korittki]

Hello folks,

i have two FreeIPA 3.3 Machines running on CentOS7: ipa01.internal and 
ipa02.internal. Both have a CA installed.
Initially ipa02 is a replication from ipa01. Recently ipa01 had some 
trouble while ipa02 was running fine (see "FreeIPA 3.3 performance 
issues with many hosts" on this maillinglist).


So what i did was to uninstall ipa01 via "ipa-server-install 
--uninstall" and recreated ipa01 as a replica of ipa02 via 
"ipa-replica-install --setup-ca". Since then I was having trouble with 
replication. It seems to be there is still some RUV information about 
the old ipa01 in the database.


Well long story short: I want to completely delete ipa02 from the 
replication agreement on host ipa01 to be able to re-add ipa02 later.


Currently the situation on ipa01 is as follows:

root@ipa01:~ > ipa-replica-manage list
Directory Manager password:

ipa01.internal: master
ipa02.internal: master

root@ipa01:~ > ipa-replica-manage list-ruv
Directory Manager password:

ipa01.internal:389: 6
ipa02.internal:389: 5

root@ipa01:~ > ipa-csreplica-manage list
Directory Manager password:

ipa01.internal: master
ipa02.internal: master

root@ipa01:~ > ldapsearch -D "cn=directory manager" -W -b "cn=mapping 
tree,cn=config" 'objectClass=nsDS5ReplicationAgreement' nsds50ruv -LLL

Enter LDAP Password:
dn: 
cn=cloneAgreement1-ipa01.internal-pki-tomcat,cn=replica,cn=o\3Dipaca,cn=ma

 pping tree,cn=config
nsds50ruv: {replicageneration} 547485400060
nsds50ruv: {replica 97 ldap://ipa02.internal:389} 547485480061 
56139e1

 800020061
nsds50ruv: {replica 1095 ldap://ipa01.internal:389} 56139e170447 
56139

 e1e00020447
nsds50ruv: {replica 96 ldap://ipa01.internal:389}


I'm a bit worried about the ldapsearch command. There is a nsds50ruv 
attribute with value 1035. It appeared after I readded ipa01 into the 
replication agreement. Do I need to get rid of it and if yes, how?


Another question is: ipa02 is not responsible anymore, so the 
CLEANALLRUV Task started on ipa01 by "ipa-replica-manage del ..." would 
not be able to connect to ipa02. According to 389ds documentation it 
would stay active a long time trying to connect to the other host.  Is 
it save to abort the task via "ipa-replica-manage abort-clean-ruv ..." 
after a while?


Thanks in advance!


Kind regards,
Dominik

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

First commend came back:

]# grep internal= /var/lib/pki-ca/conf/password.conf
grep: /var/lib/pki-ca/conf/password.conf: No such file or directory

There is no pki-ca dir on this server

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, October 08, 2015 11:37 AM
To: Gronde, Christopher (Contractor) ; Alexander 
Bokovoy 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

Gronde, Christopher (Contractor) wrote:
> When I ran "getcert list" rather than "ipa-getcert list" I get the following:
> 
> # getcert list
> Number of certificates and requests being tracked: 2.
> Request ID '20150922143354':
> status: NEED_TO_SUBMIT
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
> CA: dogtag-ipa-retrieve-agent-submit
> issuer: CN=Certificate Authority,O=ITMODEV.GOV
> subject: CN=IPA RA,O=ITMODEV.GOV
> expires: 2013-10-09 11:45:01 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
> Request ID '20151007150853':
> status: CA_UNREACHABLE
> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed 
> request, will retry: -504 (libcurl failed to execute the HTTP POST 
> transaction.  Peer certificate cannot be authenticated with known CA 
> certificates).
> stuck: no
> key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=ITMODEV.GOV
> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV
> expires: 2015-09-23 17:46:26 UTC
> key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes

I don't know how the certificates became un-tracked but the result is that the 
expiration date passed and I can only assume that they are all expired now. 
What is really strange is that someone poked at ipaCert last month, though that 
cert expired 2 years ago. The Apache cert is equally confusing as it has 
probably been renewed at least once given the date of ipaCert.

In any case, the first thing to do is to see what the state of the other certs 
are. These will enable certmonger tracking of them.

NOTE: I haven't tested these commands on a live system but I think it is right.

# grep internal= /var/lib/pki-ca/conf/password.conf

The series of numbers is the PIN you need next.

# for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" 
"subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
do
getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c 
dogtag-ipa-renew-agent -P  -B 
/usr/lib64/ipa/certmonger/stop_pkicad -C 
'/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"'
done

The tracking is incorrect for ipaCert so you'll need to try to fix it with:

# getcert start-tracking -i 20150922143354 -C 
/usr/lib64/ipa/certmonger/renew_ra_cert

And finally track the 389-ds certs:

# getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p 
/etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C 
'/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV'
# getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p 
/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -n Server-Cert -C 
'/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA'

So now theoretically getcert list will show all 8 certificates as being tracked.

Start with the 4 CA certificates and see when they expire. Stop ntpd if 
running, go back to when those are valid and try restarting the CA. You may 
have to go back *really* far given the expiration date of ipaCert.
In fact, to get things working you might have to go back, renew some of the 
certs, move forward to when those would expire last month and renew again.

# service pki-cad restart

Give it a minute to fully start then try the renewal either by restarting 
certmonger or for each of the CA subsystem certs run getcert resubmit -i .

Assuming that worked next try to renew ipaCert. If that gets renewed then do 
the 3 remaining certs: Apache and the two 389-ds instances.

If that works 

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Rob Crittenden]

Gronde, Christopher (Contractor) wrote:
> First commend came back:
> 
> ]# grep internal= /var/lib/pki-ca/conf/password.conf
> grep: /var/lib/pki-ca/conf/password.conf: No such file or directory
> 
> There is no pki-ca dir on this server

That simplifies things a bit.

The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that
it has a CSR and it doesn't. This CA will attempt to fetch an update
cert from LDAP.

See what is available with:

% ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov

I'm just assuming your IPA Instance isn't actually running, right?
You'll probably need to go back in time to have any chance of this
working. Apache would be most vocal about not being able to start with
an expired cert and offer a means to workaround it (going back in time
is a better solution).

This is of course assuming that the other IPA master(s) actually have
renewed certificates themselves.

rob
> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com] 
> Sent: Thursday, October 08, 2015 11:37 AM
> To: Gronde, Christopher (Contractor) ; 
> Alexander Bokovoy 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
> manually renewing Server-Cert
> 
> Gronde, Christopher (Contractor) wrote:
>> When I ran "getcert list" rather than "ipa-getcert list" I get the following:
>>
>> # getcert list
>> Number of certificates and requests being tracked: 2.
>> Request ID '20150922143354':
>> status: NEED_TO_SUBMIT
>> stuck: no
>> key pair storage: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> certificate: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
>> Certificate DB'
>> CA: dogtag-ipa-retrieve-agent-submit
>> issuer: CN=Certificate Authority,O=ITMODEV.GOV
>> subject: CN=IPA RA,O=ITMODEV.GOV
>> expires: 2013-10-09 11:45:01 UTC
>> key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command:
>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>> track: yes
>> auto-renew: yes
>> Request ID '20151007150853':
>> status: CA_UNREACHABLE
>> ca-error: Server at https://comipa02.itmodev.gov/ipa/xml failed 
>> request, will retry: -504 (libcurl failed to execute the HTTP POST 
>> transaction.  Peer certificate cannot be authenticated with known CA 
>> certificates).
>> stuck: no
>> key pair storage: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> certificate: 
>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
>> Certificate DB'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=ITMODEV.GOV
>> subject: CN=comipa02.itmodev.gov,O=ITMODEV.GOV
>> expires: 2015-09-23 17:46:26 UTC
>> key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command:
>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>> track: yes
>> auto-renew: yes
> 
> I don't know how the certificates became un-tracked but the result is that 
> the expiration date passed and I can only assume that they are all expired 
> now. What is really strange is that someone poked at ipaCert last month, 
> though that cert expired 2 years ago. The Apache cert is equally confusing as 
> it has probably been renewed at least once given the date of ipaCert.
> 
> In any case, the first thing to do is to see what the state of the other 
> certs are. These will enable certmonger tracking of them.
> 
> NOTE: I haven't tested these commands on a live system but I think it is 
> right.
> 
> # grep internal= /var/lib/pki-ca/conf/password.conf
> 
> The series of numbers is the PIN you need next.
> 
> # for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert 
> cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
> do
> getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c 
> dogtag-ipa-renew-agent -P  -B 
> /usr/lib64/ipa/certmonger/stop_pkicad -C 
> '/usr/lib64/ipa/certmonger/renew_ca_cert "${nickname}"'
> done
> 
> The tracking is incorrect for ipaCert so you'll need to try to fix it with:
> 
> # getcert start-tracking -i 20150922143354 -C 
> /usr/lib64/ipa/certmonger/renew_ra_cert
> 
> And finally track the 389-ds certs:
> 
> # getcert start-tracking -d /etc/dirsrv/slapd-ITMODEV-GOV -p 
> /etc/dirsrv/slapd-ITMODEV-GOV/pwdfile.txt -n Server-Cert -C 
> '/usr/lib64/ipa/certmonger/restart_dirsrv ITMODEV-GOV'
> # getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -p 
> 

Re: [Freeipa-users] Web login problems

[Pat Gunn]

On 7/10/15 21:57, Simo Sorce wrote:

>On 07/10/15 13:36, Pat Gunn wrote:

Hi,
I'm trying to build a cluster of 3 IPA (staging at this point, but
eventually later I'll make a prod version)
systems (that will reside in AWS) that will manage select systems in our
infrastructure (mostly but not entirely in AWS).
The systems will be fronted (like most of our infrastructure) with a
load-balancer that manages pooling and SSL termination; we'd like
freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will
then route that to a specific one of the three servers based on pool
settings).

>Please read this before you proceed with your LB plan:
>http://ssimo.org/blog/id_019.html
>
>HTH,
>Simo.


Hi,

I spoke imprecisely. In our hoped-for design, our LB

will front access to the web interface for FreeIPA (to manage accounts
when needed), but the systems that will use FreeIPA for auth will be
contacting the servers directly (we care much more about the LDAP
functionality and the GUI than anything else, FWIW).


I think I at least identified the initial problem we're having - when
the auth is first posted, it succeeds, and the server sends a
Set-Cookie for ipa_session that unfortunately includes "Domain="
equivalent to the hostname. This seems unaffected by the Tomcat
convention for specifying a proxy as well as setting the host in
Apache. I could tell our LB to rewrite that cookie as it comes out of
the pool, but I'm hoping to figure out how to get FreeIPA's WebUI to
not set the Domain for that cookie or to set it to a specified value,
and to do that for only the WebUI.


I'm hoping our desired use case and existing infrastructure style
isn't incompatible with what FreeIPA is designed for. Any thoughts on
that or advice on getting that cookie sent as we like?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

# ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

ipa service was not running...I attempted to start it.

# service ipa start
Starting Directory Service
Starting dirsrv:
ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: 
CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of 
family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - 
Peer's Certificate has expired.)
   [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:  [  OK  ]
Starting MEMCACHE Service
Starting ipa_memcached:[  OK  ]
Starting HTTP Service
Starting httpd:[FAILED]
Failed to start HTTP Service
Shutting down
Stopping Kerberos 5 KDC:   [  OK  ]
Stopping Kerberos 5 Admin Server:  [  OK  ]
Stopping ipa_memcached:[  OK  ]
Stopping httpd:[FAILED]
Shutting down dirsrv:
ITMODEV-GOV... [  OK  ]
Aborting ipactl

Ntpd is still stopped but date was back to today so I changed the date back to 
9/21 and started ipa services

# service ipa start
Starting Directory Service
Starting dirsrv:
ITMODEV-GOV... [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:  [  OK  ]
Starting MEMCACHE Service
Starting ipa_memcached:[  OK  ]
Starting HTTP Service
Starting httpd:[  OK  ]

]# service ipa start
Starting Directory Service
Starting dirsrv:
ITMODEV-GOV...[08/Oct/2015:14:03:08 -0400] - SSL alert: 
CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of 
family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - 
Peer's Certificate has expired.)
   [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:  [  OK  ]
Starting MEMCACHE Service
Starting ipa_memcached:[  OK  ]
Starting HTTP Service
Starting httpd:[FAILED]
Failed to start HTTP Service
Shutting down
Stopping Kerberos 5 KDC:   [  OK  ]
Stopping Kerberos 5 Admin Server:  [  OK  ]
Stopping ipa_memcached:[  OK  ]
Stopping httpd:[FAILED]
Shutting down dirsrv:
ITMODEV-GOV... [  OK  ]
Aborting ipactl



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, October 08, 2015 1:51 PM
To: Gronde, Christopher (Contractor) 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Certmonger and dogtag not workingissues 
manually renewing Server-Cert

Gronde, Christopher (Contractor) wrote:
> First commend came back:
> 
> ]# grep internal= /var/lib/pki-ca/conf/password.conf
> grep: /var/lib/pki-ca/conf/password.conf: No such file or directory
> 
> There is no pki-ca dir on this server

That simplifies things a bit.

The NEED_TO_SUBMIT status is odd on ipaCert because that suggests that it has a 
CSR and it doesn't. This CA will attempt to fetch an update cert from LDAP.

See what is available with:

% ldapsearch -x -b cn=ca_renewal,cn=ipa,cn=etc,dc=itmodev,dc=gov

I'm just assuming your IPA Instance isn't actually running, right?
You'll probably need to go back in time to have any chance of this working. 
Apache would be most vocal about not being able to start with an expired cert 
and offer a means to workaround it (going back in time is a better solution).

This is of course assuming that the other IPA master(s) actually have renewed 
certificates themselves.

rob
> 
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Thursday, October 08, 2015 11:37 AM
> To: Gronde, Christopher (Contractor) ; 
> Alexander Bokovoy 
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] Certmonger and dogtag not 
> workingissues manually renewing Server-Cert
> 
> Gronde, Christopher (Contractor) wrote:
>> When I ran "getcert list" rather than "ipa-getcert list" I get the following:
>>
>> # getcert list
>> Number of certificates and requests being tracked: 2.
>> Request ID