Setting up a FreeIPA Replica

In my last post, I mentioned that I would show how to configure a client with sudo access. Well, I lied! Hopefully that will be the next post. Instead, I’m going to cover how to set up FreeIPA replica.

Replicating FreeIPA services is useful in many ways. Managing DNS, LDAP and Kerberos services, for one. Additionally, it makes sense to have replicas in different VLANs or network zones. Opening up only the ports needed for replication between the FreeIPA servers instead of for all hosts makes things more secure.

All Replicas are Masters

Save for things like running a Certificate Authority or DNS, all of the hosts which run FreeIPA are masters. They replicate using agreements. This means that when a new replica is setup, it will communicate with other FreeIPA servers and replicate to/from only the ones it is allowed to communicate. Further reading is available here.

Preparing for the FreeIPA Replica

Preparing the replica requires setting up the agreement documents on one of the IPA master servers.

$ ssh ipa7.example.com
..snip..

$ su -
Password: centos

# ipa-replica-prepare replica.example.com --ip-address 192.168.122.210
Directory Manager (existing master) password: manager72

Preparing replica for replica.example.com from ipa.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-replica.example.com.gpg
Adding DNS records for replica.example.com
Using reverse zone 122.168.192.in-addr.arpa.

Copy the Replica gpg Data to the New Replica

The data is now packaged and needs to be put on the replica. The simplest and most secure process is to scp the file directly to the replica. In some cases, this is not possible, and other methods may need to be employed.

# scp /var/lib/ipa/replica-info-replica.example.com.gpg root@192.168.122.210:
..snip..

Install the Replica

Once the agreements are created and moved to the new replica, it’s time to perform the install.

$ ssh root@192.168.122.210
root@192.168.122.210's password:

Ensure the replica can contact the master server. Additionally, make sure the replica’s ip address resolves locally. Modifying /etc/hosts is the simplest solution.

# cat /etc/hosts
..snip..
192.168.122.210 replica.example.com
192.168.122.200 ipa7.example.com
..snip..

Set the hostname properly. If it isn’t, correct it by modifying /etc/sysconfig/network.

# hostname
replica.example.com

Once all of the above is correct, it’s time to perform the installation itself. Since a replica is just a clone of another master, installing the same packages makes sense.

# yum install ipa-server bind-dyndb-ldap -y
..snip..

Next, perform the install. Consider options like –setup-ca and –setup-dns as optional, though very useful if those processes are going to be needed on the new replica.

# ipa-replica-install --setup-dns /root/replica-info-replica.example.com.gpg \
--no-forwarders --ip-address=192.168.122.210
Directory Manager (existing master) password: manager72

Run connection check to master
Check connection from replica to remote master 'ipa7.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@CODEAURORA.ORG password: ipaadmin72

