Jump to: navigation, search


Obsolete Documentation

Please note that this content was marked as obsolete. We left the content here for study and archaeological purposes.

Please check our Documentation for a recent list of topics.

Introduction to freeIPA

What is freeIPA?

FreeIPA is an integrated solution which combines the following technologies:

  • Linux
  • 389 Directory Server
  • MIT Kerberos
  • NTP
  • DNS
  • Web and command-line provisioning and administration tools

The architecture of an IPA server can be represented as follows:

IPA Server Architecture

IPA and 389 Directory Server

What is 389 Directory Server?

389 Directory Server is an open source, LDAP-based directory service, which provides an LDAP server, a web management interface, and command-line and graphical management tools. It is highly scalable, and supports a number of features including:

  • multi-master replication
  • TLS/SSL and SASL security
  • support for custom plug-in extensions
  • online schema and configuration updates over LDAP
  • internationalized entries
  • optional on-disk encryption of selected attributes
  • virtual DIT views

389 Directory Server consists of several different components. The core directory server, ns-slapd, consists of a front end which handles network communications, extensible plug-ins which handle basic server functions, and a database back end which implements an indexed, transactional store on top of a Berkeley DB.

How IPA and 389 DS Work Together

389 DS is an integral part of IPA. In freeIPA, 389 DS serves as the data store, maintaining all of an organization's information. The Directory Server also controls access to all directory information; IPA users are restricted in the level of access they have to 389 DS information by the controls in place within 389 DS itself. 389 DS access control cannot be overridden by permissions, delegations, or other controls in IPA.

IPA and Kerberos

What is Kerberos?

Kerberos is a network authentication protocol created by MIT, and uses symmetric-key cryptography to authenticate users to network services, which means that passwords are never actually sent over the network.

Consequently, when users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted.

The primary design goal of Kerberos is to eliminate the transmission of unencrypted passwords across the network. If used properly, Kerberos effectively eliminates the threat that packet sniffers would otherwise pose on a network.

How IPA and Kerberos Work Together

The IPA implementation of Kerberos differs from a typical Kerberos implementation mainly in that it uses Directory Server to store data instead of a flat file. Access control is also provided by the directory. The IPA Kerberos implementation does not use the native tools because by default the KDC is not aware of Directory Server.

IPA provides its own set of tools for working with Kerberos. Kerberos' native tools, for example, those provided by kadmin.local, should not be used. For many reasons, kadmin.local does not currently have permission to operate outside of cn=kerberos. One reason is that it does not understand LDAP, which means that you cannot create principals where you want. Another reason is that it cannot proxy a password change to the IPA plugin. Consequently, if a password change is performed via kadmin.local, then the user entry would be corrupted.


Note: It is highly recommended that you avoid the use of kadmin and kadmin.local in an IPA deployment.

IPA, Kerberos, and Service Principals

A Service Principal is needed by a server program in order to perform Kerberos authentication. Kerberos authentication works by obtaining an encrypted ticket for a service, a ticket that only the service can decrypt (and therefore verify that the user obtained it from the KDC, indirectly proving that the client was able to authenticate to the KDC and is therefore trustworthy).

The Service Principal is therefore needed to make it possible for the client to tell the KDC which service it needs a ticket for, and for the KDC to be able to store and provide a secret to the service at the moment the Service Principal is created.

Service Principals are typically released per service, although it is possible for one Service Principal to be used for more services. For example, host/<fqdn>@REALM is used for both the SSH service and also as the generic "host" principal.

IPA, Kerberos, and DNS

As discussed in How IPA and DNS Work Together, IPA relies heavily on a fully-functional DNS for correct operation. Because of its tight integration with IPA, Kerberos also requires that the DNS be configured correctly.

Using CNAME and A Records

When Kerberos requests a ticket to begin authentication, it will always resolve a CNAME to its corresponding A record; Kerberos libraries will never use a CNAME to ask for a ticket. This means that when you create service or host principals you need to use the host A record. For example, consider the following zone file entry:

CNAME www.example.com -> A name web-01.example.com

If you use the following command to connect to the host via SSH and want GSSAPI authentication:

$ ssh www.example.com

it will actually request a ticket for host/web-01.example.com@EXAMPLE.COM

