FreeIPA How To (Fedora)

FreeIPA is an open source alternative to Microsoft Directory Server. It provides the following functionality:

  • Centralised LDAP based authorisation
  • Kerberos
  • Time server
  • DNS
  • Certificate Authority
  • Host and Role based access control

and more, all with a reasonable web GUI and excellent command line tools.

This how to walks through an install of FreeIPA on a Fedora 19 install and configures three servers in a multi-master configuration. It should be similar on CentOS and RHEL (although the packages might be called ipa not freeipa).

The example network configuration is as follows:
IPA master server #1:

  • ipa1.test.lan
  • 192.168.122.11

IPA master server #2 (replica):

  • ipa2.test.lan
  • 192.168.122.12

IPA master server #3 (replica):

  • ipa3.test.lan
  • 192.168.122.13

You can follow this structure and substitute your domain and IP range, or if you don’t want 3 servers, then modify to suit.

Prepare server

First, perform a basic install of Fedora on all three of your servers.

During install make sure that you choose:

  • minimal package selection

01-ipa-server-install

  • manually configure networking (pointing to itself for DNS)

02-ipa-server-install-network

Once your basic servers have been installed, it will only look to itself for
DNS. However until you have set up the IPA server, you need to use an external DNS
server so that we can install packages from the Internet.

So, make sure your resolv.conf has at least one working DNS server entry. This will probably be your network’s or ISP’s, but here we are using Google’s:
echo nameserver 8.8.8.8 >> /etc/resolv.conf
echo nameserver 8.8.4.4 >> /etc/resolv.conf

Packages

Post install, update all three systems and install any tools you like:
yum update
yum install vim rsync

Now, install the freeipa packages on all three servers:
yum install freeipa-server bind bind-dyndb-ldap oddjob-mkhomedir

Networking

Ensure network is configured statically in its config, such as:

  • /etc/sysconfig/network-scripts/ifcfg-eth0

Here’s an example of my first master IPA server:

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=eth0
UUID=f3ab848b-a33c-4b84-ab7a-566bad76963c
ONBOOT=yes
HWADDR=52:54:00:C3:3F:D7
IPADDR0=192.168.122.13
PREFIX0=24
GATEWAY0=192.168.122.1
DNS1=192.168.122.11
DOMAIN=test.lan

After that, disable network manager and enable network service:
systemctl disable NetworkManager.service
chkconfig network on

Now we need to start and stop relevant networking services:
service network start
systemctl stop NetworkManager.service

Set /etc/hosts to contain all three IPA servers. This is so that they can resolve each other, even if DNS is not yet working:
cat >> /etc/hosts << EOF
192.168.122.11 ipa1.test.lan ipa1
192.168.122.12 ipa2.test.lan ipa2
192.168.122.13 ipa3.test.lan ipa3
EOF

After all that, check that the host resolves itself properly:
hostname -f && hostname -s && hostname -d

Ensure search is set properly in resolv.conf. Note, the name server should point to itself, in this case the first IPA server (but replace appropriately as you configure all three). This should have been done as a part of your manual network configuration:
search test.lan
nameserver 192.168.122.11

Firewall

We need to enable ports on the firewall to enable access to services and synchronisation between replicas.

Get default zone, this should be public:
firewall-cmd --get-active-zones

List services on zone:
firewall-cmd --zone=public --list-all

Add required TCP ports:
for x in 53 80 88 389 443 464 636 7389 9443 9444 9445; do firewall-cmd --permanent --zone=public --add-port=$x/tcp ; done

Note: TCP on port 53 is required for dynamic dns updates to work!

Add required UDP ports:
for x in 53 88 123 464; do firewall-cmd --permanent --zone=public --add-port=$x/udp ; done

Restart firewall:
systemctl restart firewalld.service

Authentication

Before we set up the servers, we need to enable making home directory at log in:
authconfig --enablemkhomedir --update

This is important to do before you configure IPA, so that when users log in their home directory is made. Doing this after you've configured IPA on the box is a pain, so do it now before you start.

Configure IPA Master

We need to set up the first IPA master instance, from which others will be replicated.

Note, you can set the id range if you like, or let it auto-allocate.

Also, by default, we are setting no HBAC (host based access control) rules, so no-one will be able to access the servers or clients, we will then build up the rules as we go. If you don't want to use HBAC then remove the --no_hbac_allow option.

