Re: [Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

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

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 ?

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.



>
> > 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 <
> prasun.g...@gmail.com
> > 
> > >>
> wrote:
> >
> >  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 <
> prasun.g...@gmail.com
> > 
> >  >>
> wrote:
> >
> >  I've set up a couple of dell idrac card's ssl certs
> signed by
> >  ipa CA. I've also added the ipa CA to java's trusted
> CAs.
> >  However, when you try to launch the idrac java console,
> it will
> >  still show an error that the site is untrusted. Upon
> clicking on
> >  "more information", the message says that although the
> cert is
> >  signed by the CA, it cannot verify the revocation
> status. I
> >  found this page
> > http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs ,
> >  which explains potential problems with this since the
> main ipa
> >  server itself is also using an ssl cert signed by the
> ipa CA. So
> >  the client cannot verify the revocation if it can't
> reach the
> >  CA. Is there any solution to this ? Anyone tried this
> with idrac
> >  cards ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
-- 
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] dns location based discovery

[Winfried de Heiden]

  
  
Can't wait!
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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Ken Bass]

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. So when I am running into
a bunch of issues it makes me wonder how this stuff got through Q in 
the first place.




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.


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


--
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] dns location based discovery

[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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns location based discovery

[Winfried de Heiden]

  
  
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?

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

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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns location based discovery

[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:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] dns location based discovery

[Sumit Bose]

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

-- 
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] Unable to access to web ui

[Martin Kosek]

On 05/30/2016 04:36 PM, Martin Basti wrote:
> 
> 
> On 30.05.2016 14:20, seli irithyl wrote:
>> Hi,
>>
>> Since last update, I'am unable to log in to web ui with FF (e.g. blank page)
>> Any idea where too look for ?
>>
>> Best regards,
>>
>> Seli
>>
>>
>>
>>
>>
> Hello,
> 
> can you provide version of the freeIPA, firefox. Does it work from different 
> browser? does it work from private mode?

+ does [CTRL]+F5 helps? Do advise in
http://www.freeipa.org/page/Troubleshooting#Web_UI
help?

-- 
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] Unable to access to web ui

[Martin Basti]

On 30.05.2016 14:20, seli irithyl wrote:

Hi,

Since last update, I'am unable to log in to web ui with FF (e.g. blank 
page)

Any idea where too look for ?

Best regards,

Seli






Hello,

can you provide version of the freeIPA, firefox. Does it work from 
different browser? does it work from private mode?


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] Install best practice -

[Martin Kosek]

On 05/29/2016 07:11 PM, Ben .T.George wrote:
> Hi
> 
> I would like to know how can i proceed with best practices
> 
> My AD domain is : corp.examle.com.kw 
> My DNS (appliances ) : kw.test.com 
> 
> All my clients are pointed to kw.test.com  including AD.
> 
> How can i proceed with Free IPA installation? where i need to manage DNS of 
> freeipa master server?
> 
> 
> creating new DNS zone in kw.test.com  will be little bit 
> difficult.
> 
> which will be best configuration with minimal changes in existing setup.

The best resources for this topic is probably

http://www.freeipa.org/page/Deployment_Recommendations#Considerations_for_Active_Directory_integration_on_DNS_level

This may be related:
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain

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] Centos 7.2 ipa-backup failure

[Martin Kosek]

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.

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

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] EXAMPLE.COM IPA CA Import /etc/httpd/alias

[Martin Kosek]

On 05/29/2016 09:18 AM, 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

I have hard time understanding what the use case is, but it looks like you are
looking for information in

http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure

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

[Martin Kosek]

On 05/28/2016 05:30 AM, Prasun Gera wrote:
> The problem is that I'm not using ipa for dns. dns is handled externally, and 
> I 
> don't have admin access. I have 1 master and 1 replica, and all the clients 
> are 
> enrolled with --server=a,--server=b during installation, and I think it works 
> perfectly fine. Is it possible to instruct ipa to use some alternative for 
> the 
> certs ? If it's not possible to list multiple uris, even just the master 
> would 
> be fine. It would at least work when the master is up, which it doesn't right 
> now.

ipa-ca.$DOMAIN OCSP/CRL is currently hardcoded in the Certificate Profiles, you
would need to edit them with different value (which may then make FreeIPA
upgrades funny).

I still think the easiest solution may be to simply request DNS change in your
external DNS and create the ipa-ca DNS record - it is a simple list of IPA CA
server's IP addresses.

