Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide

(1)

Ella Deon Ballard Tomáš Čapek Aneta Petrová

Red Hat Enterprise Linux 7 Linux Domain Identity,

Authentication, and Policy Guide

Managing Identity and Authorization Policies for Linux-Based

Infrastructures

(2)

(3)

Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide

Managing Identity and Authorization Policies for Linux-Based Infrastructures

Ella Deon Ballard

Red Hat Customer Content Services dlackey@redhat.com

Tomáš Čapek

Red Hat Customer Content Services tcapek@redhat.com

Aneta Petrová

Red Hat Customer Content Services apetrova@redhat.com

(4)

This document is licensed by Red Hat under the Creative Commons Attribution-

ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Keywords

1. FreeIPA. 2. Identity Management. 3. IdM. 4. IPA.

Abstract

Identity and policy management, for both users and machines, is a core function for most enterprise environments. Identity Management provides a way to create an identity domain that allows machines to enroll to a domain and immediately access identity information required for single sign-on and authentication services, as well as policy settings that govern authorization and access.

(5)

. . . .

. . . . . . . .

. . . .

. . . . . . . .

. . . .

Chapter 1. Introduction to Identity Management

Re d Hat Ente rpris e Linux IdM is a way to cre ate ide ntity s tore s , ce ntralize d authe ntication, domain control for Ke rbe ros and DNS s e rvice s , and authorization policie s — all on Linux s ys te ms , us ing native Linux tools . While ce ntralize d ide ntity/policy/authorization s oftware is hardly ne w, Ide ntity Manage me nt is one of the only options that s upports Linux/Unix domains .

Ide ntity Manage me nt provide s a unifying s kin for s tandards -de fine d, common ne twork s e rvice s , including PAM, LDAP, Ke rbe ros , DNS, NTP, and ce rtificate s e rvice s , and it allows Re d Hat Ente rpris e Linux s ys te ms to s e rve as the domain controlle rs .

Ide ntity Manage me nt de fine s a domain, with s e rve rs and clie nts that s hare ce ntrally- manage d s e rvice s , like Ke rbe ros and DNS. This chapte r firs t e xplains what

Ide ntity Manage me nt is . This chapte r als o cove rs how all of the s e s e rvice s work toge the r within the domain and how s e rve rs and clie nts inte ract with e ach othe r.

1.1. IdM v. LDAP: A More Focused T ype of Service

At the mos t bas ic le ve l, Re d Hat Ide ntity Manage me nt is a domain controlle r for Linux and Unix machine s . Ide ntity Manage me nt de fine s the domain, us ing controlling s e rve rs and e nrolle d clie nt machine s . This provide s ce ntralize d s tructure that has pre vious ly be e n unavailable to Linux/Unix e nvironme nts , and it doe s it us ing native Linux applications and protocols .

1.1.1. Defining a T rue Linux Domain

Se curity information fre que ntly re late s to identities of us e rs , machine s , and s e rvice s . Once the ide ntity is ve rifie d, the n acce s s to s e rvice s and re s ource s can be controlle d.

For e fficie ncy, ris k manage me nt, and e as e of adminis tration, IT adminis trators try to manage ide ntitie s as ce ntrally as pos s ible and to unite ide ntity manage me nt with

authe ntication and authorization policie s . His torically, Linux e nvironme nts have had a ve ry difficult time e s tablis hing this ce ntralize d manage me nt. The re are a numbe r of diffe re nt protocols (s uch as NIS and Ke rbe ros ) which de fine domains , while othe r applications s tore data (s uch as LDAP) and s till othe rs manage acce s s (s uch as s udo). None of the s e

applications talk to e ach othe r or us e the s ame manage me nt tools . Eve ry application had to be adminis te re d s e parate ly and it had to be manage d locally. The only way to ge t a cons is te nt ide ntity policy was to copy configuration file s around manually or to try to de ve lop a proprie tary application to manage ide ntitie s and policie s .

The goal of Ide ntity Manage me nt is to s implify that adminis trative ove rhe ad. Us e rs , machine s , s e rvice s , and police s are all configure d in one place , us ing the s ame tools . Be caus e IdM cre ate s a domain, multiple machine s can all us e the s ame configuration and the s ame re s ource s s imply by joining the domain. Us e rs only have to s ign into s e rvice s once , and adminis trators only have to manage a s ingle us e r account.

IdM doe s thre e things :

Cre ate a Linux-bas e d and Linux-controlle d domain. Both IdM s e rve rs and IdM clie nts are Linux or Unix machine s . While IdM can s ynchronize data with an Active Dire ctory domain to allow inte gration with Windows s e rve rs , it is not an adminis trative tool for Windows machine s and it doe s not s upport Windows clie nts . Ide ntity Manage me nt is a

manage me nt tool for Linux domains .

Ce ntralize ide ntity manage me nt and ide ntity policie s .

(10)

Build on e xis ting, native Linux applications and protocols . While IdM has its own proce s s e s and configuration, its unde rlying te chnologie s are familiar and trus te d by Linux adminis trators and are we ll e s tablis he d on Linux s ys te ms .

IdM s e rve s as a bridge be twe e n Linux and the IdM world. IdM, whe n us e d in conce rt with Cros s -Re alm Ke rbe ros Authe ntication, make s it pos s ible for both IdM and Linux to

coope rate in te rms of ide ntity, authe ntication and authorization. IdM and Ke rbe ros are e ach able to us e the ir own native clie nts .

In a s e ns e , Ide ntity Manage me nt is n't making adminis trators do s ome thing ne w; it is he lping the m do it be tte r. The re are a fe w ways to illus trate that.

On one e xtre me is the low control e nvironme nt. Little Example Corp. has s e ve ral Linux and Unix s e rve rs , but e ach one is adminis te re d s e parate ly. All pas s words are ke pt on the local machine , s o the re is no ce ntral ide ntity or authe ntication proce s s . Tim the IT Guy jus t has to manage us e rs on e ve ry machine , s e t authe ntication and authorization policie s s e parate ly, and maintain local pas s words . With IdM, things come to orde r. The re is a s imple way to have ce ntral us e r, pas s word, and policy s tore s , s o Tim the IT Guy only has to maintain the ide ntitie s on one machine (the IdM s e rve r) and us e rs and policie s are uniformly applie d to all machine s . Us ing hos t-bas e d acce s s control, de le gation, and othe r rule s , he can e ve n s e t diffe re nt acce s s le ve ls for laptops and re mote us e rs .

In the middle is the medium control e nvironme nt. Mid-Example Corp. has s e ve ral Linux and Unix s e rve rs , but Bill the IT Guy has trie d to maintain a gre ate r de gre e of control by

cre ating a NIS domain for machine s , an LDAP dire ctory for us e rs , and Ke rbe ros for authe ntication. While his e nvironme nt is we ll unde r control, e ve ry application has to be maintaine d s e parate ly, us ing diffe re nt tools . He als o has to update all of the s e rvice s manually whe ne ve r a ne w machine is adde d to his infras tructure or whe n one is take n offline . In this s ituation, IdM gre atly re duce s his adminis trative ove rhe ad be caus e it inte grate s all of the diffe re nt applications toge the r s e amle s s ly, us ing a s ingle and

