June 2020 - FreeIPA-users - Fedora mailing-lists

RuntimeError: Failed to start replication (ipa-replica-install)
by Christian Mertes 25 Jun '20

25 Jun '20

Dear all, we tried to setup our first replica for our current ipa installation but failed with RuntimeError: Failed to start replication Our main instance is running on Scientific Linux 7 and is already 4 years old but kept always up-to-date and served us with no problems. We followed the steps lined out in the documentation: https://www.freeipa.org/page/V4/Replica_Setup But we always fail at the point where the replication starts. ~# ipa-replica-install Run connection check to masterConnection check OKConfiguring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpdDone configuring NTP daemon (ntpd).Configuring directory server (dirsrv). Estimated time: 30 seconds [1/42]: creating directory server instance [2/42]: enabling ldapi [3/42]: configure autobind for root [4/42]: stopping directory server [5/42]: updating configuration in dse.ldif [6/42]: starting directory server [7/42]: adding default schema [8/42]: enabling memberof plugin [9/42]: enabling winsync plugin [10/42]: configure password logging [11/42]: configuring replication version plugin [12/42]: enabling IPA enrollment plugin [13/42]: configuring uniqueness plugin [14/42]: configuring uuid plugin [15/42]: configuring modrdn plugin [16/42]: configuring DNS plugin [17/42]: enabling entryUSN plugin [18/42]: configuring lockout plugin [19/42]: configuring topology plugin [20/42]: creating indices [21/42]: enabling referential integrity plugin [22/42]: configuring certmap.conf [23/42]: configure new location for managed entries [24/42]: configure dirsrv ccache [25/42]: enabling SASL mapping fallback [26/42]: restarting directory server [27/42]: creating DS keytab [28/42]: ignore time skew for initial replication [29/42]: setting up initial replicationStarting replication, please wait until this has completed.Update in progress, 15 seconds elapsed[ldap://freeipa.xxx.xxx.xxx:389] reports: Update failed! Status: [Error (-2) - LDAP error: Local error] [error] RuntimeError: Failed to start replicationYour system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up. ipapython.admintool: ERROR Failed to start replicationipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information We tried to debug it a bit but did not come far. Somehow our master fails to acquire the replica for a total update (error log from dirsrv on main): [16/Jun/2020:01:26:00.049005795 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 1 seconds.[16/Jun/2020:01:26:01.080674785 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 2 seconds.[16/Jun/2020:01:26:03.115527897 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 3 seconds.[16/Jun/2020:01:26:06.137927640 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 4 seconds.[16/Jun/2020:01:26:10.167358832 +0200] - WARN - NSMMReplicationPlugin - repl5_tot_run - Unable to acquire replica for total update, error: -2, retrying in 5 seconds. I guess the error log on the replica is intended, since we just started to replicate it [16/Jun/2020:01:26:00.674747749 +0200] - WARN - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTofreeipa.i12g.informatik.tu-muenchen.de" (freeipa:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. As we do not know if this is a bug or just a configuration issue on our side, we would appreciate any help or hints on this. The times are synchronized btw. To make sure we, did the the right things we tried successfully everything with a fresh installation within a VM network using CentOS 7 images. For more details I attached the install log and the error log from our dirsrv. If you need further logs please let me know. Some additional information from our system (our main instance): # lsb_release -aLSB Version: :core-4.1-amd64:core-4.1- noarchDistributor ID: ScientificDescription: Scientific Linux release 7.8 (Nitrogen)Release: 7.8Codename: Nitrogen# ipa --versionVERSION: 4.8.7, API_VERSION: 2.239# yum list installed "ipa- server"Loaded plugins: fastestmirror, langpacksLoading mirror speeds from cached hostfile * epel * sl * sl-fastbugs * sl-securityInstalled Packagesipa-server.x86_64 4.6.6-11.sl7 @sl And from our replica system: # lsb_release -aLSB Version: :core-4.1-amd64:core-4.1- noarchDistributor ID: CentOSDescription: CentOS Linux release 7.8.2003 (Core)Release: 7.8.2003Codename: Core# ipa -- versionVERSION: 4.6.6, API_VERSION: 2.231# yum list installed ipa- serverLoaded plugins: fastestmirrorLoading mirror speeds from cached hostfile * base: * elrepo: * epel: * extras: * updates:Installed Packagesipa-server.x86_64 4.6.6-11.el7.centos @base I'm just puzzled a bit by the difference in version number on the master. Could that be an issue and if so how to solve this? Best, Christian -- Christian Mertes | PhD Student / Lab Administrator Gagneur Lab - Computational Genomics I12 - Department of Informa ti Technical University of Munich Boltzmannstr. 3, 85748 Garching, Germany mertes(a)in.tum.de | https://in.tum.de/gagneurlab

