Hi All,

I would like to get right into my current issues.

Operating system : CentOS Linux release 7.2.1511 (Core)
Kernel Version : 3.10.0-327.10.1.el7.x86_64
IPA server Version : ipa-server-4.2.0-15.el7_2.6.x86_64
VM platform : ProxMox Virtual Environment Version 3.4-9/4b51d87a


I have prepared, what I would call the "first" master, by preparing and
installing the machine via the following method  :

*Source*
http://www.freeipa.org/page/Quick_Start_Guide#Getting_started_with_IPA
https://www.certdepot.net/rhel7-configure-freeipa-server/

Standard FreeIPA version distributed with the OS

yum install freeipa-server
yum install ipa-server-dns

ipa-server-install --setup-dns  --forwarder=x.x.x.x -a PASSWORD --hostname=
ipatester1.xxxxx.com --realm IPATESTER.XXXX.XXX -p PASSWORD -n xxxx.xxx -U

firewall-cmd --permanent
--add-service={ntp,http,https,ldap,ldaps,kerberos,kpasswd,dns}
firewall-cmd --reload

The first master is installed and now I would create a replica instance for
multi master replications.

First, create the replica file from first master :

ipa-replica-prepare  ipahostname --ip-address x.x.x.x

Copy the replica master info file to the new replica master. Then run the
replica install script :

ipa-replica-install --setup-dns --setup-ca
--forwarder=x.x.x.x /var/lib/ipa/replica-info-ipahostname.gpg

firewall-cmd --permanent
--add-service={ntp,http,https,ldap,ldaps,kerberos,kpasswd,dns}
firewall-cmd --reload

I now have 2 multi-masters with replication agreements.

ipatester1 - first master
ipatester2 - replica master

>From master to replica :

 ipa-replica-conncheck --replica ipatester2
Check connection from master to remote replica 'ipatester2.macrolan.co.za':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): WARNING
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): WARNING
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
The following UDP ports could not be verified as open: 88, 464
This can happen if they are already bound to an application
and ipa-replica-conncheck cannot attach own UDP responder.

Connection from master to replica is OK.

>From replica to master :

ipa-replica-conncheck --master ipatester1
Check connection from replica to remote master 'ipatester1.macrolan.co.za':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

*QUESTION 1 : Determining the Renewal Master/First Master*

Source  :
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

According to the above source, identifying the Renewal Master/First Master
can be done with the following ldap search command :
ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b
'cn=masters,cn=ipa,cn=etc,dc=example,dc=com'
'(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn

However, when I run this ldapsearch I get presented with both masters in
the results :

*# extended LDIF*
*#*
*# LDAPv3*
*# base <dc=ipatester,dc=macrolan,dc=com> with scope subtree*
*# filter: (&(cn=CA)(ipaConfigString=caRenewalMaster))*
*# requesting: dn*
*#*

*# CA, ipatester1.xxxxx.xxx, masters, ipa, etc, ipatester.xxxxx.xxx*
*dn:
cn=CA,cn=ipatester1.xxxxx.xxx,cn=masters,cn=ipa,cn=etc,dc=ipatester,dc=xxxx,dc=xxx*

*# CA, ipatester2.xxxxx.xxx, masters, ipa, etc, ipatester.xxxxx.xxx*
*dn:
cn=CA,cn=ipatester2.xxxxx.xxx,cn=masters,cn=ipa,cn=etc,dc=ipatester,dc=xxxx,dc=xxx*

*# search result*
*search: 2*
*result: 0 Success*

*# numResponses: 3*
*# numEntries: 2*

The above source also states : "There should only one master at a time,
otherwise the renewed certificates will step all over each other"

Two masters appear in the ldapsearch when the replica, installed from the
first master, includes a CA installation. Is this correct? Does this mean
that the two are indeed both renewal masters? If so, how is it possible to
ensure that when a CA is installed  as a replica, that is does not take on
the role as a renewal master?

The CRL generation master seems more straightforward and involves the
editing of /etc/pki/pki-tomcat.ca/CS.config and
the /etc/httpd/conf.d/ipa-pki-proxy.conf.

What is the best method within the IPA environment to test the CRL
generation?

*QUESTION 2 : Restoring data to the first master from a ipa FULL backup
using the ipa-backup, ipa-restore and the ipa-replica-manage
/ ipa-csreplica-manage  re-initialize commands*

As a test I created 5 standard users on the first master. The replication
was successful to the replication master as all users appeared on the
replication masters user list. I made a backup of the first master using
the /usr/sbin/ipa-backup -v command. I then deleted all 5 users from the
first master and the replication action-ed the deletion  to the replication
master. This mimics a loss of data that would need to be restored. My
restore procedure involves a uninstall of the ipa-server on the first
master and then a restore of the latest backup using the ipa-restore
command. Is this the correct method? i.e first uninstall the ipa-server and
then restore because this would mean replication agreements would possibly
need to be removed - but since the data will be restored, my assumption is
that no replication agreements need to be removed. Is this correct? Should
I use the first master to restore to or should I rather use a replica
master to restore to?

Following this procedure, I am able to restore the first master back to an
instance before the deletion. All 5 users are back. However, now
replication does not exist between the first master and the replica master.
I attempt an re-initialize from the replica master to the first master
using the ipa-replica-manage command : ipa-replica-manage re-initialize
ipatester1 and ipa-csreplica-manage re-initialize ipatester1.

I have experienced inconsistent results using this method of restore. When
running the ip-replica-manage --reinitialize command from the replica
master I was experiencing credential issues connecting to ldap and hence
why I would like confirmation whether this would be the best method of
restore when restoring IPA data and not restoring from a snap shot. As of
recently I am getting consistent results. I suspect the issues I have been
experiencing relate to not having all the correct ports open on both the
first master and the replica master. I have chosen to have all the
necessary ports open using UDP and TCP.

I thank anyone in advance who responds to this message.

Regards,

Mike Hyland
www.macrolan.com
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to