Replicate your identity management

Jan Pazdziora

Sr. Principal Software Engineer
Identity Management Engineering, Red Hat

12th October 2016

CC BY-SA License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

These slides are also available in PDF format.

Highly available infrastructure

  • Ability to obtain service, without experiencing components down.
  • Minimizing access and thus the load, for example via caching.
  • Adding redundancy to the system, ensuring failover to the good component.

Identity management

  • Resolution of identities — users, groups, hosts, services, ...
  • Verification of identities (authentication).
  • Evaluation of access requests and attempts (authorization), based on centrally managed policies.
  • For example: ls -l on POSIX systems
    • It can make number of NSS (Name Service Switch) calls resolving owner and group identities.
    • Identities can be stored on external identity source, not in /etc.


  • Integration of multiple identity-management tools.
    • directory server (LDAP), Kerberos key distribution center, one-time password (OTP) daemon
    • optionally DNS server, certification authority, vault
    • WebUI, command-line interface
  • Built-in replication using 389 Directory Server replication functionality.
    • Multi-master.
  • Client machines get IPA-enrolled to one of the servers.
    • Typically via ipa-client-install which configures all subsystems.
      • Often using one-time password for the host identity.
    • They can do a lot of caching.

IPA-enrolled systems

  • SSSD (System Security Services Daemon):
    • NSS service;
    • PAM (Pluggable Authentication Module) service;
    • plugs to other subsystems — sudo, Kerberos, ...
    • DNS records can prioritize IPA servers used:
      # /etc/sssd/sssd.conf
      ipa_server = _srv_,
    • KDC's IP address cached in /var/lib/sss/pubconf/kdcinfo.*.

FreeIPA replication

IPA realm
IPA server

IPA server
IPA-enrolled system IPA-enrolled system IPA-enrolled system
  • IPA servers get found via DNS or with their hostname hardcoded on clients.

Replication and topology enhancements

Three areas of replication improvement:

  • Replica promotion which simplifies setup of new replicas.
  • Topology plugin for central control over replication agreements.
  • DNS-based locations for central management of client priorities.

Replica promotion

  • Promotion of any IPA-enrolled client to FreeIPA replica.
    • Can also start with unenrolled host.
  • GPG-encrypted replica information files no longer needed.
  • The ipa-replica-install tool still used.
  • Standard Kerberos authentication.
  • With host OTP and ipaservers host group, admin credentials do not need to be used on the replicas.

Example workflow

  • Create host record for the future replica, give the host ability to make itself a replica with the ipaservers host group.

client$ kinit admin
Password for admin@EXAMPLE.COM: 
client$ ipa host-add --random
Added host ""
  Host name:
  Random password: ImgXN_VxNC,B
  Password: True
  Keytab: False
  Managed by:
client$ ipa hostgroup-add-member ipaservers
  Host-group: ipaservers
  Description: IPA server hosts
  Member hosts:,
Number of members added 1

Example workflow (cont)

  • On the replica machine:

replica# ipa-replica-install --password 'ImgXN_VxNC,B'
Configuring client side components
Client hostname:
DNS Domain:
IPA Server:
Enrolled in IPA realm EXAMPLE.COM
Created /etc/ipa/default.conf
  Configuring directory server (dirsrv). Estimated time: 1 minute
  [28/43]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 6 seconds elapsed
Update succeeded
  [29/43]: adding sasl mappings to the directory
  [2/2]: configuring ipa-otpd to start on boot
Done configuring ipa-otpd.

Replica promotion of IPA-enrolled client

  • Check /etc/ipa/default.conf points to the master.
    server =
    xmlrpc_uri =
  • After replica promotion, it gets updated to point to itself.
    xmlrpc_uri =
  • Domain level at least 1 (important for upgrades).
    ipa1# ipa domainlevel-get
    Current domain level: 1

Topology information

  • Topology info is now replicated across all replicas.
ipa1$ ipa topologysegment-find domain
3 segments matched
  Segment name:
  Left node:
  Right node:
  Connectivity: both

  Segment name:
  Left node:
  Right node:
  Connectivity: both

  Segment name:
  Left node:
  Right node:
  Connectivity: both
Number of entries returned 3

Topology graph

Managing topology

  • Segment is added by creating it in directory server.
ipa1$ ipa topologysegment-add domain \
Added segment ""
  Segment name:
  Left node:
  Right node:
  Connectivity: both
  • Via command-line or WebUI.
  • Information gets replicated to the target nodes.
  • New replication agreement is established.
  • The ca suffix is used for the certification authority.
  • Can only add segment between nodes that already have the role installed and configured.

DNS-based locations

  • With easy way to set up replicas and segments, complex network topologies are possible.
  • Clients should be able to seamlessly fail over.
  • With DNS SRV records, no need to hardcode a particular FreeIPA server on clients.
  • But different clients need different servers resolved, for cheapest operation.
  • Traditionally, mix of hardcoded and SRV was used:
    ipa_server =, _srv_
    • Problem: configuration on every client.
  • New DNS-based location feature allows grouping of FreeIPA servers and managing their priorities.

DNS-based locations operation

  • FreeIPA server with embedded DNS server running in every location.
  • Clients are configured to use that DNS server.
    • E.g. via DHCP in given subnet — handled outside of FreeIPA.
    • Can also resolve through that DNS server recursively.
  • Locations defined, FreeIPA servers assigned to them.
  • The DNS servers in each location will autogenerate SRV records as CNAMEs to given location.

Location definition

$ ipa location-show emea
  Location name: emea
  Advertised by servers:,
  Servers details:
    Server name:
    Service weight: 10
    Service relative weight: 25.0%
    Enabled server roles: CA server, DNS server, NTP server
    Server name:
    Service weight: 30
    Service relative weight: 75.0%
    Enabled server roles: DNS server, NTP server
$ ipa location-show us
  Location name: us
  Advertised by servers:
  Servers details:
    Server name:
    Service weight: 10
    Service relative weight: 100.0%
    Enabled server roles: CA server, DNS server, NTP server

Location resolution

$ dig +short SRV
0 10 88
0 30 88
50 10 88
$ dig +short SRV
50 10 88
0 10 88
50 30 88
  • Only SRV configuration is needed on clients.
    ipa_server = _srv_
  • Works for any service which can resolve SRV, not just SSSD.
  • No more hardcoding server names on clients.
  • Ideal for roaming clients (laptops).


  • Replicas can be created in more automated manner.
  • No admin password needed on the replica machine.
  • No manual action needed on the master.
  • Replication topology information is now replicated.
  • It is possible to manage segments without having direct network connection to the nodes.
  • Partitioning servers to locations removes need for hardcoding server names on clients for priority purposes.