[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Rob Crittenden via FreeIPA-users]

Aaron Hicks via FreeIPA-users wrote:
> Hi Simo,
> 
>> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
>> to the servers.
> 
> We have _many_ hosts in a cluster, so this is not practical on a per host 
> basis. I single line command we could bulk execute on each of them to 
> retrieve the key would be preferred.

Your best bet is to get ipa-client built for SLE.

rob

> 
> Regards,
> 
> Aaron
> 
> -Original Message-
> From: Simo Sorce [mailto:s...@redhat.com] 
> Sent: Wednesday, 25 October 2017 2:26 AM
> To: FreeIPA users list 
> Cc: Aaron Hicks 
> Subject: Re: [Freeipa-users] Enrolling SLE 12 SP2 hosts with FreeIPA
> 
> On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
>> Hello the FreeIPA List,
>>
>>  
>>
>> We've got a FreeIPA directory set up and running. That's all good.
>>
>>  
>>
>> The difficult part is that we also have a number (many) of SLE 12 SP2 
>> hosts that need to be enrolled.
>>
>>  
>>
>> I can see that the freeipa-client package has not been available to 
>> SLE/SUSE since 2015 or so, so the ipa-client-install, ipa-join, and 
>> ipa- getkeytab tools are unavailable. They would be nice, we'd just do 
>> a check and execute it when host is redeployed to enroll and configure 
>> the host.
>>
>>  
>>
>> We've manage to figure out the static parts of the required 
>> configuration (/etc/nsswitch.conf /etc/sssd/sssd.conf and 
>> /etc/krb5.conf) as well as deploying the FreeIPA server's certificate 
>> to /etc/ipa/ca.crt. We can also enroll the hosts 'remotely' by 
>> scripting over their hostnames and IP addresses from a CSV file, so 
>> the exist in the FreeIPA directory and even join them to some 
>> hostgroups.
>>
>>  
>>
>> The bit we're a bit stuck at is retrieving the host's Kerberos keytab. 
>> There does not seem to be a getkeytab request for the FreeIPA API, and 
>> the use of kadmin and ktutil to process the keytab is not recommended.
> 
> Use ipa-getkeytab on an admin workstation, then securely transfer the keytab 
> to the servers.
> 
> 
>> We need a stepwise process to run on the host being enrolled that gets 
>> the keytab from the FreeIPA directory and installs it into the host.
>>
>>  
>>
>> At the moment the method that looks like it's going to work is to 
>> write a script that ssh to the FreeIPA server, kinit as a user who can 
>> retrieve keytabs, get the keytab and write to a temporary file, scp 
>> the keytab back to the host, tidy up temp files, then return to the 
>> host, validate the keytab, install it, and restart Kerberos/sshd/sssd.
> 
> This may work also.
> 
>>  
>>
>> This seems less than ideal, alternatively should we look a compiling 
>> the ipa-client into a package?
> 
> In the freeIPA git repo there is, in the spec file, a variable that allows 
> you to compile only the client bits IIRC. You should be able to compile that 
> for SLES.
> 
> Simo.
> 
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA cross-forest trust, retrieve additional ldap attributes for users

[Alexander Bokovoy via FreeIPA-users]

On ti, 24 loka 2017, Steve Dainard wrote:

Hi Alexander,

That makes sense, is there a simple method to test which
ldap_user_extras_attrs sssd is pulling in on the IPA server side (are we
actually pulling in these attributes), and then test from the client side
dbus (list said attributes)?

See Stephen's blog, first part ("Configuring SSSD") has a good example
how to access SSSD infopipe with a command line:
https://sgallagh.wordpress.com/2016/05/27/openshift-and-sssd-part-3-extended-ldap-attributes/


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

[Freeipa-users] Re: Install replica

[Rob Crittenden via FreeIPA-users]

Oleg Danilovich via FreeIPA-users wrote:
> Hello guys, 
> I want deploy freeipa replica. Now my master works on Ubuntu 16.04.
> Master version VERSION: 4.3.1, API_VERSION: 2.164
> Then i try to install replica on ubuntu i get error. I tried to find a
> solution but could not. 

It would help if you told us what error you saw.

> I want try to install freeipa replica on centos. Can i use freeipa
> replica on centos then my master on Ubuntu 16.04 ? 

Yes that should work.

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

[Freeipa-users] Re: Latest updates broke pki-tomcatd

[Rob Crittenden via FreeIPA-users]