s implifie d tool s e t. It als o make s it pos s ible for him to imple me nt s ingle s ign-on s e rvice s for all of the machine s in his domain.

On the othe r e xtre me is the absent control e nvironme nt. At Big Example Corp., mos t of the s ys te ms are Windows bas e d and are manage d in a tightly-knit Active Dire ctory fore s t.

Howe ve r, de ve lopme nt, production, and othe r te ams have many Linux and Unix s ys te ms

— which are bas ically e xclude d from the Windows controlle d e nvironme nt. IdM brings native control to the Linux/Unix s e rve rs , us ing the ir native tools and applications — s ome thing that is not pos s ible in an Active Dire ctory fore s t. Additionally, be caus e IdM is Windows -aware , data can be s ynchronize d be twe e n Active Dire ctory and IdM, pre s e rving a ce ntralize d us e r s tore .

IdM provide s a ve ry s imple s olution to a ve ry common, ve ry s pe cific proble m: ide ntity manage me nt.

1.1.2. Cont rast ing Ident it y Management wit h a St andard LDAP Direct ory

The clos e s t re lative to Ide ntity Manage me nt is a s tandard LDAP dire ctory like

389 Dire ctory Se rve r, but the re are s ome intrins ic diffe re nce s be twe e n what the y do and what the y're intended to do.

Firs t, it he lps to unde rs tand what a dire ctory s e rvice is . A dire ctory s e rvice is a colle ction of s oftware , hardware , and proce s s e s that s tore s information. While dire ctory s e rvice s can be highly s pe cific (for e xample , DNS is a dire ctory s e rvice be caus e it s tore s

information on hos tname s ), a ge ne ric dire ctory s e rvice can s tore and re trie ve any kind of information. LDAP dire ctorie s like 389 Dire ctory Se rve r are ge ne ric dire ctorie s . The y have

(11)

a fle xible s che ma that s upports e ntrie s for us e rs , machine s , ne twork e ntitie s , phys ical e quipme nt, and buildings , and that s che ma can be cus tomize d to de fine e ntrie s of almos t anything. Be caus e of its e xte ns ibility, LDAP s e rve rs like 389 Dire ctory Se rve r are

fre que ntly us e d as backe nds that s tore data for othe r applications . 389 Dire ctory Se rve r not only contains information, it organize s information. LDAP dire ctorie s us e a hie rarchical s tructure , a directory tree, that organize e ntrie s into root e ntrie s (s uffixe s ), inte rme diate or containe r e ntrie s (s ubtre e s or branche s ), and le af e ntrie s (the actual data). Dire ctory tre e s can be ve ry comple x, with a lot of branch points , or ve ry s imple (flat) with fe w branch points .

The primary fe ature of an LDAP dire ctory is its ge ne rality. It can be made to fit into a varie ty of applications .

Ide ntity Manage me nt, on the othe r hand, has a ve ry s pe cific purpos e and fits a ve ry s pe cific application. It is not a ge ne ral LDAP dire ctory, it is not a backe nd, and it is not a ge ne ral policy s e rve r. It is not ge ne ric.

Ide ntity Manage me nt focus e s on ide ntitie s (us e r and machine ) and policie s that re late to thos e ide ntitie s and the ir inte ractions . While it us e s an LDAP backe nd to s tore its data, IdM has a highly-cus tomize d and s pe cific s e t of s che ma that de fine s a particular s e t of

ide ntity-re late d e ntrie s and de fine s the m in de tail. It has a re lative ly flat and s imple dire ctory tre e be caus e it has only a handful of e ntry type s and re lations hips that are

re le vant to its purpos e . It has rule s and limitations on how the IdM s e rve r can be de ploye d be caus e it can only be de ploye d for a s pe cific purpos e : managing ide ntitie s .

The re s trictions on IdM als o give it a gre at de al of adminis trative s implicity. It has a s imple ins tallation proce s s , a unifie d s e t of commands , and a cle arly de fine d role in the ove rall IT infras tructure . An IdM domain is e as y to configure , e as y to join, and e as y to manage , and the functions that it s e rve s — particularly ide ntity/authe ntication tas ks like e nte rpris e -wide s ingle s ign-on — are als o e as ie r to do with IdM than with a more ge ne ral-purpos e

dire ctory s e rvice .

T able 1.1. Ident it y Management Co mpared t o 389 Direct o ry Server

389 Direct o ry Server Ident it y Management

Us e Ge ne ral purpos e Single domain, focus e d on

ide ntity manage me nt

Fle xibility Highly-cus tomizable Limitations to focus on

ide ntity and authe ntication

Sche ma De fault LDAP s che ma Optimize d, s pe cial s che ma

for ide ntity manage me nt Dire ctory Tre e Standard and fle xible

hie rarchy

Flat tre e with a fixe d hie rarchy

Authe ntication LDAP Ke rbe ros or Ke rbe ros and

LDAP Active Dire ctory

Synchronization

Bi-dire ctional Unidire ctional,

Active Dire ctory to Ide ntity Manage me nt

Pas s word Policie s LDAP-bas e d Ke rbe ros -bas e d

Us e r Tools Java Cons ole and s tandard

LDAP utilitie s

We b-bas e d UI and s pe cial Python command-line tools LDAP dire ctorie s like 389 Dire ctory Se rve r have fle xibility and adaptability which make s the m a pe rfe ct backe nd to any numbe r of applications . Its primary purpos e is to s tore and re trie ve data e fficie ntly.

(12)

IdM fills a ve ry diffe re nt niche . It is optimize d to pe rform a s ingle tas k ve ry e ffe ctive ly. It s tore s us e r information and authe ntication and authorization policie s , as we ll as othe r information re late d to acce s s , like hos t information. Its s ingle purpos e is to manage ide ntitie s .

1.2. Bringing Linux Services T oget her

Ide ntity Manage me nt unifie s dis parate ye t re late d Linux s e rvice s into a s ingle

manage me nt e nvironme nt. From the re , it e s tablis he s a s imple , e as y way to bring hos t machine s into the domain of thos e s e rvice s .

An IdM s e rve r is , at its core , an ide ntity and authe ntication s e rve r. The primary IdM s e rve r, e s s e ntially a domain controlle r, us e s a Ke rbe ros s e rve r and KDC for

authe ntication. An LDAP backe nd contains all of the domain information, including us e rs , clie nt machine s , and domain configuration.

Figure 1.1. T he IdM Server: Unif ying Services

Othe r s e rvice s are include d to provide s upport for the core ide ntity/authe ntication functions . DNS is us e d for machine dis cove ry and for conne cting to othe r clie nts in the domain. NTP is us e d to s ynchronize all domain clocks s o that logging, ce rtificate s , and ope rations can occur as e xpe cte d. A ce rtificate s e rvice provide s ce rtificate s for Ke rbe ros - aware s e rvice s . All of the s e additional s e rvice s work toge the r unde r the control of the IdM s e rve r.

(13)

The IdM s e rve r als o has a s e t of tools which are us e d to manage all of the IdM-as s ociate d s e rvice s . Rathe r than managing the LDAP s e rve r, KDC, or DNS s e ttings individually, us ing diffe re nt tools on local machine s , IdM has a s ingle manage me nt tools e t (CLI and we b UI) that allows ce ntralize d and cohe s ive adminis tration of the domain.

