June 2020 - FreeIPA-users - Fedora mailing-lists

AddTrust CA expiration
by Peter Lewis 05 Jun '20

05 Jun '20

On May 30, 2020, the AddTrust CA expired as a CA. I'll get to the IPA issue after a bit of background in case everyone is not familiar. The external certs we're using are from InCommon and were cross signed by AddTrust and when we originally got the certs, the trust A path was below: AddTrust Ext CA -> UserTrust CA (intermediate) -> InCommon CA (Intermediate) -> server_cert The B path which should have worked was: UserTrust CA (Root) -> InCommon CA (Intermediate) -> server_cert How OpenSSL is supposed to work is after path A expires, its supposed to use path B. Unfortunately for OpenSSL and OpenLDAP in CENTOS/RHEL 7 and older there is a bug and that does not happen and will not attempt path B. See bugzilla for more information: https://bugzilla.redhat.com/show_bug.cgi?id=1840767 The only way I could get them to walk to path B was to remove the AddTrust CA from all openssl certificate stores. Also, blacklisting doesn't work either as it just made the certs as self-signed. Fortunately there is a path C that we can deploy and force that trust path: Comodo AAA Certificate (Root) -> UserTrust CA (Intermediate) -> InCommon CA (Intermediate) -> server_cert This is also the cert bundle now provided by InCommon. The main issue here is when openssl "builds" the extracted certificates, it adds in the CA's from both /etc/ipa/ca.crt and from katello-ca.crt. We've been able to update the katello and push out that as an RPM, we're having issues with the ca distributed by IDM. ====== actual issue with IPA =============== Post May 30, we could no longer log into IPA. We'd attempted to follow the process for "updating" the certificate. That didn't work. We did an install as we did end up adding a new signed server certificate. That didn't update the Root or the Intermediate CAs. So I went in with a hammer and manually removed the offending AddTrust cert chain A from the following NSSDB files: /etc/httpd/alias /etc/pki/pki-tomcat/alias /etc/dirsrv/slapd-LIDS-VIRGINIA-EDU /etc/ipa/nssdb I also manually cleaned up the /etc/ipa/ca.crt and /etc/pki/ca-trust/source/ipa.p11-kit cert stores. With the above, I was able to get IPA to restart and we could then log into the console and do all we needed to do. The issue now is that the command "ipa-certupdate" still pulls the old AddTrust cert path and I'm pretty sure its because its stored in 389ds. ldapsearch -x -b dc=dom,dc=example,dc=com "(objectClass=ipaCertificate)" | grep Subject ipaCertSubject: CN=Certificate Authority,O=DOM.EXAMPLE.COM ipaCertSubject: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor, ipaCertSubject: CN=USERTrust RSA Certification Authority,O=The USERTRUST Netwo ipaCertSubject: CN=AddTrust External CA Root,OU=AddTrust External TTP Network, How do I update LDAP without things blowing up (oh we're 3 node clustered as well)? Or better yet, is was there a better way to replace certs? Our main com.example.com CA is just fine. All the articles/info I could find was replacing that and not the external CA's. CENTOS/RHEL8 does not have this problem btw. It's fixed in openssl 1.1.1.

3 5

About command line and multi ipa servers
by lune voo 05 Jun '20

05 Jun '20

Hello ! I send you this mail because I have a question with the command line of IPA and the high availability of IPA. I have the following setup : - 2 IPA servers (version 4.6.6) on RHEL 7.6 : S1 and S2 - n IPA clients (version 3.0.0) on RHEL 6.6 When I installed ipa clients with ipa-client-install, I specified both IPA servers. Yesterday, S1 crashed. On one of the client, the command line was not working anymore. ipa user-show myuser ipa: ERROR: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-MYREALM.socket': It appears the command line use the following file to know which IPA server to contact : /etc/ipa/default.conf In this file, I saw that there was only S1 mentioned : # cat /etc/ipa/default.conf #File modified by ipa-client-install [global] basedn = dc=myrealm realm = MYREALM domain = mydomain.com server = S1.mydomain.com xmlrpc_uri = https://S1.mydomain.com/ipa/xml enable_ra = True Is it possible to benefit from high availability when we use IPA command line ? If yes, how ? Best regards. Lune

