Re: [Freeipa-users] FreeIPA4.2: Recovering from an IPA master server failure

[Martin Basti]

On 31.05.2016 17:36, Michael Rainey (Contractor) wrote:


Greetings community,

I've run into an interesting problem which may be old hat to all of 
you.  I was working to bring down my IPA master server and did it 
improperly.  It was a rookie mistake, but I'm willing to view it as an 
exercise in recovering from a massive system failure.


The original master server is gone with no way of recovering and I 
have managed to replace the server by promoting one of my replicas, 
but I find myself in a situation where I cannot remove the original 
master server from the LDAP directory.  It is still seen as a master 
server and the webUI will not let me delete the system from directory 
server.  Is there a process somewhere that will walk me through 
demoting the old server so I can delete it from the directory and 
officially promote its replacement?


For reference, I followed the steps located at this link.

Centos 7.2 / freeIPA 4.2

Your help is greatly appreciated.

--
*Michael Rainey*




Hello,

can you next time please continue with just one thread please?

You haven't replied if this works for you 
https://www.redhat.com/archives/freeipa-users/2016-May/msg00521.html


regards,
Martin
-- 
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] IPA 2.2 Certificate Renewal issue

[Rob Crittenden]

Kay Zhou Y wrote:

Hi Rob,

The status for ipaCert is MONITORING no matter before or after resubmit this 
request ID, as below:

Request ID '20140605220249':
 status: MONITORING
 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-renew-agent
 issuer: CN=Certificate Authority,O=DRUTT.COM
 subject: CN=IPA RA,O=DRUTT.COM
 expires: 2014-06-24 14:08:50 UTC
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command:
 post-save command:
 track: yes
 auto-renew: yes

I have restarted ipa service before renewal since there is no pki-cad service 
in our env.


Oh. So unfortunately the version of certmonger you have has a bug where 
the pre/post commands weren't displayed (it was only a display issue). 
If you look in /var/lib/certmonger/requests/ you can find the source 
for this output. See what the pre/post save command is for any of the CA 
subsystem certs and I guess perhaps ipaCert. I need to see how they are 
configured to do the renewal.


Maybe my memory is failing but I'd have sworn the CA process name was 
pki-cad. ipactl restart will restart the world. Given that the certs are 
expired you need to restart things when you go back in time. I saw that 
you are tracking the subsystem certs on this master so the CA must be 
installed.



I have tried so many times for this processes, and I even want to recreate the 
ipaCert, but it failed.


Before you go poking too manually into things I'd strongly recommend 
backing up the NSS databases first. You could easily break something.



