Today, lets take things one step further by
adding redundancy into the equation. If you are familiar with Microsoft
Active Directory and how Windows Domain Controllers replicate between
each other, this article will show you how to set up FreeIPA to achieve
the same goal.
For this article, you will obviously need an existing FreeIPA server
that is up and running, as well as a new system you wish to make as a
secondary master.
In this article, I will be using the below details.
Existing FreeIPA server: ds01.example.com (10.0.1.11)
New FreeIPA server: ds02.example.com (10.0.1.12)
FreeIPA Admin user: admin
FreeIPA Admin password: redhat123
FreeIPA Directory Manager user: admin
FreeIPA Directory Manager password: redhat123
DNS Forwarder: 10.0.0.254 (Same as forwarder configured on ds01.example.com)
Operating System of both hosts: Red Hat Enterprise Linux 6.3 x86_64
Step 1. Install FreeIPA packages on new system
Although possible, you *could* set up replication with different
versions of FreeIPA on different servers, I highly recommend sticking
with the same version as your existing host.
Install the same packages as you did on your first host. Note: if you
are using external DNS, you do not need to install the bind packages.
[root@ds02 ~]# yum install -y ipa-server bind bind-utils bind-dyndb-ldap
Step 2. Add new host to DNS
We need to set up IPA so that it knows to allow replication with the new
host when we install it. This has a prerequisite on DNS however, so we
will need to add the DNS entries for our new server before we can
prepare IPA.
Note: if you are using external DNS, this does not apply to you.
To add your new host to DNS, run the following commands on your existing FreeIPA server.
[root@ds01 ~]# kinit admin
Password for admin@EXAMPLE.COM:
[root@ds01 ~]# ipa dnsrecord-add example.com ds02 --a-rec 10.0.1.12
Record name: ds02
A record: 10.0.1.12
[root@ds01 ~]# ipa dnsrecord-add 1.0.10.in-addr.arpa. 12 --ptr-rec ds02.example.com.
Record name: 12
PTR record: ds02.example.com.
[root@ds01 ~]#
Step 3. Prepare your current FreeIPA server for a replication agreement
Once you have your host stored in DNS, you are now ready to
create a replication GPG key for your new server to use to commence the
replication install.
To prepare FreeIPA for replication, run the following command.
[root@ds01 ~]# ipa-replica-prepare ds02.example.com
Directory Manager (existing master) password:
Preparing replica for ds02.example.com from ds01.example.com
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/replica-info-ds02.example.com.gpg
[root@ds01 ~]#
Now we need to copy this gpg file to our new replica-to-be
[root@ds01 ~]# scp /var/lib/ipa/replica-info-ds02.example.com.gpg root@ds02.example.com:/var/lib/ipa/
The authenticity of host 'ds02.example.com (10.0.1.12)' can't be established.
RSA key fingerprint is 36:b0:7e:de:29:7f:96:1a:f8:43:00:9a:22:24:75:15.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ds02.example.com,10.0.1.12' (RSA) to the list of known hosts.
root@ds02.example.com's password:
replica-info-ds02.example.com.gpg 100% 28KB 28.4KB/s 00:00
[root@ds01 ~]#
Step 4. Open firewall port on both hosts to allow replication
Your existing FreeIPA server will already have several ports that are open.
Note: If you don’t use your local firewall in your environment, which I
highly recommend against, you can jump to step 5 if you wish.
Just as a reminder, they are below
TCP: 80, 443, 389, 636, 88, 464, 53
UDP: 88, 464, 53, 123
We need to open one more port on both hosts, as this port will be needed to allow the communication of replication data.
TCP: 7389
To open this port, you can run the following
[root@ds01 ~]# iptables -I INPUT -p tcp --dport 7389 -j ACCEPT
[root@ds01 ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@ds01 ~]#
You will need to open all of the above ports on your new system in
order to proceed. As my IPA servers only ever exist for the purpose of
IPA, I cheat here and I copy the /etc/sysconfig/iptables file to my
replicas.
From your new system, copy the existing iptables config file and restart the iptables service
[root@ds02 ~]# scp root@ds01.example.com:/etc/sysconfig/iptables /etc/sysconfig/
The authenticity of host 'ds01.example.com (10.0.1.11)' can't be established.
RSA key fingerprint is b2:ea:40:2c:1d:55:50:b6:c6:df:d8:19:09:4d:2a:6a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ds01.example.com,10.0.1.11' (RSA) to the list of known hosts.
root@ds01.example.com's password:
iptables 100% 1023 1.0KB/s 00:00
[root@ds02 ~]# service iptables restart
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
[root@ds02 ~]#
Or alternatively you can run the following if you want to do it the manual way.
[root@ds02 ~]# for x in 80 443 389 636 88 464 53 7389; do iptables -I INPUT -p tcp --dport $x -j ACCEPT ; done
[root@ds02 ~]# for x in 88 464 53 123 ; do iptables -I INPUT -p udp --dport $x -j ACCEPT ; done
[root@ds02 ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@ds02 ~]#
Step 5. Setting up replication (This is where the magic happens)
As I am setting FreeIPA up in a way similar to how Microsoft Active
Directory is generally used, I will be replicating DNS as well.
Note: again, if you are using external DNS, you should omit the “–setup-dns” option in the below command.
To start the replication set up, run the following. You will be prompted for your Directory Manager and Admin password.
Note: Brace yourself, there is a fair bit of output here again.
[root@ds02 ~]# ipa-replica-install --setup-dns --setup-ca --forwarder=10.0.0.254 /var/lib/ipa/replica-info-ds02.example.com.gpg
Directory Manager (existing master) password:
Run connection check to master
Check connection from replica to remote master 'ds01.example.com':
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
PKI-CA: Directory Service port (7389): 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
Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@EXAMPLE.COM password:
Execute check on remote master
Check connection from master to remote replica 'ds02.example.com':
Directory Service: Unsecure port (389): OK
Directory Service: Secure port (636): OK
Kerberos KDC: TCP (88): OK
Kerberos KDC: UDP (88): OK
Kerberos Kpasswd: TCP (464): OK
Kerberos Kpasswd: UDP (464): OK
HTTP Server: Unsecure port (80): OK
HTTP Server: Secure port (443): OK
PKI-CA: Directory Service port (7389): OK
Connection from master to replica is OK.
Connection check OK
Configuring ntpd
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
done configuring ntpd.
Configuring directory server for the CA: Estimated time 30 seconds
[1/3]: creating directory server user
[2/3]: creating directory server instance
[3/3]: restarting directory server
done configuring pkids.
Configuring certificate server: Estimated time 3 minutes 30 seconds
[1/13]: creating certificate server user
[2/13]: creating pki-ca instance
[3/13]: configuring certificate server instance
[4/13]: disabling nonces
[5/13]: creating RA agent certificate database
[6/13]: importing CA chain to RA certificate database
[7/13]: fixing RA database permissions
[8/13]: setting up signing cert profile
[9/13]: set up CRL publishing
[10/13]: set certificate subject base
[11/13]: enabling Subject Key Identifier
[12/13]: configuring certificate server to start on boot
[13/13]: Configure HTTP to proxy connections
done configuring pki-cad.
Restarting the directory and certificate servers
Configuring directory server: Estimated time 1 minute
[1/30]: creating directory server user
[2/30]: creating directory server instance
[3/30]: adding default schema
[4/30]: enabling memberof plugin
[5/30]: enabling referential integrity plugin
[6/30]: enabling winsync plugin
[7/30]: configuring replication version plugin
[8/30]: enabling IPA enrollment plugin
[9/30]: enabling ldapi
[10/30]: configuring uniqueness plugin
[11/30]: configuring uuid plugin
[12/30]: configuring modrdn plugin
[13/30]: enabling entryUSN plugin
[14/30]: configuring lockout plugin
[15/30]: creating indices
[16/30]: configuring ssl for ds instance
[17/30]: configuring certmap.conf
[18/30]: configure autobind for root
[19/30]: configure new location for managed entries
[20/30]: restarting directory server
[21/30]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress
Update in progress
Update in progress
Update in progress
Update in progress
Update in progress
Update succeeded
[22/30]: adding replication acis
[23/30]: setting Auto Member configuration
[24/30]: enabling S4U2Proxy delegation
[25/30]: initializing group membership
[26/30]: adding master entry
[27/30]: configuring Posix uid/gid generation
[28/30]: enabling compatibility plugin
[29/30]: tuning directory server
[30/30]: configuring directory to start on boot
done configuring dirsrv.
Configuring Kerberos KDC: Estimated time 30 seconds
[1/9]: adding sasl mappings to the directory
[2/9]: writing stash file from DS
[3/9]: configuring KDC
[4/9]: creating a keytab for the directory
[5/9]: creating a keytab for the machine
[6/9]: adding the password extension to the directory
[7/9]: enable GSSAPI for replication
[8/9]: starting the KDC
[9/9]: configuring KDC to start on boot
done configuring krb5kdc.
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
done configuring kadmin.
Configuring ipa_memcached
[1/2]: starting ipa_memcached
[2/2]: configuring ipa_memcached to start on boot
done configuring ipa_memcached.
Configuring the web interface: Estimated time 1 minute
[1/13]: disabling mod_ssl in httpd
[2/13]: setting mod_nss port to 443
[3/13]: setting mod_nss password file
[4/13]: enabling mod_nss renegotiate
[5/13]: adding URL rewriting rules
[6/13]: configuring httpd
[7/13]: setting up ssl
[8/13]: publish CA cert
[9/13]: creating a keytab for httpd
[10/13]: clean up any existing httpd ccache
[11/13]: configuring SELinux for httpd
[12/13]: restarting httpd
[13/13]: configuring httpd to start on boot
done configuring httpd.
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Using reverse zone 1.0.10.in-addr.arpa.
Configuring named:
[1/8]: adding NS record to the zone
[2/8]: setting up reverse zone
[3/8]: setting up our own record
[4/8]: setting up kerberos principal
[5/8]: setting up named.conf
[6/8]: restarting named
[7/8]: configuring named to start on boot
[8/8]: changing resolv.conf to point to ourselves
done configuring named.
Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files
Restarting the web server
[root@ds02 ~]#
Step 6. Verify that replication is responding correctly
As with all things that involve setting up technology, you should always
verify your work. I never thought I’d enforce this saying as much as I
do. My high school maths teacher would be very proud.
One of the first things I do post-setup, is verify that I have two
directory server instances running. You will see your DOMAIN instance,
and if you set up CA replication, you will also see PKI-IPA.
To check, run the following
[root@ds02 ~]# service dirsrv status
dirsrv EXAMPLE-COM (pid 5115) is running...
dirsrv PKI-IPA (pid 5185) is running...
[root@ds02 ~]#
also, make sure you can authenticate.
That’s pretty important!!
[root@ds02 ~]# kinit admin
Password for admin@EXAMPLE.COM:
[root@ds02 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@EXAMPLE.COM
Valid starting Expires Service principal
08/29/12 22:53:02 08/30/12 22:53:00 krbtgt/EXAMPLE.COM@EXAMPLE.COM
[root@ds02 ~]#
All looking good so far. Lastly, lets just make sure that our servers are in fact replicating.
Check to see all IPA replica’s in the domain
[root@ds02 ~]# ipa-replica-manage list
ds01.example.com: master
ds02.example.com: master
[root@ds02 ~]#
Great… Now lets make sure that ds01.example.com is replicating to ds02.example.com
[root@ds02 ~]# ipa-replica-manage list ds01.example.com
ds02.example.com: replica
[root@ds02 ~]#
Also great
Last one, lets check to see that ds02.example.com can replicate back to ds01.example.com
[root@ds02 ~]# ipa-replica-manage list ds02.example.com
ds01.example.com: replica
[root@ds02 ~]#
Happy Days!. We have one we peachy IPA replicated environment.
Stay tuned as I’ll be covering more detail on managing more than 2
replica’s in an upcoming article. This will be useful for those of you
who might be looking to deploy IPA into a multi-site environment.
