June 2020 - FreeIPA-users - Fedora mailing-lists

Problems Cleaning Up After Migration and Upgrade
by Auerbach, Steven 20 Jun '20

20 Jun '20

I have finally been able to create an RHEL7/IPAv4 server using ipa-replica-prepare on a RHEL6/IPA v3 server (ipa01)(added the needed schema) and running ipa-replica-install on the RHEL7/IPAv4 server (ipa03). I followed a number of steps to stop CA and CA Renewal on ipa01 and make ipa03 the CA and CA Renewal master as well as the DNS master. I then created another RHEL7 server (ipa04) and ran the ipa-replica-prepare on ipa03 and ran ipa-replica-install in ipa04. In the IPA Administrative GUI I am exploring the topology because I need to ultimately get rid of ipa01 and ipa-r02 - both RHEL6/IPAv3 servers. I have 2 suffixes: ca and domain. The four servers show up in the IPA Servers pane. Only ipa03 and ipa04 have Managed Suffixes. Both have domain and ca. Both have Min Domain Level 0 and Max Domain Level 1. Is this as it should be? Server Roles pane shows that ipa01, ipa03, and ipa04 are CA servers. Eventually I need to remove ipa01. DNS servers are only ipa03 and ipa04. This is okay, I think. Domain Level pane show Level 0 Topology Graph pane says "Managed topology requires minimum level 1". The Add and Delete buttons are greyed out. IPA Locations pane has No entries. When I tried to run ipa-server-install -uninstall -U on ipa-r02 I received a number of errors: Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Unconfiguring named Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached ipa : ERROR Some certificates may still be tracked by certmonger. This will cause re-installation to fail. Start the certmonger service and list the certificates being tracked # getcert list These may be untracked by executing # getcert stop-tracking -i <request_id> for each id in: 20150127222017 In the CLI on ipa03 when I ran "ipa-replica-manage list" and the result is ipa01: master, ipa-r02: master, ipa03: master, ipa04: master. In the CLI on ipa03 when I ran "ipa-csreplica-manage list" and the result is ipa01: master, ipa-r02: CA not configured, ipa03: master, ipa04: master. So ipa-r02 still shows up....How do I clean this up properly in the system? And how do I properly remove ipa01 when the time comes? All the documentation I find refers to replicas. It seems I do not have any replicas, I have all masters. There is something fundamental I continue to miss in administering this environment. Steven Auerbach Assistant Director of Information Systems Information Technology & Security State University System of Florida Board of Governors 325 W. Gaines Street Tallahassee, Florida 32399 (850) 245-9592 www.flbog.edu<http://www.flbog.edu/> [Graphic for Email]

1 0

cipher support and nsSSL3Ciphers: +all
by Chris Herdt 19 Jun '20

19 Jun '20

I have an appliance that I want to use with our FreeIPA-provided LDAP servers. The appliance only supports the following ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) I tried changing the following in dse.ldif, based on http://www.port389.org/docs/389ds/design/nss-cipher-design.html: nsSSL3Ciphers: +all However, this enabled only the following 7 ciphers (based on the output of nmap --script ssl-enum-ciphers -p 636 freeipa-01.example.com) TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_RSA_WITH_SEED_CBC_SHA Here's the content of the dn: cn=encryption,cn=config section: dn: cn=encryption,cn=config CACertExtractFile: /etc/dirsrv/slapd-EXAMPLE-COM/CN3dUSERTrust20RSA20Certif ication20Authority2cO3dThe20USERTRUST20Network2cL3dJersey20City2cST3dNew20Jer sey2cC3dUS.pem allowWeakCipher: off cn: encryption createTimestamp: 20181108213233Z creatorsName: cn=server,cn=plugins,cn=config modifiersName: cn=server,cn=plugins,cn=config modifyTimestamp: 20181108213359Z nsSSL3Ciphers: +all nsSSLClientAuth: allowed nsSSLSessionTimeout: 0 objectClass: top objectClass: nsEncryptionConfig sslVersionMin: TLS1.2 numSubordinates: 1 Any ideas why this change isn't enabling the additional ciphers? Thanks!