Kristian Petersen via FreeIPA-users wrote:
> You mentioned that once before, but that path doesn't seem to exist on
> my server for some reason.  When I go to /var/log/pki i get:
> -bash-4.2$ cd /var/log/pki/ 
> -bash-4.2$ ls 
> pki-server-upgrade-10.4.1.log  pki-upgrade-10.4.1.log  server
> 
> In a previous reply, I ran a command you asked me to that showed some
> information about the setup of our IPA server that you had requested
> that you may need to look at.

Then you don't have a CA installed on this host. This is where the logs
would be on a 4.5.0 server. You can try something like find /var/log
-name debug in case this was an oft-upgraded server and the path is for
an older release.

rob

> 
> On Thu, Oct 19, 2017 at 1:21 AM, Rob Crittenden  > wrote:
> 
> Kristian Petersen wrote:
> 
> I'm still struggling with this one and it seems at least partially
> responsible for the UI misbehaving as we discussed in another
> thread.
> Have you had any new insights regarding this?
> 
> 
> I'd start with looking at /var/log/pki/pki-tomcat/ca/debug. You want
> to find the latest start and work down from there (rather than
> bottom up).
> 
> rob
> 
> 
> On Mon, Oct 9, 2017 at 3:54 PM, Kristian Petersen
> 
> >>
> wrote:
> 
> The installation is a standard RedHat IdM install with DNS,
> SMB, and
> CA services installed.
> 
> The output of the ldapsearch you mentioned is:
> -bash-4.2$ ldapsearch -LLL -Y GSSAPI -b cn=ipa1.chem.byu.edu
> 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> SASL/GSSAPI authentication started
> SASL username: nesre...@chem.byu.edu
>   >
> SASL SSF: 56
> SASL data security layer installed.
> dn: cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> ipaMaxDomainLevel: 1
> ipaReplTopoManagedSuffix: dc=chem,dc=byu,dc=edu
> ipaReplTopoManagedSuffix: o=ipaca
> objectClass: top
> objectClass: nsContainer
> objectClass: ipaConfigObject
> objectClass: ipaSupportedDomainLevelConfig
> objectClass: ipaReplTopoManagedServer
> cn: ipa1.chem.byu.edu 
> 
> ipaMinDomainLevel: 0
> 
> dn: cn=CA,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: enabledService
> ipaConfigString: startOrder 50
> ipaConfigString: caRenewalMaster
> cn: CA
> 
> dn: cn=KDC,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=edu
> 
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: startOrder 10
> ipaConfigString: enabledService
> ipaConfigString: kdcProxyEnabled
> ipaConfigString: pkinitEnabled
> cn: KDC
> 
> dn: cn=KPASSWD,cn=ipa1.chem.byu.edu 
>
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc
> =edu
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: enabledService
> ipaConfigString: startOrder 20
> cn: KPASSWD
> 
> dn: cn=MEMCACHE,cn=ipa1.chem.byu.edu 
>
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,d
> c=edu
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: startOrder 39
> ipaConfigString: enabledService
> cn: MEMCACHE
> 
> dn: cn=OTPD,cn=ipa1.chem.byu.edu 
>
> 
> ,cn=masters,cn=ipa,cn=etc,dc=chem,dc=byu,dc=ed
> 
> u
> objectClass: ipaConfigObject
> objectClass: nsContainer
> objectClass: top
> ipaConfigString: 

[Freeipa-users] Re: ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Would you look at that! Problem solved.Thanks.

On Tue, Oct 24, 2017 at 12:08 PM, Rob Crittenden 
wrote:

> Alexandre Pitre via FreeIPA-users wrote:
> > Hi,
> >
> > I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple
> > groups with the sudorule-add-user command.
> >
> > Example:
> >
> > ipa sudorule-add-user sudorule --groups=group1,group2
> >
> >  Failed users/groups:
> > member user:
> > member group: group1,group2
> > -
> > Number of members added 0
> > -
> >
> > Other similar ipa commands support multiple groups just fine.
> >
> > Is this normal ?
>
> CSV hasn't been supported for quite a long time. I'd be curious where it
> is still working.
>
> You can do let bash expand it instead:
>
> ipa sudorule-add-user sudorule --groups={group1,group2}
>
> rob
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Rob Crittenden via FreeIPA-users]