1.2.1. Aut hent icat ion: Kerberos KDC

Ke rbe ros is an authe ntication protocol. Ke rbe ros us e s s ymme tric ke y cryptography to ge ne rate tickets to us e rs . Ke rbe ros -aware s e rvice s che ck the ticke t cache (a keytab) and authe nticate us e rs with valid ticke ts .

Ke rbe ros authe ntication is s ignificantly s afe r than normal pas s word-bas e d authe ntication be caus e pas s words are ne ve r s e nt ove r the ne twork — e ve n whe n s e rvice s are

acce s s e d on othe r machine s .

In Ide ntity Manage me nt, the Ke rbe ros adminis tration s e rve r is s e t up on the IdM domain controlle r, and all of the Ke rbe ros data are s tore d in IdM's backe nd Dire ctory Se rve r. The Dire ctory Se rve r ins tance de fine s and e nforce s acce s s controls for the Ke rbe ros data.

NOTE

The IdM Ke rbe ros s e rve r is manage d through IdM tools ins te ad of Ke rbe ros tools be caus e all of its data are s tore d in the Dire ctory Se rve r ins tance . The KDC is

unaware of the Dire ctory Se rve r, s o managing the KDC with Ke rbe ros tools doe s not affe ct the IdM configuration.

1.2.2. Dat a St orage: 389 Direct ory Server

Ide ntity Manage me nt contains an inte rnal 389 Dire ctory Se rve r ins tance . All of the

Ke rbe ros information, us e r accounts , groups , s e rvice s , policy information, DNS zone and hos t e ntrie s , and all othe r information in IdM is s tore d in this 389 Dire ctory Se rve r

ins tance .

Whe n multiple s e rve rs are configure d, the y can talk to e ach othe r be caus e

389 Dire ctory Se rve r s upports multi-master replication. Agre e me nts are automatically configure d be twe e n the initial s e rve r and any additional replicas which are adde d to the domain.

1.2.3. Aut hent icat ion: Dogt ag Cert ificat e Syst em

Ke rbe ros can us e ce rtificate s along with ke ytabs for authe ntication, and s ome s e rvice s re quire ce rtificate s for s e cure communication. Ide ntity Manage me nt include s a ce rtificate authority, through Dogtag Ce rtificate Sys te m, with the s e rve r. This CA is s ue s ce rtificate s to the s e rve r, re plicas , and hos ts and s e rvice s within the IdM domain.

The CA can be a root CA or it can have its policie s de fine d by anothe r, e xte rnal CA (s o that it is subordinate to that CA). Whe the r the CA is a root or s ubordinate CA is de te rmine d whe n the IdM s e rve r is s e t up.

(14)

Note

In Re d Hat Ente rpris e Linux 7.0 and highe r, CA is optional. Cus tome rs can ins tall "CA- le s s " IdM with only s igne d ce rtificate s . In s uch ins tallations , CA manage me nt is

unne ce s s ary.

1.2.4. Server/Client Discovery: DNS

Ide ntity Manage me nt de fine s a domain — multiple machine s with diffe re nt us e rs and s e rvice s , e ach acce s s ing s hare d re s ource s and us ing s hare d ide ntity, authe ntication, and policy configuration. The clie nts mus t be able to contact the s e rve rs . Additionally, s e rvice s like Ke rbe ros de pe nd on hos tname s to ide ntify the ir principal ide ntitie s .

Hos tname s are as s ociate d with IP addre s s e s us ing the Domain Name Service (DNS). DNS maps hos tname s to IP addre s s e s and IP addre s s e s to hos tname s , providing a re s ource that clie nts can us e whe n the y ne e d to look up a hos t. From the time a clie nt is e nrolle d in the IdM domain, it us e s DNS s e rvice dis cove ry to locate IdM s e rve rs within the domain and the n all of the s e rvice s and clie nts within the domain.

The clie nt ins tallation tool automatically configure s the local Sys te m Se curity Se rvice s Dae mon (SSSD) to us e the IdM domain for s e rvice dis cove ry. SSSD us e s DNS alre ady to look for LDAP/TCP and Ke rbe ros / UDP s e rvice s ; the clie nt ins tallation only ne e ds to s upply the domain name . SSSD s e rvice dis cove ry is cove re d in the SSSD chapte r in the Sys te m- Le ve l Authe ntication Guide.

On the s e rve r, the ins tallation s cript configure s the DNS file to s e t which s e rvice s the DNS s e rvice dis cove ry que rie s . By de fault, DNS dis cove ry que rie s the LDAP s e rvice on TCP and diffe re nt Ke rbe ros s e rvice s on both UDP and TCP. The DNS file which is cre ate d is de s cribe d in Se ction 15.2, “Us ing IdM and DNS Se rvice Dis cove ry with an Exis ting DNS Configuration”.

NOTE

While it is te chnically pos s ible to configure the IdM domain to us e DNS s e rvice dis cove ry without having an IdM s e rve r hos t the DNS s e rvice s , this is not re comme nde d.

Multiple DNS s e rve rs are us ually configure d, e ach one working as an authoritative re s ource for machine s within a s pe cific domain. Having the IdM s e rve r als o be a DNS s e rve r is optional, but it is s trongly re comme nde d. Whe n the IdM s e rve r als o manage s DNS, the re is tight inte gration be twe e n the DNS zone s and the IdM clie nts and the DNS configuration can be manage d us ing native IdM tools . Eve n if an IdM s e rve r is a DNS s e rve r, othe r e xte rnal DNS s e rve rs can s till be us e d.

1.2.5. Management : SSSD

The Sys te m Se curity Se rvice s Dae mon (SSSD) is a platform application which cache s cre de ntials . Mos t s ys te m authe ntication is configure d locally, which me ans that s e rvice s mus t che ck with a local us e r s tore to de te rmine us e rs and cre de ntials . What SSSD doe s is allow a local s e rvice to che ck with a local cache in SSSD, but that cache may be take n from any varie ty of re mote ide ntity provide rs — including Ide ntity Manage me nt.

(15)

SSSD can cache us e rname s and pas s words , Ke rbe ros principals and ke ytabs , automount maps , s udo rule s that are de fine d on IPA s e rve rs , and SSH ke ys which are us e d by Ide ntity Manage me nt domain us e rs and s ys te ms . This allows two s ignificant be ne fits to adminis trators : firs t, all ide ntity configuration can be ce ntralize d in a s ingle application (the IdM s e rve r), and s e cond, that e xte rnal information is able to be cache d on a local s ys te m to e ns ure continuous authe ntication ope rations in the e ve nt that the s ys te m or the IdM s e rve r goe s offline .

SSSD is automatically configure d by IdM clie nt ins tallation and manage me nt s cripts , s o the s ys te m configuration ne ve r ne e ds to be manually update d, e ve n as domain configuration change s .

1.2.6. Management : NT P

Many s e rvice s re quire that s e rve rs and clie nts have the s ame s ys te m time , within a ce rtain variance . For e xample , Ke rbe ros ticke ts us e time s tamps to de te rmine the ir validity. If the time s be twe e n the s e rve r and clie nt s ke w outs ide the allowe d range , the n any Ke rbe ros ticke ts are invalidate d.