2 4

ipa-replica-install fails
by Orion Poplawski 19 Jun '20

19 Jun '20

I'm trying run ipa-replica-install on a non-IPA joined CentOS 8.2 system: ipa-replica-install --principal admin --admin-password='SECRET' Configuring client side components This program will set up IPA client. Version 4.8.4 Using existing certificate '/etc/ipa/ca.crt'. Skip SERVER1: cannot verify if this is an IPA server Skip SERVER2: cannot verify if this is an IPA server Skip SERVER3: cannot verify if this is an IPA server Unable to find IPA Server to join The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information ipaclient-install.log has: 2020-06-18T18:22:05Z DEBUG [LDAP server check] 2020-06-18T18:22:05Z DEBUG Verifying that SERVER1 (realm NWRA.COM) is an IPA server 2020-06-18T18:22:05Z DEBUG Init LDAP connection to: ldap://SERVER1:389 2020-06-18T18:22:05Z DEBUG Error checking LDAP: Connect error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) 2020-06-18T18:22:05Z WARNING Skip SERVER1: cannot verify if this is an IPA server How can I resolve this? Thanks, Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 2

Re: Last FreeIPA master is failing
by Rob Crittenden 19 Jun '20

19 Jun '20

Ricardo Mendes wrote: > Hi Rob once again many thanks for helping! > >> My guess is that the LE CA certificates are not trusted by the NSS >> database that dogtag uses. Assuming you've added those CA certificates >> to IPA using ipa-cacert-manage install then running ipa-certupdate >> should fix things for you. >> >> rob > > I think the LE CA certificates are added with certutil as per the script > I don't know if it runs ipa-cacert-manage install. If you ran setup-le.sh then yes. > I had tried ipa-certupdate as I remember having read that running it > usually fixes a number of issues with the cert setup. It finishes > succesfully. > > # ipa-certupdate > trying https://main.domain.io/ipa/json > [try 1]: Forwarding 'schema' to json server > 'https://main.domain.io/ipa/json' > trying https://main.domain.io/ipa/session/json > [try 1]: Forwarding 'ca_is_enabled/1' to json server > 'https://main.domain.io/ipa/session/json' > [try 1]: Forwarding 'ca_find/1' to json server > 'https://main.domain.io/ipa/session/json' > Systemwide CA database updated. > Systemwide CA database updated. > The ipa-certupdate command was successful > > But the issue (now my issue is solely in starting pki-tomcatd. I can > connect to the GUI when I access via https I get the new cert, edit DNS > records (adding via web), authenticate to the web interface using > kerberos ticket. BUT the pki-tomcat keeps throwing errors and when I run > "ipactl restart" it fails unless I add the --ignore-service-failure > flag. (and --skip-version-check as well I still have that one stuck). > The certificates are at the $WORKDIR (ipa-le). You'd need to look at the certs in the tomcat NSS database and/or look at the 389-ds access log to see why the bind failed. > New issues: I can't use ldapsearch with 'cn=directory manager' it fails > with "ldap_bind: Invalid credentials (49)" and other apps that use LDAP > with other sysaccount just to bind cannot bind as well. Don't think it > is related to pki-tomcat tho. Neither would be affected by the certificates. rob > > Ricardo >

2 1

Secondary groups intermittently missing from id/groups lookups
by Alfred Victor 19 Jun '20

19 Jun '20