> Secondly, I'm a bit confused regarding the dns too. This error is on a client 
> system like my laptop, which is an entirely unrelated system from the ipa 
> clients. The connection is over the internet. So the dns mapping would have 
> to 
> be visible globally for my laptop to see it. However, the name of the ipa 
> domain 
> is not the same the same as the name of domain in the server addresses. (This 
> was for some historic reason in NIS, and I didn't change the domain name 
> during 
> migration). So what ipa is suggesting is something like ipa-ca.abc.com 
> , whereas all my servers are like server1.pqr.xyz.com 
> . I don't think it is anyway possible to do this 
> right now since I don't control abc.com .

This feature uses the primary FreeIPA DNS domain, which is derived from it's
realm. This is the same approach as with AD. If you do not have access to this
DNS domain, I expect you will have trouble if you want to for example start
using AD Trusts which expects working primary DNS domain with proper SRV
records (FreeIPA servers can still live in other domain though).

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

> 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  
> >> wrote:
> 
>  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 
>  
>  >> 
> wrote:
> 
>  I've set up a couple of dell idrac card's ssl certs signed by
>  ipa CA. I've also added the ipa CA to java's trusted CAs.
>  However, when you try to launch the idrac java console, it 
> will
>  still show an error that the site is untrusted. Upon 
> clicking on
>  "more information", the message says that although the cert 
> is
>  signed by the CA, it cannot verify the revocation status. I
>  found this page
> http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs ,
>  

[Freeipa-users] Unable to access to web ui

[seli irithyl]

Hi,

Since last update, I'am unable to log in to web ui with FF (e.g. blank page)
Any idea where too look for ?

Best regards,

Seli
-- 
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] question about automount config

[Arthur Fayzullin]

thanks! I'll try to debug at my test environment.


24.05.2016 18:01, Prasun Gera пишет:
> You can stop the autofs daemon, and run it in foreground with
> automount -fvv. Then try to access the mount point in parallel. The
> logs from the foreground run should shed some light. Also, does your
> autofs setup work without kerberos ? As a first step it to work with
> non-kerberised nfs. 
>
> On Mon, May 23, 2016 at 11:06 AM, Arthur Fayzullin  > wrote:
>
> Good day, colleagues!
> I am confused about how automount work and howto configure it. I have
> tried to configure it according to
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
> document (paragraph 9.1.1 and chapter 20).
> I have tried to make it work on 3 servers:
> 1. ipa server;
> 2. nfs server (node00);
> 3. nfs client (postgres).
>
>
> *** so here how it configured on ipa server:
> $ ipa automountlocation-tofiles amantai
> /etc/auto.master:
> /-  /etc/auto.direct
> /home   /etc/auto.home
> ---
> /etc/auto.direct:
> ---
> /etc/auto.home:
> *   -sec=kr5i,rw,fstype=nfs4 node00.glavsn.ab:/home/&
>
> maps not connected to /etc/auto.master:
>
> $ ipa service-find nfs
> --
> 2 services matched
> --
>   Основной: nfs/node00.glavsn...@glavsn.ab
>   Keytab: True
>   Managed by: node00.glavsn.ab
>
>   Основной: nfs/postgres.glavsn...@glavsn.ab
>   Keytab: True
>   Managed by: postgres.glavsn.ab
>
>
> *** here is nfs server config:
> $ sudo klist -k
> Пароль:
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>
> $ cat /etc/exports
> /home *(rw,sec=sys:krb5:krb5i:krb5p)
>
> $ sudo firewall-cmd --list-all
> public (default, active)
>   interfaces: bridge0 enp1s0
>   sources:
>   services: dhcpv6-client nfs ssh
>   ports: 8001/tcp
>   masquerade: no
>   forward-ports:
>   icmp-blocks:
>   rich rules:
>
> $ getenforce
> Enforcing
>
>
> *** here nfs client config:
> # klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>
> # firewall-cmd --list-all
> FedoraServer (default, active)
>   interfaces: ens3
>   sources:
>   services: cockpit dhcpv6-client ssh
>   ports:
>   protocols:
>   masquerade: no
>   forward-ports:
>   icmp-blocks:
>   rich rules:
>
> # mount -l  (contains next string)
> auto.home on /home type autofs
> (rw,relatime,fd=25,pgrp=960,timeout=300,minproto=5,maxproto=5,indirect)
>
> # ll /home/afayzullin
> ls says that it cannot access /home/afayzullin: no such file or
> directory
>
> I have run
> # ipa-client-automount --location=amantai
> on client and it has completed successfully.
>
> I have tried to disable selinux, drop iptables rules. And now I am
> little confused about what to do next. May if someone has faced with
> automount config can give me some advice, or if there is any howto
> config automount, or some can advise howto debug this situation?
>
> --
> 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
>
>