2 3

IPA -> AD trust : can't ssh with an AD user
by Christophe BERGER 04 Jun '20

04 Jun '20

Good morning all, I created a lab with freeIPA and AD with a trust. - AD domain : test.lu - IPA domain : test2.lu I have installed a Oracle Linux 8.2 VM as the client. I created a freeIPA user group : tgo_admins There are 2 members : - ipalocaluser (local IPA account) - aduser (AD account) sudo ipa group-show tgo_admins Group name: tgo_admins External member: aduser(a)test.lu Member users: ipalocaluser Member of groups: admins Member of Sudo rule: tgo_admins Member of HBAC rule: tgo_admins The HBAC rule allows tgo_admins to login in any machine. The sudo rule allows tgo_admins to sudo in any machine. - With an account created in freeIPA I can ssh to the vm : ssh ipalocaluser(a)10.168.78.122 Last login: Thu Jun 4 14:23:43 2020 from 10.168.78.1 [ipalocaluser@ipa-test ~]$ klist Ticket cache: KCM:703800005:58408 Default principal: ipalocaluser(a)TEST2.LU Valid starting Expires Service principal 06/04/2020 14:24:01 06/05/2020 14:24:01 krbtgt/TEST2.LU(a)TEST2.LU - With the ad account, it fails to login ssh aduser@test.lu@10.168.78.122 aduser@test.lu@10.168.78.122's password: aduser@test.lu@10.168.78.122's password: The password is correct, I double checked. From the workstation itself, the authentication looks fine : sudo kinit aduser(a)test.lu Password for aduser(a)test.lu: [cbr@ipa-test ~]$ sudo klist Ticket cache: KCM:0:28293 Default principal: aduser(a)TEST.LU Valid starting Expires Service principal 06/04/2020 12:31:53 06/04/2020 22:31:53 krbtgt/TEST.LU(a)TEST.LU renew until 06/05/2020 12:31:50 I can also sudo su - aduser(a)test.lu Creating home directory for aduser(a)test.lu. Last failed login: Thu Jun 4 14:30:52 CEST 2020 from 10.168.78.1 on ssh:notty There were 2 failed login attempts since the last successful login. Any idea ?

2 2

Add Windows host in Freeipa
by dmitriys 04 Jun '20

04 Jun '20

Good day! I tried add windows host in Freeipa and get 04:05:59.302019 IP (tos 0x0, ttl 123, id 27536, offset 0, flags [none], proto UDP (17), length 205) cyberark-psm.exemple.com.54676 > ldap.exemple.com.kerberos: [udp sum ok] v5 04:05:59.303073 IP (tos 0x0, ttl 64, id 24242, offset 0, flags [DF], proto UDP (17), length 187) ldap.exemple.com.kerberos > cyberark-psm.exemple.com.54676: [bad udp cksum 0x9a1a -> 0x88b5!] Can you help me with this issue ?

3 2

sub-cas ipa-certupdate
by Natxo Asenjo 03 Jun '20

03 Jun '20

hi, in the rhel 8 documentation I came across this: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… 1. In the command-line interface, run the *ipa-certupdate* command to create a *certmonger* tracking request for the *webserver-ca* and *webclient-ca* sub-CAs certificates: [root@ipaserver ~]# ipa-certupdate Important Forgetting to run the *ipa-certupdate* command after creating a sub-CA means that if the sub-CA certificate expires, end-entity certificates issued by the sub-CA are considered invalid even if the end-entity certificate has not expired. Is this also valid for rhel 7? I do not see this in the documentation https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… and taking a peek at getcert list on the CA role servers I do not see any certmonger tracking request for our sub cas. -- Regards, natxo

3 5

root CA 4096 bits signing key
by Natxo Asenjo 03 Jun '20

03 Jun '20