Hi all, We have built a FreeIPA system and used ipa migrate-ds to migrate and are testing the environment however we have a stubbornly persistent issue with gid array from posix commands or when dealing with filesystem ownerships. When I create a user in IPA, then add some groups, the issue is immediately present. In this case these first two below are missing a group ("testers"): [alvic@HOD28 ~]$ id ipatest uid=464200021(ipatest) gid=464200021(ipatest) groups=464200021(ipatest),464200000(admins) And another: [alvic@NODE-1-1 ~]$ id ipatest uid=464200021(ipatest) gid=464200021(ipatest) groups=464200021(ipatest),464200000(admins) More commonly, this is the case where only primary gid is returned, and both groups are missing: [alvic@NODE-1-2 ~]$ id ipatest uid=464200021(ipatest) gid=464200021(ipatest) groups=464200021(ipatest) The client systems were each provisioned like so, and we have also tested and found this issue on a totally up to date new CentOS 7 system: ipa-client-install -U -q -p [redacted] --domain=redacted.com --server= ipa.redacted.com --fixed-primary --force-join We have also attempted a full update of the IPA server via yum update and restarted it but the issue is incredibly common. We have also enabled sssd debuglevel 7 and I noted the following line: (Tue Jun 16 10:01:09 2020) [sssd[be[redacted.com]]] [sdap_save_user] (0x0400): Original memberOf is not available for [ipatest(a)redacted.com] Worth noting that groups display fine for a user, without fail, only if using "ipa user-show" Alfred

2 9

Re: Better way to upgrade IPAServer4.6.4 to 4.6.5 + OS 7.6 to 7.7?
by Florence Blanc-Renaud 18 Jun '20

18 Jun '20

On 6/12/20 2:52 PM, Karim Bourenane wrote: > Hello Florence, All > > After your recommendation : > yum update > ipactl start ( start will be start ipa-server-upgrade too) > > In attachment the ipaupgrade.log file > I hope the file will be taken by the website. > Hi, can you check the content of the /etc/ipa/default.conf file? I have never seen this error but it may happen if "mode = developer" is set in your default.conf, instead of "mode = production". HTH, flo > > Bien à vous > Mr Karim Bourenane > +33686464439 > +32 493 86 63 54 > > > Le jeu. 11 juin 2020 à 10:02, Florence Blanc-Renaud <flo(a)redhat.com > <mailto:flo@redhat.com>> a écrit : > > On 6/9/20 10:04 AM, Karim Bourenane via FreeIPA-users wrote: > > Hello Florence, all > > > > I have also only update ipa-*, but i have same Error. Its appears > that > > unable to unlink the port 8433 TCPV6 by pki-tomcat used by > FreeIPA. Im > > actually blocked with this minor update. > > > Hi, > do you mean that you ran > # yum update ipa-* > instead of > # yum update > ? > > The recommendation is to upgrade all the packages when upgrading the OS > version, not only the ipa ones. > Also please post the content of /var/log/ipaupgrade.log for us to > understand the exact issue. > > flo > > > .... > > [Ensurung CA is using LDAPProfileSubsustem) > > [Migration certificat profiles to LDAP] > > IPA server upgrade failed : Inspect /var/log/ipaupgrade.log and run > > command ipa-upgrade manually. Unexpected error - see > > /var/log/ipaupgrade.log for details: > > AttributeError: locked cannot see ra_certprofile.override_port to > 8443 > > > > ipa: DEBUG : File > > > /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py at > > line 1015, in run_script > > return_value = main_function () > > > > File /usr/sbin/ipactl, line 598, in main > > ipa_start (options) > > > > File /usr/sbin/ipactl, line 288, in main > > version_check () > > > > File /usr/sbin/ipactl, line161, in version_ckeck > > raise IpactlError ("Abording ipactl") > > > > Regard > > Karim > > > > > > Le lun. 8 juin 2020 à 08:58, Florence Blanc-Renaud > <flo(a)redhat.com <mailto:flo@redhat.com> > > <mailto:flo@redhat.com <mailto:flo@redhat.com>>> a écrit : > > > > On 6/6/20 11:42 AM, Karim Bourenane via FreeIPA-users wrote: > > > Hello Team > > > > > > I have some questions : > > > 1°) I need your help, to find the better way to upgrade my > 3 servers > > > linked (replicat). > > > I want to upgrade servers from CentOS 7.6 to CentOS7.7 with > > update in > > > same time the IPAServer (or separately ?) > > > > Hi, > > > > in order to upgrade each server from centOS 7.6 to CentOS > 7.7, you need > > to run "yum update". > > This command will also update ipa-* packages and internally call > > ipa-server-upgrade, meaning you don't need to manually call > > ipa-server-upgrade. > > Please find more information in "Updating Identity > Management" [1]. > > > > For multiple servers upgrade, keep in mind that the upgrade > needs to be > > done sequentially, i.e upgrade server 1, wait a few minutes for > > replication to propagate changes, upgrade server 2, etc... > > > > HTH, > > flo > > > > [1] > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… > > > > > > > > After searching on Freeipa.org and other site, i find : > > > #ipactl stop > > > #ipa-server-upgrade > > > #ipactl start > > > > > > I not need to delete first the replication link before ? > > > What is the better solution ways ? > > > > > > 2°) Is not better to migrate my IPAServers's to 4.7 or 4.8 > version ? > > > Or i need steps too ? > > > > > > Thanks you for your help > > > > > > Best Regard > > > Bien à vous > > > Mr Karim Bourenane > > > +33686464439 > > > +32 493 86 63 54 > > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- > > freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > <mailto:freeipa-users@lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org>> > > > To unsubscribe send an email to > > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > <mailto:freeipa-users-leave@lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org>> > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > > > > > > > > > _______________________________________________ > > FreeIPA-users mailing list -- > freeipa-users(a)lists.fedorahosted.org > <mailto:freeipa-users@lists.fedorahosted.org> > > To unsubscribe send an email to > freeipa-users-leave(a)lists.fedorahosted.org > <mailto:freeipa-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > > >

2 1

pki-tomcat fails to start after I update CA for dirsrv and httpd.
by luckydog xf 18 Jun '20

18 Jun '20

Hi, As state in https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA… I cannot login in FreeIPA web page. So I update CA by : # delete everything except IPA CA of httpd and dirsrv certutil -d /etc/http/alias -D -n 'xxx' # ca-bundle.crt is 3 files named USERTrust, .etc. # server.all is an combination of my certificate signed by Sectigo( fomerly named Comodo). openssl pkcs12 -export -chain -CAfile ca-bundle.crt -in server.all -out Server-Cert.p12 -name "Server-Cert" # add to httpd and dirsrv. pk12util -i Server-Cert.p12 -d /etc/httpd/alias/ -n Server-Cert I restart all services by ipactl restart. But it seems pki-tomcat fails to startup. #### log of ipactcl start #### Starting pki-tomcatd Service ipa: DEBUG: Starting external process ipa: DEBUG: args=/bin/systemctl start pki-tomcatd.target ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: request POST http://wocfreeipa.sap.wingon.hk:8080/ca/admin/ca/getStatus ipa: DEBUG: request body '' ipa: DEBUG: response status 500 ipa: DEBUG: response headers Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 2208 Date: Wed, 17 Jun 2020 09:13:19 GMT Connection: close ipa: DEBUG: response body '<html><head><title>Apache Tomcat/7.0.76 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-s ...... ipa: DEBUG: Failed to check CA status: Retrieving CA status failed with status 500 ipa: DEBUG: Waiting until the CA is running #### END of log ##### Here is log of pki-tomcat ### Internal Database Error encountered: Could not connect to LDAP server host wocfreeipa.sap.wingon.hk port 636 Error netscape.ldap.LDAPException: Unable to create socket: org.mozilla.jss.ssl.SSLSocketException: org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: (-8172) Peer's certificate issuer has been marked as not trusted by the user. (-1) ### The point is ' Peer's certificate issuer has been marked as not trusted by the user.' As far as I know pki-tomcat needs a certificate to bind to 389 DS and store information. But I didn't touch CA named 'IPA CA', so basically pki-tomcatd could use its own certificate named 'substemCert cert-pki-ca' to bind to 389 DS. Please help. Thanks a lot.

2 8

Re: Last FreeIPA master is failing
by Rob Crittenden 17 Jun '20

17 Jun '20