-- 
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] Multiple issues (weblogin, DNS) with 4.3.1 @ Fedora 24

[Petr Spacek]

On 27.5.2016 14:28, Tomasz Torcz wrote:
> Hi,
> 
>   In my home environment I'm using two-server FreeIPA configuration on Fedora.
> Initially installed on fedora 19 in November 2013, it have been upgraded every
> Fedora release. It generally works OK, but somewhat degrades during operation.
> Recently I've jumped to F24 in hope my problems will be resolved, but they 
> weren't.
> Thus this email and plea for assistance.
> 
>   In the meantime there was a problem with expired certificates, but it solved
> with the help of rcrit on IRC.
> 
>   I'm using freeipa-server-4.3.1-1.fc24.x86_64. One of the servers is called
> kaitain.pipebreaker.pl, the other okda.pipebreaker.pl.
> 
>   Currently I encounter following main problems:
> 1) named is not servicing all the records from LDAP
> 2) can't login to WebUI on kaitain.pipebreaker.pl
> 3) can't login to WebUI on okda.pipebreaker.pl
> 4) pycparser.lextab/lextab.py/yacctab.py permission errors
> 
>   More details:
> -
> ad 1) named problems
>   Recently I've added new  host entry to my zone (.pipebreaker.pl). It is
>  visible in CLI, but named doesn't resolve it:
> 
> $ ipa dnsrecord-find pipebreaker.pl microstation 
>   Record name: microstation
>    record: 2001:6a0:200:d1::2
> 
> Number of entries returned 1
> 
> 
> $ host microstation ; host microstation.pipebreaker.pl
> Host microstation not found: 3(NXDOMAIN)
> Host microstation.pipebreaker.pl not found: 3(NXDOMAIN)
> 
>   Entries added previously resolve fine.  I see no errors reported
>  in named-pkcs11.service logs.
>   
> -
> 
> ad 2) can't login to webui at kaitain
>   When I open a WebUI while having valid ticket, I'm shown my user page,
> i.e. https://kaitain.pipebreaker.pl/ipa/ui/#/e/user/details/zdzichu is opened.
>   But when I logout from WebUI and try to login as admin, I receive:
>  
>  The password or username you entered is incorrect.
>   
>   The password is certainly correct, I can use it for 'kinit admin' 
> successfully. 
>  /var/log/httpd/error log contains:
> 
> [Fri May 27 14:17:37.104341 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] mod_wsgi (pid=1882): Exception 
> occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
> [Fri May 27 14:17:37.106932 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] Traceback (most recent call last):
> [Fri May 27 14:17:37.106985 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File "/usr/share/ipa/wsgi.py", line 
> 63, in application
> [Fri May 27 14:17:37.107436 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return 
> api.Backend.wsgi_dispatch(environ, start_response)
> [Fri May 27 14:17:37.107461 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 261, in 
> __call__
> [Fri May 27 14:17:37.107769 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return self.route(environ, 
> start_response)
> [Fri May 27 14:17:37.107786 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 273, in route
> [Fri May 27 14:17:37.107808 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] return app(environ, start_response)
> [Fri May 27 14:17:37.107829 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 943, in 
> __call__
> [Fri May 27 14:17:37.107848 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] self.kinit(user, 
> self.api.env.realm, password, ipa_ccache_name)
> [Fri May 27 14:17:37.107887 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28]   File 
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 965, in kinit
> [Fri May 27 14:17:37.107918 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] raise 
> CCacheError(message=unicode(e))
> [Fri May 27 14:17:37.136615 2016] [wsgi:error] [pid 1882] [remote 
> 2001:470:71:68d:216:eaff:fec2:68b4:28] CCacheError: Major (851968): 
> Unspecified GSS failure.  Minor code may provide more information, Minor 
> (2529639107): No credentials cache found
> 
>   What cache is it talking about?  How can I refresh it?
> 
> -
> 
> 
> ad 3) cannot login to webui on okda
>
>   When I go to https://okda.pipebreaker.pl/ipa/ui/ (the other server), I see 
> "Loading…" screen
>  for couple of seconds, and afterwards "Gateway timeout" message. Everything
>  seems to be running on this server:
> 
> root@okda ~$ ipactl status
> WARNING: yacc table file version is out of date
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> 

Re: [Freeipa-users] dynamic dns working for forward zone but not reverse zone

[Petr Spacek]

On 27.5.2016 15:27, Brian J. Murrell wrote:
> I have a FreeIPA 4.2.0 on CentOS 7.2.  I have dynamic DNS updates
> working for a forward zone but they are failing (NOTAUTH) for a reverse
> zone.  Here are configuration of the two zones:
> 
>   dn: idnsname=example.com.,cn=dns,dc=example,dc=com
>   Zone name: example.com.
>   Active zone: TRUE
>   Authoritative nameserver: server.example.com.
>   Administrator e-mail address: hostmaster.example.com.
>   SOA serial: 1464354354
>   SOA refresh: 3600
>   SOA retry: 900
>   SOA expire: 1209600
>   SOA minimum: 3600
>   BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM 
> krb5-self * ; grant EXAMPLE.COM krb5-self * SSHFP; grant 
> linux_home_nsupdate wildcard * ANY;
>   Dynamic update: TRUE
>   Allow query: any;
>   Allow transfer: 10.75.22.1;
>   mxrecord: 200 linux
>   nsrecord: server.example.com.
>   objectclass: idnszone, top, idnsrecord
>   txtrecord: "v=spf1 a:server.klug.on.ca"
> 
> 
>   dn: idnsname=0.8.10.in-addr.arpa.,cn=dns,dc=example,dc=com
>   Zone name: 0.8.10.in-addr.arpa.
>   Active zone: TRUE
>   Authoritative nameserver: server.example.com.
>   Administrator e-mail address: hostmaster
>   SOA serial: 1464354356
>   SOA refresh: 3600
>   SOA retry: 900
>   SOA expire: 1209600
>   SOA minimum: 3600
>   BIND update policy: grant EXAMPLE.COM krb5-subdomain 0.8.10.in-addr.arpa. 
> PTR; grant linux_home_nsupdate wildcard * ANY;
>   Dynamic update: TRUE
>   Allow query: any;
>   Allow transfer: none;
>   nsrecord: server.example.com.
>   objectclass: idnszone, top, idnsrecord
> 
> Here are example updates to the two zones:
> 
> # nsupdate -y linux_home_nsupdate: -d /tmp/fwdupdate 
> Creating key...
> namefromtext
> keycreate
> Sending update to 10.75.22.247#53
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  53154
> ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;example.com. IN  SOA
> 
> ;; UPDATE SECTION:
> chost.example.com. 0  ANY A   
> chost.example.com. 60 IN  A   10.8.0.2
> 
> ;; TSIG PSEUDOSECTION:
> linux_home_nsupdate.  0   ANY TSIGhmac-md5.sig-alg.reg.int. 
> 1464355147 300 16 oRoIWfkmmmCKQWj9NrrRDw== 53154 NOERROR 0 
> 
> 
> Reply from update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  53154
> ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;example.com. IN  SOA
> 
> ;; TSIG PSEUDOSECTION:
> linux_home_nsupdate.  0   ANY TSIGhmac-md5.sig-alg.reg.int. 
> 1464355225 300 16 3IVCZr+MjyD75sHr53LEHw== 53154 NOERROR 0 
> 
> 
> # nsupdate -y linux_home_nsupdate: -d /tmp/revupdate 
> Creating key...
> namefromtext
> keycreate
> Sending update to 10.75.22.247#53
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  26720
> ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;0.10.8.in-addr.arpa. IN  SOA
> 
> ;; UPDATE SECTION:
> 2.0.10.8.in-addr.arpa.0   ANY PTR 
> 2.0.10.8.in-addr.arpa.60  IN  PTR chost.example.com.
> 
> ;; TSIG PSEUDOSECTION:
> linux_home_nsupdate.  0   ANY TSIGhmac-md5.sig-alg.reg.int. 
> 1464355166 300 16 ooWRdNhQ1170LkSjIiCqSA== 26720 NOERROR 0 
> 
> 
> Reply from update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id:  26720
> ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;0.10.8.in-addr.arpa. IN  SOA
> 
> ;; TSIG PSEUDOSECTION:
> linux_home_nsupdate.  0   ANY TSIGhmac-md5.sig-alg.reg.int. 
> 1464355244 300 16 N5Dg0rMokW9sNGGO9BwGNQ== 26720 NOERROR 0 
> 
> When the first update is done the following is logged by named-pkcs11:
> 
> client 10.75.22.253#51414/key linux_home_nsupdate: updating zone 
> 'example.com/IN': deleting rrset at 'chost.example.com' A
> client 10.75.22.253#51414/key linux_home_nsupdate: updating zone 
> 'example.com/IN': adding an RR at 'chost.example.com' A
> 
> Nothing is logged for the second update attempt.
> 
> Any ideas why one is working and the other is not?

This is really weird.
Can you query the SOA record from the reverse zone, please?

$ dig @10.75.22.247 0.10.8.in-addr.arpa. SOA

-- 
Petr^2 Spacek

-- 
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] Install best practice -

[Natxo Asenjo]

On Mon, May 30, 2016 at 7:14 AM, Ben .T.George 
wrote:

> Hi
>
> thanks for the reply.
>
> "the easiest would be to create a zone and delegating that to the ipa
> hosts. No other change necessary."
>
> can you explain little more. You mean need to create separate DNS zone ?
>
>
create a zone in your dns appliances unix.example.com.kw (name it what you
like). Delegate the dns managment of that zone to the freeipa dns
servers/domain controllers. Create glue records so clients can find those
servers.

A normal dns delegated zone, in short.

--
Groeten,
natxo
-- 
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] Adding groupOfUniqueNames to all freeipa replicas for Zenoss LDAP authentication

[Martin Kosek]

On 05/27/2016 03:17 PM, Bob Hinton wrote:
> Hi Martin,
> 
> On 27/05/2016 14:01, Martin Kosek wrote:
>> On 05/25/2016 09:51 PM, Bob Hinton wrote:
>>> Hello,
>>>
>>> We are trying to get Zenoss login authentication to use freeipa over
>>> LDAP. Group mappings don't currently work and we think this is because
>>> Zenoss requires the groupOfUniqueNames object class.
>>>
>>> I managed to add the object class to a test VM using
>>> vsphere_groupmod.ldif taken from
>>> http://www.freeipa.org/page/HowTo/vsphere5_integration -
>>>
>>> content of vsphere_groupmod.ldif -
>>>
>>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
>>> changetype: modify
>>> add: schema-compat-entry-attribute
>>> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
>>> -
>>> add: schema-compat-entry-attribute
>>> schema-compat-entry-attribute:
>>> uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
>>> -
>>>
>>> apply with -
>>>
>>> ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W
>>>
>>> However, the following command seemed to freeze -
>>>
>>> ipa permission-mod "System: Read Group Compat Tree" --includedattrs
>>> uniquemember
>>>
>>> and I had to kill it then subsequent ldapsearch commands froze.
>> That's... strange. Looks like a DS bug.
> I tried this on one of the three live servers after using ipa-backup on
> each of them and it completed without hanging so this suggests a problem
> with my test VM rather than a bug.
> 
>>
>>> Rebooting the VM seemed to fix things and the groupOfUniqueNames object
>>> class appeared in the schema.
>>>
>>> I'd like to apply this to our live system which uses a master and two
>>> replicas running  IPA v4.2.0 on RHEL 7.2.
>>>
>>> Do I need to make the same change to all three servers ?
>> Changes in cn=config needs to be done on all servers as the tree is not
>> replicated. Normal permission changes are replicated (unless the permission 
>> is
>> about cn=config tree).
> Yes. I've now spotted that the change is confined to the single live
> server. I'll apply it to the other two when we've got the connectivity
> with Zenoss working.
>>> Can I leave the
>>> replicas connected or do I need to break the replication and
>>> re-establish it?
>> I do not see reason why you would need to break the replication between 
>> replicas.
>>
>>> Do I need the "ipa permission-mod" if so then how do I
>>> avoid it freezing ?
>> I think the freeze is a bug, I would try reproducing with the latest and
>> greatest 389-ds-base (I do not know what version you are using), the bug may 
>> be
>> already fixed (there were some bugs fixed).
> My test VM is quite old, since it didn't happen on the live server and
> that is more up to date, it suggests either a bug that has been fixed or
> a problem with the test VM.

Ok, thanks for info. It looks like you are in a "green state" then :-)

Martin

>>
>> And yes, the command is needed, so that the new attribute is allowed to be 
>> served.
>>
>> HTH,
>> Martin
>> .
>>
> Thanks
> 
> Bob
> 

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