The references I used as below, but both of them are not available for my 
issue:(
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal
http://www.freeipa.org/page/PKI

and if it's feasible we modify the expiration date for these certs manually or 
recreate it directly ?


You can't change any attributes of a certificate without re-issuing it. 
You can't issue a new cert without the CA up and I suspect it isn't up.


The cert may be in MONITORING when you go back in time because really, 
it's fine as long as it isn't expired, so MONITORING is a-ok.


rob



Thanks,
BR//Kay
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Tuesday, May 31, 2016 11:10 PM
To: Kay Zhou Y; freeipa-users@redhat.com
Cc: Doris Hongmei; Xionglin Gu
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:

Hi Rob,

Thanks  for your reply.

And about your suggestion, actually I have done it. but it just renew the two 
389-ds certs and Apache certs.
Since the ipaCert and subsystem certs are expired at 20140624, so I must roll 
back time before it. then begin to renew, but after I done this:

"Let's force renewal on all of the certificates:
# for line in `getcert list | grep Request | cut -d "'" -f2`; do
getcert resubmit -i $line; done ..."

According to the wiki, (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal 
). The CA subsystem c



ertificates will be renewed. But it did not.


Ok, what state are the certificates in? When you go back in time are you 
restarting the pki-cad service before attempting to do the renewal?


Finally after I finish all action mentioned in the wiki page, I still can't 
renew ipaCert and other four CA subsystem certificates.
And the two 389-ds and apache certs will still expired after the date 20160623 
( expire date of ipaCert 20140624 + two years).

If there is any other guide or doc about the ipaCert and CA subsystem 
certificates?


Not really for IPA 2.x

rob



Thanks a lot for your support!





Thanks,
BR//Kay

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Friday, May 27, 2016 11:41 PM
To: Kay Zhou Y; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:

Hi,

This is Kay.

I am not sure if the email address is correct, and I am really
appreciate if there is any help for my issue. it's baffling for few
days, and the expire date is coming soon.. L

There is a IPA 2.2 environment, and three "Server-Cert"(two 389-ds
and the Apache certs) will be expired at 2016-06-05 22:03:17 UTC.

Two years ago, these certs were renewed by other guys according to
this
document: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal

and it was successful then the certificates has been renewed until 20160605.

But recently I want to renew it again since the expire date is coming.
Then I follow the above guide, however things not go well.


The problem looks to be because the IPA RA cert (ipaCert) isn't
matching what dogtag expects. See the wiki page starting at

"For ipaCert, stored in /etc/httpd/alias you have another job to do..."

You'll want to be sure that 

Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

[Kay Zhou Y]

Hi Rob,

The status for ipaCert is MONITORING no matter before or after resubmit this 
request ID, as below:

Request ID '20140605220249':
status: MONITORING
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-renew-agent
issuer: CN=Certificate Authority,O=DRUTT.COM
subject: CN=IPA RA,O=DRUTT.COM
expires: 2014-06-24 14:08:50 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

I have restarted ipa service before renewal since there is no pki-cad service 
in our env.

I have tried so many times for this processes, and I even want to recreate the 
ipaCert, but it failed.
The references I used as below, but both of them are not available for my 
issue:( 
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal
http://www.freeipa.org/page/PKI 

and if it's feasible we modify the expiration date for these certs manually or 
recreate it directly ?

Thanks,
BR//Kay
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Tuesday, May 31, 2016 11:10 PM
To: Kay Zhou Y; freeipa-users@redhat.com
Cc: Doris Hongmei; Xionglin Gu
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:
> Hi Rob,
>
> Thanks  for your reply.
>
> And about your suggestion, actually I have done it. but it just renew the two 
> 389-ds certs and Apache certs.
> Since the ipaCert and subsystem certs are expired at 20140624, so I must roll 
> back time before it. then begin to renew, but after I done this:
>
> "Let's force renewal on all of the certificates:
> # for line in `getcert list | grep Request | cut -d "'" -f2`; do 
> getcert resubmit -i $line; done ..."
>
> According to the wiki, 
> (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal ). The CA subsystem 
> certificates will be renewed. But it did not.

Ok, what state are the certificates in? When you go back in time are you 
restarting the pki-cad service before attempting to do the renewal?

> Finally after I finish all action mentioned in the wiki page, I still can't 
> renew ipaCert and other four CA subsystem certificates.
> And the two 389-ds and apache certs will still expired after the date 
> 20160623 ( expire date of ipaCert 20140624 + two years).
>
> If there is any other guide or doc about the ipaCert and CA subsystem 
> certificates?

Not really for IPA 2.x

rob


> Thanks a lot for your support!


>
> Thanks,
> BR//Kay
>
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Friday, May 27, 2016 11:41 PM
> To: Kay Zhou Y; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue
>
> Kay Zhou Y wrote:
>> Hi,
>>
>> This is Kay.
>>
>> I am not sure if the email address is correct, and I am really 
>> appreciate if there is any help for my issue. it's baffling for few 
>> days, and the expire date is coming soon.. L
>>
>> There is a IPA 2.2 environment, and three "Server-Cert"(two 389-ds 
>> and the Apache certs) will be expired at 2016-06-05 22:03:17 UTC.
>>
>> Two years ago, these certs were renewed by other guys according to 
>> this
>> document: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal
>>
>> and it was successful then the certificates has been renewed until 20160605.
>>
>> But recently I want to renew it again since the expire date is coming.
>> Then I follow the above guide, however things not go well.
>
> The problem looks to be because the IPA RA cert (ipaCert) isn't 
> matching what dogtag expects. See the wiki page starting at
>
> "For ipaCert, stored in /etc/httpd/alias you have another job to do..."
>
> You'll want to be sure that description correctly matches the certificate in 
> the Apache database and confirm that the usercertificate value in LDAP 
> matches the cert being presented.
>
> rob
>
>>
>> As below, it's the 8 certs which certmonger are tracking:
>>
>> root@ecnshlx3039-test2(SH):~ #getcert list
>>
>> Number of certificates and requests being tracked: 8.
>>
>> Request ID '20120704140859':
>>
>>   status: CA_UNREACHABLE
>>
>>   ca-error: Server failed request, will retry: 4301 (RPC 
>> failed at server.  Certificate operation cannot be completed:
>> EXCEPTION(Invalid Credential.)).
>>
>>   stuck: yes
>>
>>   key pair storage:
>> type=NSSDB,location='/etc/dirsrv/slapd-DRUTT-COM',nickname='Server-Ce
>> r
>> t',token='NSS
>> Certificate DB',pinfile='
>> /etc/dirsrv/slapd-DRUTT-COM/pwdfile.txt'
>>
>>   certificate:
>> type=NSSDB,location='/etc/dirsrv/slapd-DRUTT-COM',nickname='Server-Ce
>> r
>> t',token='NSS
>> Certificate DB'
>>
>>   CA: IPA
>>
>>   issuer: 

Re: [Freeipa-users] dns location based discovery

[Winfried de Heiden]

  
  
Hi all,

  I've been playing on this topic but one can implement services
  discovery. Allthough it looks a bit dirty, you add _sites support
  to IPA by manually create a DNS zone, something like:

  _tcp.locationX._sites.example.com
and
_tcp.locationY._sites.example.com

and put two SRV records, _ldap en _kerberos, in
  it.

  Now, add "dns_discovery_domain = locationX._sites.example.com" 
  or "dns_discovery_domain = locationY._sites.example.com"

dns location based discovery is there...?

Just curious!

Winny


Op 30-05-16 om 18:39 schreef Martin
  Basti:


  
  
  
  
  
  On 30.05.2016 18:16, Winfried de
Heiden wrote:
  
  

Hi all,
Thanks for the quick answer even though I
  send it to the wrong email address.
About "Please note that for AD users (which
  is IIRC the majority of your environment), SSSD should
  already choose the right site." I noticed that, but I was
  curious about  the IPA part as well

Now, it looks like this is going to be an
  item for IPA 4.4 (http://www.freeipa.org/page/V4/DNS_Location_Mechanism/)

Willl it be?
  
  Yes it will be there (unless something very
very bad happen)

  
   
  IPA 4.4 is announced "the end of May". When can we expect
  Freeipa 4.4, I curious to test
  
  
  Soon :)

Martin
  
   
Kind regards,

Winny 

  

Op 30-05-16 om 17:54 schreef Jakub
  Hrozek:

 
  On Mon, May 30, 2016 at 05:22:33PM +0200, Sumit Bose wrote:
  
   
On Mon, May 30, 2016 at 05:13:35PM +0200, Winfried de Heiden
wrote:

 
  Hi all,
  The sssd-ipa man page will tell:
     ipa_enable_dns_sites (boolean)
     Enables DNS sites - location based service
  discovery.
     If true and service discovery (see Service
  Discovery paragraph at
  the bottom of the man page) is enabled, then the SSSD will
  first attempt
     location based discovery using a query that
  contains
  "_location.hostname.example.com" and then fall back to
  traditional SRV
  discovery. If the
     location based discovery succeeds, the IPA
  servers located with the
  location based discovery are treated as primary servers
  and the IPA servers
     located using the traditional SRV discovery are
  used as back up
  servers
  After enabling it in a EL 6.8 IPA client (together with
  some debugging) this
  will show up in the sssd logging: (Mon May 30 16:51:08
  2016) [sssd[be[blabla.bla]]]
  [resolv_discover_srv_next_domain] (0x0400): SRV resolution
  of service 'ldap'. Will use DNS discovery domain
  '_location.ipa-client-6.blabla.bla' (Mon May 30 16:51:08
  2016) [sssd[be[blabla.bla]]] [resolv_getsrv_send]
  (0x0100): Trying to resolve SRV record of
  '_ldap._tcp._location.ipa-client-6.blabla.bla'
  Since this option is mentioned in the sssd-ipa man page,
  it sugests I could
  implement this location based service discovery.
  But how? Any documentation on this? How to implement on
  the server? How to
  implement a location on the client (while running
  ipa-client-install)
  Hope someone can help, it would be nice a client will
  choose the correct server
  based on it's location...
  


In this case SSSD was a bit faster then the server side.
Please monitor
https://fedorahosted.org/freeipa/ticket/2008
for the progress. There is
a link to a design page with more details as well.
HTH
bye,
Sumit
P.S. I changed the mailing-list address to @redhat.com.

  
  
  btw Winfried, I saw today the case you filed. Please note that
  for AD
  users (which is IIRC the majority of your environment), SSSD
  should
  already choose the right site. The RFE Sumit linked is 'just'
  about the
  IPA side of the equation.
  





  
  


  


-- 
Manage your subscription for the Freeipa-users mailing list:

[Freeipa-users] FreeIPA4.2: Recovering from an IPA master server failure

[Michael Rainey (Contractor)]

Greetings community,

I've run into an interesting problem which may be old hat to all of 
you.  I was working to bring down my IPA master server and did it 
improperly.  It was a rookie mistake, but I'm willing to view it as an 
exercise in recovering from a massive system failure.


The original master server is gone with no way of recovering and I have 
managed to replace the server by promoting one of my replicas, but I 
find myself in a situation where I cannot remove the original master 
server from the LDAP directory.  It is still seen as a master server and 
the webUI will not let me delete the system from directory server.  Is 
there a process somewhere that will walk me through demoting the old 
server so I can delete it from the directory and officially promote its 
replacement?


For reference, I followed the steps located at this link.

Centos 7.2 / freeIPA 4.2

Your help is greatly appreciated.

--
*Michael Rainey*
-- 
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] IPA 2.2 Certificate Renewal issue