Alexandre Pitre via FreeIPA-users wrote:
> Hi,
> 
> I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple
> groups with the sudorule-add-user command.
> 
> Example:
> 
> ipa sudorule-add-user sudorule --groups=group1,group2
> 
>  Failed users/groups:
> member user:
> member group: group1,group2
> -
> Number of members added 0
> -
> 
> Other similar ipa commands support multiple groups just fine.
> 
> Is this normal ?

CSV hasn't been supported for quite a long time. I'd be curious where it
is still working.

You can do let bash expand it instead:

ipa sudorule-add-user sudorule --groups={group1,group2}

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

[Freeipa-users] ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Hi,

I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple groups
with the sudorule-add-user command.

Example:

ipa sudorule-add-user sudorule --groups=group1,group2

 Failed users/groups:
member user:
member group: group1,group2
-
Number of members added 0
-

Other similar ipa commands support multiple groups just fine.

Is this normal ?

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

[Freeipa-users] Re: cross-forest trust, client system cannot id AD users.

[Steve Dainard via FreeIPA-users]

Hi Jakub,

As a follow up, you are correct - neither the primary group or wheel group
that existed in AD needed to be created in IPA.

Thanks

On Fri, Oct 20, 2017 at 1:01 AM, Jakub Hrozek  wrote:

> On Thu, Oct 19, 2017 at 05:34:41PM -0700, Steve Dainard wrote:
> > Thanks Jakub and Justin,
> >
> > It definitely is related to the wheel group. For a quick explanation, the
> > wheel group exists in AD with a gid of 10 so users who belong to that
> group
> > automatically have wheel/sudo perms on EL systems (we use posix
> attributes
> > in AD for all our users/groups).
> >
> > The easy fix seems to have been to add a wheel group with gid 10 to the
> IPA
> > side, no group members. Now I get:
> >  uid=1587(steve.dain...@addomain.com) gid=1028(employ...@ipadomain.zone)
> > groups=1028(employ...@ipadomain.zone),10(wheel),
> 1027(clus...@addomain.com
> > ),1029(sys...@addomain.com),1041(confluence-administrat...@addomain.com
> > ),1060(employees-vancou...@addomain.com),1086(dev...@addomain.com)
> > context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >
> > I got the idea from the RH IPA docs mentioning if a user has a primary
> > group in AD with a gid, the group must also exist in IPA albeit doesn't
> > need any members.
> > If this step isn't completed some secondary group
> > memberships may not be resolved on the IPA side.
>
> Maybe the docs are not totally clear, but the requirement is a bit
> different
> -- it is actually that each GID number the user is a member of (as reported
> by "id -G") must be resolvable into a group object with getgrgid() (or,
> with getent group $gidnumber) on the command line.
>
> >
> > Its still a bit odd that the wheel group appears to be a client local
> wheel
> > group rather than @IPADOMAIN.
>
> I think this is because /etc/nsswitch.conf defines "groups" as "files sss".
>
> So the initgroups operation returns a list of gids, which are then
> translated
> into names, but because files precedes sss, the local group name is used
> first.
>
> By the way, you might be interested in
> https://sourceware.org/glibc/wiki/Proposals/GroupMerging
>
> (I keep forgetting it this is already backported to RHEL-7, though..)
>
> > The 'employees@IPADOMAIN' group listed above
> > is actually the primary gid in AD Unix attributes, and is defined in IPA
> > with the same gid but has no members. I'm guess this is because an EL
> host
> > /etc/group defines 'wheel' by default, but not 'employees'.
> >
> > Once we get IPA into production I'll pull the wheel group out of AD and
> > keep it defined in IPA only.
> >
> > Thanks,
> > Steve
> >
> > On Thu, Oct 19, 2017 at 11:37 AM, Justin Stephenson via FreeIPA-users <
> > freeipa-users@lists.fedorahosted.org> wrote:
> >
> > > On 10/19/2017 02:14 PM, Jakub Hrozek via FreeIPA-users wrote:
> > >
> > >> On Tue, Oct 17, 2017 at 02:21:07PM -0700, Steve Dainard via
> FreeIPA-users
> > >> wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I've installed a 60 day 'self supported' trial of red hat idm on
> rhel7.
> > >>> I've created a cross-forest trust with an AD domain (2012R2) which
> > >>> already
> > >>> has posix attributes in ldap for users and groups.
> > >>>
> > >>> On my ipa server I can id/getent my AD user, and can SSH to the ipa
> > >>> server
> > >>> with my AD credentials/kerberos ticket.
> > >>> # id steve.dain...@addomain.com
> > >>> uid=1587(steve.dain...@addomain.com) gid=1028(employees)
> > >>> groups=1028(employees),1041(confluence-administrat...@addomain.com
> > >>> ),1060(employees-vancou...@addomain.com),10(wheel),1027(clus
> > >>> t...@addomain.com
> > >>> ),1086(dev...@addomain.com),1029(sys...@addomain.com)
> > >>>
> > >>> I installed Centos 7.4 and joined it to the realm but I'm having
> > >>> intermittent issues id'ing users. At first I couldn't id any AD
> user, but
> > >>> then I added a trusted domain ldap_search_base to the ipa servers
> > >>> sssd.conf:
> > >>>
> > >>> ldap_search_base = OU=Employees,OU=Users,OU=
> Accounts,DC=ADDOMAIN,DC=com
> > >>>
> > >>> This initially seemed to work intermittently, some users I could id
> and
> > >>> some I could not. I also noticed that the group membership of the
> users I
> > >>> could id was incomplete, notably I have an AD group 'wheel' with gid
> 10
> > >>> that shows on the ipa server side when I id my AD user, but didn't
> show
> > >>> on
> > >>> the client side.
> > >>>
> > >>> I decided to clear out the cache files manually and restart sssd on
> the
> > >>> client, and now I can't id my user, but I can id users outside of the
> > >>> ldap_search_base, specifically user accounts which are inactive and
> exist
> > >>> in a inactive-users OU ouside the ldap_search_base. Very confusing.
> > >>>
> > >>> The sssd server side seems to be iterating through all my AD users
> > >>> account
> > >>> names in the logs (debug_level = 10) and I don't feel comfortable
> posting
> > >>> logs with their complete names online..
> > >>>
> > >>>
> > >>> IPA server sssd.conf:

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Simo Sorce via FreeIPA-users]