Clocks are s ynchronize d ove r a ne twork us ing Network Time Protocol (NTP). A ce ntral s e rve r acts as an authoritative clock and all of the clie nts which re fe re nce that NTP s e rve r s ync the ir time s to match.

Whe n the IdM s e rve r is the NTP s e rve r for the domain, all time s and date s are

s ynchronize d be fore any othe r ope rations are pe rforme d. This allows all of the date - re late d s e rvice s — including pas s word e xpirations , ticke t and ce rtificate e xpirations , account lockout s e ttings , and e ntry cre ation date s — to function as e xpe cte d.

The IdM s e rve r, by de fault, works as the NTP s e rve r for the domain. Othe r NTP s e rve rs can als o be us e d for the hos ts .

1.3. Relat ionships Bet ween Servers and Client s

Ide ntity Manage me nt its e lf de fine s a domain, a group of machine s that have s hare d configuration, policie s , and ide ntity s tore s . This s hare d configuration allows the machine s (and us e rs ) within the domain to be aware of e ach othe r and ope rate toge the r. This aware ne s s can be us e d to e nable cros s -platform compatibility, like unifying Windows and Linux s ys te ms , or to e nable infras tructure -wide s ingle s ign-on.

1.3.1. About IdM Servers and Replicas

Ide ntity Manage me nt works by having ide ntifie d s e rve rs which are the mas te r s tore s of information for us e r and machine ide ntitie s and domain-wide policie s . The s e s e rve rs hos t domain-re late d s e rvice s s uch as ce rtificate authoritie s , NTP, Ke rbe ros , SSH, and DNS. The s e rve r als o acts as a ce ntral re pos itory of ide ntity and policy information.

Clie nts inte ract indire ctly with IdM s e rve rs whe n the y atte mpt to acce s s domain re s ource s , s uch as file s hare s , s e rvice s , re mote machine s , or authe ntication (through SSSD and Ke rbe ros ).

As s aid, an IdM s e rve r is a controlle r for a lot of as s ociate d s e rvice s . While a numbe r of thos e s e rvice s are supported, mos t of the m are not required. For e xample , a s e rve r may have a CA, a DNS s e rve r, or an NTP s e rve r — or it can be ins talle d without thos e

s e rvice s .

(16)

Once an IdM s e rve r is s e t up, its configuration can be copie d and us e d as the bas is for anothe r IdM s e rve r. Whe n an IdM s e rve r is copie d, that copy is calle d a replica.

NOTE

The re are s ome diffe re nce s be twe e n IdM s e rve rs and IdM re plicas . A s e rve r is a ne w ins tallation — and that me ans that it de fine s the domain configuration. A re plica is bas e d on an e xis ting s e rve r and an e xis ting domain configuration. In ve rs ions of Re d Hat Ente rpris e Linux prior to 7.1, only one s e rve r in the IPA domain ge ne rate s the CRL and re ne ws the PKI s ubs ys te m ce rtificate s .

Once an ins tance is configure d, s e rve rs and re plicas are bas ically ide ntical in functionality and be havior within the IdM domain.

The re is a good de al of fle xibility in the IdM s e rve r (and re plica) topology. For e xample , Se rve r A can be ins talle d with a CA and DNS s e rvice s , while Re plica A can be bas e d on Se rve r A's configuration but not hos t e ithe r DNS or CA s e rvice s . Re plica B can be adde d to the domain, als o without CA or DNS s e rvice s . At any time in the future , a CA or DNS

s e rvice can be cre ate d and configure d on Re plica A or Re plica B.

Se rve rs and re plicas both us e unde rlying LDAP dire ctorie s to s tore us e r and hos t e ntrie s , configuration data, policy configuration, and ke ytabs , ce rtificate s , and ke ys . Se rve rs and re plicas propagate data among e ach othe r through multi-master replication agreements.

Re plication agre e me nts are configure d for all LDAP backe nds as we ll as the LDAP s ubtre e s us e d by Dogtag Ce rtificate Sys te m. Both s e rve rs and re plicas are mas te rs (pe e rs ) in the re plication topology.

Be caus e the s e rve rs within the IdM domain are all LDAP pe e r s e rve rs , the re plication topology mus t conform to the topology limits of a 389 Dire ctory Se rve r domain. Planning the s e rve r/re plica topology is de s cribe d more in Se ction 4.1, “Planning the Se rve r/Re plica Topologie s ”.

(17)

Figure 1.2. Server and Replica Int eract io ns

TIP

The re plication topology e s s e ntially cre ate s a cloud of IdM s e rve rs . One be ne fit of a s e rve r domain is automatic load balancing, us ing the SRV re cords in DNS. The SRV re cord s e ts the priority orde r that s e rve rs and re plicas are contacte d, while we ight dis tribute s the load be twe e n s e rve rs /re plicas with the s ame priority. The s e rve r and re plica DNS e ntrie s can be e dite d to change the load balancing, which is

cove re d in Example 15.9, “SRV Re cord” and Se ction 25.4.3, “Changing Load Balancing for IdM Se rve rs and Re plicas ”.

1.3.2. About IdM Client s

A clie nt is s imply any machine which is configure d to ope rate within the IdM domain, us ing its Ke rbe ros and DNS s e rvice s , NTP s e ttings , and ce rtificate s e rvice s . That's an important dis tinction: a clie nt doe s not re quire a dae mon or (ne ce s s arily) an ins talle d product. It re quire s only s ys te m configurations which dire ct it to us e IdM s e rvice s .

For Re d Hat Ente rpris e Linux s ys te ms , a ce rtain numbe r of platform tools are available for IdM to us e , s uch as the Sys te m Se curity Se rvice s Dae mon (SSSD). IdM-e nable d platform applications are as pe cts of the unde rlying platform that work with IdM s e rvice s . Othe r tools , like ce rtain PAM and NSS module s and IdM command-line utilitie s , are provide d by Ide ntity Manage me nt its e lf as IdM-s pe cific package s that mus t be ins talle d on the machine . The s e are IdM compone nts , rathe r than platform compone nts us e d by

Ide ntity Manage me nt.

Figure 1.3. Server and Client Int eract io ns

IdM us e s the local s torage (cache ) on a clie nt to improve pe rformance in a fe w ways : Store IdM information whe n the machine is offline .

Ke e p information active be yond its normal time out pe riod if the clie nt cannot acce s s the ce ntral s e rve r. The cache is pe rs is te nt e ve n afte r re booting the machine .

(18)

Re duce the round-trip time of re que s ts by che cking information locally be fore looking at the s e rve r.

Information is s tore d e ithe r in an LDB databas e (s imilar to LDAP) or the local file s ys te m (as XML file s ), de pe nding on the type of information.

Ide ntity information (about us e rs , machine s , and groups ) is s tore d in the LDB databas e , which us e s the s ame s yntax as an LDAP dire ctory. This ide ntity information is originally s tore d in the IdM s e rve r's 389 Dire ctory Se rve r ins tance . Be caus e this information change s fre que ntly and is re fe re nce d fre que ntly, it is important to be able to call the more curre nt information quickly, which is pos s ible us ing an LDB databas e on the clie nt and the Dire ctory Se rve r on the s e rve r.