[Rob Crittenden]

Kay Zhou Y wrote:

Hi Rob,

Thanks  for your reply.

And about your suggestion, actually I have done it. but it just renew the two 
389-ds certs and Apache certs.
Since the ipaCert and subsystem certs are expired at 20140624, so I must roll 
back time before it. then begin to renew, but after I done this:

"Let's force renewal on all of the certificates:
# for line in `getcert list | grep Request | cut -d "'" -f2`; do getcert 
resubmit -i $line; done
..."

According to the wiki, (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal 
). The CA subsystem certificates will be renewed. But it did not.


Ok, what state are the certificates in? When you go back in time are you 
restarting the pki-cad service before attempting to do the renewal?



Finally after I finish all action mentioned in the wiki page, I still can't 
renew ipaCert and other four CA subsystem certificates.
And the two 389-ds and apache certs will still expired after the date 20160623 
( expire date of ipaCert 20140624 + two years).

If there is any other guide or doc about the ipaCert and CA subsystem 
certificates?


Not really for IPA 2.x

rob



Thanks a lot for your support!





Thanks,
BR//Kay

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Friday, May 27, 2016 11:41 PM
To: Kay Zhou Y; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:

Hi,

This is Kay.

I am not sure if the email address is correct, and I am really
appreciate if there is any help for my issue. it's baffling for few
days, and the expire date is coming soon.. L