Ricardo Mendes wrote: > You're totally right. I feel dumb. > > Ok so I did the following: > > I edited the renew-le.sh and replaced the cert name but the line that > adds the cert again > "certutil -A -d ... -n Server-Cert" > > Edited /etc/httpd/conf.d/nss.conf and changed the NSSNickname > > But I still can't start pki-tomcatd: > > # systemctl status pki-tomcatd@pki-tomcat -l > ● pki-tomcatd(a)pki-tomcat.service - PKI Tomcat Server pki-tomcat > Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; > vendor preset: disabled) > Active: active (running) since Wed 2020-06-17 17:24:46 WEST; 19s ago > Process: 4750 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=0/SUCCESS) > Process: 4788 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, > status=0/SUCCESS) > Main PID: 4916 (java) > CGroup: > /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd(a)pki-tomcat.service > └─4916 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java > -DRESTEASY_LIB=/usr/share/java/resteasy-base > -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar > -Dcatalina.base=/var/lib/pki/pki-tomcat > -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= > -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp > -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.security.manager > -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy > org.apache.catalina.startup.Bootstrap start > > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'serverCertNickFile' to > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a > matching property. > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not > find a matching property. > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'passwordClass' to 'org.apache.tomcat.util.net.jss.PlainPasswordFile' > did not find a matching property. > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching > property. > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > 'xmlValidation' to 'false' did not find a matching property. > Jun 17 17:24:48 main.domain.io server[4916]: WARNING: > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > 'xmlNamespaceAware' to 'false' did not find a matching property. > Jun 17 17:24:56 main.domain.io server[4916]: > CMSEngine.initializePasswordStore() begins > Jun 17 17:24:56 main.domain.io server[4916]: > CMSEngine.initializePasswordStore(): tag=internaldb > Jun 17 17:24:56 main.domain.io server[4916]: > CMSEngine.initializePasswordStore(): tag=replicationdb > Jun 17 17:24:56 main.domain.io server[4916]: Internal Database Error > encountered: Could not connect to LDAP server host main.domain.io port > 636 Error netscape.ldap.LDAPException: Unable to create socket: > java.net.ConnectException: Connection refused (Connection refused) (-1) > > Currently all other services appear to be ok. Do I have to install it > manually here now? My guess is that the LE CA certificates are not trusted by the NSS database that dogtag uses. Assuming you've added those CA certificates to IPA using ipa-cacert-manage install then running ipa-certupdate should fix things for you. rob > >> You must have restored your git repo to HEAD. As I said before, the >> current HEAD does not work against anything < IPA 4.7.something. >> >> You need to get to the commit before "Move from mod_nss to mod_ssl" >> >> Then you'll see Server-Cert in renew-le.sh. >> >> --- >> >> We don't normally just dump code but it's a specific script for the >> demo. It seemed generally useful so it was shared. >> >> It has no branches and only supports that latest release of IPA that the >> demo runs. >> >> There are no plans to generalize or package it. You're free to tackle it >> if you'd like and include it in EPEL, for example. >> >> rob >> > I'm not skilled to do that, but maybe it is a fun project to learn how > somewhere in the future :) > Thanks for all the help so far! > > Ricardo >

2 1

Re: Last FreeIPA master is failing
by Rob Crittenden 17 Jun '20

17 Jun '20