2 2

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

25 Jun '20

Ricardo Mendes wrote: > Hi Rob, > > Thank you for all your help so far I haven't write back before, I've > been swamped. > Ok so I was going kinda crazy about the lost access to ldap. In the > meanwhile we got developments on the server that had the freeipa replica > and this is back up. > So now I have this: > > - Master is malfunctioning. pki-tomcat can't connect to the CMS as I had > described before this server is struggling. > - Replica is working fine. I can access to all services and everything > seems operational apart from what would need the CA Master. > > Given this I was thinking that maybe the best scenario would be to > promote the replica to master CA and completely decommission the failing > server. I was going through this article, is this all I need to make the > Replica the CA Master? > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… You need to move the CRL generator and more importantly, set the CA renewal master. Also check DNA ranges, and a few more things IIRC. I think it's all in the docs. I'd also stand up a 3rd master just in case. rob

2 1

ipa: ERROR: No valid Negotiate header in server
by Nathanaël Blanchet 25 Jun '20

25 Jun '20

Hello, I meet this error: ipa: ERROR: No valid Negotiate header in server on the master and I want to try the solution get there: https://access.redhat.com/solutions/3533431 but I don't remember when the "directory manager" password have been defined and how to recover it? Thank you -- Nathanaël Blanchet Supervision réseau SIRE 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 2

bad filter to find ad users
by Nathanaël Blanchet 25 Jun '20

25 Jun '20