Policy information is more s tatic than ide ntity information, and it can include

configuration for SELinux or s udo. The s e policie s are s e t globally on the s e rve r and the n are propagate d to the clie nts . On the clie nt, the policy information is s tore d in the file s ys te m in XML file s which can be downloade d and conve rte d into a native file for whate ve r s e rvice is be ing manage d.

A s pe cific s e t of s e rvice s on the IdM s e rve r inte ract with a s ubs e t of s e rvice s and

module s on the IdM clie nt. A clie nt is any machine (a host) which can re trie ve a ke ytab or ce rtificate s from the IdM domain.

Figure 1.4. Int eract io ns Bet ween IdM Services

(19)

Figure 1.4, “Inte ractions Be twe e n IdM Se rvice s ” s hows that Re d Hat Ente rpris e Linux us e s two native dae mons to inte ract with the IdM s e rve r:

SSSD provide s the us e r authe ntication for the machine and e nforce s hos t-bas e d acce s s control rule s .

certmonger monitors and re ne ws the ce rtificate s on the clie nt. It can re que s t ne w ce rtificate s for the s e rvice s on the s ys te m, including virtual machine s .

Whe n a Re d Hat Ente rpris e Linux clie nt is adde d to the domain (enrolled), its SSSD and certmonger are configure d to conne ct to the IdM s e rve r and the re quire d Ke rbe ros ke ytab and hos t ce rtificate s are cre ate d. (The hos t ce rtificate is not us e d dire ctly by IdM; it may be us e d by othe r s e rvice s , s uch as a we b s e rve r.)

1.4. Addit ional Resources

In addition to this guide , you can find docume ntation on othe r fe ature s and s e rvice s re late d to Re d Hat Ente rpris e Linux Ide ntity Manage me nt in the following guide s :

System-Level Authentication Guide

The System-Level Authentication Guide docume nts diffe re nt applications and s e rvice s available to configure authe ntication on local s ys te ms , including the authconfig utility and the one -time pas s word (OTP) authe ntication, the SSSD s e rvice , the Pluggable Authe ntication Module (PAM) frame work, Ke rbe ros , the certmonger utility, and s ingle -s ign on (SSO) for applications .

Windows Integration Guide

The Windows Integration Guide docume nts how to inte grate Linux domains with Micros oft Windows Active Dire ctory (AD) us ing Ide ntity Manage me nt. Among othe r topics , the guide cove rs various as pe cts of dire ct and indire ct AD inte gration, the ID Vie ws fe ature , us ing SSSD to acce s s a Commong Inte rne t File Sys te m (CIFS), and the realmd s ys te m.

(20)

⁠Part I. Installing Identity Management Servers and

Services

(21)

Chapter 2. Prerequisites for Installation

Be fore you ins tall IdM, e ns ure that the ins tallation e nvironme nt is s uitably configure d. You als o ne e d to provide ce rtain information during the ins tallation and configuration

proce dure s , including re alm name s and ce rtain us e rname s and pas s words . This s e ction de s cribe s the information that you ne e d to provide .

2.1. Support ed Server Plat forms

IdM 4.1 is s upporte d on the s e platforms : Re d Hat Ente rpris e Linux 7 x86_64

2.2. Hardware Recommendat ions

A bas ic us e r e ntry is about 1 KB in s ize , as is a s imple hos t e ntry with a ce rtificate . The mos t important hardware fe ature to s ize prope rly is RAM. While all de ployme nts are diffe re nt, de pe nding on the numbe r of us e rs and groups and the type of data s tore d, the re is a rule of thumb to us e to he lp de te rmine how much RAM to us e :

For 10,000 us e rs and 100 groups , have at le as t 2GB of RAM and 1GB s wap s pace . For 100,000 us e rs and 50,000 groups , have at le as t 16GB of RAM and 4GB of s wap s pace .

TIP

For large r de ployme nts , it is more e ffe ctive to incre as e the RAM than to incre as e dis k s pace be caus e much of the data are s tore d in cache .

The unde rlying Dire ctory Se rve r ins tance us e d by the IdM s e rve r can be tune d to

incre as e pe rformance . For tuning information, s e e the Dire ctory Se rve r docume ntation at http://docs .re dhat.com/docs /e n-

US/Re d_Hat_Dire ctory_Se rve r/8.2/html/Pe rformance _Tuning_Guide /s ys te m-tuning.html.

2.3. Soft ware Requirement s

Mos t of the package s that an IdM s e rve r de pe nds on are ins talle d as de pe nde ncie s whe n the IdM package s are ins talle d. The re are s ome package s , howe ve r, which are re quire d be fore ins talling the IdM package s :

Ke rbe ros 1.10. This is ins talle d as a de pe nde ncy if it is not alre ady ins talle d.

The bind and bind-dyndb-ldap package s for DNS. Both package s mus t be e xplicitly ins talle d firs t or atte mpting to configure an IdM s e rve r with DNS s upport will fail.

(22)

Important

Due to CVE-2014-3566, the Se cure Socke t Laye r ve rs ion 3 (SSLv3) protocol ne e ds to be dis able d in the mod_nss module . You can e ns ure that by following the s e s te ps :

1. Edit the /etc/httpd/conf.d/nss.conf file and s e t the NSSProtocol parame te r to TLSv1.0 (for backward compatibility) and TLSv1.1.

NSSProtocol TLSv1.0,TLSv1.1 2. Re s tart the httpd s e rvice .

# service httpd restart

Note that Ide ntity Manage me nt in Re d Hat Ente rpris e Linux 7 automatically pe rforms the above s te ps whe n the yum update ipa-* command is launche d to upgrade the main package s .

2.4. Syst em Prerequisit es

The IdM s e rve r is s e t up us ing a configuration s cript, and this s cript make s ce rtain as s umption about the hos t s ys te m. If the s ys te m doe s not me e t the s e pre re quis ite s , the n s e rve r configuration may fail.

2.4.1. DNS Records

Prope r forward and re ve rs e DNS s e ttings are critical for both IdM s e rve rs and re plicas (copie s of s e rve rs ) to be configure d. DNS is us e d to e s tablis h conne ctions be twe e n re plicas . Se rve rs mus t the re fore be re s olvable in both forward and re ve rs e DNS configuration.

The DNS s e ttings for a hos t can be de te rmine d e as ily us ing the ip and dig commands . 1. Obtain the hos tname .

[root@server ~]# hostname server.example.com

2. Ge t the IP addre s s . In this e xample , the re turne d IP addre s s is 196.2.3.4.

[root@server !]# ip addr show eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff

inet 196.2.3.4/22 brd 10.16.79.255 scope global dynamic eth0 valid_lft 106694sec preferred_lft 106694sec

inet6 2620:52:0:104c:21a:4aff:fe10:4e33/64 scope site noprefixroute dynamic

valid_lft 2591904sec preferred_lft 604704sec

(23)

inet6 fed0:babe:baab:0:21a:4aff:fe10:4e33/6E scope site noprefixroute dynamic

valid_lft 86385sec preferred_lft 14385sec ...