There is a IPA 2.2 environment, and three "Server-Cert"(two 389-ds and
the Apache certs) will be expired at 2016-06-05 22:03:17 UTC.

Two years ago, these certs were renewed by other guys according to
this
document: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal

and it was successful then the certificates has been renewed until 20160605.

But recently I want to renew it again since the expire date is coming.
Then I follow the above guide, however things not go well.


The problem looks to be because the IPA RA cert (ipaCert) isn't matching what 
dogtag expects. See the wiki page starting at

"For ipaCert, stored in /etc/httpd/alias you have another job to do..."

You'll want to be sure that description correctly matches the certificate in 
the Apache database and confirm that the usercertificate value in LDAP matches 
the cert being presented.

rob



As below, it's the 8 certs which certmonger are tracking:

root@ecnshlx3039-test2(SH):~ #getcert list

Number of certificates and requests being tracked: 8.

Request ID '20120704140859':

  status: CA_UNREACHABLE

  ca-error: Server failed request, will retry: 4301 (RPC failed
at server.  Certificate operation cannot be completed:
EXCEPTION(Invalid Credential.)).

  stuck: yes

  key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DRUTT-COM',nickname='Server-Cer
t',token='NSS
Certificate DB',pinfile='
/etc/dirsrv/slapd-DRUTT-COM/pwdfile.txt'

  certificate:
type=NSSDB,location='/etc/dirsrv/slapd-DRUTT-COM',nickname='Server-Cer
t',token='NSS
Certificate DB'

  CA: IPA

  issuer: CN=Certificate Authority,O=DRUTT.COM

  subject: CN=ipa1.drutt.com,O=DRUTT.COM

  expires: 2016-06-05 22:03:17 UTC

  eku: id-kp-serverAuth,id-kp-clientAuth

  pre-save command:

  post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
DRUTT-COM

  track: yes

  auto-renew: yes

Request ID '20120704140922':

  status: CA_UNREACHABLE

  ca-error: Server failed request, will retry: 4301 (RPC failed
at server.  Certificate operation cannot be completed:
EXCEPTION(Invalid Credential.)).

  stuck: yes

  key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert'
,token='NSS
Certificate DB',pinfile='/e
tc/dirsrv/slapd-PKI-IPA/pwdfile.txt'

  certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert'
,token='NSS
Certificate DB'

  CA: IPA

  issuer: CN=Certificate Authority,O=DRUTT.COM

  subject: CN=ipa1.drutt.com,O=DRUTT.COM

  expires: 2016-06-05 22:03:17 UTC

  eku: id-kp-serverAuth,id-kp-clientAuth

  pre-save command:

  post-save command:

  track: yes

  auto-renew: yes

Request ID '20120704141150':

  status: CA_UNREACHABLE

  ca-error: Server failed request, will retry: 4301 (RPC failed
at server.  Certificate operation cannot be completed:
EXCEPTION(Invalid Credential.)).

  stuck: yes

  key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N
SS
Certificate
DB',pinfile='/etc/httpd/
alias/pwdfile.txt'

  

Re: [Freeipa-users] EXAMPLE.COM IPA CA Import /etc/httpd/alias

[Rob Crittenden]

Günther J. Niederwimmer wrote:

Hello
I found any Help for the IPA Certificate but I found no way to import the IPA
CA ?
I like to create a webserver with a owncloud virtualhost and other..

But it is for me not possible to create the /etc/httpd/alias correct ?

I found this in IPC DOCS

certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt

but with this command line I have a Error /etc/ipa/ca.crt have wrong format ?

Have any a link with a working example


Does the file /etc/ipa/ca.crt exist? It is installed there on enrolled 
clients so the documentation is written from that perspective.


You can grab a copy from any enrolled system, including an IPA Master. 
Otherwise the command looks ok assuming you were sitting in 
/etc/httpd/alias when the command was executed (-d .).


rob

--
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 ALL rule

[Pavel Březina]

On 05/31/2016 11:19 AM, Tony Brian Albers wrote:

Hi guys,

I'm implementing FreeIPA to auhenticate users on a small HPC cluster
here. For a few of these I need a sudo rule that in essence does the
same as the standard ALL(ALL) rule. How do I implement that in FreeIPA?

I've found some links/guides on the net, but they don't seem appropriate
for our version, 4.2.0

Any help is appreciated.

/tony


Hi,
the IPA alternative to keyword all is category "all". The following 
command should do what you want:


$ ipa sudorule-add allow-all --usercat=all --hostcat=all --cmdcat=all

--
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] dynamic dns working for forward zone but not reverse zone

[Brian J. Murrell]

On Mon, 2016-05-30 at 13:43 +0200, Petr Spacek wrote:
> 
> Can you query the SOA record from the reverse zone, please?
> 
> $ dig @10.75.22.247 0.10.8.in-addr.arpa. SOA

Ahhh.  That's the problem.  The subnet is 10.8.0.0/24 so the query
should be for 0.8.10.in-addr.arpa.

Sometimes it just takes a fresh set of eyes to stop seeing what we want
to see and see what's really there.  Thanks for being those eyes for
me.

Cheers,
b.




signature.asc
Description: This is a digitally signed message part
-- 
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

[Freeipa-users] Sudo ALL rule

[Tony Brian Albers]

Hi guys,