Configuring NTP daemon (ntpd)
..snip..
Configuring directory server for the CA (pkids): Estimated time 30 seconds
..snip..
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
..snip..
Done configuring certificate server (pki-cad).
Restarting the directory and certificate servers
Configuring directory server (dirsrv): Estimated time 1 minute
..snip..
Starting replication, please wait until this has completed.
Update in progress
..snip..
Update succeeded
..snip..
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
..snip..
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
..snip..
Done configuring kadmin.
Configuring ipa_memcached
..snip..
Done configuring ipa_memcached.
Configuring the web interface (httpd): Estimated time 1 minute
..snip..
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Using reverse zone 122.168.192.in-addr.arpa.
Configuring DNS (named)
..snip..
Done configuring DNS (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

At this point, the replica should start functioning. Since this is a FreeIPA server, make sure to allow successful logins. A reboot is a very good idea.

# authconfig --enablemkhomedir --update
..snip..
# chkconfig sssd on
..snip..
# init 6

Once rebooted, login with an existing user.

$ ssh replica.example.com
Warning: Permanently added 'replica.example.com' (ECDSA) to the 
list of known hosts.
Creating home directory for herlo.
Last login: Fri Oct 22 12:27:44 2014 from 192.168.122.1
[herlo@replica ~]$ id
uid=151600001(herlo) gid=151600001(herlo) groups=151600001(herlo)...

Assuming all works well, replication should be working.

If all goes well, I’ll show how to install a client and enable sudo access in the next post.

Cheers,

herlo

Posted in FreeIPA, Tech | Tagged , , , , , , | Leave a comment

Introducing FreeIPA – Identity Management (IdM) Done Right!

It has been a while since I’ve posted anything on this blog. It is high time I get something useful up here. Lucky for you, dear reader, I have a series of posts to share. Each of them about a new technical passion of mine, Identity Management.

Many of you probably know of Active Directory. The all encompassing Identity Management solution from Microsoft. It’s is the most popular solution out there, and its got a good hold on the market, for sure. But with almost all things Microsoft comes closed source, GUI only management, and resentment among many.

I’m not saying that Active Directory does not do its job as an IdM solution. In fact, I think it’s a fine solution, if you want to have a proprietary solution, pay a ton of money yearly and not follow standards. In terms of Identity Management, however, it is a pretty good system overall.

The thing is, closed source systems historically have more issues and delays for fixes long term. Until recently, however, there hasn’t been a reasonable open source solution for IdM. Enter FreeIPA, Identity Management done right.

What is FreeIPA?

FreeIPA is a solution for managing users, groups, hosts, services, and much, much more. It uses open source solutions with some Python glue to make things work. Identity Management made easy for the Linux administrator.

ipa-componentsInside FreeIPA are some common pieces; The Apache Web Server, BIND, 389DS, and MIT Kerberos. Additionally, Dogtag is used for certificate management, and sssd for client side configurations. Put that all together with some python glue, and you have FreeIPA.

As you can see from the diagram, there is also an API which provides programmatic management via Web and Command Line interfaces. Additionally, many plugins exist. For example, one exists to set up trust agreements for replication to Active Directory. Additional functionality exists for managing Samba shares via users and groups in FreeIPA.

It’s probably a good time to setup a FreeIPA server and show its power.

Installation

Installing FreeIPA is simple on a Linux system. However, there are a few things needed. This installation is being performed on a fully updated CentOS 7.0 system. An entry in the /etc/hosts matching the server ip and hostname is useful. Additionally, make sure to set the hostname properly.

# echo 192.168.122.200 ipa7.example.com ipa7 >> /etc/hosts
# echo ipa7.example.com > /etc/hostname

We’ll be installing the server at this time, but there is a client install, which we’ll show in later posts. It’s recommended to use RHEL/CentOS >= 6.x or Fedora >= 14. Simply perform a yum install.

(rhel/centos) # yum install ipa-server
(fedora) # yum install freeipa-server
..snip..

Once the {free,}ipa-server package is installed. Run the install itself. Since FreeIPA can manage a dns server, a decision must be made. Here, we are going to choose to manage our internal dns with FreeIPA, which uses ldap via 389DS to store the records.

# yum install bind-dyndb-ldap
..snip..
# ipa-server-install --setup-dns
The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.

This includes:
 * Configure a stand-alone CA (dogtag) for certificate management
 * Configure the Network Time Daemon (ntpd)
 * Create and configure an instance of Directory Server
 * Create and configure a Kerberos Key Distribution Center (KDC)
 * Configure Apache (httpd)
 * Configure DNS (bind)

To accept the default shown in brackets, press the Enter key.

WARNING: conflicting time&date synchronization service 'chronyd' will be disabled
in favor of ntpd

Existing BIND configuration detected, overwrite? [no]: yes

The installation explains the process and services which will be installed. Because we’re installing using DNS, some skeleton files exist. It’s safe to overwrite them and move forward.

Next, define the server hostname, and the domain name (for DNS).

Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.


Server host name [ipa7.example.com]: ipa7.example.com

Warning: skipping DNS resolution of host ipa7.example.com
The domain name has been determined based on the host name.

Please confirm the domain name [example.com]: example.com

The next section covers the kerberos realm. This may seem confusing, but kerberos is one of the big powerhouses behind FreeIPA. It makes registering client systems very simple. Kerberos realm names are always in upper case. Usually, they emulate the domain name.

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [EXAMPLE.COM]: EXAMPLE.COM

Next, configure the passwords for the Directory Manager (for ldap administration) and the IPA admin user.

Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: manager72
Password (confirm): manager72

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: ipaadmin72
Password (confirm): ipaadmin72

Finally, the installer follows up with a request for more DNS info.

Do you want to configure DNS forwarders? [yes]: yes
Enter the IP address of DNS forwarder to use, or press Enter to finish.
Enter IP address for a DNS forwarder: 8.8.8.8
DNS forwarder 8.8.8.8 added
Enter IP address for a DNS forwarder: 8.8.4.4
DNS forwarder 8.8.4.4 added
Enter IP address for a DNS forwarder: <enter>
Do you want to configure the reverse zone? [yes]: yes
Please specify the reverse zone name [122.168.192.in-addr.arpa.]: 122.168.192.in-addr.arpa
Using reverse zone 122.168.192.in-addr.arpa.

Now that all of the questions have been asked and answered. It’s time to let the installer do its thing. A verification step prints out all of the values entered. Make sure to review them carefully.

The IPA Master Server will be configured with:
Hostname: ipa7.example.com
IP address: 192.168.122.200
Domain name: example.com
Realm name: EXAMPLE.COM

BIND DNS server will be configured to serve IPA domain with:
Forwarders: 8.8.8.8, 8.8.4.4
Reverse zone: 122.168.192.in-addr.arpa.

Then, when ready, confirm the install and go grab a cup of joe. Installation takes anywhere from 10-30 minutes.

Continue to configure the system with these values? [no]: yes

The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring NTP daemon (ntpd)
 [1/4]: stopping ntpd
 [2/4]: writing configuration
 [3/4]: configuring ntpd to start on boot
 [4/4]: starting ntpd
..snip..

When complete, the installation gives a bit of useful information. Make sure to open the ports within the firewall. This is beyond the scope here, and is left as an exercise for the reader.

Setup complete

Next steps:
    1. You must make sure these network ports are open:
        TCP Ports:
          * 80, 443: HTTP/HTTPS
          * 389, 636: LDAP/LDAPS
          * 88, 464: kerberos
          * 53: bind
        UDP Ports:
          * 88, 464: kerberos
          * 53: bind
          * 123: ntp

    2. You can now obtain a kerberos ticket using the command: 'kinit admin'
       This ticket will allow you to use the IPA tools (e.g., ipa user-add)
       and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password

Now that everything is installed. One last simple configuration will help. To ensure users can login correctly, use authconfig to ensure home directories are created. Followed by a quick reboot.

# authconfig --enablemkhomedir --update
# chkconfig sssd on
Note: Forwarding request to 'systemctl enable sssd.service'.
# init 6

Once the system has rebooted, point the browser to the newly installed FreeIPA service. Logging into FreeIPA can be done in two different ways; from the browser, or via kerberos. For now, login via the web browser as the admin user.

 

Once logged in, a useful configurations is necessary before adding users. Change the default shell for all users to /bin/bash. This is done by choosing IPA Server -> Configuration. Once modified, click Update.

ipa-config-shell

Now it’s time to add a user. Choose the Identity tab. Then click Add.

ipa-user-add

Clicking Add and Edit presents the user’s data. This is useful for adding an ssh key.

ipa-user-sshkey

NOTE: Don’t forget to click Update after setting the key.

This should now allow ssh into the FreeIPA server as the new user. To make this possible, make sure the new FreeIPA server is configured as a resolver. The simplest way is to update the /etc/resolv.conf file.

# cat /etc/resolv.conf
search egavas.org
nameserver 192.168.122.200
..snip..

# host ipa7.example.com
ipa7.example.com has address 192.168.122.200

Once the FreeIPA server is resolvable, ssh should now work.

[herlo@x220 ~]$ ssh ipa7.example.com
The authenticity of host 'ipa7.example.com (192.168.122.200)' can't be established.
ECDSA key fingerprint is 42:96:09:a7:1b:ac:df:dd:1c:de:73:2b:86:51:19:b1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ipa7.example.com' (ECDSA) to the list of known hosts.
Creating home directory for herlo.
Last login: Fri Oct 10 02:27:44 2014 from 192.168.122.1
[herlo@ipa7 ~]$ id
uid=151600001(herlo) gid=151600001(herlo) groups=151600001(herlo) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c102

Congratulations! The FreeIPA server is now configured. In the next post, I will cover how to configure a client system and setup centralized sudo.

Cheers,

herlo

Posted in DNS, FreeIPA, Tech, Tools | Tagged , , , , , , , , , , , , , , , | Leave a comment

Changing the IP range for docker0

Lately, I’ve been tinkering a lot with docker. Mostly, I’ve been doing it for work at The Linux Foundation. But I do have a desire to have docker instances on my local box for distros which I do not run.

While doing some testing for work on my personal laptop, I noticed that the network which docker uses for it’s bridge, aptly named docker0, was in the same network as one of our VPNs.

# ip a s docker0
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
 link/ether fe:54:00:18:1a:fd brd ff:ff:ff:ff:ff:ff
 inet 172.17.41.1/16 brd 10.100.72.255 scope global docker0
 ..snip..

# ip a s tun0
139: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 ...
    link/none 
    inet 172.17.123.32/24 brd 172.17.224.255 scope global tun0
       valid_lft forever preferred_lft forever

As you can tell, the docker0 network bridge covers all of the tun0 network. Any time I would attempt to ssh into one of the systems inside the VPN, it would time out. I was left wondering why for a few moments.

Luckily, it’s very easy to fix this problem. All that is needed is a defined bridge for docker0 and to restart the docker service. Here’s what to do:

First, stop docker:

# service docker stop
Redirecting to /bin/systemctl stop  docker.service

Next, create the network bridge file. You can choose any IP range you like. On Fedora 19, it looks like this:

# cat /etc/sysconfig/network-scripts/ifcfg-docker0 
DEVICE="docker0"
TYPE="Bridge"
ONBOOT="yes"
NM_CONTROLLED="no"
BOOTPROTO="static"
IPADDR=10.100.72.254
NETMASK=255.255.255.0

Restart your network services.  NOTE: service network restart may be needed.

# service NetworkManager restart
Redirecting to /bin/systemctl restart  NetworkManager.service

The docker0 bridge should now be in a range outside the VPN.

# ip a s docker0
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether fe:54:00:18:1a:fd brd ff:ff:ff:ff:ff:ff
    inet 10.100.72.254/24 brd 10.100.72.255 scope global docker0

Starting new containers with docker should get IP addesses in the above range:

# service docker start
Redirecting to /bin/systemctl start  docker.service

# docker run -i -t herlo/fedora:20 /bin/bash
bash-4.2# ip a s eth0
141: eth0: <BROADCAST,UP,LOWER_UP> mtu 1412 ...
    link/ether fa:5f:e3:8d:61:f2 brd ff:ff:ff:ff:ff:ff
    inet 10.100.72.2/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f85f:e3ff:fe8d:61f2/64 scope link 
       valid_lft forever preferred_lft forever

SUCCESS!

Cheers,

herlo

Posted in docker, Fedora, Networking | Tagged , , , | Leave a comment

Fedora Ambassadors Update: February 2013

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in February:

Mon Mar 11 02:53:08 2013 | Accounts: 624 | Inactive: 81 (12.98%)

Cheers,

herlo

Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

Fedora Ambassadors Update: January 2013

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in January:

Fedora Ambassador Statistics

Thu Feb 7 12:29:06 2013 | Accounts: 619 | Inactive: 81 | % inactive: 13.09

Cheers,

herlo

Yes, the announcement is behind this month. Moving into a new home will do that to you!
Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

FUDCon Lawrence: Day 1 Session Videos and More

While you might have seen the barrage of posts from Fedora’s FUDCon Lawrence this weekend, you might not know that many sessions were streamed for your joy and enrichment.

Here’s a list with links to the videos (all of them are on youtube):

Enjoy,

herlo

Posted in Fedora, FUDCon, Tech | Tagged , , , , , , , | Leave a comment

Fedora Ambassadors Update: December 2012

Welcome New Ambassadors

We are happy to welcome our new sponsored Fedora Ambassador in December:

Fedora Ambassador Statistics

Cheers,

herlo

Posted in Ambassadors, Fedora, Tech | Tagged , , , , , | Leave a comment

FUDCon Lawrence Hackfest: GPG SmartCard Configuration

As I’ve been working at my new job at the Linux Foundation, we have been implementing quite a bit of two-factor authentication. In fact, back in November, Fedora implemented two-factor authentication for sudo at the Security FAD. I was there and helped setup the clients and did some testing.

While I was there, I had another agenda item, creating a HOWTO for enabling a GPG SmartCard for use with SSH. Of course, the SmartCard can be used for both encryption and signing as well.

After finishing that HOWTO, I was talking about it with a few people within Fedora, and there seemed to be quite a bit of interest. It turns out there was quite a bit of interest, so I’ve decided to do a hackfest on Saturday at FUDCon to help move people over to GPG SmartCards. This is also going to be quite nice in that there will be a GPG key signing event after this hackfest.

Come Prepared – Equipment Required

It’s important you come prepared! If you have ever had interest in this sort of thing, there’s time to get equipment for the hackfest. Here’s what you need:

Both pieces are required. Order ASAP, it takes about 10 days to ship. Consider even shipping to the FUDCon hotel if you are concerned or late. I know Petra will work hard to deliver them as fast as possible.

Doing a Little Prep Work

If you get your Token and SmartCard before FUDCon Lawrence and have a few spare minutes, feel free to read through my HOWTO. If you get through it, come to the hackfest and help others who might not have had time.

Cheers,

herlo

Posted in Fedora, FUDCon, Tech | Tagged , , , , , , , | Leave a comment

Well, that didn’t work: GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) Now Available!