3. Ve rify that forward DNS is prope rly configure d by us ing dig to que ry the hos tname and che ck what IP addre s s is re turne d. In this e xample , the e xpe cte d IP addre s s is 196.2.3.4.

[root@server ~]# dig server.example.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>>

server.example.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56680

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL:

12

;; QUESTION SECTION:

;server.example.com. IN A

;; ANSWER SECTION:

server.example.com. 2946 IN A 196.2.3.4

4. Ve rify the re ve rs e DNS configuration us ing dig with the -t ptr to que ry the PTR re cords (re ve rs e re cords ) for the addre s s . This is the IP addre s s in re ve rs e orde r, with .in-addr.arpa. appe nde d to the addre s s . This s hould re s olve to the

hos tname , server.example.com. in this e xample .

[root@server ~]# dig -t ptr 4.3.2.196.in-addr.arpa.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ptr 241.40.16.10.in-addr.arpa

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57899

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL:

10

;; QUESTION SECTION:

;4.3.2.196.in-addr.arpa. IN PTR

;; ANSWER SECTION:

4.3.2.196.in-addr.arpa. 21600 IN PTR server.example.com.

The DNS re cords s hould re s olve to whate ve r hos tname is us e d in the IdM ce rtificate s .

(24)

NOTE

If IdM is the DNS s e rve r, corre ct de le gation from the pare nt domain to the IdM s e rve rs mus t be prope rly s e t up. For ins tance , if the IdM domain is

ipa.example.com, it mus t be prope rly de le gate d from example.com. This follows the normal DNS rule s .

All s ys te ms within the domain mus t be configure d to us e the IdM-manage d DNS s e rve r.

2.4.2. Host name and IP Address Requirement s

Re gardle s s of whe the r the DNS is within the IdM s e rve r or e xte rnal, the s e rve r hos t mus t have DNS prope rly configure d:

The hos tname mus t be a fully-qualifie d domain name . For e xample , ipaserver.example.com.

IMPORTANT

This mus t be a valid DNS name . This me ans that only numbe rs , alphabe tic

characte rs , and hyphe ns (-) are allowe d. Any characte rs in the hos tname that are not in one of the s e cate gorie s will caus e DNS failure s .

The hos tname mus t be all lowe r-cas e .

The s e rve r's A re cord mus t be s e t and re s olve to its public IP addre s s .

The fully-qualifie d domain name cannot re s olve to the loopback addre s s . It mus t re s olve to the machine 's public IP addre s s , not to 127.0.0.1. The output of the hostname command cannot be localhost or localhost6.

The A and PTR re cords do not ne e d to match for the s e rve r.

The forward DNS re cord (A, AAAA) mus t match.

The s e rve r's hos tname and IP addre s s is in the /etc/hosts file . The fully-qualifie d domain name for the IdM s e rve r mus t be lis te d in the hosts file before any alias e s . ipa-server-inst all adds the re cord in this location automatically.

NOTE

A mis configure d file can pre ve nt the IdM command-line tools from functioning corre ctly and can pre ve nt the IdM we b inte rface from conne cting to the IdM s e rve r.

Additionally, the hos tname cannot be part of the localhos t e ntry.

For e xample , this lis ts the IPv4 and IPv6 localhos t e ntrie s for the hos t (prope rly), the n the IdM s e rve r IP addre s s and hos tname as the firs t e ntry.

(25)

127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 192.168.1.1 ipaserver.example.com ipaserver

It is re comme nde d that a s e parate DNS domain be allocate d for the IdM s e rve r to manage . While not re quire d (clie nts from othe r domains can s till be e nrolle d in the IdM domain), this is a conve nie nce for ove rall DNS manage me nt.

2.4.3. Direct ory Server

The re mus t not be any ins tance s of 389 Dire ctory Se rve r ins talle d on the hos t machine .

2.4.4. Syst em Files

The s e rve r s cript ove rwrite s s ys te m file s to s e t up the IdM domain. The s ys te m s hould be cle an, without cus tom configuration for s e rvice s like DNS and Ke rbe ros , be fore

configuring the IdM s e rve r.

Sys te m file s are backe d up to /var/lib/ipa/sysrestore/ during the ins tallation of s e rve rs and re plicas .

2.4.5. Syst em Port s

IdM us e s a numbe r of ports to communicate with its s e rvice s . The s e ports , lis te d in Table 2.1, “IdM Ports ”, mus t be ope n and available for IdM to work. The y cannot be in us e by anothe r s e rvice or blocke d by a fire wall. To make s ure that the s e ports are available , try nc, telnet, or nmap to conne ct to a port or run a port s can.

Ope ning ports re quire s the firewalld s e rvice to be running. To configure firewalld to s tart whe n the s ys te m boots :

[root@server ]# systemctl enable firewalld.service

To ope n a port in the public zone and make the change both pe rmane nt and runtime : 1. Run the firewall-cmd command with the --permanent option s pe cifie d.

[root@server ~]# firewall-cmd --permanent --zone=public --add- port=389/tcp

2. Change s made with firewall-cmd --permanent are not e ffe ctive imme diate ly. To e ns ure that the change s take place imme diate ly, run firewall-cmd again, this time without --permanent.

[root@server ~]# firewall-cmd --zone=public --add-port=389/tcp If you adde d multiple ports , it is s imple r to make the change s take place

imme diate ly by running the firewall-cmd --reload command, which make s the curre nt pe rmane nt configuration be come ne w runtime configuration.

[root@server ~]# firewall-cmd --reload

(26)

To ope n all the IdM re quire d ports in the public zone and make the change both pe rmane nt and runtime :

1. Run the firewall-cmd command with the --permanent option s pe cifie d.

[root@server ~]# firewall-cmd --permanent --zone=public --add- port=

{80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,464/tcp,53/tcp,88/udp,464/u dp,53/udp,123/udp}

2. Re load the fire wall-cmd configuration to e ns ure that the change take s place imme diate ly.

[root@server ~]# firewall-cmd --reload

The fire wall-cmd(1) man page has more information on ope ning and clos ing ports on a s ys te m.

Note

Do not be conce rne d that IdM us e s port 389. Us ing it is s afe be caus e all communication with IdM is e ncrypte d with GSSAPI.

T able 2.1. IdM Po rt s

Service Po rt s T ype

HTTP/HTTPS 80, 443 TCP

LDAP/LDAPS 389, 636 TCP

Ke rbe ros 88, 464 TCP and UDP

DNS 53 TCP and UDP

NTP 123 UDP

In addition, IdM can lis te n on port 8080 and in s ome ins tallations als o on ports 8443 and 749. Howe ve r, the s e thre e ports are only us e d inte rnally: e ve n though IdM ke e ps the m ope n, the y are not re quire d to be acce s s ible from outs ide . It is re comme nde d that you do not ope n ports 8080, 8443, and 749 us ing firewalld and ins te ad le ave the m blocke d by a fire wall.

2.4.6. NT P

Ne twork time protocol (NTP) s ynchronize s time be twe e n s ys te ms on a ne twork. An NTP s e rve r ce ntralize s and manage s that clock s ynchronization. By de fault,