This is the service principal that you must use to obtain and save tickets in /etc/krb5.keytab for this host.


What is NTP?

Many computer services (for example, Kerberos) require that the time differential between different hosts on a network be kept to a minimum for correct or accurate operation. The Network Time Protocol (NTP) is a protocol used to synchronize computer clocks over the network. Most operating systems can be configured to synchronize their clocks with any of a number of time servers.

How IPA and NTP Work Together

IPA combines a number of different technologies, many of which constantly communicate with each other over the network. In order for these technologies to work together correctly, the time differential between the clients and servers on the network must be kept to a minimum.

Kerberos, for example, only tolerates a five minute time difference between the KDC and a client requesting authentication. A time difference greater than five minutes will result in a failed authentication.

System Administrators also rely on accurate time keeping for correlation of system logs across machines on the network. In the event of problems on the network or other aspects of a deployment, it may be necessary to inspect the log files of various machines to determine if specific problems occur at the same time. Without NTP or another time synchronization system, such troubleshooting would be all but impossible.

The IPA startup process ensures that the NTP service is started and that the time and date is synchronized before any other IPA-related processes are started. This is to avoid problems with certificates, LDAP entry creation dates, password expiration dates, account expiration dates, and any other date-related issues.


What is DNS?

A Domain Name Service (DNS) associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses.

DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other domains.

How IPA and DNS Work Together

IPA clients find, or discover, IPA servers using a process known as Service Discovery. This can occur automatically, using DNS, or manually, by entering the IPA server details during the client configuration phase.

Service Discovery using DNS

The recommended method for ensuring that IPA clients discover IPA servers is via DNS. This requires adding special records to the DNS configuration. The IPA Server installation generates a sample zone file which contains sample records for this purpose. In particular, it includes records for the LDAP servers, Kerberos realm, and Kerberos servers required in an IPA deployment. These records can be added to an existing DNS infrastructure - even one hosted on a different OS - or they can be added to a new DNS server if one does not already exist.

The following is an extract from a zone file where the IPA server, KDC, and DNS server all exist on the same machine (ipaserver) in the realm EXAMPLE.COM:

; ldap servers
_ldap._tcp              IN SRV 0 100 389        ipaserver

;kerberos realm
_kerberos               IN TXT EXAMPLE.COM

; kerberos servers
_kerberos._tcp          IN SRV 0 100 88         ipaserver
_kerberos._udp          IN SRV 0 100 88         ipaserver
_kerberos-master._tcp   IN SRV 0 100 88         ipaserver
_kerberos-master._udp   IN SRV 0 100 88         ipaserver
_kpasswd._tcp           IN SRV 0 100 464        ipaserver
_kpasswd._udp           IN SRV 0 100 464        ipaserver

If you already have DNS configured on your network, you can add this to the existing zone file (in this example, /var/named/example.com.zone.db) so that the IPA clients know where to find the LDAP and Kerberos servers.

Clients will attempt to discover the IPA server first using parameters passed via the command line, then using the configuration file (/etc/ipa/ipa.conf), and then via DNS.

Service Discovery without using DNS

It is possible, but not recommended, to operate without these records. If you do not use DNS for service discovery, then your clients will not automatically find other IPA services in a high-availability setup.

During an IPA client installation, if you do not have DNS correctly configured so that the client can discover the IPA server, you will need to enter the appropriate information manually.

Using IPA with Multi-Homed Machines

Some of the machines in your IPA deployment may support multiple Network Interface Cards (NICs). This is often the case for servers or other machines where high availability or failover is required. These muti-homed machines will typically have multiple IPs all assigned to the same hostname. Normally this will not cause any issues for IPA, as it listens on all available interfaces except localhost. The KDC does not listen on this interface; it only listens to the machine's public IP addresses.

For a server that has multiple NICs and IP addresses, you need to configure the DNS with the appropriate A records if the IPA server is to be available via any NIC.

For example, the zone file on the DNS server might have the following A records for an IPA server (ipaserver.example.com) with three NICs:

ipaserver  IN A
ipaserver  IN A
ipaserver  IN A

This allows IPA clients to discover the IPA server using any of the available network interfaces.