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, 123We need to open one more port on both hosts, as this port will be needed to allow the communication of replication data.
TCP: 7389To 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.
0 comments:
Post a Comment
Note: only a member of this blog may post a comment.