On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the FreeIPA List,
> 
>  
> 
> We've got a FreeIPA directory set up and running. That's all good.
> 
>  
> 
> The difficult part is that we also have a number (many) of SLE 12 SP2
> hosts
> that need to be enrolled.
> 
>  
> 
> I can see that the freeipa-client package has not been available to
> SLE/SUSE
> since 2015 or so, so the ipa-client-install, ipa-join, and ipa-
> getkeytab
> tools are unavailable. They would be nice, we'd just do a check and
> execute
> it when host is redeployed to enroll and configure the host.
> 
>  
> 
> We've manage to figure out the static parts of the required
> configuration
> (/etc/nsswitch.conf /etc/sssd/sssd.conf and /etc/krb5.conf) as well
> as
> deploying the FreeIPA server's certificate to /etc/ipa/ca.crt. We can
> also
> enroll the hosts 'remotely' by scripting over their hostnames and IP
> addresses from a CSV file, so the exist in the FreeIPA directory and
> even
> join them to some hostgroups.
> 
>  
> 
> The bit we're a bit stuck at is retrieving the host's Kerberos
> keytab. There
> does not seem to be a getkeytab request for the FreeIPA API, and the
> use of
> kadmin and ktutil to process the keytab is not recommended.

Use ipa-getkeytab on an admin workstation, then securely transfer the
keytab to the servers.


> We need a stepwise process to run on the host being enrolled that
> gets the
> keytab from the FreeIPA directory and installs it into the host.
> 
>  
> 
> At the moment the method that looks like it's going to work is to
> write a
> script that ssh to the FreeIPA server, kinit as a user who can
> retrieve
> keytabs, get the keytab and write to a temporary file, scp the keytab
> back
> to the host, tidy up temp files, then return to the host, validate
> the
> keytab, install it, and restart Kerberos/sshd/sssd.

This may work also.

>  
> 
> This seems less than ideal, alternatively should we look a compiling
> the ipa-client into a package?

In the freeIPA git repo there is, in the spec file, a variable that
allows you to compile only the client bits IIRC. You should be able to
compile that for SLES.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

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

[Florence Blanc-Renaud via FreeIPA-users]

On 10/23/2017 08:59 PM, Bhavin Vaidya via FreeIPA-users wrote:

Hello Rob,


here what we have. Looks like /etc/http/alias certificate is different, 
as it is from Sug 03 2014 through Aug 03 2034, which is original date.


If /etc/httpd/alias does not contain the latest IPA CA certificate, 
running ipa-certupdate should fix this. The tool gets certificates from 
cn=certificates,cn=ipa,cn=etc,$BASEDN so you need to make sure that the 
latest one is present in this tree.


