Re: Last FreeIPA master is failing
by Rob Crittenden
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/...
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
3 years, 9 months
ipa: ERROR: No valid Negotiate header in server
by Nathanaël Blanchet
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
3 years, 9 months
bad filter to find ad users
by Nathanaël Blanchet
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?
3 years, 9 months
Root CA is changing in an AD Trust environment
by White, David
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 years, 9 months
Setting up a custom service
by Dominik Vogt
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
3 years, 9 months
IPA authentication to Samba shares failing
by Kristian Petersen
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
3 years, 9 months
Re: Continuing Problems Cleaning Up After Migration and Upgrade
by Rob Crittenden
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....
>
> [2]
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
>
> [3]
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
>
> [4]
> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
>>
>> 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.flbo... <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbo...>
>>
>> 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.fe...
>> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
>> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>>
>
> _______________________________________________
> 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.fedoraho...
>
3 years, 9 months
Continuing Problems Cleaning Up After Migration and Upgrade
by Auerbach, Steven
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....
[2]
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
[3]
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
[4]
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess....
>
> 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.flbo... <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.flbo...>
>
> 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.fe...
> List Guidelines: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
> List Archives: https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
>
3 years, 9 months
Issues with failing master - DNSSEC & CA
by Ricardo Mendes
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/...
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
3 years, 9 months
Re: Problems Cleaning Up After Migration and Upgrade
by Florence Blanc-Renaud
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://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[2]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[3]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[4]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>
> 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
>
>
> _______________________________________________
> 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.fedoraho...
>
3 years, 9 months