I'm implementing FreeIPA to auhenticate users on a small HPC cluster
here. For a few of these I need a sudo rule that in essence does the
same as the standard ALL(ALL) rule. How do I implement that in FreeIPA?

I've found some links/guides on the net, but they don't seem appropriate
for our version, 4.2.0

Any help is appreciated.

/tony
-- 
Best regards,

Tony Albers
Systems administrator, IT-development
State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 8946 2316




-- 
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] OCSP and CRL in certs for java firefox plugin

[Martin Kosek]

On 05/30/2016 10:53 PM, Prasun Gera wrote:
> 
> To summarize, your options seem to be:
> * Create ipa-ca DNS record in your primary domain
> * Update the main default certificate profile (present in FreeIPA 4.2+)
> * Migrate whole FreeIPA deployment to other DNS primary you would control
> (pqr.xyz.com ) - which is a lot of work but may 
> unblock
> you in future if you
> want to start the mentioned AD trusts.
> 
> Martin
> 
> 
> Thanks Martin for the suggestions. In the short term, updating the external 
> will 
> probably not work. Eventually, migration to a domain that I can control will 
> be 
> a better idea, but that will involve a lot more work. Is there any 
> documentation 
> on doing the migration ? My deployment is actually fairly simple right now. 
> We 
> just use it internally for our small lab, mostly as a replacement for NIS. No 
> AD 
> or windows machines. Hence, I didn't bother with a lot of complex dns stuff 
> to 
> begin with. I guess, the only thing we need to preserve is usernames, groups 
> and 
> passwords in the migration.

If you use only users, groups and passwords, the migration may actually not be
that painful as you can migrate with "ipa migrate-ds" command as advised in
http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA
and then enrolling your clients with the new FreeIPA realm. We have a RFE for a
more complete migration tracked
https://fedorahosted.org/freeipa/ticket/3656
that was being worked on as a thesis.

> Regarding your second point, how do I go about updating the cert profile ? Is 
> there any documentation ? If this is not a standard feature, do you think I 
> should open an RFE ?

Certificate Profiles is a standard feature in FreeIPA 4.2+. Profile edit is not
that straightforward, but if you download current one for the profile, you
should be able to figure out what line to edit (and then you just upload the
profile again).

> Also, I'm surprised that nothing broke yet despite the OCSP/CRL stuff not 
> working ever. Isn't this important security-wise? Yet, browsers don't seem to 
> complain by default for https certs once the CA is trusted. Only the java 
> plugin 
> brought this to my attention.

Yeah, browsers generally not care about CRL/OCSP unless explicitly enabled. I
know that at least Firefox has a setting to always check for certificate 
validity.

> 
> 
> > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden  
>  > >> wrote:
>  >
>  > Prasun Gera wrote:
>  >
>  > I've identified the problem. The uris seem to be incorrect. 
> This
> looks
>  > like some substitution gone wrong. Instead of using the actual 
> ipa
>  > server's address, it points to a generic placeholder type text
>  > (ipa-ca.domain.com 
> 
>  > ). Relevant part of the
>  > certificate:
>  >
>  >
>  > A generic name is used in case the server that issued the cert 
> goes away.
>  > Create an entry in DNS for this generic name and things should work
> as expected.
>  >
>  > rob
>  >
>  >
>  > Authority Information Access:
>  >   OCSP - URI:*http://ipa-ca.domain.com/ca/ocsp*
>  >
>  >   X509v3 Key Usage: critical
>  >   Digital Signature, Non Repudiation, Key
> Encipherment,
>  > Data Encipherment
>  >   X509v3 Extended Key Usage:
>  >   TLS Web Server Authentication, TLS Web Client
>  > Authentication
>  >   X509v3 CRL Distribution Points:
>  >
>  >   Full Name:
>  >   
>   URI:*http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*
>  >
>  >
>  > This is on RHEL 7.2, idm 4.2 btw
>  >
>  > On Fri, May 27, 2016 at 7:22 PM, Prasun Gera
> 
>  > >
> > 
>  >
> >  It looks like that issue was fixed and the OCSP and CRL 
> uris in the
> >  certs are now http. So I'm not sure why java is 
> complaining.
> >
> >  On Fri, May 27, 2016 at 7:03 PM, Prasun Gera 
> 
> > >
>  >   