Here's the command:
ipa-server-install --ssh-trust-dns --setup-dns --idstart=50000
--idmax=99999 --no_hbac_allow

Here's a complete example:

[root@ipa1 ~]# ipa-server-install --ssh-trust-dns --setup-dns --idstart=50000 --idmax=99999 --no_hbac_allow
 
The log file for this installation can be found in /var/log/ipaserver-install.log
======================================================================
This program will set up the FreeIPA 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
Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
.
Example: master.example.com.
 
 
Server host name [ipa1.test.lan]:
 
Warning: skipping DNS resolution of host ipa1.test.lan
The domain name has been determined based on the host name.
 
Please confirm the domain name [test.lan]:
 
The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.
 
Please provide a realm name [test.lan]:
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:
Password (confirm):
 
The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.
 
IPA admin password:
Password (confirm):
 
Do you want to configure DNS forwarders? [yes]: no
No DNS forwarders configured
Do you want to configure the reverse zone? [yes]:
Please specify the reverse zone name [122.168.192.in-addr.arpa.]:
Using reverse zone 122.168.192.in-addr.arpa.
 
The IPA Master Server will be configured with:
Hostname: ipa1.test.lan
IP address: 192.168.122.11
Domain name: test.lan
Realm name: TEST.LAN
 
BIND DNS server will be configured to serve IPA domain with:
Forwarders: No forwarders
Reverse zone: 122.168.192.in-addr.arpa.
 
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
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/37]: creating directory server user
[2/37]: creating directory server instance
[3/37]: adding default schema
[4/37]: enabling memberof plugin
[5/37]: enabling winsync plugin
[6/37]: configuring replication version plugin
[7/37]: enabling IPA enrollment plugin
[8/37]: enabling ldapi
[9/37]: configuring uniqueness plugin
[10/37]: configuring uuid plugin
[11/37]: configuring modrdn plugin
[12/37]: configuring DNS plugin
[13/37]: enabling entryUSN plugin
[14/37]: configuring lockout plugin
[15/37]: creating indices
[16/37]: enabling referential integrity plugin
[17/37]: configuring certmap.conf
[18/37]: configure autobind for root
[19/37]: configure new location for managed entries
[20/37]: configure dirsrv ccache
[21/37]: enable SASL mapping fallback
[22/37]: restarting directory server
[23/37]: adding default layout
[24/37]: adding delegation layout
[25/37]: creating container for managed entries
[26/37]: configuring user private groups
[27/37]: configuring netgroups from hostgroups
[28/37]: creating default Sudo bind user
[29/37]: creating default Auto Member layout
[30/37]: adding range check plugin
[31/37]: initializing group membership
[32/37]: adding master entry
[33/37]: configuring Posix uid/gid generation
[34/37]: adding replication acis
[35/37]: enabling compatibility plugin
[36/37]: tuning directory server
[37/37]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
[1/20]: creating certificate server user
[2/20]: configuring certificate server instance
[3/20]: disabling nonces
[4/20]: creating RA agent certificate database
[5/20]: importing CA chain to RA certificate database
[6/20]: fixing RA database permissions
[7/20]: setting up signing cert profile
[8/20]: set up CRL publishing
[9/20]: set certificate subject base
[10/20]: enabling Subject Key Identifier
[11/20]: enabling CRL and OCSP extensions for certificates
[12/20]: setting audit signing renewal to 2 years
[13/20]: configuring certificate server to start on boot
[14/20]: restarting certificate server
[15/20]: requesting RA certificate from CA
[16/20]: issuing RA agent certificate
[17/20]: adding RA agent as a trusted user
[18/20]: configure certificate renewals
[19/20]: configure Server-Cert certificate renewal
[20/20]: Configure HTTP to proxy connections
Done configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds
[1/10]: adding sasl mappings to the directory
[2/10]: adding kerberos container to the directory
[3/10]: configuring KDC
[4/10]: initialize kerberos container
[5/10]: adding default ACIs
[6/10]: creating a keytab for the directory
[7/10]: creating a keytab for the machine
[8/10]: adding the password extension to the directory
[9/10]: starting the KDC
[10/10]: configuring KDC to start on boot
Done configuring Kerberos KDC (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 ipa-otpd
[1/2]: starting ipa-otpd
[2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Configuring the web interface (httpd): Estimated time 1 minute
[1/15]: disabling mod_ssl in httpd
[2/15]: setting mod_nss port to 443
[3/15]: setting mod_nss password file
[4/15]: enabling mod_nss renegotiate
[5/15]: adding URL rewriting rules
[6/15]: configuring httpd
[7/15]: setting up ssl
[8/15]: setting up browser autoconfig
[9/15]: publish CA cert
[10/15]: creating a keytab for httpd
[11/15]: clean up any existing httpd ccache
[12/15]: configuring SELinux for httpd
[13/15]: configure httpd ccache
[14/15]: restarting httpd
[15/15]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Configuring DNS (named)
[1/11]: adding DNS container
[2/11]: setting up our zone
[3/11]: setting up reverse zone
[4/11]: setting up our own record
[5/11]: setting up records for other masters
[6/11]: setting up CA record
[7/11]: setting up kerberos principal
[8/11]: setting up named.conf
[9/11]: restarting named
[10/11]: configuring named to start on boot
[11/11]: changing resolv.conf to point to ourselves
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
======================================================================
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 reboot your IPA server and make sure that everything comes up properly.
init 6

Kerberos ticket

Before you can run any ipa commands you need a kerberos ticket, so make sure you get one before trying the commands:
kinit admin

You can see your tickets with the klist command, including their expiry time.

System account

While FreeIPA v3 allows anonymous bind (to be disabled in v4), the "memberOf" attributes of a user's record are not available anonymously. So if you need to configure LDAP based services where you need to filter users by certain groups, you will need to bind as a user.

SSH onto one of the IPA servers first, then create a system user via ldapmodify (replace uid and password with what you want).
ldapmodify -x -D 'cn=Directory Manager' -W
Enter LDAP Password:
dn: uid=system,cn=sysaccounts,cn=etc,dc=test,dc=lan
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: password
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

Now you can bind as user uid=system,cn=sysaccounts,cn=etc,dc=test,dc=lan with password you set above, and filtering should work.

You can reset that user's password with:

ldappasswd -Y GSSAPI -S -h ipa1.test.lan uid=system,cn=sysaccounts,cn=etc,dc=test,dc=lan

Global forwarders

Now add some DNS forwarders for when you want to resolve something outside of your network domain. This may be your ISP's DNS, or perhaps Google's (as below).
ipa dnsconfig-mod --forwarder=8.8.8.8 --forwarder=8.8.8.4

Per zone forwarders

If you have another domain that you do not control but you need to resolve, you can do this by adding a domain and then setting a forward policy for that.

For example, we are configuring test.lan but let's say we want to forward for the another.lan domain. You need to know the root server and its IP address:

ipa dnszone-add another.lan --name-server=ns1.another.lan --ip-address=192.168.1.1 --admin-email=admin@another.lan

Now we can set a zone forwarder for that zone:

ipa dnszone-mod --forwarder=192.168.1.1 another.lan

Or you can do it all in one step:
ipa dnszone-add another.lan --name-server=ns1.another.lan --ip-address=192.168.1.1 --admin-email=admin@another.lan --forwarder=192.168.1.1

Web UI

If you're feeling brave, you can now use your browser to log into the web GUI as the admin user. Just browse to:
http://ipa1.test.lan

This will re-direct you and you'll have to access the self-signed certificate. After that, log in and play around!

Replicas

Prepare replicas on the master IPA server (so ssh in there first). This will add the replica host to DNS and generate an encrypted configuration file which we will copy to the replica.
ipa-replica-prepare ipa2.test.lan --ip-address 192.168.122.12

Repeat this procedure for any other replicas, e.g. ipa3.test.lan:
ipa-replica-prepare ipa3.test.lan --ip-address 192.168.122.13

Here's a complete example:

[root@ipa1 ~]# ipa-replica-prepare ipa2.test.lan --ip-address 192.168.122.12
Directory Manager (existing master) password:
 
Preparing replica for ipa2.test.lan from ipa1.test.lan
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Saving dogtag Directory Server port
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/replica-info-ipa2.test.lan.gpg
Adding DNS records for ipa2.test.lan
Using reverse zone 122.168.192.in-addr.arpa.
The ipa-replica-prepare command was successful

Now, copy the key across to the replica:
scp /var/lib/ipa/replica-info-ipa2.test.lan.gpg
ipa2:/var/lib/ipa/replica-info-ipa2.test.lan.gpg

Repeat for any other replicas, such as ipa3:
scp /var/lib/ipa/replica-info-ipa3.test.lan.gpg
ipa3:/var/lib/ipa/replica-info-ipa3.test.lan.gpg

Here's a complete example:
[root@ipa1 ~]# scp /var/lib/ipa/replica-info-ipa2.test.lan.gpg ipa2:/var/lib/ipa/replica-info-ipa2.test.lan.gpg
root@ipa2's password:
replica-info-ipa2.test.lan.gpg 100% 36KB 36.2KB/s 00:00

The next step is to configure the replica but this does a check via SSH as the admin user. This will fail if you have disabled the "allow all" HBAC rule. It's no drama, you can add --skip-conncheck option if you're sure that your ports are all correct, else skip ahead to the HBAC section and create a rule allowing the admin user to ssh into ipa servers.

Now we ssh into the replica instance as root and set up the replica using the key we just copied.
ssh root@ipa2
ipa-replica-install --setup-ca --setup-dns --no-forwarders
--ssh-trust-dns --skip-conncheck
/var/lib/ipa/replica-info-ipa2.test.lan.gpg

Again, repeat for any other replicas, e.g. ipa3.test.lan
ssh root@ipa3
ipa-replica-install --setup-ca --setup-dns --no-forwarders
--ssh-trust-dns --skip-conncheck
/var/lib/ipa/replica-info-ipa3.test.lan.gpg

Here's a complete example:
[root@ipa2 ~]# ipa-replica-install --setup-ca --setup-dns --no-forwarders --ssh-trust-dns --skip-conncheck /var/lib/ipa/replica-info-ipa2.test.lan.gpg
WARNING: conflicting time&date synchronization service 'chronyd' will
be disabled in favor of ntpd
 
Directory Manager (existing master) password:
 
Configuring NTP daemon (ntpd)
[1/4]: stopping ntpd
[2/4]: writing configuration
[3/4]: configuring ntpd to start on boot
[4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv): Estimated time 1 minute
[1/33]: creating directory server user
[2/33]: creating directory server instance
[3/33]: adding default schema
[4/33]: enabling memberof plugin
[5/33]: enabling winsync plugin
[6/33]: configuring replication version plugin
[7/33]: enabling IPA enrollment plugin
[8/33]: enabling ldapi
[9/33]: configuring uniqueness plugin
[10/33]: configuring uuid plugin
[11/33]: configuring modrdn plugin
[12/33]: configuring DNS plugin
[13/33]: enabling entryUSN plugin
[14/33]: configuring lockout plugin
[15/33]: creating indices
[16/33]: enabling referential integrity plugin
[17/33]: configuring ssl for ds instance
[18/33]: configuring certmap.conf
[19/33]: configure autobind for root
[20/33]: configure new location for managed entries
[21/33]: configure dirsrv ccache
[22/33]: enable SASL mapping fallback
[23/33]: restarting directory server
[24/33]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 2 seconds elapsed
Update succeeded
 
[25/33]: setting Auto Member configuration
[26/33]: enabling S4U2Proxy delegation
[27/33]: initializing group membership
[28/33]: adding master entry
[29/33]: configuring Posix uid/gid generation
[30/33]: adding replication acis
[31/33]: enabling compatibility plugin
[32/33]: tuning directory server
[33/33]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
[1/17]: creating certificate server user
[2/17]: configuring certificate server instance
[3/17]: disabling nonces
[4/17]: creating RA agent certificate database
[5/17]: importing CA chain to RA certificate database
[6/17]: fixing RA database permissions
[7/17]: setting up signing cert profile
[8/17]: set up CRL publishing
[9/17]: set certificate subject base
[10/17]: enabling Subject Key Identifier
[11/17]: enabling CRL and OCSP extensions for certificates
[12/17]: setting audit signing renewal to 2 years
[13/17]: configuring certificate server to start on boot
[14/17]: configure certmonger for renewals
[15/17]: configure clone certificate renewals
[16/17]: configure Server-Cert certificate renewal
[17/17]: Configure HTTP to proxy connections
Done configuring certificate server (pki-tomcatd).
Restarting the directory and certificate servers
Configuring Kerberos KDC (krb5kdc): 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 Kerberos KDC (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 (httpd): Estimated time 1 minute
[1/14]: disabling mod_ssl in httpd
[2/14]: setting mod_nss port to 443
[3/14]: setting mod_nss password file
[4/14]: enabling mod_nss renegotiate
[5/14]: adding URL rewriting rules
[6/14]: configuring httpd
[7/14]: setting up ssl
[8/14]: publish CA cert
[9/14]: creating a keytab for httpd
[10/14]: clean up any existing httpd ccache
[11/14]: configuring SELinux for httpd
[12/14]: configure httpd ccache
[13/14]: restarting httpd
[14/14]: configuring httpd to start on boot
Done configuring the web interface (httpd).
Configuring ipa-otpd
[1/2]: starting ipa-otpd
[2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Using reverse zone 122.168.192.in-addr.arpa.
Configuring DNS (named)
[1/9]: adding NS record to the zone
[2/9]: setting up reverse zone
[3/9]: setting up our own record
[4/9]: setting up CA record
[5/9]: setting up kerberos principal
[6/9]: setting up named.conf
[7/9]: restarting named
[8/9]: configuring named to start on boot
[9/9]: changing resolv.conf to point to ourselves
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

Next, reboot the replica and ensure things come up properly
init 6

Back on the IPA master server, get a kerberos ticket so that we can manage the replicas.
kinit admin

Check sync relationship:
ipa-replica-manage list

Now create 3-way sync relationship by joining the two replicas:
ipa-replica-manage connect ipa2.test.lan ipa3.test.lan

Now we should have 3 multi-master IPA servers, all serving authentication, DNS, etc, to your network.

Client machine

Now that we have our first IPA server, we can set our desktop to use our IPA servers for DNS to IPA servers. You probably want to do this in your network settings for a permanent solution, or set your DHCP server to provide them by default. Don't worry that you don't have the other IPA servers up yet.

Here's a temporary solution:
cat > /etc/resolv.conf << EOF
domain test.lan
search test.lan
nameserver 192.168.122.11
nameserver 192.168.122.12
nameserver 192.168.122.13
EOF

Now (if you've installed bind-utils) you can try to resolve the IPA servers on your desktop's terminal:
nslookup ipa1.test.lan

You should get a response with the IP address from your first server.

Now we can install the client tools and join ourselves to the domain.
yum install ipa-client oddjob-mkhomedir

Enable mkhomedir also, like on the servers:
authconfig --enablemkhomedir --update

Now, do the task of joining the client to the realm. It will prompt for an account which has credentials to add the machine, so use the admin account:
ipa-client-install --enable-dns-updates --mkhomedir --ssh-trust-dns --force-ntpd

Here's a complete example:

[root@client ~]# ipa-client-install --enable-dns-updates --mkhomedir --ssh-trust-dns
Discovery was successful!
Hostname: client.test.lan
Realm: TEST.LAN
DNS Domain: test.lan
IPA Server: ipa2.test.lan
BaseDN: dc=test,dc=lan
 
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Password for admin@TEST.LAN:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=TEST.LAN
Issuer: CN=Certificate Authority,O=TEST.LAN
Valid From: Wed Aug 07 05:52:25 2013 UTC
Valid Until: Sun Aug 07 05:52:25 2033 UTC
 
Enrolled in IPA realm TEST.LAN
Created /etc/ipa/default.conf
New SSSD config will be created
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm TEST.LAN
trying https://ipa2.test.lan/ipa/xml
Forwarding 'env' to server 'https://ipa2.test.lan/ipa/xml'
Hostname (client.test.lan) not found in DNS
DNS server record set to: client.test.lan -> 192.168.122.100
Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to server 'https://ipa2.test.lan/ipa/xml'
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.

Reboot the machine and test log back on with root.
Note, that without HBAC rules, your IPA users can't log onto the machine!

See the HBAC section below on how to add your machine to a group and create a rule for it so that you can log on.

Configuring central sudo

IPA can serve up central sudo rules to connected clients, but they need to be configured manually (server configuration happens in the GUI or via ipa CLI commands).

Set this in /etc/nsswitch.conf
echo "sudoers: files sss" >> /etc/nsswitch.conf

Set the services line in /etc/sssd/sssd.conf to include sudo, like so:
services = nss, pam, ssh, sudo

Set NISDOMAIN in /etc/sysconfig/network
echo "NISDOMAIN=test.lan" >> /etc/sysconfig/network

Enable the domainname service:
systemctl enable fedora-domainname

Reboot and the client should be configured to get sudo rules from IPA (and also files first).

Administration

There are excellent ipa commands which make administrating IPA simple.

Here you can see all the possibilities:
ipa help commands

Users

Create a user and follow the prompts:
ipa user-add

You can also pass in options if you like, such as first name. Here's an example:

[root@ipa1 ~]# ipa user-add --first=Testing --last=Tester --displayname="Testing Tester" --homedir=/home/ttester --shell=/bin/bash ttester
--------------------
Added user "ttester"
--------------------
User login: ttester
First name: Testing
Last name: Tester
Full name: Testing Tester
Display name: Testing Tester
Initials: TT
Home directory: /home/ttester
GECOS field: Testing Tester
Login shell: /bin/bash
Kerberos principal: ttester@TEST.LAN
Email address: ttester@test.lan
UID: 50004
GID: 50004
Password: False
Member of groups: ipausers
Kerberos keys available: False

Passwords

Now we need to set the password for our user:
ipa passwd ttester

Host groups

Let's create a group of hosts for the IPA servers (called ipa), which we can later create a HBAC rule for.
ipa hostgroup-add --desc="IPA Servers" ipa

Find our hosts:
ipa host-find

Add our IPA hosts to the group:
ipa hostgroup-add-member --hosts=ipa1.test.lan --hosts=ipa2.test.lan --hosts=ipa3.test.lan ipa


HBAC


Let's create a HBAC rule for sshing into the IPA servers, and allow our test user to access those servers.

Create rule:
ipa hbacrule-add ssh-ipa

Add a user to the rule:
ipa hbacrule-add-user --users=ttester sshd-ipa

Add a host group to the rule:
ipa hbacrule-add-host --hostgroups=ipa sshd-ipa

Add a service to the rule:
ipa hbacrule-add-service --hbacsvcs=sshd sshd-ipa

Now let's take a look at your HBAC rule:
ipa hbacrule-show sshd-ipa

Here's an example:
[root@ipa1 ~]# ipa hbacrule-show sshd-ipa
Rule name: sshd-ipa
Enabled: TRUE
Users: ttester
Host Groups: ipa
Services: sshd

You can see our user has permissions to access hosts in the ipa group via ssh.

Give it a try!

ssh ttester@ipa1

The user should be prompted to change their password. Do that, then log back in.

Removing replicas and masters

Before we remove a replica or master server we should delete any relationships it has with other servers. This was a hard-learned lesson from early IPA days and it helps to prevent a situation where sync relationships exist but the servers don't.

Let's removing ipa3 server. First we need to disconnect any relationships:
ipa-replica-manage disconnect ipa3.test.lan ipa.test.lan
ipa-replica-manage disconnect ipa3.test.lan ipa2.test.lan

Now we can delete the replica (the second command removes the certificate authority component).
ipa-replica-manage del ipa3.test.lan
ipa-csreplica-manage del ipa3.dev.lan

Now the replica should be disconnected and removed from the realm. The remaining IPA servers will know this and life should be happy. You can always re-join this same box if you want to, with regular ipa-replica-install documentation above.

Certificate management

Your initial IPA server is also your network's Certificate Authority and uses the dogtag server to manage certificates. It manages expiration of certificates and

You can use this to generate not only host certificates but service certificates for servers on your network, such as apache or postfix. Any client machines on your network can import the IPA CA cert and trust any services you provide.

You can join your servers to the realm in just the same manner as the client (desktops) above. However, even if they are not joined to the realm you can still create certs for them!

Let's create a certificate for a web server on host.test.lan which is has not joined our realm.

SSH onto your IPA server and get a kerberos ticket:
[user@machine ~]# ssh root@ipa1
[root@ipa1 ~]# kinit admin

Add the host (this is not required if your server is on the realm).
[root@ipa1 ~]# ipa host-add host.test.lan

Add a service for that machine.
[root@ipa1 ~]# ipa service-add HTTP/host.test.lan

Allow the IPA server to manage service (else certificates must be done on the client as IPA uses the host kerberos ticket to generate the cert).
[root@ipa1 ~]# ipa service-add-host --hosts=ipa1.test.lan HTTP/host.dev.lan

Create new cert.
[root@ipa1 ~]# ipa-getcert request -r -f /etc/pki/tls/certs/host.test.lan.crt -k
/etc/pki/tls/private/host.test.lan.key -N CN=host.test.lan -D
host.test.lan -K HTTP/host.test.lan

Now copy that key and certificate to your web server host and configure apache as required.
[root@ipa1 ~]# rsync -P /etc/pki/tls/certs/host.test.lan.crt /etc/pki/tls/private/host.test.lan.key host:

You can delete keys, first get the request id:
[root@ipa1 ~]# ipa-getcert list

Take note of the id for the certificate you want to delete.
[root@ipa1 ~]# getcert stop-tracking -i [request id]

26 Responses to “FreeIPA How To (Fedora)”


  • Great article Chris!

    One gotcha from my own experiences with FreeIPA on Fedora has been try to run either the server or client command with a variable set for the http proxy (HTTP_PROXY I think) these cause a strange failure of one of the setup scripts.

    Regards,

    Glenn

  • Hey Glenn, thanks. Yeah I have had a number of problems with the connectivity check, I ended up skipping it each time :-)

    Cheers,
    -c

  • what’s wrong??? :(
    after i reboot (init 6) after all the instalation of principal server i do the kinit admin and :

    kinit: Cannot contact any KDC for realm ‘MYDOMAIN.COM’ while getting initial credentials

    and when i do an ipctl status:

    Directory Service: RUNNING
    ipa: INFO: The ipactl command was successful

    may you help me???

    thank you…

  • This is a great article for getting FreeIPA setup. So first of all thanks. There is one problem in it that got me stuck for a while. In the for statement for firewall rules you left out tcp port 53. This causes the auto DNS to fail when configuring clients.

  • I thought you said this was an alternative to MS Active Directory.

    That mammoth setup is ridiculously complicated when compared to AD (on any version).

    If the setup is not as easy as AD, it is doomed to fail in real life. How do you expect your average IT guy to perform all those steps without stuffing up at least somewhere?

  • Hey Jeremy, there’s much more in there than just the setting up of the FreeIPA server itself. I tried to be thorough and step through opening up the firewall, manual networking (in case you didn’t do it in the installer), plus there’re topics on managing dns, replicas, clients, certificates, host based access control and all sorts of things.

    Installing a FreeIPA server can be as easy as:

    1) Install Fedora choosing “Minimal Install” and select “FreeIPA Server” add-on.
    2) Post-install, log in as root and run command:
    ipa-server-install
    3) Log into the web interface and go nuts

  • hi, do you know if is possible to install and configure ipa-client on sles 11 ??, if yes, can you recommend me an article or book that helps me to install and configure the necessary software to enroll a sles 11 client to freeipa-server?

    hope you can help me.
    peace.

  • is it possible to connect a free ipa server running in CentOS 6 and a freeipa client running in fedora 20 ?? if so how?, cuz I’m stuck please help :|

  • Good day.

    I stuck in the beginning (using Fedora 20):

    1) where did you get “UUID=f3ab848b-a33c-4b84-ab7a-566bad76963c”?
    I used uuidgen, it spit out a value, and I used it.

    2) this command execution failed: “service network start”.

    Maybe the problem will be apparent to you if you just spend 10 minutes to create a VM with Fedora 20 and try to follow your instructions up to the command “service network start”.

  • Hi Rolf, yes it should be possible although I think there was a point where the later client scripts would only connect to newer servers. You should however, be able to configure it all manually regardless. What problems are you having?

  • Hi Orkhan, UUID is unique to my system and was generated although it’s is not really required so try removing it.

  • Sorry, I haven’t tried it on SLES or openSUSE..

  • Sorry for the delay, are you sure you have the right admin password?

  • Hi Chris,

    Do you think its possible to use this product to manage multi-organization structure, for example in IT hosting company? Where users would be separated and organization are independent?
    It would require multiple suffixes created at the root of ldap tree, but I don’t see how it’s possible in this product.

    Thanks,
    Roman

  • Yeah I don’t think you can have a single IPA server serving multiple domains/realms and you would need a server for each. Might be best to ask on #freeipa IRC channel though.

  • Hi Chris,

    First off great article – works well with centos7 too. Just posting to say thanks, and to warn centos7 users of a bug, if they run into it.

    At the part where you are setting remote sudo permissions in particular the rhel-domainname (“NISDOMAIN=test.lan”), centos7 has a bug with initscripts which will mean the server will hang on restart. Took me a while to find the solution, but it is fixable.

    If you’re already stuck, add “systemd.log_target=null” to your kernel boot params. Will allow you to get to the OS again. Source: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=71721

    And to fix permanently, add the line:
    DefaultDependencies=no
    in the [Unit] section of /usr/lib/systemd/system/rhel-domainname.service

    (rhel-domainname === fedora-domainname) for centos

    apart from that – everything works great, thanks!

  • Hey Alex,

    Glad it was useful. My apologies, I ran into that same problem on CentOS, so if I’d have added that as a note to this article that might have saved you some time. Will add that for anyone else doing the same.

    Cheers,
    Chris

  • Hi Chris,

    when i setting up the ipa replica servers, it can’t be updated between the 2 replica servers, /var/log/message always showing:
    ipa ns-slapd: encoded packet size too big (227976 > 65536)

    [root@ipa1 ~]# ldapsearch -b cn=config -D “cn=Directory Manager” -W | grep nsslapd-sasl-max-buffer-size
    Enter LDAP Password:
    nsslapd-sasl-max-buffer-size: 65536

    i know there’s a patch can fix this problmes:
    https://fedorahosted.org/389/ticket/47457

    but how can i update this patch? when i make and make install the 389-ds-base-1.3.3.5, and run ipactl restart, the processes failed to up, can you tell me how can i update this patch?

    Best Restarts,
    Sean

  • ps: I installed the ipa-server-3.0.0-42.el6.centos.x86_64 on CentOS release 6.6 (Final)

  • Hey Sean,

    You would need to re-compile the RPM from a source RPM and modify the spec file to apply the patch..

    There should be a way to modify your config database instead. If you can just change the nsslapd-sasl-max-buffer-size entry in your config database that should do the trick without re-compilation..

    -c

  • Hi Chris,

    Thanks for the reply! I re-compiled the source files after installed lots of dependence packages, but failed to “make install” it. run “ldapmodify -x -D “cn=Directory Manager” -W -h ipa1.example.com -p 389″ on server side all gave no response. do you know how change the nsslapd-sasl-max-buffer-size entry?

    another questions: I’m configuring ipa-client-2.1.3-7.el5 on centos 5.7, after configured the related files specified by this article: http://wiki.bsdserver.nl/doku.php?id=linux:freeipa:freeipasudo, and https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Configuring_Identity_Management/configuring-rhel5.html there’s no /etc/nss_ldap.conf file, i created one, and run “ln -s /etc/nss_ldap.conf /etc/ldap.conf”, but the sudo rules didn’t work after done that, do you have any suggestions?

    Best Regards,
    Sean

  • Hi Chris,

    Sorry to bother you, please ignore the second question: about sudo configuration on Centos 5, it works after i configured it~, there’s only one questions left: how to modify the nsslapd-sasl-max-buffer-size?

  • I’m not sure how well sudo rules are supported under 5.7, unfortunately I never configured IPA under 5. I know they got better in 6 and is now quite reliable (going through sssd).

    As to config, can you do an authenticated ldapsearch of cn=config? You probably need to bind as Directory Manager. See if you can find that nsslapd-sasl-max-buffer-size entry. If you can find it, we should be able to modify it with ldapmodify commands.

  • it can be searched through following commands:
    [root@ipa1 ~]# ldapsearch -b cn=config -D “cn=Directory Manager” -W | grep nsslapd-sasl-max-buffer-size
    Enter LDAP Password:
    nsslapd-sasl-max-buffer-size: 65536

    But when using ldapmodify as following:
    [root@ipa1 ~]# ldapmodify -x -D “cn=Directory Manager” -W -h ipa1.example.com -p 389
    Enter LDAP Password:

    it’s frozen here gives no response, have you ever met such problems on EPEL 6?

  • That looks good, now you need to start running your commands.

    At a guess, something like this:
    dn: cn=config
    changetype: modify
    replace: nsslapd-sasl-max-buffer-size
    nsslapd-sasl-max-buffer-size: 2097152
    [enter key]

  • Dear Chris,

    It works! I thought it’s frozen there, but didn’t think it waiting for me to put the contents of modifying, you are so nice to remind me about it, you solved me a big problems and gave me so big help! thanks very much!!!

    Best Regards,
    Sean Lv

Leave a Reply