Problems Cleaning Up After Migration and Upgrade
by Auerbach, Steven
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]
3 years, 10 months
cipher support and nsSSL3Ciphers: +all
by Chris Herdt
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!
3 years, 10 months
ipa-replica-install fails
by Orion Poplawski
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/
3 years, 10 months
Re: Last FreeIPA master is failing
by Rob Crittenden
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
>
3 years, 10 months
Secondary groups intermittently missing from id/groups lookups
by Alfred Victor
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
3 years, 10 months
Re: Better way to upgrade IPAServer4.6.4 to 4.6.5 + OS 7.6 to 7.7?
by Florence Blanc-Renaud
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/...
> >
> > >
> > > 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.fedoraho...
> > >
> >
> >
> > _______________________________________________
> > 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.fedoraho...
> >
>
3 years, 10 months
pki-tomcat fails to start after I update CA for dirsrv and httpd.
by luckydog xf
Hi, As state in https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-...
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.
3 years, 10 months
Re: Last FreeIPA master is failing
by Rob Crittenden
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
>
3 years, 10 months
Re: Last FreeIPA master is failing
by Rob Crittenden
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
3 years, 10 months
Problem with AD users after upgrade
by Ronald Wimmer
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/...
.
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 years, 10 months