Re: [Freeipa-users] Centos 7.2 ipa-backup failure

[Martin Kosek]

On 05/30/2016 06:57 PM, Ken Bass wrote:
> On 05/30/2016 10:32 AM, Martin Kosek wrote:
>> On 05/29/2016 05:33 PM, Ken Bass wrote:
>>> Today I tried my very first ipa-backup attempt. The command reported 'The
>>> ipa-backup command was successful'
>>>
>>> YET  I saw:
>>>
>>> /usr/sbin/db2ldif: line 157: 22567 Segmentation fault /usr/sbin/ns-slapd
>>> db2ldif -D /etc/dirsrv/slapd-DOMAIN-NET -n userRoot -a "/var/l
>>> ib/dirsrv/slapd-DOMAIN-NET/ldif/DOMAIN-NET-userRoot.ldif" -r
>>>
>>> I am running Centos 7.2. After googling, I did find -
>>> https://fedorahosted.org/freeipa/ticket/5571
>>> https://fedorahosted.org/389/ticket/48388
>>>
>>> How am I supposed to backup this box? I want to run the backup-script 
>>> nightly
>>> to generate the tarball so I can use another script to backup it up along 
>>> with
>>> other stuff. It is a small system with no replication.
>>>
>>> As a Centos 7.2 user am I just out of luck since it appears the various 
>>> bugs I
>>> am encountering with this software are not being fixed except in newer 
>>> versions
>>> of freeipa and sssd which are not available
>>> via the standard repos?
>> Hello Ken,
>>
>> I am sorry to hear about your trouble. The standard way for people with RHEL
>> subscription is to request a RHEL fix from support, but if you do not have 
>> it,
>> you would need to deal with it other way.
> Correct, I do not have a RHEL subscription. However my justification for using
> Centos 7.2, rather than Fedora,
> was that I would be using a production quality product. The same as the 'big
> guys' so to speak.

Right.

> So when I am running into
> a bunch of issues it makes me wonder how this stuff got through Q in the
> first place.

You obviously must be hitting some scenario or have a configuration environment
that was not tested. Filing a RHEL Bug should help also to ensure that this
scenario is tested.

>> As this is a DS issue (linked from FreeIPA ticket), you can try raising
>> awareness in RHEL-7 product of the 389-ds-base and ask for backport of this
>> issue to RHEL-7.2.x stream.
> 
>  I dont think it is solely a DS issue. The ipa-backup script is reporting
> command successful when something internal is seg faulting.
> That would seem like someone is not checking a return code in the ipa-backup
> script. At least the ipa-backup script should be reporting a failure since I
> assume the backup is incomplete.

That *is* a good point and is worth filing upstream ticket
https://fedorahosted.org/freeipa/newticket

If you can also help FreeIPA with a code contribution, it would help project
immensely as there is a lots of tickets...

>> Alternatively, projects may have own CentOS repos
>> where they can publish builds of upcoming releases, like FreeIPA has:
>>
>> https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-3-centos-7/
> 
> I had thought about using that, but it warns it is not for production, and 
> with
> the number of issues I have encountered in the production
> version, I worry that the copr version would be even worse, and that if there
> are any issues the response will just be don't use it for production.

It is true that these packages are provided as builds of FreeIPA upstream
project, with "community support", i.e. this mailing list and voluntary based
help. RHEL is officially QE'd and supported, so the base CentOS packages should
be more stable, yes - though with lower amount of updates, given the QE and
support related processes. It is a trade-off as usual.

> Do you know how stable the software being fed to the copr is? While perhaps
> overkill, I am only using this for 2 boxes with 2 users -- mainly for the 2FA
> component. I am not doing anything
> fancy like replication, etc. I had replaced some custom radius server code and
> openldap stuff with freeIPA since it helped with enrolling tokens via freeOTP
> and such. The freeIPA is better
> integrated into sssd than my custom solution (though I had to install sssd 
> from
> copr due to basic bugs in the sudo 2FA code).

It is hard to quantify stability, so I would go with "more stable than git
builds as it goes through Upstream QE test suite, less stable than RHEL bits -
that are production ready".

Martin

-- 
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