Ide ntity Manage me nt ins talls and configure s an NTP s e rve r which is us e d by the domain to s ynchronize clocks for othe r Ide ntity Manage me nt s e rve rs , re plicas , and s ys te ms and s e rvice s within the IdM domain.

An NTP s e rve r mus t be running in orde r for s ome domain tas ks to function prope rly.

The s e domain tas ks include data re plication be twe e n s e rve rs and re plicas in the topology.

Ke rbe ros authe ntication doe s not work without pre cis e time ke e ping, e ithe r for s e rve r-to- s e rve r authe ntication or for the initiation of re plication. T he IdM server do es no t have t o ho st t he NT P server, but it is st ro ngly reco mmended. T his is t he def ault co nf igurat io n.

(27)

If a s e rve r is be ing ins talle d on a virtual machine , that s e rve r should not run an NTP

s e rve r. To dis able NTP for IdM, us e the --no-ntp option whe n the IdM s e rve r is configure d to pre ve nt an NTP s e rve r from be ing ins talle d.

2.4.7. NSCD

It is strongly recommended that you avoid or re s trict the us e of nscd in an IdM de ployme nt.

The nscd s e rvice is e xtre me ly us e ful for re ducing the load on the s e rve r, and for making clie nts more re s pons ive , but the re can be proble ms whe n a s ys te m is als o us ing SSSD, which pe rforms its own caching.

nscd cache s authe ntication and ide ntity information for all s e rvice s that pe rform que rie s through ns s witch, including getent. Be caus e nscd pe rforms both pos itive and ne gative caching, if a re que s t de te rmine s that a s pe cific IdM us e r doe s not e xis t, it cache s this as a ne gative re s pons e . Value s s tore d in the cache re main until the cache e xpire s , re gardle s s of any change s that may occur on the s e rve r. The re s ults of s uch caching is that ne w us e rs and me mbe rs hips may not be vis ible , and us e rs and me mbe rs hips that have be e n re move d may s till be vis ible .

To avoid clas he s with SSSD cache s and to pre ve nt locking out us e rs , avoid us ing nscd altoge the r. Alte rnative ly, us e a s horte r cache time by re s e tting the time -to-live caching value s in the /etc/nscd.conf file :

positive-time-to-live group 3600 negative-time-to-live group 60 positive-time-to-live hosts 3600 negative-time-to-live hosts 20

(28)

Chapter 3. Installing an IdM Server

The IdM domain is de fine d and manage d by an IdM server which is e s s e ntially a domain controlle r. The re can be multiple domain controlle rs within a domain for load-balancing and failove r tole rance . The s e additional s e rve rs are calle d replicas of the mas te r IdM s e rve r.

Both IdM s e rve rs and re plicas only run on Re d Hat Ente rpris e Linux s ys te ms . For both s e rve rs and re plicas , the ne ce s s ary package s mus t be ins talle d and the n the IdM s e rve r or re plica its e lf is configure d through s e tup s cripts , which configure all of the re quis ite s e rvice s .

3.1. Inst alling t he IdM Server Packages

Ins talling only the IdM s e rve r re quire s a s ingle package , ipa-server. If the IdM s e rve r will als o manage a DNS s e rve r, the n it re quire s two additional package s to s e t up the DNS.

All of the s e package s can be ins talle d us ing the yum command:

[root@server ~]# yum install ipa-server bind bind-dyndb-ldap

Ins talling the ipa-server als o ins talls a large numbe r of de pe nde ncie s , s uch as 389-ds- base for the LDAP s e rvice and krb5-server for the Ke rbe ros s e rvice , along with IdM tools . Afte r the package s are ins talle d, the s e rve r ins tance mus t be cre ate d us ing the ipa- server-install command. The options for configuring the ne w s e rve r ins tance are de s cribe d in Se ction 3.2, “About ipa-s e rve r-ins tall”.

3.2. About ipa-server-inst all

An IdM s e rve r ins tance is cre ate d by running the ipa-server-install s cript. This s cript can acce pt us e r-de fine d s e ttings for s e rvice s , like DNS and Ke rbe ros , that are us e d by the IdM ins tance , or it can s upply pre de fine d value s for minimal input from the

adminis trator.

The IdM s e tup s cript cre ate s a s e rve r ins tance , which include s configuring all of the re quire d s e rvice s for the IdM domain:

The ne twork time dae mon (ntpd) A 389 Dire ctory Se rve r ins tance

A Ke rbe ros ke y dis tribution ce nte r (KDC) Apache (httpd)

An update d SELinux targe te d policy The Active Dire ctory WinSync plug-in A ce rtificate authority

Optional. A domain name s e rvice (DNS) s e rve r

(29)

The IdM s e tup proce s s can be minimal, whe re the adminis trator only s upplie s s ome re quire d information, or it can be ve ry s pe cific, with us e r-de fine d s e ttings for many parts of the IdM s e rvice s . The configuration is pas s e d us ing argume nts with the ipa-server- install s cript.

NOTE

The port numbe rs and dire ctory locations us e d by IdM are all de fine d automatically, as de fine d in Se ction 2.4.5, “Sys te m Ports ” and Se ction 25.1, “Ide ntity Manage me nt File s and Logs ”. The s e ports and dire ctorie s cannot be change d or cus tomize d.

While ipa-server-install can be run without any options , s o that it prompts for the re quire d information, it has nume rous argume nts which allow the configuration proce s s to be e as ily s cripte d or to s upply additional information which is not re que s te d during an inte ractive ins tallation.

Table 3.1, “ipa-s e rve r-ins tall Options ” lis ts s ome common argume nts us e d with ipa- server-install. The full lis t of options are in the ipa-server-install manpage . The ipa-server-install options are ve rs atile e nough to be cus tomize d to the s pe cific de ployme nt e nvironme nt to ins tall and configure diffe re nt s e rvice s as ne e de d.

T able 3.1. ipa-server-inst all Opt io ns

Argument Descript io n

-a ipa_admin_password The pas s word for the IdM adminis trator.

This is us e d for the admin us e r to authe nticate to the Ke rbe ros re alm.

--hos tname =hostname The fully-qualifie d domain name of the IdM s e rve r machine .

IMPORTANT

This mus t be a valid DNS name , which me ans only numbe rs ,

alphabe tic characte rs , and hyphe ns (- ) are allowe d. Othe r characte rs , like unde rs core s , in the hos tname will caus e DNS failure s .

Additionally, the hos tname mus t be all lowe r-cas e . No capital le tte rs are allowe d.

-n domain_name The name of the LDAP s e rve r domain to

us e for the IdM domain. This is us ually bas e d on the IdM s e rve r's hos tname . -p directory_manager_password The pas s word for the s upe rus e r,

cn=Directory Manager, for the LDAP s e rvice .

(30)

-P kerberos_master_password The pas s word for the KDC adminis trator.

This is randomly ge ne rate d if no value is give n.

-r realm_name The name of the Ke rbe ros re alm to cre ate

for the IdM domain.

--s ubje ct=subject_DN Se ts the bas e e le me nt for the s ubje ct DN of the is s ue d ce rtificate s . This de faults to O=realm.

--forwarde r=forwarder Give s a DNS forwarde r to us e with the DNS s e rvice . To s pe cify more than one