It will also update /etc/dirsrv/slapd-DOMxx, /etc/ipa/ca.crt and 
/etc/ipa/nssdb. It can be run on all IPA hosts (masters or clients).


Flo.



[root@ds01 alias]# certutil -L -d /etc/httpd/alias/

Certificate Nickname                                         Trust 
Attributes
 
  SSL,S/MIME,JAR/XPI


ipaCert                                                      u,u,u
Server-Cert                                                  u,u,u
EXAMPLE.COM IPA CA                                           CT,C,C

[root@ds01 alias]# certutil -d /etc/httpd/alias/ -L -n "EXAMPLE.COM IPA CA"
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 1 (0x1)
         Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
         Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
         Validity:
             Not Before: Sun Aug 03 19:28:18 2014
             Not After : Thu Aug 03 19:28:18 2034
         Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
         Subject Public Key Info:
             Public Key Algorithm: PKCS #1 RSA Encryption
             RSA Public Key:
                 Modulus:
                     c3:9d:33:68:81:3a:7e:83:15:ba:bd:54:1c:a3:28:6a:
                     

                 Exponent: 65537 (0x10001)
         Signed Extensions:
             Name: Certificate Authority Key Identifier
             Key ID:
                 48:da:13:cd:37:06:74:ac:
                 da:f7:6d:c6

             Name: Certificate Basic Constraints
             Critical: True
             Data: Is a CA with no maximum path length.

             Name: Certificate Key Usage
             Critical: True
             Usages: Digital Signature
                     Non-Repudiation
                     Certificate Signing
                     CRL Signing

             Name: Certificate Subject Key ID
             Data:
                 48:da:13:cd:37:06:74:ac:
                 da:f7:6d:c6

             Name: Authority Information Access
             Method: PKIX Online Certificate Status Protocol
             Location:
                 URI: "http://ipa01.example.com:80/ca/ocsp;

     Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
     Signature:
         7e:bb:1e:d8:f7:2c:57:45:57:2a:cb:a9:43:a9:1e:88:
         
     Fingerprint (SHA-256):
         64::1C
     Fingerprint (SHA1):
         28:How can we promote or update all the certificates on first master, then 
replica and client? Will we have to reboot or re-install client?


thank you and with regards,
Bhavin


*From:* Rob Crittenden 
*Sent:* Monday, October 23, 2017 11:14 AM
*To:* Anvar Kuchkartaev; Bhavin Vaidya via FreeIPA-users
*Cc:* John Dennis; Bhavin Vaidya
*Subject:* Re: [Freeipa-users] Re: several IPA CA certificate entries
Anvar Kuchkartaev wrote:

Have you tried to add CA to systemwide database?


It gets added as part of ipa-client-install, after the point where it is
failing.

This leads me to believe you don't have the "right" CA certificate after
all.

Is your Apache web cert signed by the IPA CA or a 3rd party? If by IPA
then I'd compare the CA cert in the NSS db in /etc/httpd/alias with the
one you have in LDAP.

mod_nss won't let Apache start with a bad cert chain.

rob



Anvar Kuchkartaev 
an...@aegisnet.eu 
*From: *Bhavin Vaidya via FreeIPA-users

*Sent: *lunes, 23 de octubre de 2017 07:46 p.m.
*To: *Rob Crittenden; FreeIPA users list
*Reply To: *FreeIPA users list
*Cc: *John Dennis; Bhavin Vaidya
*Subject: *[Freeipa-users] Re: several IPA CA certificate entries


Thank you everyone.


We did manage to delete the certificates, all but the right one (we
figured out looking at clients' /etc/ipa/ca.crt)


But on client installation we now get different message, which is
related to certificate too. tried another IPA server too, same message.


Successfully retrieved CA cert
 Subject: CN=Certificate Authority,O=EXAMPLE.COM
 Issuer:  CN=Certificate Authority,O=EXAMPLE.COM
 Valid From:  Thu Jun 01 12:55:08 2017 UTC
 Valid Until: Mon Jun 01 12:55:08 2037 UTC

Joining realm failed: libcurl failed to execute the HTTP POST
transaction.  Peer certificate cannot be authenticated with known CA
certificates

Installation failed. Rolling back changes.
IPA client is not configured on this system.

I have attached the log file.

thank you all once again.
regards,
Bhavin