The hope was to make a Golden GoOSe available for Christmas, but it didn’t work. Oh well, here’s another release candidate!

GoOSe Linux 6.0 Beta Release Candidate 5 (RC5) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC5/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

Testing can be done by anyone. Please feel free to check our new testing wiki page for information on what tests need to be run and which have already passed. If you have interest in helping us test, thank you, thank you, thank you for the help!

GoOSe Beta-RC5 will be available for 1 week from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

Posted in Fedora, GoOSe, Tech | Tagged , , , , , , , , | Leave a comment

GoOSe Linux 6.0 Beta Release Candidate 4 (RC4) Now Available!

GoOSe Linux 6.0 Beta Release Candidate 4 (RC4) is now available for testing. Visit http://get.gooseproject.org/ to obtain the download.

Once you arrive at the above link, the downloads are under /releases/6.0/Beta-RC4/GoOSe/<arch>/.

The GoOSe Project is always interested in feedback around its project. Please feel free to drop us a line about this release.

Comments/Questions:

Issues with GoOSe 6.0

If you find yourself having trouble installing, using or managing GoOSe Linux, please let us know. The best way is to file issues at our main project site on github, but we’re happy to have the information in any of the ways listed above.

GoOSe Beta-RC4 will be available for 2 weeks from today. At such time the GoOSe team will decide whether it will be the first Golden GoOSe release. This will be based upon feedback provided, so please do tell us what you think!

Cheers,

herlo

Posted in Fedora, GoOSe, News, Releases, Tech | Tagged , , , , , , , , | Leave a comment