Hello, I manage two independant AD domains, and I set up a trust with my freeipa server (realm NAT.ABES.FR). The trust-add step is ok for both and trust are both seen as active directory trust: 2 trusts matched ---------------- Realm name: ACME.local Domain NetBIOS name: ACME Domain Security Identifier: S-1-5-21-3044139164-2180978765-3887461208 Trust type: Active Directory domain Realm name: levant.abes.fr Domain NetBIOS name: LEVANT Domain Security Identifier: S- 1-5-21 - [ callto:116659660-2524593236 | 116659660-2524593236 ] - [ callto:2569697501 | 2569697501 ] Trust type: Active Directory domain Idranges are also ok: Range name: ACME.LOCAL_id_range First Posix ID of the range: 542000000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-3044139164-2180978765-3887461208 Range type: Active Directory domain range Range name: LEVANT.ABES.FR_id_range First Posix ID of the range: 564400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S- 1-5-21 - [ callto:116659660-2524593236 | 116659660-2524593236 ] - [ callto:2569697501 | 2569697501 ] Range type: Active Directory domain range I can get id with ACME.local but not on levant.abes.fr: id toto(a)ACME.local uid=542001112( toto(a)ACME.local ) gid=542001112( toto(a)ACME.local ) groups=542001112( toto(a)ACME.local ),542000513(utilisateurs du domaine(a)ACME.local ) id administrateur(a)levant.abes.fr id: ‘ administrateur(a)levant.abes.fr ’: no such user when debugging sssd, I find that the ldap filter query is not the same on both domains: ACME.local: [(&(sAMAccountName=toto)(objectclass=user)(sAMAccountName=*)(objectSID=*))] levant.abes.fr: [(&(sAMAccountName=poujol)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))] The ACME domain is on a single 2012R2 server The LEVANT domain is on an AD cluster with different AD versions: 2008, 2012R2, 2016 SRV records are all ok from AD side and from ipaserver side. Some users on LEVANT hadpreviously some unix attributes that I deleted, and so any vmsSFU30OrderNumber or msSFU30MaxUidNumber or msSFU30MaxUidNumber as mentionned here [ https://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD | https://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD ] I deleted, recreated trust, restarted sssd daemon, but the result is always the same, the ldap search on AD is always done with uidNumber instead of objectSID and no users of the trusted domain are found. What can I do more?

2 2

Root CA is changing in an AD Trust environment
by White, David 24 Jun '20

24 Jun '20

We have IdM / FreeIPA running on RHEL 7 boxes. This is a 6-node cluster that has an existing 1-way trust back to Active Directory. IdM is still acting as the CA for its own clients, and when we setup the trust, we used the following command: ipa trust-add --type=ad example.com --admin admin_user We just learned very recently that our Active Directory team is generating and installing a new Root CA certificate into AD. That is happening tonight at 9pm. The existing Root CA will remain in place until it expires in about 1 month. Is there anything that we will have to do to IdM to get it to trust the new certificate? Even though the existing Root CA should remain in place for the next month, is there any chance something will break tonight when the new Root certificate is installed? I know we would be facing a lot more work, had we used AD’s Root CA for the client connections. So I feel fortunate in that regard.

3 3

Setting up a custom service
by Dominik Vogt 24 Jun '20

24 Jun '20

For a test setup, we need to create a custom service running on a server and a custom application running on the client. The sample gss client/server from the Kerberos sources is used for demonstration. Setting this up with plain Kerberos is easy: 1. Create the service principal with $ addprinc -randkey sample/server.domain 2. Add key to keytab $ ktadd ... 3. Copy keytab to server 4. Run the service $ gss_server -port 12345 sample Now, how would one do this with freeipa, using the command line interface? 1. Create service $ ipa service-add sample/server.domain 2a. Create the service key? How? 2b. Generate the keytab for the key? How? 3. Copy the keytab to the server? Manually or is there a freeipa way to do that? Is this approach correct? Any pointer to the relevant documentation would also be helpful. (I'm completely new to freeipa.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt

2 1

IPA authentication to Samba shares failing
by Kristian Petersen 22 Jun '20

22 Jun '20

Hey all, I have been using my FreeIPA users to authenticate to Samba shares on my file server for some time now. All of a sudden the other day it stopped working and smb won't even start. It gives errors about ipasam: "No builtin nor plugin backend for ipasam found". The following is from the journal after a startup failure: Jun 18 09:03:40 fs.cpms.byu.edu systemd[1]: Starting Samba SMB Daemon... -- Subject: Unit smb.service has begun start-up -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- Unit smb.service has begun starting up. Jun 18 09:03:40 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:40.444763, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:40 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:41 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:41.445977, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:41 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:42 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:42.447213, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:42 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:43 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:43.448469, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:43 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:44 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:44.449674, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:44 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:45 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:45.450791, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:45 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:46 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:46.452048, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:46 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:47 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:47.453281, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:47 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:48 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:48.454439, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:48 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:49 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:49.455579, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:49 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:50 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:50.456812, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:50 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:51 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:51.458054, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:51 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:52 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:52.459257, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:52 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:53 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:53.460436, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:53 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:54 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:54.461567, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:54 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:55 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:55.462721, 0] ../../source3/lib/smbldap.c:65> Jun 18 09:03:55 fs.cpms.byu.edu smbd[13266]: ldap_initialize: Bad parameter to an ldap routine Jun 18 09:03:56 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:56.463513, 0] ipa_sam.c:4865(pdb_init_ipasam) Jun 18 09:03:56 fs.cpms.byu.edu smbd[13266]: Failed to get base DN. Jun 18 09:03:56 fs.cpms.byu.edu smbd[13266]: [2020/06/18 09:03:56.463583, 0] ../../source3/passdb/pdb_inter> Jun 18 09:03:56 fs.cpms.byu.edu smbd[13266]: pdb backend ipasam:ldaps// ipa2.cpms.byu.edu did not correctly> Jun 18 09:03:56 fs.cpms.byu.edu systemd[1]: smb.service: Main process exited, code=exited, status=1/FAILURE Jun 18 09:03:56 fs.cpms.byu.edu systemd[1]: smb.service: Failed with result 'exit-code'. Jun 18 09:03:56 fs.cpms.byu.edu systemd[1]: Failed to start Samba SMB Daemon. -- Subject: Unit smb.service has failed -- Defined-By: systemd -- Support: https://access.redhat.com/support -- -- Unit smb.service has failed. Can anyone help me get this working again or even an idea of why it failed after working for months on end? -- Kristian Petersen System Administrator BYU Dept. of Chemistry and Biochemistry

2 3

Re: Continuing Problems Cleaning Up After Migration and Upgrade
by Rob Crittenden 22 Jun '20

22 Jun '20

Auerbach, Steven via FreeIPA-users wrote: > I had already executed the very steps you suggest in your reply. The results did not remove ipa-r02. I provide again the steps I followed- You don't show here the running ipa-replica-manage as Flo suggested. > On the server to be removed (ipa-r02) I ran ipa-replica-install --uninstall -U > The messages from that process: > 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 > > I then obtained the root password, signed on, started the certmonger service, and ran > # getcert list to confirm the certificate number > Then > # getcert stop-tracking -i 20150127222017 > Result: > Request "20150127222017" removed. > So I stopped the certmonger service on ipa-r02: > # service certmonger stop Did you look at what this cert was before you stopped tracking it? It's probably not important if you are retiring the machine but this means that some cert was issued (or requested) for some non-IPA-master service. > On another ipa server (the new "master") ipa03, I ran: > Ipa-replica-manage list > The result > ipa01.fbog.local: master > ipa-r02.fbog.local: master > ipa03.fbog.local: master > ipa04.fbog.local: master > > and I ran ipa-csreplica-manage list > the result > ipa01.fbog.local: master > ipa-r02.fbog.local: CA not configured > ipa03.fbog.local: master > ipa04.fbog.local: master > > the server ipa-r02 remains on both lists even though I ran the uninstall. > Might there be a problem with these commands performing as documented across the IPA realm? Or am I missing something? Try running the cleanup as suggested. rob > > Please explain why the IdM (ipa03 and ipa04) see ipa-r02 as a member of this service group > > -Steven Auerbach > > -----Original Message----- > From: Florence Blanc-Renaud <flo(a)redhat.com> > Sent: Monday, June 22, 2020 3:40 AM > To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> > Cc: Auerbach, Steven <Steven.Auerbach(a)flbog.edu> > Subject: Re: [Freeipa-users] Problems Cleaning Up After Migration and Upgrade > > On 6/20/20 9:59 PM, Auerbach, Steven via FreeIPA-users wrote: >> 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? >> > Hi, > > The domain level is explained in "Displaying and raising the domain level" [1]. Domain-level 1 was introduced in IPA 4.3 and adds: > - replica promotion > - topology management plugin > > As ipa01 and ipa-r02 are IPAv3 servers, it's expected that they don't show max domain level 1. > >> 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. > As 2 nodes out of 4 are IPAv3, they are at domain level 0 and prevent from moving to domain level 1. When they are removed from the topology you will be able to raise the domain level if you want to benefit from domain-level 1 features, using ipa domainlevel-set 1. > >> 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? >> > On domain-level 0, the tool to manage replicas is ipa-replica-manage > [2]. In order to completely remove a server, you can use > ipa-replica-manage del <server> --force --cleanup > > As a reminder, the supported method to remove a server in domain-level 0 > is described in "Removing a replica" [3] and involves: > - (on another server) ipa-replica-manage del <server> > - (on another server) ipa-csreplica-manage del <server> > - (on the server to be removed) ipa-server-install --uninstall -U > >> All the documentation I find refers to replicas.Â It seems I do not have >> any replicas, I have all masters. > You can find more explanation in "IdM terminology" [4] but there is no > functional difference between a master and a replica. > > Hope this clarifies, > flo > > [1] > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… > > [2] > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… > > [3] > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… > > [4] > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… >> >> 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 >> https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbog.… <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbog.…> >> >> Graphic for Email >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >> Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… >> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… >> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >> > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)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… >

1 0

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

22 Jun '20

I had already executed the very steps you suggest in your reply. The results did not remove ipa-r02. I provide again the steps I followed- On the server to be removed (ipa-r02) I ran ipa-replica-install --uninstall -U The messages from that process: 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 I then obtained the root password, signed on, started the certmonger service, and ran # getcert list to confirm the certificate number Then # getcert stop-tracking -i 20150127222017 Result: Request "20150127222017" removed. So I stopped the certmonger service on ipa-r02: # service certmonger stop On another ipa server (the new "master") ipa03, I ran: Ipa-replica-manage list The result ipa01.fbog.local: master ipa-r02.fbog.local: master ipa03.fbog.local: master ipa04.fbog.local: master and I ran ipa-csreplica-manage list the result ipa01.fbog.local: master ipa-r02.fbog.local: CA not configured ipa03.fbog.local: master ipa04.fbog.local: master the server ipa-r02 remains on both lists even though I ran the uninstall. Might there be a problem with these commands performing as documented across the IPA realm? Or am I missing something? Please explain why the IdM (ipa03 and ipa04) see ipa-r02 as a member of this service group -Steven Auerbach -----Original Message----- From: Florence Blanc-Renaud <flo(a)redhat.com> Sent: Monday, June 22, 2020 3:40 AM To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org> Cc: Auerbach, Steven <Steven.Auerbach(a)flbog.edu> Subject: Re: [Freeipa-users] Problems Cleaning Up After Migration and Upgrade On 6/20/20 9:59 PM, Auerbach, Steven via FreeIPA-users wrote: > 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? > Hi, The domain level is explained in "Displaying and raising the domain level" [1]. Domain-level 1 was introduced in IPA 4.3 and adds: - replica promotion - topology management plugin As ipa01 and ipa-r02 are IPAv3 servers, it's expected that they don't show max domain level 1. > 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. As 2 nodes out of 4 are IPAv3, they are at domain level 0 and prevent from moving to domain level 1. When they are removed from the topology you will be able to raise the domain level if you want to benefit from domain-level 1 features, using ipa domainlevel-set 1. > 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? > On domain-level 0, the tool to manage replicas is ipa-replica-manage [2]. In order to completely remove a server, you can use ipa-replica-manage del <server> --force --cleanup As a reminder, the supported method to remove a server in domain-level 0 is described in "Removing a replica" [3] and involves: - (on another server) ipa-replica-manage del <server> - (on another server) ipa-csreplica-manage del <server> - (on the server to be removed) ipa-server-install --uninstall -U > All the documentation I find refers to replicas.Â It seems I do not have > any replicas, I have all masters. You can find more explanation in "IdM terminology" [4] but there is no functional difference between a master and a replica. Hope this clarifies, flo [1] https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… [2] https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… [3] https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… [4] https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.re… > > 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 > https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbog.… <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbog.…> > > Graphic for Email > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedo… > List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorapro… > List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fed… >

1 0

Issues with failing master - DNSSEC & CA
by Ricardo Mendes 22 Jun '20

22 Jun '20

Hi all, We've had problems with our master IPA server, the issue was the second master-replica died due to an issue with the hypervisor and we lost access to the first master as the Let's Encrypt certificates expired. In the meanwhile we got to renew some certificates but the CA master functionality is broken and I get errors of not being able to reach CMS. Ok so then we salvaged the other server, the replica. We were able to bring it up but it is out of sync with the primary master. This primary master is having issues. pki-tomcat is malfunctioning, able to start but with an error "Subsystem unavailable". I always have to use --ignore-service-failures and --skip-version-check to put the IPA services working. So our objective now is to remove this primary master from the topology and promote other server to be DNSSEC key master and CA Master. First question about CA Master: To promote a replica to CA master is this all I have to do? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… Second question about DNSSEC Key Master: We disabled the dnssec key master with the command ipa-dns-install --disable-dnssec-master finished: Done configuring DNS key synchronization service (ipa-dnskeysyncd). Unconfiguring ods-enforcerd Exporting DNSSEC data before uninstallation Unconfiguring ipa-ods-exporter ipaserver.plugins.dogtag: ERROR ra.find(): Unable to communicate with CMS (500) Unexpected error - see /var/log/ipaserver-install.log for details: CertificateOperationError: Certificate operation cannot be completed: Unable to communicate with CMS (500) and querying for dnssec key master: ldapsearch -Y GSSAPI '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' returns: SASL/GSSAPI authentication started SASL username: rmendes(a)DOMAIN.IO SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=domain,dc=io> (default) with scope subtree # filter: (&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster)) # requesting: ALL # # search result search: 4 result: 0 Success # numResponses: 1 however if I make the same query on the replica servers, they still return the DNSSEC Key Master, preventing me to restart dnssec key master on any other server. How can I manually remove this orphaned reference so I can proceed with dnssec key master service restore? I have backed up the kasp.db.backup generated upon disabling the first master. Thank you

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2020