hi, We have a new realm with rhel 7.8 and a default CA key of 2048 bits. Recently a question arose to upgrade this to 4096 bits. According to this blog post https://frasertweedale.github.io/blog-redhat/posts/2020-01-28-freeipa-overr… ) this should already be possible for new deployments with RHEL 8.1 but is it possible to configure the root CA and eventually sub CAs to use the 4096 bits signing keys? In doing so, do we need to resign all certificates already in use? Is it possible to do this in RHEL 7 or do we need to update the CA hosts to 8.1 to achieve it? Thanks in advance for your answers. -- Regards, Natxo

4 6

clients with uppercase names
by Ben Aveling 03 Jun '20

03 Jun '20

Hi, I have some hosts with partially uppercase hostnames that I want to install ipa-client on. On a test machine called Centos6, I installed ipa-client, let it change the hostname to centos6 and then changed the hostname back to Centos6. It seems to have worked, but am I exposing myself to potential problems down the track? This is how it looks now: -sh-4.2$ hostname Centos6.myclients.example.com -sh-4.2$ cat default.conf #File modified by ipa-client-install [global] basedn = dc=my,dc=example,dc=com realm = MY.EXAMPLE.COM domain = my.example.com server = centos4.my.example.com host = centos6.my.example.com xmlrpc_uri = https://centos4.my.example.com/ipa/xml enable_ra = True # klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/centos6.my.example.com(a)MY.EXAMPLE.COM 1 host/centos6.my.example.com(a)MY.EXAMPLE.COM The server seems quite happy to believe what it is being told about the clients identity. ... 10.0.4.106: ISSUE: authtime 1591194632, etypes {rep=18 tkt=18 ses=18}, test6(a)MY.EXAMPLE.COM for host/centos6.my.example.com(a)MY.EXAMPLE.COM Regards, Ben

1 0

small office options
by Ben Aveling 03 Jun '20

03 Jun '20

Hi, I'm looking for a way to set up a small office. I'm trying not to have to have all the clients SSSD back to the central office. It would be nice to be able to have a small FreeIPA server, and just pull in the necessary user data from the central servers. But it's not clear what the best way to do that would be. A replica seems like overkill - and forces the central servers to trust the small office, which isn't ideal. Some sort of selective one-way replication would work. What would be nice would be if the small office FreeIPA server could retrieve user data as needed, and then cache it, a bit like SSSD does for clients. Some sort of filtered export/import would also be acceptable, so long as we can be sufficiently confident about security of key material. Any suggestions? Regards, Ben

2 2

Re: Planing multi-site deployment
by Willie Lima 03 Jun '20

03 Jun '20

I'm using these commands to the installation: ipa-server-install \ --realm INT.MYDOMAIN.COM --domain site1.prod.int.mydomain.com \ --hostname ipa01.site1.prod.int.mydomain.com \ --setup-dns --auto-forwarders --forward-policy only with this command, the client is able to join normally. ipa-client-install --realm INT.MYDOMAIN.COM --domain site1.prod.int.mydomain.com The problem is when I try to create the replica server on the second domain, I got: "Cannot promote this client to a replica. Local domain 'site2.prod.int.mydomain.co m' does not match IPA domain 'site1.prod.int.mydomain.com'. I might be doing something wrong.

1 0

Still issues with member_of
by Mary Georgiou 03 Jun '20

03 Jun '20

Dear all, We are still experiencing issues with the memberOf plugin for which you may have some advice. We are constantly synchronizing accounts and groups into freeipa from external resources. At each time we have approx 60.000+ users and 60.000+ groups, where there are groups with more than 10.000 memberships. In order to do the full first synchronization, we disabled memberOf and run the fixup afterward. The problem is that we are still experiencing issues with the plugin when we have an update on groups that requires modifying more than a certain number of memberships (more specifically the LDAP server stops being responsive). I read here [1] that this is because the plugin is doing lots of recomputations each time a group is updated. We thought of disabling the plugin for the user and group containers, and manage the memberOf ourselves (for the group memberships only) but then there's the issue of netgroups, roles, HBAC Rules, and sudo rules memberships. Is there any advice on how to approach this? Any part of the configuration we should tweak? Thank you very much in advance, Mary Georgiou [1] https://www.freeipa.org/page/V4/Performance_Improvements#memberof_fixup

2 3

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2020