Ricardo Mendes wrote: > Hi Rob thanks for your message. > >> Right the cert nickname is CN=main.domain.io. I'm assuming you manually > installed the LE certs originally using ipa-server-certinstall right? >> That doesn't follow the pattern of using Server-Cert for the nickname by > default. > > Iirc I used the antevens/letsencrypt-freeipa script to first install LE > certs. My issue with these scripts has been that they never renew > automatically and this has caused my issues in the past, but I was able > to fix it more simply, this time around I'm struggling a bit more. I > don't know if it was due to version changes but probably I guess. > >> You can probably just hack the LE script and replace Server-Cert with > CN=main.domain.io. > > I was looking to try this but I can't find "Server-Cert" in the LE > script. The LE script has the setup-le.sh: installs letsencrypt/certbot, > installs DSTRootCAX3.pem and LetsEncryptAuthorityX3.pem and calls > "renew-le.sh". > Renew checks the dates, makes a cleanup, generates csr, gets a new > certificate, replaces it and restarts httpd. > So in these scripts (on github freeipa repo, freeipa-letsencrypt) I > don't see a place to replace "Server-Cert". Can you please give me a > hint where to look for that "Server-Cert" validation and where to hack it? > > Today I ran the renew-le.sh script again (the one from 2017). I got this > error in the end: > > ipaplatform.redhat.tasks: INFO: Systemwide CA database updated. > ipalib.backend: DEBUG: Destroyed connection > context.rpcclient_140348868817552 > ipapython.admintool: INFO: The ipa-certupdate command was successful > Error opening Private Key /var/lib/ipa/private/httpd.key > 140615547713424:error:02001002:system library:fopen:No such file or > directory:bss_file.c:402:fopen('/var/lib/ipa/private/httpd.key','r') > 140615547713424:error:20074002:BIO routines:FILE_CTRL:system > lib:bss_file.c:404: > unable to load Private Key > > Looking at /var/lib/ipa, these are the directories: > > # ls -la /var/lib/ipa > total 48 > drwxr-xr-x. 9 root root 4096 Apr 2 14:40 . > drwxr-xr-x. 45 root root 4096 May 25 2020 .. > drwxr-xr-x. 2 root root 4096 May 26 2020 auth_backup > drwx------. 4 root root 4096 Apr 2 14:40 backup > -rw-------. 1 root root 1196 May 16 00:32 ca.csr > drwxrwx---. 3 ods named 4096 Feb 20 2019 dnssec > drwx------. 2 root root 4096 Apr 2 14:40 gssproxy > drwxr-xr-x. 3 root root 4096 Apr 2 14:40 pki-ca > -r--r-----. 1 root ipaapi 1704 Feb 20 2019 ra-agent.key > -r--r-----. 1 root ipaapi 1229 Feb 20 2019 ra-agent.pem > drwx--x--x. 2 root root 4096 Apr 2 14:40 sysrestore > drwx------. 2 root root 4096 Apr 2 14:40 sysupgrade > > There is no "private" folder. You must have restored your git repo to HEAD. As I said before, the current HEAD does not work against anything < IPA 4.7.something. You need to get to the commit before "Move from mod_nss to mod_ssl" Then you'll see Server-Cert in renew-le.sh. rob > > >> It's important to know that the LE script was written specifically for > the IPA demo site and a repo created to share the general method. It > isn't shipped with IPA or otherwise really supported at all. No > backwards compatibility testing is done, just what is needed for the > demo site. So while it might eventually work fine for you it isn't > intended to be a general-purpose tool. > >> rob > > It is important to know thanks, I actually thought it was more used. > People use LE across a number of applications and websites, and having > this as functional would be interesting as prevents the errors thrown by > self-signed certs, and I didn't thought it was unsupported at all, on > the contrary really. It would be nice if it was tended a little. For > example the script on the repo has dnf, but yum is still used on red hat > and CentOS. a simple validator for yum or dnf would also be nice and its > an easy thing to implement. But well just a thought, thanks, I will have > to think about using a proper certificate after fixing this. We don't normally just dump code but it's a specific script for the demo. It seemed generally useful so it was shared. It has no branches and only supports that latest release of IPA that the demo runs. There are no plans to generalize or package it. You're free to tackle it if you'd like and include it in EPEL, for example. rob

2 1

Problem with AD users after upgrade
by Ronald Wimmer 16 Jun '20

16 Jun '20

I did an IPA migration from CentOS 7 machines to OL 8.1 following the procedure as documented in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ht… . Today I found out that only four of my eight IPA servers do resolve AD users (tested with id <AD_user> on every IPA server). The setup procedure did not differ. (except for machine no. 1 which is the CA renewal master) AD users are resolved on machines 1, 5, 6 and 8. Machine 2, 3, 4 and 7 do not resolve AD users. Only machines 1, 2, 5 and 6 should have become trust controllers but when I had a look at the server roles in the WebGUI I saw the trust controller role on every machine. Is it possible to remove the trust controller role on 4 of the 8 machines? Where should I take a closer look? Cheers, Ronald

3 10

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2020