forwarde r, us e this option multiple time s . --no-forwarde rs Us e s root s e rve rs with the DNS s e rvice

ins te ad of forwarde rs .

--no-re ve rs e Doe s not cre ate a re ve rs e DNS zone whe n

the DNS domain is s e t up. (If a re ve rs e DNS zone is alre ady configure d, the n that e xis ting re ve rs e DNS zone is us e d.) If this option is not us e d, the n the de fault value is true , which as s ume s that re ve rs e DNS s hould be configure d by the ins tallation s cript.

--s e tup-dns Te lls the ins tallation s cript to s e t up a DNS s e rvice within the IdM domain. Us ing an inte grate d DNS s e rvice is optional, s o if this option is not pas s e d with the

ins tallation s cript, the n no DNS is configure d.

--idmax=number Se ts the uppe r bound for IDs which can be

as s igne d by the IdM s e rve r. The de fault value is the ID s tart value plus 199999.

--ids tart=number Se ts the lowe r bound (s tarting value ) for IDs which can be as s igne d by the IdM s e rve r. The de fault value is randomly s e le cte d.

Argument Descript io n

The way that an IdM s e rve r is ins talle d can be diffe re nt de pe nding on the ne twork e nvironme nt, s e curity re quire me nts within the organization, and the de s ire d topology.

The s e e xample s illus trate s ome common options whe n ins talling the s e rve r. The s e e xample s are not mutually e xclus ive ; it is e ntire ly pos s ible to us e CA options , DNS

options , and IdM configuration options in the s ame s e rve r invocation. The s e are calle d out s e parate ly s imply to make it more cle ar what e ach configuration are a re quire s .

3.3. Example: Running t he Script Int eract ively and Silent ly

3.3.1. Basic Int eract ive Inst allat ion

All that is re quire d to s e t up an IdM s e rve r is to run the ipa-server-install s cript. This launche s the s cript inte ractive ly, which prompts for the re quire d information to s e t up a s e rve r, but without more advance d configuration like DNS and CA options .

1. Run the ipa-server-install s cript.

(31)

[root@server ~]# ipa-server-install

2. If DNS configuration is not s pe cifie d, the n the s cript prompts to configure inte grate d DNS s e rvice s . This e xample goe s with the de fault of no; ins talling DNS s e rvice s is de s cribe d in Se ction 3.5, “Example : Configuring DNS Se rvice s within the IdM

Domain”.

Do you want to configure integrated DNS (BIND)? [no]:

3. Ente r the hos tname . This is de te rmine d automatically us ing re ve rs e DNS.

Server host name [ipaserver.example.com]:

4. Ente r the domain name . This is de te rmine d automatically bas e d on the hos tname .

Please confirm the domain name [example.com]:

5. Ente r the ne w Ke rbe ros re alm name . This is us ually bas e d on the domain name .

Please provide a realm name [EXAMPLE.COM]:

6. Ente r the pas s word for the Dire ctory Se rve r s upe rus e r, cn=Directory Manager.

The re are pas s word s tre ngth re quire me nts for this pas s word, including a minimum pas s word le ngth (e ight characte rs ).

Directory Manager password:

Password (confirm):

7. Ente r the pas s word for the IdM s ys te m us e r account, admin. This us e r is cre ate d on the machine .

IPA admin password:

Password (confirm):

8. The s cript the n re prints the hos tname , IP addre s s , and domain name . Confirm that the information is corre ct.

The IPA Master Server will be configured with

Hostname: ipaserver.example.com

IP address: 192.168.1.1

Domain name: example.com

Realm name: EXAMPLE.COM

Continue to configure the system with these values? [no]: yes 9. Afte r that, the s cript configure s all of the as s ociate d s e rvice s for IdM, with tas k

counts and progre s s bars .

Configuring NTP daemon (ntpd)

[1/4]: stopping ntpd

...

Done configuring NTP daemon (ntpd).

Configuring directory server (dirsrv): Estimated time 1 minute

(32)

[1/38]: creating directory server user

....

Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds

[1/20]: creating certificate server user

...

Done configuring certificate server (pki-tomcatd).

Configuring Kerberos KDC (krb5kdc): Estimated time 30 seconds

[1/10]: adding sasl mappings to the directory

...

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

...

Done configuring the web interface (httpd).

Applying LDAP updates

Restarting the directory server

Restarting the KDC

Sample zone file for bind has been created in /tmp/sample.zone.pUfcGp.db

Restarting the web server

Setup complete

10. Re s tart the SSH s e rvice to re trie ve the Ke rbe ros principal and to re fre s h the name s e rve r s witch (NSS) configuration file :

[root@server ~]# systemctl start sshd.service

11. Authe nticate to the Ke rbe ros re alm us ing the admin us e r's cre de ntials to e ns ure that the us e r is prope rly configure d and the Ke rbe ros re alm is acce s s ible .

[root@server ~]# kinit admin

Password for admin@EXAMPLE.COM:

12. Te s t the IdM configuration by running a command like ipa user-find. For e xample :

[root@server ~]# ipa user-find admin

---

1 user matched

---

User login: admin

Last name: Administrator

Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide

Ella Deon Ballard Tomáš Čapek Aneta Petrová

Red Hat Enterprise Linux 7 Linux Domain Identity,

Authentication, and Policy Guide

Managing Identity and Authorization Policies for Linux-Based

Infrastructures

Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide

Managing Identity and Authorization Policies for Linux-Based Infrastructures

Keywords

1. FreeIPA. 2. Identity Management. 3. IdM. 4. IPA.

Abstract

Table of Contents

Chapter 1. Introduction to Identity Management

1.1. IdM v. LDAP: A More Focused T ype of Service

1.1.1. Defining a T rue Linux Domain

1.1.2. Cont rast ing Ident it y Management wit h a St andard LDAP Direct ory

1.2. Bringing Linux Services T oget her

1.2.1. Aut hent icat ion: Kerberos KDC

NOTE

1.2.2. Dat a St orage: 389 Direct ory Server

1.2.3. Aut hent icat ion: Dogt ag Cert ificat e Syst em

Note

1.2.4. Server/Client Discovery: DNS

NOTE

1.2.5. Management : SSSD

1.2.6. Management : NT P

1.3. Relat ionships Bet ween Servers and Client s

1.3.1. About IdM Servers and Replicas

NOTE

TIP

1.3.2. About IdM Client s

1.4. Addit ional Resources

⁠Part I. Installing Identity Management Servers and

Services

Chapter 2. Prerequisites for Installation

2.1. Support ed Server Plat forms

2.2. Hardware Recommendat ions

TIP

2.3. Soft ware Requirement s

Important

2.4. Syst em Prerequisit es

2.4.1. DNS Records

NOTE

2.4.2. Host name and IP Address Requirement s

IMPORTANT

NOTE

2.4.3. Direct ory Server

2.4.4. Syst em Files

2.4.5. Syst em Port s

Note

2.4.6. NT P

2.4.7. NSCD

Chapter 3. Installing an IdM Server

3.1. Inst alling t he IdM Server Packages

3.2. About ipa-server-inst all

NOTE

IMPORTANT

3.3. Example: Running t he Script Int eract ively and Silent ly

3.3.1. Basic Int eract ive Inst allat ion